Непрограммирующие программисты


Джефф Атвуд несколько дней назад написал еще одну статью про непрограммирующих программистов.
В ней он пишет, что 3 года назад он вдруг осознал, что многие люди, приходящие на собеседование на должность программиста, не могут написать даже простейшей программы. Также он пишет о том, как это понимание изменило его подход к интервьюированию программистов - теперь он всегда просит писать код, даже самый простейший, чтобы сразу отсеять тех, кто совсем не может ничего написать. Причем он делает это еще до того, как приглашает людей на личное интервью - по телефону или через интернет.


Интересно, что те же самые мысли у меня были еще лет 5 назад, когда я был главным программистом и руководил отделом программирования в геймдевелоперской компании. Мы тогда начали активно набирать народ. Так активно, что метод рекоммендации уже не срабатывал и пришлось размещать объявления на сайтах поиска работы и проводить интервью - очень много интервью. Работа у программистов в геймдеве очень специфическая, требует постоянного развития и отличного умения программировать, поэтому мало кто на эту должность подходит. К тому же зарплаты в геймдеве были гораздо ниже, чем по отрасли в целом. В итоге, по статистике, я проводил 10-20 личных собеседований, чтобы взять 1 человека. А еще больше отсеивалось на уровне резюме и телефонных звонков или email-ов. Наверняка и кого-то из отличных программистов не взяли, но неважно.
Зато те, кого в итоге брали - это были бриллианты. Готов лично поручиться практически за каждого, кто прошел мое собеседование и испытательный срок, хотя были и те, кто в итоге не выдерживал гонки геймдев-разработки и уходил.
Как же я проводил собеседования?


Когда я начал звать народ на собеседования, то быстро понял, что в простом разговоре невозможно понять уровень программиста. Есть люди, у которых на сложные вопросы есть ответы, которые знают неплохо теорию, но на практике делают все медленно, а то и вообще не могут ничего сделать.
К тому же я был увлечен Джоэлем Сполски и сильное влияние оказала его фраза “Лучше не нанять 10 хороших программистов, чем нанять 1 плохого”. В итоге весь процесс собеседований был направлен именно на то, чтобы не взять плохих программистов.
Сначала я критически читал резюме. Тут я применял небольшой трюк: если человек был без опыта работы или студент, то я часто звал его на собеседование, так как слишком часты бриллианты среди студентов, к тому же переучивать его не надо и банально - платить ему можно меньше. Если же человек был с опытом работы, то я просил его расписать подробнее чем он занимался и чего достиг за предыдущие годы. Если ничего внятного человек написать не может - я его не приглашал на собеседование, ибо, если программист не достиг ничего за несколько лет, то почему он должен измениться?
В конце я также применял несколько раз телефонные интервью и это помогло отсеять несколько кандидатов. Но я себя неуютно чувствовал, разговаривая по телефону, поэтому не практиковал это очень часто.


С теми, кто попал на личное интервью, я сначала беседовал на личные темы, про старую работу, про прочитанные профессиональные книги, про лучший проект или код, который они написали и т.п. - это дает отличное представление о личности человека. Эта вступительная часть собеседования была направлена на то, чтобы человека раскрепостить. Это был не допрос - это было общение. Я водил претендента по офису, показывал наши рекламные ролики и игры, показывал, как мы работаем и чем занимаемся. Узнавал, что человеку интересно, а что нет. Мы никогда не сидели, разделенные столом, а все собеседования проходили в неформальной обстановке - на стульях в большой комнате у доски.
Потом я давал претенденту компьютер с открытым блокнотом и просил написать несколько простейших программ, типа “напишите функцию конвертирования int в строку” и “есть 100000 объектов в игре. для объекта X напишите функцию поиска 10 ближайших объектов в 3D мире. предложите будущие методы оптимизации этой функции.”. Мне не нужна была работающая версия всех функций и правильность синтаксиса. Мне нужно было видеть, как человек думает и как быстро может соображать.
Удивительно, но чуть ли не 90% претендентов проваливали этот тест совершенно. И их код был настолько неработоспособен и страшен, что было очевидно - мы не сработаемся. На этом их интервью заканчивалось.
Остальные делали что-то (а кто-то делал всё - и это были лучшие программисты в итоге) и получали задание на дом.
Да, после всего этого я давал еще и серьезное задание на дом, на которое разрешалось потратить вплоть до недели (чтобы проверить, я сам выполнил все эти задания. У меня ушло на каждое от 4 до 12 часов). Задания были типа “Написать игру “змейка”". Или “сделать физическую симуляцию колодца, в который кидают шары в 2d или 3d”.
Если программист прошел такое интервью и сделал домашнее задание, то он безусловно умеет программировать и учиться. Такие брались на испытательный срок.
На испытательном сроке они уже проверялись на реальных проектах и тут уже даже самый сильный программист может не выдержать пресса геймдева, что и случалось пару раз.
Еще интересное наблюдение - обычно очень сложно отказать человеку по результатам домашнего тестового задания, если он его выполнил, но не очень хорошо. Например, код некрасивый или неоптимально сделано, или глючит и падает. Кажется, что сделал ведь человек - надо брать. Но в итоге каждый раз оказывалось, что и в работе человек такой же, как и в тестовом задании. Я через себя тогда так и не смог перешагнуть и не помню, чтобы отказывал кому-то, кто выполнил тестовое задание, даже если оно мне не нравилось.
Сейчас бы я был жестче и простого плохого выполнения тестового задания было бы уже недостаточно.


Вот такой вот подход у меня был.
Конечно, кому-то он может показаться слишком жестким. Далеко не каждый программист может за час прямо на собеседовании написать требуемый код или потратить дома несколько часов\дней на написание тестового задания. Но в геймдеве нужны были именно такие, кто может и первое и второе. И я считаю, что именно такой метод интервьюирования и принцип “Лучше не нанять 10 хороших программистов, чем нанять 1 плохого” - позволили нам в свое время создать отличную команду, которая была готова к подвигам и совершала их.
А еще было очень приятно потом слышать от тех, кто проходил моё интервью, что они меня помнят и отзываются об интервью очень хорошо, даже если не прошли его. Оставить хорошее впечатление и не обидеть человека - это очень важно для интервьюера.


Похожие записи:
Православный Геймдев во всей его красе
Книги + программисты = деньги
Shu-ha-ri для программистов
25 самых опасных программистских ошибок


31 комментариев к Непрограммирующие программисты

  • >> “есть 100000 объектов в игре. для объекта X напишите функцию поиска 10 ближайших объектов в 3D мире. предложите будущие методы оптимизации этой функции.”
    Я попал в те самые 90%, ну не помню я по какой формуле измеряется расстояние между точками. Зато знаю где посмотреть.

    • Во-первых, любые советы и объяснения я всегда готов давать.
      Во-вторых, если хороший программист не знает формулы, то он хотя бы вызовет getDistance(p1, p2), но не будет ее реализовывать, ибо для алгоритма это совершенно неважно.
      В-третьих, если программист не может даже расстояние между двумя точками посчитать, то что ему делать в геймдеве? :)

      • Владимир Степанов

        По задаче с расчетами о ближайших объектах я бы затупил, и стал бы думать, как реализовать R-Tree деревья, а о решении “в лоб” даже не подумал бы…

        • Владимир Степанов

          это к тому, что приходя устраиваться на работу ожидаешь постановки повседневных задач, и полный перебор для нахождения ближайшей точки для 10000 объектов - это то, что называется неоптимальным решением. С другой стороны R-Tree - большинство (я в том числе) лишь поверхностно представляет как оно работает. И если такое задание является тестовым, то это будет сигналом - “тут требуются яйцелобые, пойду ка я поищу работу попроще”.

          • это к тому, что приходя устраиваться на работу ожидаешь постановки повседневных задач

            Такие задачи, как эта - это повседневные задачи в геймдеве. Поэтому я и хочу видеть, как будет думать про нее претендент.
            Деревья и т.п. - это отлично. Можно даже схематически набросать, как это будет выглядеть, без детальной реализации, но это неважно. Важно понять как человек подходит к задаче. Видит ли потом проблемы при обсуждении, находит ли решения или соглашается ли с моими. В общем - диалог происходит.

            С другой стороны R-Tree - большинство (я в том числе) лишь поверхностно представляет как оно работает. И если такое задание является тестовым, то это будет сигналом - “тут требуются яйцелобые, пойду ка я поищу работу попроще”.

            Опять же - про R-Tree вы сами заговорили. Этого совершенно не требуется в задании. И если человек начинает так сильно усложнять сразу, то это тоже ему дополнительный минус, если вместо простейших решений он сразу предлагает сложнейшие.

            • Владимир Степанов

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

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

              Вообще приведенным примером я пытался показать, что сторон две: интервьюер и кандидат на должность сотрудника компании. Когда дается тестовое задание, то предполагается, что человек сам на себя возьмет часть оценки - насколько он подходит для данной работы. Отсюда меньшее количество недовольных проведенных собеседованием, поскольку резюме в форме отказа в приеме на работу послужит лишь дополнительным подтверждением их собственного мнения по качеству проделанной работы.

              Отсюда же тяжесть принятия решения по тому, подходит ли человек при плохо выполненном тестовом задании. Особенно если речь идет по найму студентов, которые просто не могут иметь достаточного объема практики, что в программинге - является основоопределяющим фактором. Кстати, вопрос к Вам, наверно из области статистики: много ли было сформировавшихся бриллиантов из числа студентов в первый год-полтора работы? Иными словами, когда становится понятно, что человек - дока? Какие признаки - самостоятельность мышления, самопостановка подзадач, успешная коммуникация с заказчиками и членами команды, или что другое? Хотя бы только на примере геймдева?

              • Кстати, вопрос к Вам, наверно из области статистики: много ли было сформировавшихся бриллиантов из числа студентов в первый год-полтора работы? Иными словами, когда становится понятно, что человек - дока? Какие признаки - самостоятельность мышления, самопостановка подзадач, успешная коммуникация с заказчиками и членами команды, или что другое? Хотя бы только на примере геймдева?

                Обычно понятно уже в первые же месяц-два. И признаки все верно перечислены: самостоятельность мышления, самопостановка подзадач, успешная коммуникация с членами команды. Основной критерий - может ли человек взять и сделать. Не как кодер, которому все распиши и объясни. А как программист - взял на уровне юзер стори, сам проработал и сделал.

            • kolas

              Вы говорите, что : “дополнительный минус, если вместо простейших решений он сразу предлагает сложнейшие.” По вашему, если программист предлагает простейшее решение (np-полное), но заведомо провальное, это лучше? Да уважающий себя программист перестанет с Вами разговаривать после такого.

              Без обид :)

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

  • истину глаголешь :)

    особенно напрягают всякие HR-девочки которые проводят превичное интервью нифига не понимая в требованиях по вакансии. поубивал бы.

    • Они полезны бывают в том плане, что проверяют всякое, что собеседующий программист забудет проверить - типа не псих ли, не затевает ли чего плохого и т.п.
      А если они чисто для галочки собеседуют, то да - напрягают.

  • Есть мнение, что если на проекте требуется геороизм от разработчиков - то оного явно не хватает у ПМа/менеджера/руководителя.

    Я понимаю, что особенности отрасли - и тем не менее.

  • mikola

    Я одного из этого рассказа не понимаю.
    Почему эти бриллианты вообще шли на зарплаты ниже рыночных, да еще и с испытательным сроком ?
    Такие вот любители садо-мазо ? :-)

    • Во-первых, они еще сами могли не догадываться, что они бриллианты, а другие компании их не могли распознать, так как использовали другой подход к рекрутингу (ведь часто, если нет опыта, то никуда и не возьмут).
      А во-вторых, да - в геймдеве любителей садо-мазо полно :)

      • mikola

        если нет опыта, то никуда и не возьмут

        Если речь о приеме студентов/выпускников, тогда я вообще не понимаю тему поста.
        Ну да, 90 % студентов/выпускников программировать не умеют. Ожидаемо.
        Так они и не программисты еще :-).

        • “Нет опыта” значит не только полное отсутствие опыта, но и “нет опыта в геймдеве”, например.
          Программист может иметь хоть 20 лет опыта работы в НИИ над одной единственной проблемой запуска спутника на орбиту, но значит ли это что у него есть достаточный опыт для разработки игр?

          • mikola

            Тогда снова возвращаюсь к своему первому вопросу :
            Если у программиста ЕСТЬ опыт, зачем ему идти именно в геймдев на зарплаты ниже рыночных, да еще и с испытательным сроком ?

            • Если у программиста ЕСТЬ опыт, зачем ему идти именно в геймдев на зарплаты ниже рыночных, да еще и с испытательным сроком ?

              Это надо у них спрашивать - у каждого свои причины.
              Обычно говорят, что любят игры, что программировать игры - это фан и хотят именно этим заниматься, а не тем, что делают сейчас.
              А испытательный срок - это разве не стандартная практика во всех разработческих фирмах? Что в нем такого странного?

              • mikola

                Обычно говорят, что любят игры, что программировать игры - это фан и хотят именно этим заниматься, а не тем, что делают сейчас.

                Ну то есть Вашей задачей было:
                отобрать из любителей игр тех, кто умеет программировать ?
                Тогда ситуация понятна, но встречается она нечасто.

              • mikola

                А испытательный срок - это разве не стандартная практика во всех разработческих фирмах? Что в нем такого странного?

                В нем самом - ничего. Но вот совместно с зарплатами ниже рыночных он сильно уменьшает количество (и часто качество )желающих испытываться, по моему опыту.

  • Me

    Особенно домашнее задание прикололо. На рынке с дефицитом кадров при зарплатах ныже рыночных такими извратами заниматься антинаучно :) Придётся очёнь долго отмывать бриллианты из Г. И большинство таких бриллиантов придут лишь прокачаться.

    • Особенно домашнее задание прикололо. На рынке с дефицитом кадров при зарплатах ныже рыночных такими извратами заниматься антинаучно :) Придётся очёнь долго отмывать бриллианты из Г. И большинство таких бриллиантов придут лишь прокачаться.

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

  • Юра

    Применение практики Дж. Спольски на практике :)

  • aamonster

    Задачка на 4-12 часов - это имеет смысл, только если претендент очень хочет работать именно у вас. Или если задачка сама по себе интересная.

    • Задачка на 4-12 часов - это имеет смысл, только если претендент очень хочет работать именно у вас. Или если задачка сама по себе интересная.

      Задачки интересные были, бесспорно.
      И потом, зачем нам человек, который не хочет работать у нас? :)

  • whirlwind

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

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

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

      Готов согласиться, проработав пару лет в другой области - :)

  • а я вообще программист самоучка уже как 7 лет и собеседования мне никакие не страшны

  • vaf

    Еще все зависит от того, поддерживаешь ли ты себя. 6 лет назад я отлично программировал логику, для меня не было того, что нельзя было бы сделать, потом я забросил это дело, ушел в службу поддержки (очень не продвинутых пользователей), соответственно интересные задачи, решение которых может затянуть тебя так, что не замечаешь как летит время я решать перестал.
    Сейчас вот нужно для себя написать код, приходится сильно ломать голову.

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>