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

Original author: Brian Kelly
  • Translation
Когда вы приглашаете программиста для собеседования и выполнения тестового задания, это может оказаться интересным опытом и для вас, и для него. Большинство собеседований заканчивается тем, что менеджер по подбору персонала обещает «оставаться на связи», но иногда соискатель просто попадает в точку. В такие моменты вы обдумываете, не нанять ли его еще до того, как он успеет покинуть здание. Мы в Alconost перевели для вас статью шароварщика Брайана Келли именно о таких удачных случаях.

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

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

1. Он предлагает несколько решений


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

2. Он пишет полную документацию


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

3. Он совершенствует задание


Мы специально создаем задания с запрятанными в них мелкими изъянами, исключительно чтобы посмотреть: а) заметит ли их соискатель и б) возьмется ли их исправлять. Это могут быть некорректно использованные кавычки в строках, неправильные имена переменных или что-то в этом же духе. Соискатели, которые рассматривают в рамках задачи весь предоставленный код, — а не только тот, который мы попросили их написать, — будут действовать так же и в работе с реальным продуктом, когда присоединятся к нашей команде.

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

4. Он рефакторит с умом


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

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



5. Все остальные признаки — в его пользу


Бывает, что нужного соискателя выдает множество нетехнических признаков. Другие члены вашей команды отводят вас в сторону со словами «Мы должны нанять эту девушку». Личность соискателя выглядит исключительно подходящей для команды. У него релевантный и свежий опыт в том, чем ему придется заниматься. Вы знаете нескольких людей, которые работали с ним и считают, что он — чудесное дополнение к команде (и сами наняли бы его снова без колебаний). Соискатель в восторге от компании и возможностей, и ему не терпится начать работу.

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

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


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com

Alconost
106.74
Локализуем на 68 языков, делаем видеоролики для IT
Share post

Comments 45

    +9
    >1. Он предлагает несколько решений
    А если он не просто знает несколько решений, а может выбрать лучшее и предложит только его?

    >4. Он рефакторит с умом
    >Большинство соискателей любят добиваться того, чтобы решение заработало, после чего расслабляются и вздыхают с облегчением, удачно все >завершив. Это хорошо, но редко этого достаточно, чтобы немедленно получить предложение о найме.
    Т.е. я, например, правильно решил тестовое задание, написав при этом приличный по виду запаху код, и этого недостаточно? Нужно еще изобразить что я очень люблю рефакторить?
    Если в этот момент еще и появляется Необходимость рефакторить — я ж сам себя спрошу, а нафига я так фигово фиговый код то написал.
      +30
      Классическая компания, которой надо угодить и угадать её «хотелки и перделки». Уверен, что они отсекают не разобравшись хороших специалистов
        +2
        Это какая-то сферическая компания, лично я таких маразмов не встречал, так что непонятно о чем статья.
        Чтобы было весело потом смотреть как новички следуют этим советам?
        Ну наверное, чтобы потом проводить собеседования и ржать, смотря как они раскрашивают документацию.
        +3
        У меня на собеседовании как-то раз был примерно такой случай (обсуждали моё тестовое задание):
        -Скажите, а вот тот код который вы написали, вы не хотите его отрефакторить?
        -Нет
        -Но как же, вы же просто скопипастили эти две строчки 4 раза!
        -Да
        -И вы не хотите вынести их в процедуру!?
        -Нет, мне же не придётся поддерживать этот код.
        -Но это же не красиво!
        -Этот код идеально выполняет поставленные задачи. В связи с отсутствием развития этого кода в будущем, не считаю целесообразным выполнять пустую работу, и стремиться к какой-то мифической красоте.
        -Но как же, но это же не правильно (и дальше паника в глазах собеседующего меня тим лида)
          +2
          Может быть, это была проверка на умение отстаивать правильную точку зрения до последнего)
            0
            А где гарантия что в реальном проекте вы не будите говорить так же, и где гарантия что код, который вы написали, далее не будет поддерживаться?
          +2
          Это позволяет нам оценить производительность программиста, основываясь исключительно на времени выполнения задания: если все решено меньше, чем за час, мы будем довольны

          А если потом в реальной работе программист решает задачу вот так, за час, а после этого тратит еще три раза по часу, чтобы сделать код не просто рабочим но и правильным/красивым/обобщенным и т.п., вместо того, чтобы потратить сразу два или два с половиной часа и сделать все то же самое? Насколько объективна оценка программиста с позиции такой «производительности»?
            +25
            Вместо тысячи слов:

            Скорость программирования в реальной жизни и в кино
            image
              +6
              hackertyper.com для быстрого написания кода.
                0
                В точку. Иногда полдня сидишь и думаешь, чтобы написать потом строчек 50 а то и меньше в сумме)))
                +5
                Вообще в программировании хороший, надежный и качественный код в незнакомом контексте быстро не пишется. Это аксиома.

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

                А оценивать программиста по скорости работы — тут скорее к «индусам» — тяп-ляп и готово — закрыл требования а дальше хоть трава не расти.
                  0
                  Объективная оценка обычно и не нужна, поскольку требования к процессу субъективны. Грубо, в одном проекте аджайл, в другом водопад.
                  +5
                  >«Соискатели, которые рассматривают в рамках задачи весь предоставленный код, — а не только тот, который мы попросили их написать, — будут действовать так же и в работе с реальным продуктом, когда присоединятся к нашей команде.»

                  Совершенно не согласен.
                  Люди на собеседованиях обычно ведут себя не так, когда уже устроены на работу. Волнение, мотивация и прочие факторы никто не отменял и они влияют на результат.
                  Очень ошибочно думать, что на собеседовании человек будет точно таким же, как на работе.
                    –1
                    Я так понимаю этой компании не важен стайл гайд и другие аспекты уже существующего кода. Вот представляю компания нанимает такого программиста и он переписывает весь код вокруг потому что тот не соответвует его представлениям, не нравятся имена переменных или ещё что то…
                    • UFO just landed and posted this here
                        +1
                        Так как вы аргументируете можно конечно всё аргументировать, но я говорю не про рефакторинг (об этом пункт 4 поста) или создание нового API, а про вмешательство в новую код-базу со своими правилами. Мне было например как минимум не удобно если бы пришёл новичок и начал переправлять код который я или мои коллеги написали в едином стиле проекта на свой лад. Точно тогда когда меня клиенты просят внести изменения или что то добавить в их проект, я пишу код в том стиле в каком он написал в проекте, даже если он мне не нравится. Когда этот код меня ну уж сильно бесит или я вижу что клиент готов платить за улучшение (и потраченное на это время), я предлагаю ему рефакторинг. Было бы не очень хорошо с моей стороны начать всё переделывать, что бы когда придёт третий человек он увидел два стиля кода и начал придумывать свой третий.
                        • UFO just landed and posted this here
                    +11
                    «Зина, в печку ее!!» — Собачье сердце.
                    Набор тестовых задания с неясными критериями и требованиями один из худших способ поиска программиста.
                    А как же опыт работы, интересные задачи и то как соискатель их решил, его «философия» программирования, а также десяток других интересных тем для обсуждения на собеседовании?
                    Печаль…
                      +5
                      Дополню свой комментарий.
                      Вот приходишь на собеседование к таким товарищам с резюме в котором куча ссылок на open source проекты, демо-проекты, статьи и прочее.
                      Тебе в морду пихают лист с задачами, которые нужно решить за несколько часов, при том что этого времени особо то и нет, а на вопрос «Вы мое резюме смотрели, проходили по ссылкам, читали статьи?» получаешь ответ, вроде «Не смотрел».
                      Вопрос: какого фига??
                        +1
                        «Не смотрел» Вопрос: какого фига??

                        при том что этого времени особо то и нет

                        Времени нет ни у кого, тратить несколько часов на собеседование VS тратить на изучение портфолио каждого собеседуемого.
                      +1
                      Как же всякие эйчары любят халявить и пытаться рассматривать людей, как некие детали конструктора. В общем, мне начинает казаться, что крупные бизнес конторы мечтают превратить программистов в аналогов водителей, полностью на корню сведя всю непредсказуемость и творческую составляющую работы.
                      Отсюда напрашивается вывод, что если не хочется окостенеть, хочется постоянного развития, то нужно двигаться в сторону или R&D контор или же независимой разработки и участия в хакатонах и всяких краудфандинговых проектов.
                        +1
                        А хакатоны могут быть надежным источником дохода? У меня как далекого от профессионального программирования человека было впечатление, что хакатоны это эдакие развлекательно-познавательные программистскые тусовки.
                          0
                          Из них иногда (если получится денежку получить) получаются неплохие проекты.
                          0
                          Есть еще один вариант — создать свой интернет бизнес проект и программировать в удовольствие, получая деньги. А не искать «контору».
                            +1
                            Довольно быстро понимаешь, что надо или заниматься бизнесом, или искать контору, где ты будешь (со)владельцем и программистом, но не директором.
                          +7
                          >>Другие члены вашей команды отводят вас в сторону со словами «Мы должны нанять эту девушку»
                          Охх.))) У автора перевода как-то незаметно получилось очень юморнОе предложение
                            0
                            Перечитал три раза. Дошло.
                              0
                              Я так женился!
                              +1
                              Соискатели, которые решают проблему, а затем без передышки берутся рефакторить код, — специалисты совсем другой категории.
                                0
                                Ага, вызываешь сантехника и даёшь тестовое задание на два часа, он сразу пошлёт в одно место.
                                  +4
                                  > Крупные бизнес конторы мечтают превратить программистов в аналогов водителей, полностью на корню сведя всю непредсказуемость и творческую составляющую работы

                                  Конечно мечтают. Т.к. бизнесу в идеале нужен стабильно работающий производственный конвеер с легко заменяемыми деталями, гарантированно выдающий предсказуемый результат.
                                    0
                                    Но это далеко не в интересах самого программиста. Быть элементом конвеера скучно, сколько бы там не платили. В таких конторах большая текучка кадров.
                                      0
                                      Есть разные типы людей. Кому-то быть элементом отлаженного офисного конвеера — мука смертная из-за рутины. Ну да, бывает. А для какого-то это благо великое. Потому что есть типа стабильность и надежность, работа простая (в смысле — по силам и вчера и сегодня и завтра) и понятная, получается хорошо и платят прилично, так что жизнь вроде как удалась.
                                    +1
                                    В прошлом году я собеседовал настолько старательного, усердного и профессионального в своей работе программиста, что он создал полный Javadoc с комментариями к своему коду прежде, чем счел задачу выполненной. Он даже написал полностью автоматизированные unit-тесты и проверил процент покрытия ими кода. Когда я вернулся в комнату по истечении 2 часов, он неистово стучал по клавиатуре, и я было решил, что у него проблемы с выполнением задания, но на самом деле он как раз добавлял HTML-форматирование в свой Javadoc


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

                                      –1
                                      Напишите три базовых сортировки?
                                      И потом для каждой из них можно запилить отдельный тест)
                                        +2
                                        Как тут нам поможет вычисление покрытия? Типа вот тут получение пивота для квиксорта не покрыли — вы нам не подходите.
                                          +8
                                          Ещё один бесящий меня момент — помнить алгоритмы, которые ты никогда не пишешь в своей жизни, а используешь готовые. Меня сходу можно отсеять в таких компаниях. И не страшно за 10-летний опыт разработок, умение оптимизировать/профилировать сложные запросы, главное — это решение тестового задания, предназначенного для только получивших диплом выпускников матвузов.
                                            +2
                                            …которые потом фигачат нечитабельное спагетти.
                                        0
                                        На трезвую голову хороший рефактор не написать. На пьяную, кстати, тоже.
                                          +7
                                          Удивляет, что эта компания во время теста не стреляет над ухом из пистолета и не выдергивает стул.
                                            0
                                            Статья ж от лица собеседующего, так что, вполне возможно, что стреляют.
                                            +3
                                            Чем игра с тестами намного интереснее поговорить с кандидатом и попросить рассказать и показать что то на что он потратил не 2 часа а значительно больше времени. Там и код увидишь, и стиль написания и умение объяснять можно оценить. Люди на собеседовании могут просто волноваться и это будет мешать им что то написать так как они это могут в спокойной обстановке. Человек может не знать чего то одного но прекрасно уметь учиться и осваивать новое. Тесты при приёме это тупое решение в лоб, способ прикрыть собственное незнание, т.к. сам наверняка это задание уже обсосал. Если уж хочется тестов то садись с человеком вместе и пробуй написать что то вместе, обсуди с ним создание напр. какого то класса а потом раздели работу и вместе с ним попиши, попробуй потом состыковать Ваш совместный труд, посмотри как человек может работать в паре, насколько он полезен, инициативен и дружелюбен. Я знаю достаточно людей, профи в языке и предмете но которых я никогда не возьму в комманду только по одной простой причине, они хотят все сделать сами, а при попытке разделить их работу с кем то ещё возникают проблемы.
                                              +1
                                              Ок, исходим из предположения, что человек при найме будет себя проявлять так же как на собеседовании, а теперь по пунктам:

                                              1)
                                              Недавно я собеседовал программиста, который решил весь набор задач дважды: один раз итеративным способом, второй — рекурсивным. Я сразу же предложил ему работу. Умение находить несколько решений проблемы — навык, который инженерам приходится применять каждый день.
                                              На проекте он точно так же будет по 2 раза всё делать и тратить в 2 раза больше времени? Да нет, дело даже не в этом. Главное — объяснить, то есть, лучше, если он сделает всего 1 вариант, но объяснит почему. Даже если этот вариант не самый оптимальный, то его способность к рассуждению я, как наниматель, больше бы оценил.
                                              2) Javadoc ещё ладно, не так много времени займёт. Но полная документация и тесты… Я не говорю, что их не надо делать, но когда стоит выбор перед тестами/документацией и, собственно, написанием кода, то я бы поставил на код. Может у меня всё так неудачно складывалось, но времени на тесты/доки всегда не хватало. Даже если нет дедлайна, то начальство всегда хочет больший функционал, нежели тесты и т.п.
                                              3)
                                              Наймите их — и они, вероятно, будут творить чудеса с вашим продуктом, делая гораздо больше поставленной задачи и внося улучшения туда, где они нужны.
                                              Мне от сотрудника надо, чтобы он задачу выполнял, а не какие-то там чудеса творил. Просишь нарисовать окно новое у дизайнера, а он потратит в 2 раза больше времени, только потому что рисовал какую-то фентифлюшку совершенно не нужную, которую никто не просил, но ему, видите ли, «так подсказало сердце».
                                              4) *Тут должна быть цитата Кнута про оптимизацию*, которая к рефакторингу, собственно, тоже относится.
                                              5) Кофе вкусный готовит? Красиво поёт? Честно, я этот пункт не совсем понимаю )
                                                0
                                                5) Кофе вкусный готовит? Красиво поёт? Честно, я этот пункт не совсем понимаю )

                                                Не бесит.
                                                0
                                                После выполнения задания
                                                1. Помоет пол у рабочего места
                                                2. Покрасит лавочку
                                                3. Переведет старушек через дорогу

                                                Профит ;)

                                                Only users with full accounts can post comments. Log in, please.