Когда вы приглашаете программиста для собеседования и выполнения тестового задания, это может оказаться интересным опытом и для вас, и для него. Большинство собеседований заканчивается тем, что менеджер по подбору персонала обещает «оставаться на связи», но иногда соискатель просто попадает в точку. В такие моменты вы обдумываете, не нанять ли его еще до того, как он успеет покинуть здание. Мы в Alconost Translations перевели для вас статью шароварщика Брайана Келли именно о таких удачных случаях.В TimeTrade мы даем программистам тестовое задание, с которым большинство из них должно справиться за 2 часа. Все задание состоит из последовательности небольших задач, каждая сложнее предыдущей. Это позволяет нам оценить производительность программиста, основываясь исключительно на времени выполнения задания: если все решено меньше, чем за час, мы будем довольны. Но если прошло два часа, а первая задача все еще не решена, скорее всего, мы укажем кандидату на дверь.
Но, помимо одного лишь быстрого решения задач, есть еще несколько признаков того, что перед вами действительно потрясающий программист, которому надо немедленно предложить работу прежде, чем он успеет уйти.
1. Он предлагает несколько решений
Недавно я собеседовал программиста, который решил весь набор задач дважды: один раз итеративным способом, второй — рекурсивным. Я сразу же предложил ему работу. Умение находить несколько решений проблемы — навык, который инженерам приходится применять каждый день.
2. Он пишет полную документацию
В прошлом году я собеседовал настолько старательного, усердного и профессионального в своей работе программиста, что он создал полный Javadoc с комментариями к своему коду прежде, чем счел задачу выполненной. Он даже написал полностью автоматизированные unit-тесты и проверил процент покрытия ими кода. Когда я вернулся в комнату по истечении 2 часов, он неистово стучал по клавиатуре, и я было решил, что у него проблемы с выполнением задания, но на самом деле он как раз добавлял HTML-форматирование в свой Javadoc. Именно таких инженеров, которые делают это интуитивно, вы и хотите видеть в своей команде.
3. Он совершенствует задание
Мы специально создаем задания с запрятанными в них мелкими изъянами, исключительно чтобы посмотреть: а) заметит ли их соискатель и б) возьмется ли их исправлять. Это могут быть некорректно использованные кавычки в строках, неправильные имена переменных или что-то в этом же духе. Соискатели, которые рассматривают в рамках задачи весь предоставленный код, — а не только тот, который мы попросили их написать, — будут действовать так же и в работе с реальным продуктом, когда присоединятся к нашей команде.
Готовность инженера указать потенциальному работодателю на проблемы в предоставленном задании показывает, что они считают качество своей работы более важным, чем простое соглашательство с тем, что им говорят. Наймите их — и они, вероятно, будут творить чудеса с вашим продуктом, делая гораздо больше поставленной задачи и внося улучшения туда, где они нужны.
4. Он рефакторит с умом
Большинство соискателей любят добиваться того, чтобы решение заработало, после чего расслабляются и вздыхают с облегчением, удачно все завершив. Это хорошо, но редко этого достаточно, чтобы немедленно получить предложение о найме. Соискатели, которые решают проблему, а затем без передышки берутся рефакторить код, — специалисты совсем другой категории. Если им кажется, что они выбрали не тот алгоритм, они не могут игнорировать мысль, что все могло бы быть гораздо эффективнее. Если в их коде есть небольшой повтор, это сжигает их изнутри. Это соискатели, которые рефакторят, переписывают и улучшают свои решения до тех пор, пока они не станут произведениями искусства.
Впрочем, это палка о двух концах. Если соискатель просто продолжает переписывать, потому что ничто не приносит ему удовлетворения, кроме достижения мифического «совершенства», есть шанс, что это один из тех программистов, которые просто не знают, когда остановиться (как и сдать готовую задачу). Хотя, если они способны тщательно следить за временем, чтобы и решить задачу, и отрефакторить свое решение в срок, — это по-настоящему хороший признак: можно подумать о найме.
5. Все остальные признаки — в его пользу
Бывает, что нужного соискателя выдает множество нетехнических признаков. Другие члены вашей команды отводят вас в сторону со словами «Мы должны нанять эту девушку». Личность соискателя выглядит исключительно подходящей для команды. У него релевантный и свежий опыт в том, чем ему придется заниматься. Вы знаете нескольких людей, которые работали с ним и считают, что он — чудесное дополнение к команде (и сами наняли бы его снова без колебаний). Соискатель в восторге от компании и возможностей, и ему не терпится начать работу.
Если соискатель признан технически годным и все остальные признаки — в его пользу, зачем ждать? Затягивая с решением, вы можете упустить соискателя, которого подберет другой работодатель, умеющий распознавать все те же признаки быстрее, чем вы. Лучше будьте решительней и вручайте джоб оффер быстро, таким образом давая соискателю понять, как сильно компания хочет его заполучить. Это поможет начать отношения с ним с правильной для обеих сторон отправной точки.
Так что в следующий раз, когда в ваше здание войдет потрясающий соискатель, не ждите, что к вам со дня на день наведается кто-то еще получше. Вручите соискателю предложение о найме и приступайте к работе.
С уважением к программистам,
всегда ваши
Alconost Translations
Комментарии (45)
SVVer
14.08.2015 12:09+2Это позволяет нам оценить производительность программиста, основываясь исключительно на времени выполнения задания: если все решено меньше, чем за час, мы будем довольны
А если потом в реальной работе программист решает задачу вот так, за час, а после этого тратит еще три раза по часу, чтобы сделать код не просто рабочим но и правильным/красивым/обобщенным и т.п., вместо того, чтобы потратить сразу два или два с половиной часа и сделать все то же самое? Насколько объективна оценка программиста с позиции такой «производительности»?Cortlendt
14.08.2015 13:43+5Вообще в программировании хороший, надежный и качественный код в незнакомом контексте быстро не пишется. Это аксиома.
Относительно «быстро» писать качественный код можно лишь хорошо владея всем аспектами проекта — бизнес, дизайн, технологии, нефункциональные требования, принятые конвенции, процесс и тп.
А оценивать программиста по скорости работы — тут скорее к «индусам» — тяп-ляп и готово — закрыл требования а дальше хоть трава не расти.
VolCh
15.08.2015 08:52Объективная оценка обычно и не нужна, поскольку требования к процессу субъективны. Грубо, в одном проекте аджайл, в другом водопад.
samodum
14.08.2015 12:46+5>«Соискатели, которые рассматривают в рамках задачи весь предоставленный код, — а не только тот, который мы попросили их написать, — будут действовать так же и в работе с реальным продуктом, когда присоединятся к нашей команде.»
Совершенно не согласен.
Люди на собеседованиях обычно ведут себя не так, когда уже устроены на работу. Волнение, мотивация и прочие факторы никто не отменял и они влияют на результат.
Очень ошибочно думать, что на собеседовании человек будет точно таким же, как на работе.
NekR
14.08.2015 16:50-1Я так понимаю этой компании не важен стайл гайд и другие аспекты уже существующего кода. Вот представляю компания нанимает такого программиста и он переписывает весь код вокруг потому что тот не соответвует его представлениям, не нравятся имена переменных или ещё что то…
guai
14.08.2015 19:51+5Поделитесь, а чем это плохо? Я вот такой программист. Если я вижу хреноту в коде — я ее правлю. Остальные члены команды этого не делают, мотивируя много чем, «история гита запортится», «работает — не трогай», «мы потом переделаем хорошо, когда-нибудь, когда делать нечего будет» и т.п. В сухом остатке — код, который ковырял я, обычно лучше, чем тот, который делали без меня. Это разве плохо? Люди мне говорят о том, что с моими API работать приятнее.
Ну да, бывает заносит, и в какой-то момент я понимаю, что поправить тут всё я не осилю за обозримое время, приходится что-то окукливать и забивать на то, что там скрыта непонятно как работающая лажа.NekR
14.08.2015 20:11+1Так как вы аргументируете можно конечно всё аргументировать, но я говорю не про рефакторинг (об этом пункт 4 поста) или создание нового API, а про вмешательство в новую код-базу со своими правилами. Мне было например как минимум не удобно если бы пришёл новичок и начал переправлять код который я или мои коллеги написали в едином стиле проекта на свой лад. Точно тогда когда меня клиенты просят внести изменения или что то добавить в их проект, я пишу код в том стиле в каком он написал в проекте, даже если он мне не нравится. Когда этот код меня ну уж сильно бесит или я вижу что клиент готов платить за улучшение (и потраченное на это время), я предлагаю ему рефакторинг. Было бы не очень хорошо с моей стороны начать всё переделывать, что бы когда придёт третий человек он увидел два стиля кода и начал придумывать свой третий.
guai
14.08.2015 20:31Ну стили это да, больная тема. А вот пример с переименованием переменных — я бы только одобрил. Если новичку, видящему код в первый раз, пришлось тратить время, чтобы выяснить, что в ней лежит, а не просто прочитать ее имя, — такое исправление явно на пользу.
Своих коллег я призываю сразу делать нормально, потому что у них какое-то отторжение вызывает переделывание чего-либо. Не знаю почему. Просто боятся что ли чужой код тронуть, не знаю.
Diaver
14.08.2015 12:52+11«Зина, в печку ее!!» — Собачье сердце.
Набор тестовых задания с неясными критериями и требованиями один из худших способ поиска программиста.
А как же опыт работы, интересные задачи и то как соискатель их решил, его «философия» программирования, а также десяток других интересных тем для обсуждения на собеседовании?
Печаль…Diaver
14.08.2015 13:43+5Дополню свой комментарий.
Вот приходишь на собеседование к таким товарищам с резюме в котором куча ссылок на open source проекты, демо-проекты, статьи и прочее.
Тебе в морду пихают лист с задачами, которые нужно решить за несколько часов, при том что этого времени особо то и нет, а на вопрос «Вы мое резюме смотрели, проходили по ссылкам, читали статьи?» получаешь ответ, вроде «Не смотрел».
Вопрос: какого фига??
arvitaly
15.08.2015 18:14+1«Не смотрел» Вопрос: какого фига??
при том что этого времени особо то и нет
Времени нет ни у кого, тратить несколько часов на собеседование VS тратить на изучение портфолио каждого собеседуемого.
Gorthauer87
14.08.2015 13:04+1Как же всякие эйчары любят халявить и пытаться рассматривать людей, как некие детали конструктора. В общем, мне начинает казаться, что крупные бизнес конторы мечтают превратить программистов в аналогов водителей, полностью на корню сведя всю непредсказуемость и творческую составляющую работы.
Отсюда напрашивается вывод, что если не хочется окостенеть, хочется постоянного развития, то нужно двигаться в сторону или R&D контор или же независимой разработки и участия в хакатонах и всяких краудфандинговых проектов.
omican
14.08.2015 15:46+1А хакатоны могут быть надежным источником дохода? У меня как далекого от профессионального программирования человека было впечатление, что хакатоны это эдакие развлекательно-познавательные программистскые тусовки.
Gorthauer87
14.08.2015 18:27Из них иногда (если получится денежку получить) получаются неплохие проекты.
MaxFactor
14.08.2015 21:06Есть еще один вариант — создать свой интернет бизнес проект и программировать в удовольствие, получая деньги. А не искать «контору».
VolCh
15.08.2015 15:10+1Довольно быстро понимаешь, что надо или заниматься бизнесом, или искать контору, где ты будешь (со)владельцем и программистом, но не директором.
alan008
14.08.2015 13:17+7>>Другие члены вашей команды отводят вас в сторону со словами «Мы должны нанять эту девушку»
Охх.))) У автора перевода как-то незаметно получилось очень юморнОе предложение
m08pvv
14.08.2015 13:29+1Соискатели, которые решают проблему, а затем без передышки берутся рефакторить код, — специалисты совсем другой категории.
Methos
14.08.2015 13:33Ага, вызываешь сантехника и даёшь тестовое задание на два часа, он сразу пошлёт в одно место.
zharikovpro
14.08.2015 13:40+4> Крупные бизнес конторы мечтают превратить программистов в аналогов водителей, полностью на корню сведя всю непредсказуемость и творческую составляющую работы
Конечно мечтают. Т.к. бизнесу в идеале нужен стабильно работающий производственный конвеер с легко заменяемыми деталями, гарантированно выдающий предсказуемый результат.Gorthauer87
14.08.2015 18:29Но это далеко не в интересах самого программиста. Быть элементом конвеера скучно, сколько бы там не платили. В таких конторах большая текучка кадров.
zharikovpro
14.08.2015 19:44Есть разные типы людей. Кому-то быть элементом отлаженного офисного конвеера — мука смертная из-за рутины. Ну да, бывает. А для какого-то это благо великое. Потому что есть типа стабильность и надежность, работа простая (в смысле — по силам и вчера и сегодня и завтра) и понятная, получается хорошо и платят прилично, так что жизнь вроде как удалась.
Cortlendt
14.08.2015 13:53+1В прошлом году я собеседовал настолько старательного, усердного и профессионального в своей работе программиста, что он создал полный Javadoc с комментариями к своему коду прежде, чем счел задачу выполненной. Он даже написал полностью автоматизированные unit-тесты и проверил процент покрытия ими кода. Когда я вернулся в комнату по истечении 2 часов, он неистово стучал по клавиатуре, и я было решил, что у него проблемы с выполнением задания, но на самом деле он как раз добавлял HTML-форматирование в свой Javadoc
Пример задания, которое можно понять, выполнить, покрыть тестами, сгенерировать документацию и высчитать покрытие за 2 часа?
Судя по наличию по крайней мере нескольких юнит-тестов и не 100% покрытия задача сама по себе не маленькая. Больше похоже на кулстори.
SirEdvin
14.08.2015 13:59-1Напишите три базовых сортировки?
И потом для каждой из них можно запилить отдельный тест)Cortlendt
14.08.2015 14:28+2Как тут нам поможет вычисление покрытия? Типа вот тут получение пивота для квиксорта не покрыли — вы нам не подходите.
romy4
14.08.2015 18:03+8Ещё один бесящий меня момент — помнить алгоритмы, которые ты никогда не пишешь в своей жизни, а используешь готовые. Меня сходу можно отсеять в таких компаниях. И не страшно за 10-летний опыт разработок, умение оптимизировать/профилировать сложные запросы, главное — это решение тестового задания, предназначенного для только получивших диплом выпускников матвузов.
RusMikle
14.08.2015 18:02+3Чем игра с тестами намного интереснее поговорить с кандидатом и попросить рассказать и показать что то на что он потратил не 2 часа а значительно больше времени. Там и код увидишь, и стиль написания и умение объяснять можно оценить. Люди на собеседовании могут просто волноваться и это будет мешать им что то написать так как они это могут в спокойной обстановке. Человек может не знать чего то одного но прекрасно уметь учиться и осваивать новое. Тесты при приёме это тупое решение в лоб, способ прикрыть собственное незнание, т.к. сам наверняка это задание уже обсосал. Если уж хочется тестов то садись с человеком вместе и пробуй написать что то вместе, обсуди с ним создание напр. какого то класса а потом раздели работу и вместе с ним попиши, попробуй потом состыковать Ваш совместный труд, посмотри как человек может работать в паре, насколько он полезен, инициативен и дружелюбен. Я знаю достаточно людей, профи в языке и предмете но которых я никогда не возьму в комманду только по одной простой причине, они хотят все сделать сами, а при попытке разделить их работу с кем то ещё возникают проблемы.
Suvitruf
15.08.2015 10:48+1Ок, исходим из предположения, что человек при найме будет себя проявлять так же как на собеседовании, а теперь по пунктам:
1)Недавно я собеседовал программиста, который решил весь набор задач дважды: один раз итеративным способом, второй — рекурсивным. Я сразу же предложил ему работу. Умение находить несколько решений проблемы — навык, который инженерам приходится применять каждый день.
На проекте он точно так же будет по 2 раза всё делать и тратить в 2 раза больше времени? Да нет, дело даже не в этом. Главное — объяснить, то есть, лучше, если он сделает всего 1 вариант, но объяснит почему. Даже если этот вариант не самый оптимальный, то его способность к рассуждению я, как наниматель, больше бы оценил.
2) Javadoc ещё ладно, не так много времени займёт. Но полная документация и тесты… Я не говорю, что их не надо делать, но когда стоит выбор перед тестами/документацией и, собственно, написанием кода, то я бы поставил на код. Может у меня всё так неудачно складывалось, но времени на тесты/доки всегда не хватало. Даже если нет дедлайна, то начальство всегда хочет больший функционал, нежели тесты и т.п.
3)Наймите их — и они, вероятно, будут творить чудеса с вашим продуктом, делая гораздо больше поставленной задачи и внося улучшения туда, где они нужны.
Мне от сотрудника надо, чтобы он задачу выполнял, а не какие-то там чудеса творил. Просишь нарисовать окно новое у дизайнера, а он потратит в 2 раза больше времени, только потому что рисовал какую-то фентифлюшку совершенно не нужную, которую никто не просил, но ему, видите ли, «так подсказало сердце».
4) *Тут должна быть цитата Кнута про оптимизацию*, которая к рефакторингу, собственно, тоже относится.
5) Кофе вкусный готовит? Красиво поёт? Честно, я этот пункт не совсем понимаю )
Punk_UnDeaD
16.08.2015 15:155) Кофе вкусный готовит? Красиво поёт? Честно, я этот пункт не совсем понимаю )
Не бесит.
olegy
17.08.2015 13:16После выполнения задания
1. Помоет пол у рабочего места
2. Покрасит лавочку
3. Переведет старушек через дорогу
…
Профит ;)
jrip
>1. Он предлагает несколько решений
А если он не просто знает несколько решений, а может выбрать лучшее и предложит только его?
>4. Он рефакторит с умом
>Большинство соискателей любят добиваться того, чтобы решение заработало, после чего расслабляются и вздыхают с облегчением, удачно все >завершив. Это хорошо, но редко этого достаточно, чтобы немедленно получить предложение о найме.
Т.е. я, например, правильно решил тестовое задание, написав при этом приличный по виду запаху код, и этого недостаточно? Нужно еще изобразить что я очень люблю рефакторить?
Если в этот момент еще и появляется Необходимость рефакторить — я ж сам себя спрошу, а нафига я так фигово фиговый код то написал.
samodum
Классическая компания, которой надо угодить и угадать её «хотелки и перделки». Уверен, что они отсекают не разобравшись хороших специалистов
jrip
Это какая-то сферическая компания, лично я таких маразмов не встречал, так что непонятно о чем статья.
Чтобы было весело потом смотреть как новички следуют этим советам?
Ну наверное, чтобы потом проводить собеседования и ржать, смотря как они раскрашивают документацию.
StopKran
У меня на собеседовании как-то раз был примерно такой случай (обсуждали моё тестовое задание):
-Скажите, а вот тот код который вы написали, вы не хотите его отрефакторить?
-Нет
-Но как же, вы же просто скопипастили эти две строчки 4 раза!
-Да
-И вы не хотите вынести их в процедуру!?
-Нет, мне же не придётся поддерживать этот код.
-Но это же не красиво!
-Этот код идеально выполняет поставленные задачи. В связи с отсутствием развития этого кода в будущем, не считаю целесообразным выполнять пустую работу, и стремиться к какой-то мифической красоте.
-Но как же, но это же не правильно (и дальше паника в глазах собеседующего меня тим лида)
arvitaly
Может быть, это была проверка на умение отстаивать правильную точку зрения до последнего)
ezj
А где гарантия что в реальном проекте вы не будите говорить так же, и где гарантия что код, который вы написали, далее не будет поддерживаться?