Здравствуйте, avpavlov, Вы писали: __>>и проведение собеседования это просто часто повод поболтать с кем-то, познакомиться поближе A>Мне только остаётся спросить — сколько собеседований ты в жизни провёл? Или ты теоретически рассуждаешь?
да штук 10-то провел. но причем тут я? у меня свои подходы, я сужу больше чисто по психологии и по увиденному в других компаниях когда собеседовали меня. иногда было видно, что я им нафиг не нужен, им просто охота поболтать.
D>>+ join-groupby-having прораммисту с 5-и летним опытом
_>Так не сделал же. Тривиальная вещь, но очень хорошо отсеивает соискателей.
Таки да, если цель уменьшить поток — это способ.
Не пройдут вчерашние студенты и опытные спецы, понимающие, что знание тех. деталей — это последнее, что определяет подходит ли человек на позицию.
Нет желания выполнять тестовое задание -> нет сосредоточенности -> ошибки в результате.
Здравствуйте, JazzzMaster, Вы писали:
JM>Здравствуйте, HolyNick, Вы писали:
HN>>Просто нужно стараться не ходить по собеседованиям с таким настроением.
JM>Да почему? Ходить по собеседованиями полезно просто для того, чтобы потренировать свои коммуникативные навыки
еще помогает побыть некоторое время нанимающим самому —
я вот например для себя сделал вывод что важно не только быть профессионалом ,
но и уметь производить некоторое положительное впечатление лично.
например что важно для меня —
— не одевать рваные рубашки с капюшоном
— ходить на собеседование трезвым
— не говорить собеседующему что он баран и не знает таких элементарных вещей
(и вообще вести себя вежливее)
__>и проведение собеседования это просто часто повод поболтать с кем-то, познакомиться поближе, с возможно интересным человеком, далеко ведь не случайным — он проходит предварит отбор по резюме. это ж не гопник с остановки.
Пару-тройку лет назад, в самый разгар кризиса в срочном порядке набирал я людей на проект. Это было время, когда конторы сливали неликвид, в том числе кадровый, а профи сидели тихонько по своим хлебным местам и посмеивались.
Команду мы таки набрали, и команду хорошую. Но три четверти кандидатов, включая людей с длительным опытом работы, в профессиональном плане были такими, что лучше бы я гопников с остановки собеседовал. Жаль потерянного времени.
С другой стороны, три десятка собеседований за три недели и сотня просмотренных резюме прибавили мне здорового цинизма.
Здравствуйте, z3d, Вы писали:
z3d>Коротко напишу, как я на половину провалил собеседование этой весной. Может кому и интересно будет. Хотя в целом история ни о чем, мастодонтам будет неинтересно.
z3d>Я типичный средний программер на .net, веб-разработка, БД, сишарп. В основном внутренния автоматизация разных крупных компаний. Опыт больше 5 лет. Немного ленив. Опыт, хочу я того или нет, но поднакопился маленько.
z3d>На старом месте задолбали маразмы, пошел пособеседоваться. Вдруг, думаю, найду компанию мечты. Офис у новой компании был рядом с домом, так что это уже пол мечты. Дали тестовое задание. Сделал его. Обещал сделать за 2 дня, реально сделал за 3, правда в те дни у меня были сторонние отвлекающие факторы, но я про них не сообщал, не оправдывался, думаю собеседователи много отмазок слышали от кандидатов, проще в такой ситуации промолчать. Решение не усложнял и не делал универсальным, наоборот делал по минимуму, так как обратного не просили. Поэтому вышло все просто, как потом сказал собеседовавший меня архитектор: "По нашему тестовому заданию конечно ничего не оценишь".
z3d>Потом задавали вопросы про паттерны и популярные сторонние библиотеки. К собеседованию я совсем не готовился, и безработица не поджимала, поэтому на большинство вопросов честно отвечал: "С этим не работал, слышал, читал только для ознакомления". Как всегда попросили написать на бумажке синглтон, ну и я не вчера родился, написал конечно. Хотя отсутствие творческого подхода и штампы на собеседовании меня разочаровали маленько. Людей конечно понять можно, кучу народа надо отсмотреть. Попросили решить задачку на SQL с чем-то из серии join-groupby-having, я не решил и не сильно пытался напрягаться. Ощутил, что своим легким пофигизмом разочаровал немного собеседовавших. Хотя мужики в целом нормальные.
z3d>Было правда ощущение, что я немного раздражал менеджера. Это меня в свою очередь немного напрягло.
z3d>По итогам собеседования предложили денег меньше, чем я просил и меньше, чем имел на старом месте. Я отказался и остался на старом месте разгребать наши местные маразмы. Работу мечты не нашел. Конечно пытаюсь самообразовываться в свободное время, но двигаюсь немного в сторону от корпоративной автоматизации.
Здравствуйте, avpavlov, Вы писали:
D>>... и опытные спецы, понимающие, что знание тех. деталей — это последнее, что определяет подходит ли человек на позицию.
A>Опытные спецы неспособные ответить на простейшие вопросы? А в чём тогда заключается их опыт?
Когда последний раз искал работу, словил себя на том, что я не могу быстро (за пять минут) решить несложные задачки по SQL, вроде "Есть таблица с одной колонкой с целыми числами в ней. Выведите все значения начал и концов всех возможных непрерывных интервалов." (конкретный пример заданной мне задачи переформулированный своими словами по памяти).
Пришлось потратить два дня на решение задач по SQL. Нужный скилл по прохождению собеседований вернулся.
Некоторые программисты даже ручкой шариковой разучились писать, но это не показатель их безграмотности. Просто практики в нужной базовой области долго не было — на работе другие задачи совсем решаются, а не те, что на собеседованиях спрашивают.
Здравствуйте, avpavlov, Вы писали:
U>>В умении решать реальные задачи. A>Если у спецов проблемы с простейшими вопросами, то как они решают задачи?
Ключевыми навыками разработчика являются:
1) Способность понять реальную задачу, т.е. умение понять что надо делать и зачем делать.
2) Способность понять какие ситуации надо обрабатывать специальным образом
3) Способность написать принципиальный алгоритм обработки ситуаций.
Знания о том как принципиальный алгоритм положить на конкретную технологию являются второстепенными, т.к. даже если разработчик чего-то не знает, то это элементарно гуглится.
Здравствуйте, Undying, Вы писали:
U>Ключевыми навыками разработчика являются:
U>1) Способность понять реальную задачу, т.е. умение понять что надо делать и зачем делать. U>2) Способность понять какие ситуации надо обрабатывать специальным образом U>3) Способность написать принципиальный алгоритм обработки ситуаций.
U>Знания о том как принципиальный алгоритм положить на конкретную технологию являются второстепенными, т.к. даже если разработчик чего-то не знает, то это элементарно гуглится.
Твое утверждение справедливо лишь отчасти.
Если разработчик, что называется, "в теме", но подзабыл (давно не использовал), то позабытое гуглится легко.
Но если задача совершенно незнакома, то гугл мало поможет.
Пример из жизни, наблюдал лично.
Моему коллеге потребовалось построить триангуляцию Делоне. Он гордо вскинул голову, мол, фигня, алгоритм 100500 раз описан в книжках, взял "Вычислительную геометрию" Ласло и реализовал предложенный там алгоритм.
Вот только там был описан академический алгоритм, который работает, но медленно и на синтетических данных.
А на реальных данных валится
Таких примеров у каждого найдется не по одному.
К чему это я...
Мой коллега был достаточно опытным разработчиком.
Однако, Гугл в данном случае ни разу не помощник.
Если бы был под рукой человек, который "в теме", который объяснил бы по-быстрому, почему этот алгоритм плох и подсунул бы другой действующий алгоритм, то мой коллега не потратил бы уйму времени.
_____________________
С уважением,
Stanislav V. Zudin
SD>Хорошо решают. SD>Ответы на все простейшие вопросы есть в интернете -> 5 минут гугла — достаточно.
Ну т.е. спец это человек, умеющий читать и знающий про гугл == выпускник начальной школы?
SD>А вот с более-менее сложной задачей всё совсем не так.
Лёгкие решать западло, трудные на собеседовании решать тоже как-то мало кто рвётся. Получается остаётся только верить резюме и хорошо подвешенному языку?
U>2) Способность понять какие ситуации надо обрабатывать специальным образом
Вот этого без реального опыта никак не достичь. А реальный опыт откладывается в голове реальными знаниями
U>Знания о том как принципиальный алгоритм положить на конкретную технологию являются второстепенными, т.к. даже если разработчик чего-то не знает, то это элементарно гуглится.
Детский сад какой-то. Мы про математика говорим или программиста? Это для математиков всё заканчивается, когда они доказали принципиальную возможность чего-либо, а вот программисту нужно положить это на конкретную технологию, и это ни хрена не является второстепенным.
U>то это элементарно гуглится.
Обычно такие самоуверенные "спецы" гуглят уже после того, как говно случилось (см. п2 из своей программной речи). И хорошо если оно случилось у тестировщиков, а не на продакшн.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Твое утверждение справедливо лишь отчасти. SVZ>Если разработчик, что называется, "в теме", но подзабыл (давно не использовал), то позабытое гуглится легко. SVZ>Но если задача совершенно незнакома, то гугл мало поможет.
Проблема в том, что алгоритмов существует почти бесконечное множество. А конкретный человек имеет опыт работы только с очень ограниченным перечнем алгоритмов. Соответственно вероятность найти на рынке человека, который имеет опыт работы именно с теми алгоритмами, которые вам нужны, очень низка, а если задачи у вас не особо стандартные, то и вовсе стремится к нулю.
Но соглашусь, если в силу специфики реальных задач нужно, к примеру, постоянно работать со сложной математикой, то желательно иметь в команде человека с хорошим математическим образованием. Нескольких не особо нужно, а одного весьма желательно. И этот человек либо будет непосредственно реализовывать нужные алгоритмы, либо консультировать других разработчиков. Впрочем это вовсе не гарантирует, что этого человека в вузе обучали реально применениемым алгоритмам, а не какой-нибудь академической хрени.
Здравствуйте, avpavlov, Вы писали:
A>Лёгкие решать западло, трудные на собеседовании решать тоже как-то мало кто рвётся.
Обдумывание мало-мальски сложной задачи занимает несколько дней (хоть и проходит параллельно с решением других задач). Поэтому в формате собеседования ничего сложного решить невозможно в принципе.
A>Получается остаётся только верить резюме и хорошо подвешенному языку?
А побеседовать о предыдущем опыте человека не судьба? Нужен вам, к примеру, разработчик для написания сложных алгоритмов, так спросите у человека какие сложные алгоритмы он реализовывал и по какому-нибудь из них детально побеседуйте. Такой метод говорит о человеке намного больше нежели тестирование или ответы на примитивные вопросы на собеседовании.
U>А побеседовать о предыдущем опыте человека не судьба? Нужен вам, к примеру, разработчик для написания сложных алгоритмов, так спросите у человека какие сложные алгоритмы он реализовывал и по какому-нибудь из них детально побеседуйте. Такой метод говорит о человеке намного больше нежели тестирование или ответы на примитивные вопросы на собеседовании.
Во-первых, непонятно, почему ты думаешь что у нас всё сводится к примитивным вопросам? Примитивные вопросы это как способ быстро понять есть реальный опыт или нет.
Во-вторых (а может и в-первых) я видал много умных людей, которые теряются/сковываются на собеседовании и не могут свободно беседовать. Решение простых задач позволяет им освоиться и почуствовать уверенность.
Здравствуйте, avpavlov, Вы писали:
A>Во-первых, непонятно, почему ты думаешь что у нас всё сводится к примитивным вопросам? Примитивные вопросы это как способ быстро понять есть реальный опыт или нет.
Потому что сложную задачу решить в формате собеседования невозможно. Можно лишь вспомнить решение сложной задачи, которую человек решал ранее.
