Comments 44
UFO landed and left these words here
По своему опыту могу сказать, что чем крупнее компания тем хуже будет собеседование. Не правило, но корреляция прослеживается.
UFO landed and left these words here
В реальности за последние два года я собеседовал более 9000 инженеров
– опечатка. В оригинальной статье речь о 900 собеседований. Сразу бросилось в глаза своей нереальностью.
То есть 900 собеседований за 2 года это реалистично?
2 года это 365х2=730 дней, то есть примерно 1 собеседование в день, если человек в своей жизни вообще не имеет выходных.
В реальности же в 2016 году (нагуглил) было 247 рабочих дней. То есть 900 собеседований за 494 дня, то есть почти по 2 собеседования каждый рабочий день.

Это ж рекрутинговое агентство или что-то подобное, собеседования — их основная работа.

Всё равно как-то нереально, на одного специалиста по 2 соискателя в день.
Судя по ФБ — компания «Создана в Май 2015 г.», то есть это не может быть компания с 10к сотрудников, но даже если допустить что там 30 таких специалистов сидит, то это уже 60 инженеров/день.

Испытательный срок — крайне плохая идея, если в начале надо уволиться из текущей компании, продать дом, и переехать на другой континент.
Я, например, стараюсь заворачивать кандидата при малейшем намеке на то, что он может не пройти.

не боитесь зашкаливающего % ложноотрицательных результатов?
А по факту он работает. ИС позволяет отсечь людей с несовпадением по ценностям. Это важнее, чем недостаток хард скиллов. К сожалению, выявлять ценности человека на собесе почти никто не умеет (есть много тех, кто думает, что умеет).

Испытательный срок 6 месяцев, который в Австралии прям на законодательном уровне, никто не отменял.

Бывает испытательный срок на нормальных условиях. Например, оклад один и тот же, но премии только после успешного прохождения.
Исправьте заголовок!
Я надеялся прочитать хоть что-то интересное, новое и важное, а как только дочитал до:
Нет единого набора навыков, которые определяют хорошего программиста. Наоборот, существует целый океан разнообразных наборов навыков. Никакой инженер не может быть силён сразу во всех областях.

— сразу стало ТОЧНО понятно, что реально это 100500 по счёту статья, «Как собеседовать программистов».
Почему на всех технических ресурсах есть подобного рода статьи, и только про программистов? Только программисты везде работают? Или только они проходят собеседования? а остальные получается, прямо сразу на работу идут, мимо отдела кадров.
Вот и я думала, что статья про инженеров (а при собеседовании оных есть свои нюансы), а тут опять… =(
Об одинаковых вопросах для всех кандидатов не согласен в корне. Цель компании — не составить рейтинг (для этого есть спортивное программирование), а найти человека, который будет создавать ценность. И если будет небольшая погрешность, это не страшно.
А вот то, что одинаковые вопросы позволяют геймить систему, это важнее. Потом вопросы начинают передаваться из уст в уста. Я сам был в ситуации интервьювера со списком вопросов, когда пришел человек мгновенно отвечающий на вопросы, и я не мог понять, человек действительно крут, или просто его друг собеседовался ранее. Мне тогда помог именно десяток вопросов, которые я держал в голове, и задавал 2-3 из них в добавок к вопросам их списка.
PS некоторые компании вообще устраивают письменное групповое тестирование для джуниоров, и там выигрывают люди со свежим опытом списывания и хорошим зрением.

Все зависит от количества кандидатов. Если есть хотя бы три кандидата на место, а интервьюеров несколько — одинаковые вопросы позволяют проще прийти к общему решению о выборе конкретного кандидата.

Ситуация описанная в комментарии хорошо решится, если критерий крайне простой — каждый ответ вырождается в + или — в отчете. Такой критерий отлично зайдет при наборе формошлепов и знатоков конкретного набора фреймворков. А вот даже для набора перспективных трейни я бы так не делал.

При выборе человека, которому придется создавать что-то новое (таких принято называть инженерами), важнее ход мысли, а не конечный ответ. Сравнить ход мысли даже на одинаковых вопросах не так то просто.

PS: количество да, чем больше кандидатов, тем скорее пойдет народная молва о вопросах
Глубоко задумался после фрагмента статьи про «пугающий вопрос». Потом попытался быстро придумать решение задачи с гистограммой. Дальнейшая цепочка мыслей привела меня к мысли, что независимо от того, хорошо это или плохо, сильный программист сегодня — это тот, который умеет быстро находить (гуглить), обрабатывать и запоминать (хотя даже запоминать уже не так нужно) информацию. Конечно, вы скажете, что новичок без какого-либо опыта хуже справится с построением архитектуры хоть сколько-либо сложного приложения с нуля, и, наверное, будете правы. Но, во-первых, архитектурой занимаются архитекторы, это все же отдельная профессия, а во-вторых, значительная часть архитектур уже реализована и описана. Причем, взять готовое решение и немного подточить его для своих нужд выходит очевидно быстрее, вполне вероятно надежнее и скорее всего дешевле для бизнеса, чем велосипедить что-то свое. Я говорю о профессии в целом, конечно, есть и исследовательская работа и потребность в ультрапроизводительности в определенных областях, но субъективно мне кажется, что подавляющее большинство программистов сегодня в первую очередь лезут в интернет за документаций, примерами, обзорами и прочим по любой задаче, которую они решают. И в зависимости от умения искать и переваривать эту информацию они и разделяются на хороших программистов и плохих. Но это все мое личное мнение.
То, что пригодится в течение года и больше — учить серьезно. Случайные задачи\разовые интеграции решать гуглежкой\примерами\обзорами.
Всё таки опыт важен, решение более-менее сложной задачи (комплексной) вы вряд ли найдёте в интернете. Да, найдёте описание эффективных алгоритмов, библиотек и систем, решающих конкретные простые задачи… А вот когда надо совместить несколько алгоритмов, несколько специализированных систем, когда нужно отойти чуть в сторону от стандартов, вот тут и начинается веселуха, о которой ни чего не написано в инете и вот тут и будет заметна разница между опытным и неопытным программистом…

Читаю: Мы собеседуем инженеров, ничего не зная об их биографии, а затем смотрим, как они проявляют себя в разных крупнейших IT-компаниях. На мой взгляд, это самая лучшая проверка эффективности интервью.
То есть, на взгляд автора, лучший рекрутинг:


  1. Не знать кандидата вообще
  2. Отправить сразу в крупные компании с серьёзными проектами
  3. Посмотреть, что получилось
  4. ?????
  5. Получить премию!
Между первым и вторым пунктом есть еще собеседование. Автор пытается сказать, что они не придают значения резюме, делая упор на интервью. В итоге фраза «смотрим, как они проявляют себя в разных крупнейших IT-компаниях» выглядит как получение фидбека и подтверждение/опровержение примененных техник на собеседовании.
Что бы собеседовать программистов, нужно думать как программист… думаю дальше не стоит продолжать… Статья о чем?
> Логика такая: чтобы убедиться, что кандидат успешно выполнит работу в будущем, просто посмотрим, что он делал в прошлом.

А почему нельзя просто описать как можно более подробно будущие задачи и спросить у человека, справится он или нет?
Вот кстати да, на многих собеседованиях расспрашивают про ООП, паттерны, SVN и прочие крутые фичи, которые в их компании не используются, и мало кто рассказывает о планах на будущее. Было бы куда проще, если бы сразу спрашивали: «Чувак, нам надо говносайтики клепать один за другим, не заморачиваясь с качеством — ты справишься?»

Честно говоря, когда мне приходилось собеседовать айтишников, я тоже спрашивал всякий бред. Потому что я не HR и когда меня отрывали от работы, мол: «Там мальчик пришел, пойди позадавай ему вопросы», я вопросы выдумывал по пути в переговорку и в не самом лучшем настроении. Мог бы упростить себе жизнь, если бы честно спрашивал: «Дружище, ты согласен чихать в пыльные тазики за те деньги, что ты просишь, без всякой надежды на карьерный рост?»
Хотелось бы, чтобы кто-то из поставивших минус все же ответил на вопрос (ведь вы ответ, видимо, знаете?). Потому что мне это действительно интересно — зачем люди тратят время на многочасовые собеседования, если можно просто спросить и получить заведомо более достоверный результат? Более достоверный, чем даже оценка по результатам испытательного срока в несколько месяцев. Здесь есть какие-то нетривиальные факторы, понятные только профессиональным HR'ам, или же это просто сложившийся исторически карго-культ?
Никто и не говорит о том, что человек оценит свои навыки абсолютно точно. Но это будет в среднем заведомо более точная оценка, чем оценка любого собеседующего. С любым количеством тестов и проверочных заданий. Кроме того, человек ведь не будет отвечать просто «да» или «нет», ответ всегда будет в виде: «вот с такими задачами я постоянно работал, так что справлюсь легко, с задачами вида Y работал, но немного, могут быть проблемы, а к решению Z у меня просто душа не лежит».
Люди обманывают, когда им это выгодно. Какая выгода в том, чтобы вылететь через месяц с волчьим билетом?
В любом случае, если требуется знать, насколько человек порядочен, то вопросы по знанию тех или иных технологий тут нерелевантны.

Как какая выгода? Зарплата за месяц плюс компенсация за увольнение.

Человек ставит крест на своей карьере за месячную зарплату (окей, +компенсация). Не вижу здесь никакой выгоды. В любом случае, еще раз — если вы хотите отсеять непорядочных людей, то чем вам помогут технические вопросы?
Если вышеприведенный вариант дополнить в виде: «убедиться в порядочности и спросить, справится или нет», то так нормально?
Можно даже еще дополнить: «убедиться в порядочности, и в том, что человек не совсем уж полный дебил» (что и значительно снизит эффект Даннинга-Крюгера).

Почему вы думаете что у него есть какая-то карьера? Если верить всем полностью на слово — то может пролезть случайный человек, который решил месяц побыть программистом, а потом вернуться в дворники. Затем и нужны технические вопросы, чтобы отделить тех у кого есть карьера от случайных прохожих.

> Затем и нужны технические вопросы, чтобы отделить тех у кого есть карьера от случайных прохожих.

Для этого достаточно десятиминутной беседы в любом формате. Вопрос о том, сможет ли человек справиться с конкретными задачами или нет, такую беседу предполагает в любом случае.

> Если верить всем полностью на слово — то может пролезть случайный человек, который решил месяц побыть программистом, а потом вернуться в дворники.

Отсеивание таких людей не является задачей технического интервью в принципе. У вас, в конце концов, в резюме будет указано, что человек все жизнь работал дворником. Вы его, скорее всего, и на беседу не пригласите. А если пригласите — значит, вас, в принципе, дворник устраивает.

Тут как-то проскакивал переводной пост о "программисте", который учился в специальной летней школе проходить собеседования на программиста.


Вы уверены, что смогли бы распознать такого человека в обычной беседе?

> Вы уверены, что смогли бы распознать такого человека в обычной беседе?

Так вам и тесты не помогут его распознать. Смотрите, штука в том, что вы пытаетесь сравнивать два варианта узнать реальный уровень кандидата: либо спросить, либо протестировать/пособеседовать часиков эдак с десять. При этом первый вариант вроде как плох, потому что вдруг соврут, или еще там чего. Но проблема в том, что первый вариант — он на самом деле единственный, и если вам соврали — нету у вас никакого способа узнать, подходит вам кандидат или нет, кроме как с ним проработав хотя бы с месяц-другой. Все, что вы сможете понять в результате тестов — то, что человек не совсем идиот (или совсем), но это будет понятно и так, гораздо быстрее и без тестов.

Плюс к тому — здесь же мы говорим о статистических оценках, по-этому приводить крайние примеры смысла нет.
Задавая слишком сложные вопросы и оценивая исключительно техническую составляющую, есть риск подобрать сотрудника, который действительно может все и очень крутой профессионал, но при этом своенравный, нарциссичный, несговорчивый, самодур и далее по списку. В результате получим классного специалиста, обклеенного сертификатами со всех сторон, но выхлопа с него не получим. На любое ваше задание у него есть свое мнение, потому:
1. Я не буду это делать — так делать нельзя! И так тоже.
2. Так просто, как вы хотите, не получится — надо усложнить эту задачу, применив все существующие практики в области безопасности.
3. Это не моя зона ответственности — я учился 10 лет не для того, чтобы заниматься непрофильным трудом.
4. У меня нет времени заниматься этой ерундой, поручите ее кому-то другому.
5. У меня нет времени объяснять, идите в жопу гугл.
Именно по этому в таких конторах как *ндэкс. *угль и тд. после того как узнаю что вас ждет 6...7… возможно 5 собесов после чего мы предложим вам офер возникает желание ответить вы #$#нулись??? идите в жопу постратить 8 часов времени на всякую мутотень =) С учетом того что офер будет с той же суммой что и в самой неизвестной конторе( а за частую и даже хуже).

З.Ы. Если вы ищете кандидата в свою команду то и собес должен делать тимлид — сотрудник нужен ему а не HR, Директору и не тете Вале. А если Тимлид «очччень занят»" то гоните его в шею — он не справляется с работой =)
Мне на интервью важно понять может ли человек думать. С этим считаю типовые задачи не слишком помогают. А вот например задания на рефакторинг куска кода уже другое дело. Это менее стрессово для кандидатов, любой сможет хоть что-то да улушить в коде. Можно подобрать такой код что его будет строк 10-15 всего, но при этом он будет напичкан всякими проблемами, в том числе не слишком явными. И вот лучшие кандидаты не просто улучшают код, но пытаются догадаться каково назначение код (что он делает, часть какой системы является), и это ведет к еще более продуктивной беседе.
следующий степ — такой кусок высылать зарание и просить кодревью на почту.
Разумеется нет. Код подбирается выразительный и не объемный, то есть такой чтобы управится в час максимум при очной встрече или удаленном общении с код шарингом, но скорее пол часа максимум. Интересует ведь именно как человек рассуждает, а не как кто-то там где-то пишет ответы.
Only those users with full accounts are able to leave comments. Log in, please.