пятница, 9 октября 2015 г.

Про собеседования

Прочитал статью Get that job at Google, и очень сильно разочаровался! Ситуация подтвердилась и другими источниками: оказывается, в больших компаниях типа Google и Facebook собеседования далеко не такие качественные, как можно было бы подумать :(

В частности, я был крайне удивлен что проведение технических собеседований доверяется обычным программистам без серьезной подготовки их для этой работы. И они приносят собственновыдуманные вопросы, скорее всего не прорецензированные более опытными коллегами... В итоге имеем что имеем: например, требуют писать код на доске (whiteboard), задают алгоритмические задачки олимпиадного типа и прочую чушь, с которой обычный программист никогда не имеет дела в реальной жизни (в том числе они сами). В итоге собеседование превращается в экзамен и приводит к огромному числу неправильных оценок кандидатов, причем ребята из Google утверждают, что это исключительно "false negative", тогда как я почти уверен, что "false positive" там тоже немало.
Я давно интересуюсь собеседованиями, и есть кое-какой опыт в этой области, причем побывал на обеих "сторонах баррикад": составлял вопросы и проводил собеседования когда работал в Softline; ну и конечно приличное количество раз ходил собеседовался в разные компании - в Костроме, Москве, Питере и Хельсинки, включая например Microsoft (кстати, за последние 5 лет не услышал ни одного отказа: 100% собеседований были успешными и заканчивались предложением работы).

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


Что надо проверять на собеседованиях


На мой взгляд:
  1. Профессионализм разработчика. Умеет ли человек писать хороший код, разбираться в чужом коде и т.д.
  2. Текущий опыт и навыки по работе с конкретными технологиями/платформами/библиотеками и т.п.
  3. Вменяемость человека (впишется ли он в коллектив)
Третий пункт проверятся "автоматически": если вы беседуете с человеком целый час, скорее всего вы можете понять, вменяемый ли он. Остальные давайте рассмотрим подробно.


Профессионализм разработчика


Профессионализм - это годами наработанный опыт. Это то, что отличает Senior Developer от Junior Developer.

Для проверки профессионализма разработчика, в основном Google и Facebook заставляют его писать код. Мол, ты программист, значит должен уметь писать код. Но это на мой взгляд не лучший способ, по двум причинам:
  1. Хороший программист на самом деле гораздо больше читает код, чем его пишет код.
  2. Все пишут код в IDE с подсветкой синтаксиса и code completion. Это настолько кардинально отличается от "напишите код на доске", что я не представляю что вообще проверяется досочным методом.
Я бы вместо этого использовал в основном задания по чтению и анализу кода. Этот метод мне очень нравится, но на удивление он мало распространен. Идея в том, чтобы подготовить и распечатать небольшой кусок кода, и предложить кандидату проанализировать этот код каким-то образом. Важно, чтобы фрагмент кода был небольшим (максимум 1 печатный лист). Также обязательно использовать реальный язык программирования, принятый в компании, и если код представлен на бумаге, то очень желателен цветной принтер и подсветка синтаксиса, в общем код должен быть представлен именно так, каким разработчик его обычно видит.

Примеры, какие навыки можно проверить этим и другими способами:

Чтение кода. Способность легко разбираться в чужом коде, понять, что этот код делает.
Как проверять: Дается кусок кода, и нужно сказать что он делает (или например что выведет программа после запуска). Можно использовать кривые naming conventions и код средней запутанности. Можно использовать реальный код, но тогда нужно найти небольшой изолированный фрагмент.

Нахождение ошибок. Способность быстро находить ошибки.
Как проверять: Дается кусок кода, нужно указать ошибки. Ошибки не должны быть из серии "пропущена запятая" или что-то такое, что ловится в процессе компиляции (и об этом хорошо бы сказать претенденту, чтобы не искал эту ерунду). Опять же, можно использовать реальный код, но фрагмент должен быть небольшим и изолированным.

Простой код. Способность писать такой код, который был бы максимально простым и понятным для других людей (потому что люди меняются, а проект остается).
Как проверять: Задавать вопросы из серии "что вы считаете главными качествами хорошего кода", "какими принципами вы обычно руководствуетесь при написании кода", "что такое рефакторинг", "как часто вы делаете рефакторинг", "что вы считаете главным при рефакторинге".

Кстати, важно не путать "простой код" и оверинжиниринг. Большинство проходит как минимум через 3 этапа в разработке: 1. макароны => 2. оверинжиниринг => 3. "все в меру". Оверинжиниринг к сожалению почти не уступает по количеству проблем макаронам. В макаронном коде хотя бы все видно что происходит, при оверинжиниринге же главная беда в том, что все спрятано под полиморфизмом, эвентами или другими способами, и крайне сложно понять как оно работает.

Навыки работы в команде. Готовность и опыт использования принятых в компании методологий разработки, тестирования, систем контроля версий.
Как проверять: Начинать нужно с "coverage" вопросов. "Coverage" это вопросы из серии, "используете ли вы то-то", "есть ли у вас опыт с тем-то", "как долго вы работали с тем-то". Вместо "то-то" подставляем последовательно например Scrum, юнит-тесты и git - или другой набор, смотря что принято на вооружение в компании. Следующим шагом очень хороший подход это спросить личное мнение: "как вы лично относитесь к тому-то", "что вы больше всего НЕ любите в том-то" и др.

Умение задавать правильные вопросы. Способность правильно понять задачу и задать четкие вопросы.
Как проверять: Отдельно можно не проверять, но обращать внимание, какие вопросы человек будет задавать при выполнении других заданий.


Текущий опыт


Для проверки текущего опыта, на мой взгляд нужно задавать вопросы из серии "как вы относитесь", "какие вы видите недостатки", "есть ли какие-то правила/best practices которые вы используете при работе с технологией Х" и т.д. Задавать вопросы которые обычно гуглятся, смысла мало. Потому что любой нормальный человек их гуглит.

Довольно часто (смотря от конкретного технологии/фреймворка) можно снова использовать задания на анализ фрагментов кода, например для AngularJs, Entity Framework, t-SQL - можно спросить, что делает такой-то код и как бы вы его улучшили.

Еще один классный метод проверки текущего опыта - это практические/наглядные задания. Пример по SharePoint: однажды мне открыли 14 hive в Проводнике и спросили, какие папки какую функцию выполняют и как я их использую. Можно было бегать по папкам. На мой взгляд, офигенный вопрос, много что позволяет узнать о претенденте.


Что не надо спрашивать на собеседовании


На мой взгляд:
  1. Оффлайновые задания. Это вообще полный бред. Во-первых, невозможно проверить, что человек выполнил это сам, поэтому большого смысла давать эти задания все равно нет. Во-вторых, это категорически неверно - требовать от человека расхода большого количества его времени при том факте, что вы его возможно не возьмете. Я лично такие компании обхожу стороной.
  2. Алгоритмы. Обычный программист почти никогда не сталкивается с необходимостью знать алгоритмы или решать алгоритмические задачи. Все это либо уже в существующих библиотеках, либо гуглится. Более того, алгоритмов ограниченное количесто, и на решение большинства алгоритмов довольно легко натренироваться. Прочитал пару книжек, порешал задачки, и все, на собеседовании можно выглядеть буквально гением (на самом деле им даже отдаленно не являясь). Причем я бы даже наоборот, с подозрением относился к людям, которые щелкают разные хитроумные алгоритмические задачи. Потому что они же понапишут потом такой код, который никто не поймет и не сможет поддерживать :)
  3. Глубины теории. Например про C#: Чем абстрактный класс отличается от интерфейса, value type от reference type, ковариантность от контравариантности и т.д. Можно не знать ни одного ответа (или плохо уметь их формулировать), и прекрасно уметь кодить при этом. И наоборот, любой кто прочитал например Джона Скита "С# in Depth" будет на таких вопросах выглядеть абсолютным экспертом, даже не имея никакого практического опыта с C#... Да я думаю даже выпускник вуза, посещавший лекции по C#, на такие вопросы ответил бы лучше, чем я, человек 8 лет пишущий на этом языке почти каждый день (как минимум, если бы я Скита не читал).


Заключение


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

Что вы думаете по этому поводу? Буду рад услышать ваши мысли в комментариях!

12 комментариев:

  1. В целом совсем согласен, кроме ненужности офлайн заданий. Многих людей отсеивали именно по ним.

    ОтветитьУдалить
    Ответы
    1. Ага-ага, любые разумные люди которым дорого их время очень хорошо отсеиваются на оффлайн заданиях. Я думаю это 90% всех Senior Developers. Сразу можно судить о том, кто у вас работает ;)

      Удалить
    2. Тоже не понимаю зачем они нужны, хотя раньше давал такие задания. Смысла от них действительно немного. Вместо конкретно этого этапа, достаточно на самом собеседовании спросить как бы он решал эту задачу, какие подходы. Задать наводящие вопросы "А что если?"...

      Удалить
    3. Сразу можно судить о том, кто у вас работает ;) - верно подмечено. почти все сеньёры от нас уезжают :)
      тестовое задание даем удаленщикам, он вроде и сеньер и в резюме много страшных слов, но код говорит обратное.

      Удалить
    4. Резюме никогда не был особым показателем. Бывает же как: вот человек лентяй, или рукожопый например.

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

      Во-втором случае, видишь что человек старается, но вот не получается у него, и все тут. И выгонять вроде жалко: к примеру, семья у него, и т.п.

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

      Вот к примеру предположим, что я хороший разработчик. Я знаю, что такие как я - "товар" ценный. Потому что я могу работать в 5-10 раз быстрее Junior'а и код будет лучше и правильнее, багов будет меньше, и т.д. Я это знаю, потому что я сам был Junior'ом, и плюс я на работе с ними каждый день работаю, каждый день их (Junior'ов) коммиты вижу.

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

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

      И например из 2-3 компаний неожиданно приходят письма: потратьте на нас день своей жизни и выполните наше тестовое задание. Моя реакция: "Да вы чо с ума сошли, идиоты? У меня работа, семья, домашние дела, всякие opensource проекты, спортом заниматься надо, чтоб живот не рос, да мало ли полезных дел? И возможно вы мне еще и не подойдете. И ради чего?"

      Один раз живем, Алексей. Выкидывать несколько дней своей жизни на тестовое задание, которое нафиг по сути никому не нужно... С какой стати?

      Или может быть вы оплачиваете время затраченное на их выполнение? :) Я думаю, нет. А мое время кое-что стоит. Причем немало так стоит, на самом деле.

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

      А удаленщики элементарно проверяются по скайпу. Это в некотором роде даже удобнее: ведь есть тулзы из серии coderpad, где можно наблюдать за тем, как человек пишет код, и т.д. Я например когда собеседовался в некоторые финские компании будучи в России, проходил в том числе технические собеседования по скайпу. Никаких неудобств.

      Удалить
    5. у нас скайп запрещен безопасниками, у нас с этим вообще печаль :) а вообще мне кажется сеньеров ищут через знакомых. А кого попроще через тестовые задания. Не всегда есть бюджет на сеньера. Да и тестовое задание - это не обязательный для всех шаг. Кстати больше предпочитаем посмотреть на git hub, бывает люди уже делали задания для других компаний.Или у них вообще есть свой проект.

      в общем я с вами согласен :)

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

    ОтветитьУдалить
    Ответы
    1. Ну а что ж вы людей не по трудовому кодексу заставляете работать? :)
      На самом деле я согласен насчет вменяемости, может быть это и не настолько просто, но данный пост относится прежде всего к техническим собеседованиям, где главное проверить знания. А вменяемость проверяется наверное главным образом на собеседованиях с HR.

      Удалить
  3. Еще причиной отказа может быть не соответствие позиции. Я проходил собеседование в МС на премьер поддержку. Мне отказали т.к. предположили что на этой позиции я долго не задержусь и она мне будет не интересна. Если честно я и не скрывал что хочется более интересной работы, но говорил что был бы рад начать с этой позиции. Готов продержаться определенное время а дальше , подготовив замену уйти выше.
    Не срослось:(

    ОтветитьУдалить
  4. Андрей, недавно посмотрел это видео http://www.youtube.com/watch?v=mB4TKsIz5Sk. Есть ряд компаний, у которых свои активно используемые велосипеды, и там алгоритмы (может без деталей, но какие есть и какие они задачи решают) нужны всем инженерам.

    ОтветитьУдалить
    Ответы
    1. Оптимизация по производительности в веб-разработке на самом деле имеет очень мало с алгоритмами. На 90% это кэш, индексы и предпросчет. Даже если какие-то алгоритмы нужны, это бывает редко и изучается на месте, спрашивать кандидатов эти по сути необязательные вещи - это неоптимально тратить время, свое и кандидата.

      Удалить
  5. Соглашусь и дополню:
    В последнее время всё чаще(раньше не было совсем, сейчас 1-2 на пару десятков) попадаются люди с аккаунтами на гитхабе и контрибут активностью - их рассматриваю в первую очередь, обычно самый адекватный народ

    ОтветитьУдалить

Внимание! Реклама и прочий спам будут беспощадно удаляться.