От переводчика: За последние несколько дней тема использования головоломок и решения задач на доске при собеседовании программистов в очередной раз попала в тренд. Началось все с поста Егора Бугаенко Why I Don’t Talk to Google Recruiters, потом ссылка на запись появилась на Hacker News и Reddit, а затем получила реакцию в Твиттере. Твит David Heinemeir Hannson-а, создателя Ruby On Rails, запустил целую цепочку ответов в стиле “Hello, I’m … ” где люди высказывались, какого рода алгоритмические задачи они не в состоянии решить, несмотря на большой опыт и успешные проекты за плечами.



Мне показалось, что будет интересно узнать и про альтернативный подход к собеседованию. Подход, который не включает решение сложных алгоритмических задач у доски или знание тонкостей языка программирования. Ниже — перевод статьи из официального блога компании Pivotal. Проектами компании являются такие программные продукты как: фреймворк для разработки приложений на Java Spring Framework, облачная PaaS платформа Pivotal Cloud Foundry, система обмена сообщениями RabbitMQ. А подразделение Pivotal Labs занимается внедрением гибких практик в разработке ПО.

Как мы проводим собеседования в Pivotal


image

Спрашивали ли вас когда либо вопрос-головоломку на собеседовании? Например, «почему канализационные люки — круглые?» Или «как много шариков для пинг-понга поместится в школьный автобус?». Или, возможно, вас просили написать на доске код, который реверсирует связанный список?

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

Такого рода теоретические вопросы на интервью так же не дают кандидату шанс увидеть — каково это работать здесь. Мы верим, что собеседование — это дорога с двухсторонним движением. Мы проводим собеседование с вами точно так же, как вы проводите собеседование с нами. И каждый из нас пытается ответить на один и тот же вопрос — «Хотим ли мы работать вместе?».

Как это работает?


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

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

Когда вы работаете с командой, вы программируете в паре с кем-то. Обычно, это включает работу над реальной задачей из бэклога. Скорее всего, если мы хорошо подготовились к вашему приходу, вы даже не заметите, как тщательно подобрана эта задача. Но не думайте, что все так просто — мы действительно подходим к выбору задачи с величайшим вниманием. Задача должна быть такой, чтобы ее можно было быстро объяснить. Не слишком большой, но и не слишком маленькой. Ну и, конечно, должна включать написание кода. Иногда в качестве такой задачи выбирается не самая приоритетная. Но в этом нет ничего страшного. Если бы мы брали исключительно приоритетные задачи — то мы бы шли на риск потратить большую часть времени на объяснение контекста. Или риск работать над чем-то, что не сможет показать ваши навыки программирования.

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

Нет придуманных головоломок


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

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

Мы часто слышим от кандидатов, что наш процесс отличается всего, что они видели до этого. И им это нравится.
Поделиться с друзьями
-->

Комментарии (33)


  1. samodum
    28.02.2017 03:54

    Ребята, а вы совсем не бережёте время интервьюируемого.
    Почему вы думаете, что это вы сотрудника выбираете, а не он вас среди 3-10 других работодателей?
    Вариант viber/whatsapp — интервью напрочь отрицается?


    1. Matvey-Kuk
      28.02.2017 03:59
      +2

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


      1. samodum
        28.02.2017 04:09
        +1

        Это же очевидно.
        Чем больше общения, тем больше обратной связи. Здесь же вопрос в том, что не на всех работодателей в таком режиме хватит времени.


        1. Areso
          28.02.2017 06:57
          +3

          Видимо, идеального решения нет. Кто-то откажется тратить полный день на прохождение такого собеседования (уместно ли это назвать собеседованием?), кто-то откажется заполнять типовую анкету в 300 вопросов, где первые вопросы касаются ФИО, а последние размером дохода ближайших родственников, кто-то выйдет в дверь, услышав вопрос с люками или шариками пинг-понга.
          Другой момент, что эти люди хотя бы сразу предупреждают, что надо уделить целый день в таком формате. А когда тебя пригласили, ты отпросился на часок, и тебе дают анкету на 300 вопросов, а технический специалист и вовсе не был представлен на собеседовании, ты чувствуешь, что твое время было потрачено абсолютно бездарно.


    1. pudovMaxim
      28.02.2017 09:11
      +1

      Ох, я как сотрудник не прочь такого одного интервью на день. Все равно из-за встречи тратится очень много времени. Обычно это пару часов разъездов + час-другой «ляляля». И еще очень часто бывает что в компании интервью не одно. Но, конечно, предварительные ласки сладким голосом HR-a тоже нужны, чтобы хотя бы представлять куда идти.


    1. Hoksmur
      03.03.2017 23:15

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


  1. Terras
    28.02.2017 06:53

    Т.е. человек приходит, ему дают место, он там сидит все настраивает, потом вникает в код проекта, потом что-то пишет, потом это оценивают. В итоге, это же целый день.


    1. Pakos
      28.02.2017 09:01
      +1

      Это хорошо когда нужно сделать формочку на стандартном Фреймворке, но если проекту перевалило за десяток лет, то разобраться даже в простой части не просто (нужно читать доки, вику, изучать примеры использования API; зачастую на это уходит неделя). Т.е. за день можно посмотреть как работает команда, но не вникнуть в проект и не написать что-до достойное продакшна, но день на день не приходится и надо иметь очень сильное желание работать именно там.


    1. ApeCoder
      28.02.2017 10:18
      +1

      вы программируете в паре с кем-то


  1. avost
    28.02.2017 07:22
    +1

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


    1. TerraV
      28.02.2017 08:42
      +1

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


      1. intsurfer
        28.02.2017 09:21

        Поддерживаю! Именно так проходил собеседование в одной компании (продажа специализированного софта) еще в середине 90-х. В отпуск поработал в ней пару дней, понял, что продажи не то, что мне нравится, и мы расстались. Никто ничего не потерял. В дальнейшем были только тесты (иногда на время) и вопросы про люк.


      1. avost
        28.02.2017 13:19

        Если вы подбираете работу исключительно по зарплате, подобное разбазаривание времени вам не подходит

        Не, как правило, подбираю из интереса.


        Нужно окучить как можно больше работодателей, авось кто даст на входе большие цифры.

        Бросьте. Начиная с некоторого уровня уе в месяц, интересные вакансии появляются не так уж часто.


        И однодневный тест-драйв (на мой взгляд) отличная практика.

        Но, даже в этом случае, на мой взгляд (на взгляд зажравшегося инженера, коттрому работу скорее предлагают, чем он сам ищет), это как-то перебор. Они хоть этот день оплачивают кандидату?


      1. 3aicheg
        01.03.2017 03:43

        подобное разбазаривание времени вам не подходит. Нужно окучить как можно больше работодателей


        На практике, в день реально окучить не более одного, да и то за счастье. Помню, как-то был я юный, наивный и деловой и пытался из своей деревни понаехать в Дефолт-сити. По е-мэйлу насобирал приглашений на интервью, довольно много. Там, понятно, жить негде, денег нет, но надо держаться, пока все интервью пройдёшь. И хорошо бы пройти побыстрее. Посчитал, прикинул — вот, допустим, в 8 утра приду на первое интервью. Ну, на само интервью час-другой. Уже десять утра. Сколько ехать до места следующего интервью? Где-нибудь час, пусть для надёжности два. Получится примерно три интервью в день: в 8, в 12 и в 16 часов. По три интервью в день, получается, дней нужно совсем не так много, ура? Щазз. Суровая реальность оказалась сурова: в 8 утра никто интервью не назначает. Да и в 16 тоже. И «вот прям завтра» ни одного интервью назначить не получается, зато в среду хотят аж трое, и все в 2 часа дня! Нет-нет, перенести на другое время не можем, у нас все ходы расписаны, раз не можете в среду в два, то тогда перезвоните уже на той неделе…


    1. Pakos
      28.02.2017 09:20

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


    1. Aingis
      28.02.2017 14:19

      С точки зрения работодателя, имхо, тоже дорого. Если у вас, скажем, 10 собеседований в месяц, то это надо потратить 10 человекодней разработчиков на такие собеседования.


    1. kalombo
      03.03.2017 23:15

      В тех же Гуглах, а также в Яндексе на собеседование тратится тоже день, только вы весь этот день решаете на доске/бумаге алгоритмические задачи.


  1. Laney1
    28.02.2017 07:33
    -5

    не очень справедливо сравнивать это с гуглом.


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


    Во-вторых, возвращаясь к развороту дерева. Одному мне кажется неправильным, что куча программистов не только не может решить простенькую задачку (думаю, она вообще больше не алгоритмическая, а архитектурная), но еще и чуть ли не гордится этим? А потом кто-то удивляется, откуда берутся все эти гитлабы и прочие "успешные проекты".


  1. sbnur
    28.02.2017 09:11

    Вот так сразу человек вольется в коллектив и начнет нечто мастерить — это вариант не для всех — любому всегда надо осмотреться на новом месте, если конечно работа не уровня бери больше, кидай дальше — пока летит — отдыхай
    Кстати, если задача подобрана, то тратится рабочий день не только у испытуемого, но и у сотрудников
    Берем 5 испытуемых — получается целая рабочая неделя — не затратно ли?


  1. i360u
    28.02.2017 09:18

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


  1. Flip89
    28.02.2017 09:44

    В статье кстати еще не описано то, что они работают используя pair programming и tdd все рабочее время. По поводу того что много времени тратится — там есть серия предварительных интервью когда можно понять подходит тебе эта компания или нет. Еще из особенностей выделил бы что компания обращает много внимания на soft skills в связи с особенностями работы. Проходил там интервью в лондонском офисе, у меня осталось довольно таки положительные впечатления о процессе и о компании в целом.


  1. ternaus
    28.02.2017 10:12
    +1

    Собеседовался на позицию Data Scientitst в офис Pivotal в Palo Alto. Onsite интервью было вполне типичным.


    • Презентация о каком-нибудь проекте связанным с данными.
    • Разговор за жизнь с Head Of Data Science
    • Задачки на ML алгоритмы с тремя членами команды на протяжении трех последующих часов.

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


    Из неприятного — после oniste интервью обо мне забыли или положили про запас, работая с другими кандидатами — ни да, ни нет. Раз в неделю писал рекрутеру, а в ответ — вот прямо сейчас команда уже буквально обсуждает feedback после интервью и через пару дней будет ответ.


    Через месяц мне надоело — я написал и вежливо послал их в пешее эротическое путешествие и принял офер от другой конторы.


    1. 0xd34df00d
      03.03.2017 05:25

      А какого рода задачи в третьем пункте?


  1. Ivan22
    28.02.2017 10:37
    +5

    Мое имхо:
    По хорошому одного дня мало, что толком узнаешь о человеке за день? То что он лентяй может и не проявиться, как-нить на день соберется. Я бы сделал неделю. А лучше — месяц!!! А еще лучше три месяца. Ну и поскольку
    за даром никто три месяца работать не будет, я бы уже платил ЗП эти три месяца, ну возможно меньше обычного.
    А уж после трех месяцев уже и решал бы — берем, не берем.
    Эх, такая класная идея, жаль что никто до неё не додумался до сих пор :D


    1. 3aicheg
      28.02.2017 10:58
      +1

      Вы переизобрели испытательный срок?


      1. Ivan22
        01.03.2017 10:00

        Ну так это со стороны и выглядит однодневным испытательным сроком.


  1. 0x0FFF
    28.02.2017 11:34
    +3

    Интересный выбор статьи для перевода. Мне довелось поработать в Pivotal, и Элизабет была моим прямым руководителем какое-то время.


    Про интервью — все действительно так, но есть несколько но:


    1. Это онсайт-интервью. Перед ним проводится несколько телефонных интервью, где задачки уже ближе к алгоритмическим, и где производится основной отсев неподходящих кандидатов. Если вы попали на онсайт, то с вероятностью около 50% вас возьмут.
    2. Задача этого интервью — не только проверка навыков, но и оценка того, как хорошо вы вольетесь в коллектив, насколько приятно будет другим разработчикам с вами работать.

    По поводу траты времени — собеседования во все крупные компании занимают полный день. У Pivotal 2000+ сотрудников, и оценочная стоимость компании $2b+, то есть они могут себе позволить подобные интервью.


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


  1. Bellicus
    28.02.2017 16:26
    -1

    И так, силами кандидатов, закрываются не приоритетные задачи. Не плохо устроились.


    1. 3aicheg
      01.03.2017 10:41

      Пунктуация 80-го уровня!


      1. begemot_nn
        01.03.2017 13:32

        это орфография.
        с пунктуацией всё нормально


  1. tumikosha
    01.03.2017 14:37
    -1

    Идея-то простая: разговаривай только с людьми к-е принимают решения, а не с посредниками-шестерками.
    А столько расписывают ;))


  1. khorn_sv
    03.03.2017 23:15
    +1

    Мне такой подход больше импонирует. В первую очередь, наверное, потому что я готов потратить день своего времени на выбор места, куда я буду приходить каждый день. (Год? Два?)
    Для небольших компаний такой подход близок к оптимальному.
    Но вот в том случае, если «головоломки» являются предметной областью, тут уж никуда не деться.


  1. LiguidCool
    03.03.2017 23:15

    У меня было подобное собеседование, и ДА, это круто!
    Правда я конечно не сидел весь день, а пришел чуть позже основного состава и ушел в районе обеда…
    Попадаешь на совещание, там например говорят «нужно придумать такой-то вывод таблицы, с такой-то фильтрацией. Нужно это там-то там-то». Садишься за комп тебе открывают файлик и дают задание написать какой-нибудь класс, например описать фильтр или его часть. Входные данные такие, выходные такие. Не надо вникать в структуру систему и как где роуты идут, итп…
    Пару часов посидел, пообедал и дальше собеседоваться поехал. А тесты «Напишите функцию Sum(1)(2)(3) // 6» ничему хорошему не научат.