Гид разработчика по собеседованию

Разработчик Дейв Смит, сейчас работающий в Amazon, написал гид разработчика по собеседованию — подробнейшее руководство о том, как, с кем и о чем нужно поговорить программисту при собеседовании на работу, чтобы узнать действительно важную информацию о компании.

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

Многие разработчики, ищущие работу, задавали мне этот вопрос. За последние 15 лет я работал на семь компаний и проходил собеседование в десятках. Я наконец решил записать вопросы, которые задавал во время этих собеседований, и надеюсь, что другие найдут их полезными.

С кем вы будете говорить?

Во время собеседования вы обычно встречаете трех персон. В зависимости от размера компании, это может быть один человек или несколько:

• инженер-программист
• начальник отдела разработки (тимлид, менеджер среднего звена, директор)
• руководитель компании (вице-президент, руководитель отдела, CTO, CEO)

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

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

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

Вопросы к программистам

1. Как вы узнаете, над чем нужно работать каждый день?

Цель этого вопроса — идентифицировать дисфункцию. Я хочу получить ответы от 2-3 инженеров. Если руководство компании говорит, что они соблюдают определенный процесс, но разработчики о нем не говорят — это признак дисфункции. Если вы получили разные ответы от разных людей — это ещё один признак дисфункции.  В хорошей команде я получаю одинаковые ответы на этот вопрос. Каждый разработчик знает процесс, а он достаточно легок, чтобы поддерживать инженеров, а не подавлять их.

Пример хорошего ответа: “Мы проводим N-недельные спринты, в которых каждый разработчик работает над определенным набором функций и фиксит определенные баги. Каждый день мы сообщаем о прогрессе друг другу. У нас отличный продакт-менеджер, который взаимодействует с заказчиками, чтобы помочь нам расставить приоритеты”.

Пример плохого ответа: “Я прихожу в офис и вижу, что горит. Часто меня прерывают со срочным делом”.

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

2. Что вы используете для управления версиями?

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

Дальше можно задать вопрос о рабочих процессах. Вы используете ветки? Вы предпочитаете merge или rebase? Эти вопросы покажут вам, как они разбираются в выбранных инструментах, что скажет вам многое об их опытности. Будете ли вы “местным git-экспертом” или будете учиться у настоящего Линуса Торвальдса?

Этот вопрос может начать общее обсуждение инструментов, что может привести вас к интересным догадкам.

3. Почему вам нравится здесь работать?

Хорошие ответы: «Я получаю удовлетворение от работы». «Я отлично провожу время на работе». «Мне нравится работать с умными и дружелюбными людьми». «Менеджмент уважает разработчиков».

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

Слабые ответы: «Эта работа оплачивает счета». «Мне не нужно очень усердно работать». «Здесь нет давления». «Большим ошибкам не придают внимания». «(тишина)».

Не думайте, что я выдумал эти ответы. Я действительно слышал такое.

4. Вы пишете модульные тесты?

Будьте внимательны, когда делаете выводы о команде на основе их практики юнит-тестирования. Если команда приходит в восторг от моего вопроса, это хороший знак. Но, с другой стороны, если они не объясняют, почему проводят модульное тестирование или не говорят о недостатках, это может быть признаком слепого догматизма. Если они приводят плохие аргументы о том, почему не пишут тесты, например, “у нас нет времени” — это плохой знак.

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

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

Дальнейшие вопросы:

• Вы предпочитаете модульные тесты или интеграционные?
• У вас есть приемочное тестирование?
• Какие фреймворки вы используете? Они вам нравятся?
• Как долго проходят ваши модульные тесты?

5. У вас есть непрерывная интеграция?

Лучшие команды разработки, которые я знаю, используют Jenkins, Travis и Buildbot.  Если в команде нет непрерывной интеграции, я пытаюсь проверить, знакомы ли они с концепцией. Если нет, то это плохо. Наличие системы постоянной интеграции значит, что команда верит в автоматизацию, что, по моему опыту, является очень хорошим признаком.

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

Следующие вопросы:

• Когда CI сообщает об ошибке, сколько времени занимает её исправление?
• Что вам нравится/ не нравится в вашей системе непрерывной интеграции?
• Сколько времени занимает процесс? Вы пробуете сделать его быстрее?

6. Что вы измеряете?

Это открытый вопрос, который задается, чтобы узнать, вкладывает ли команда силы в измерение своего ПО. Для команд веб-разработки ответы обычно включают метрики производительности: время ответа сервера, пропускную способность, количество пользователей, быстрота реагирования client-side и т.д. Но обсуждение может привести вас к таким вещам, как количество пользователей, говорящих на разных языках, сбои браузера, показатель попаданий/промахов кэша и мириадам других вещей. Если команда не уделила время измерениям, это может означать, что они не используют реальные данные для принятия решений. Они могут быть неопытными оптимизаторами. Я ценю команду, которая использует настоящие, измеряемые данные, чтобы принимать решения, особенно насчет производительности, но это показывает и другие вещи.

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

Опять же, правило о догме применимо и здесь. Если команда кажется зацикленной на метрике, которая, возможно, не дает ценной и полезной информации, и они не могут это объяснить, то это предостерегающий знак.

Дальнейшие вопросы:

• Какие ваши самые важные измерения продукта?
• Какие системы для измерения вы используете? (например, MixPanel, statsd и т.д.)

7. Как вы находите и исправляете баги?

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

Дальнейшие вопросы:

• Как вы приоритезируете баги?
• Какую систему отслеживания ошибок вы используете? (и что вам в ней не нравится)
• Вы используете Excel для отслеживания багов? (неет!)
• Как долго вы исправляете ошибку? (минимум/максимум/в среднем)

8. Какие инструменты для совместной работы вы используете?

По моему опыту, хорошие команды используют много инструментов для совместной работы. Они часто используют чаты (Slack, IRC, HipChat, Jabber), сервисы обзора кода (Gerrit, GitHub, GitLab, Review Board) и, конечно, email. Я ищу признаки того, что каждый разработчик знает, чем занимаются другие. Не в безумных деталях, но в общем. Также мне нравится видеть интеграцию с инструментами совместной работы. Простейший пример: автоматическая отправка письма при сбое сборки. Другой пример для команд веб-разработки: автоматические сервисы входа в систему отправляют уведомлению в комнату чата при возникновении серьезной ошибки или когда ключевая метрика превышает определенный порог.

9. Какие фреймворки вы используете?

Мои любимые ответы входят в две категории: современные вещи и новые для человека вещи.

Если команда скажет, что создает приложение для AIX в Motif, мне будет неинтересно. Но вам, может, и будет. Это глубоко личный вопрос и вы должны подходить к нему с пониманием собственных предпочтений.

Независимо от них важно понимать, почему команда выбрала свои фреймворки. Из-за хайпа? Они меняют фреймворки, как нижнее белье? Их код усыпан осколками от “фреймворка месяца”? Или они застряли в древней версии?

Я хочу понять, насколько свободны разработчики в выборе технологий. Определяет ли его менеджмент? Или он уступает разработчикам? Чтобы понять это, я обычно спрашиваю: “Почему вы выбрали фреймворк X для своего проекта?” Если разработчики не знают ответ, это может быть плохим знаком, ну или они просто не так давно в компании и не застали это решение.

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

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

10. Когда мы можем встретиться?

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

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

11. Когда ваш следующий дедлайн?

Этот вопрос даст вам лучше понять, как на самом деле происходит процесс разработки в компании. Если вы добавите ещё эти вопросы, все станет интереснее:

• Кто установил этот дедлайн?
• Вы уложились в последний дедлайн? Если нет, почему?

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

12. Сколько времени требуется для введения новой системы разработки?

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

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

Вопросы к начальникам отдела разработки

1. Когда вы писали код в последний раз?

Мне нравятся менеджеры с сильным техническим бэкграундом. Без обид, мои друзья с MBA, но я обнаружил, что мне действительно нравятся менеджеры, которые занимались тем же, чем и я.

2. Как вы стали менеджером?

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

3. Откуда ваши инженеры знают, над чем им нужно работать?

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

4. Какое испытание самое сложное для вашей команды прямо сейчас?

Они обычно отвечают, что это нехватка сотрудников. Это общий и очевидный ответ (они же ищут человека на работу), и я спрашиваю их о втором по сложности вызову. Я ищу такие красные флаги, как меняющиеся сроки, проблемы с качеством продукта и межличностные драмы. Вы узнаете красный флаг, как только увидите его. У каждой команды есть проблемы, поэтому ответы будут зависеть от нескольких факторов:

• осведомленность менеджера о проблеме
• желание менеджера быть с вами честным
• серьезность проблем в команде

5. Как вы измеряете индивидуальную производительность?

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

6. Вы проводите формальные обзоры продуктивности?

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

Дальнейшие вопросы:

• Можете рассказать мне, как вы помогли кому-то улучшить свою продуктивность?
• Как вы учите людей во время этих обзоров?

7. Вы делаете ежегодные прибавки к зарплате?

Я хочу быть уверенным, что моя компенсация будет пропорциональна моему вкладу в компанию и что официальный пересмотр будет проводиться по меньшей мере раз в год. Для компаний, где это применяется, я спрашиваю о капитале. Дадут ли мне опционы на акции?

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

• Каков ваш бюджет на прибавки?
• Сколько составила средняя прошлогодняя прибавка по вашей команде (в процентах)?
• Какую прибавку к зарплате я могу ожидать через год? В лучшем случае и в худшем случае.

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

8. Вы оцениваете работников относительно друг друга?

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

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

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

Помните, что не все ненавидят рейтинги. То, что я не встречал таких людей, не значит, что они не существуют.

Дальнейшие вопросы:

• Вы действительно считаете Х% своих работников плохими? Что это говорит о вашем процессе найма? (это смелый вопрос, применяйте осторожно)
• Как вы определяете лучших сотрудников?
• Какие метрики вы для этого используете?
• Откуда вы знаете, что эти показатели верны и определяют лучших?

9. Вы проводите регулярные ретроспективы?

Если да, то как они выглядят? Как часто вы получаете фидбэк от членов вашей команды? Когда в последний раз вы что-то изменили в своем управлении на основе фидбэка от команды?

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

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

Вопросы к руководителям компании

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

1. Как вы финансируетесь?

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

2. Вы прибыльны?

Если да, отлично! Если нет, что в чем состоит ваш план? У некоторых стартапов есть такой план, а другие ищут выхода через приобретение или IPO.

Следующие вопросы:

• Растет ли прибыль за последние несколько кварталов/лет?
• Риски для окупаемости: конкуренты, неожиданные расходы и внезапные падения дохода.
• Как долго компания может функционировать до получения нового капитала.

3. Каково ваше мнение об аутсорсинге?

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

4. Расскажите мне о культуре компании?

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

Некоторые компании воспринимают культуру очень серьезно, и это может быть хорошим знаком. По крайней мере, вы будете знать о ценностях компании. В ином случае вам придется улавливать их из неявных намеков. Культура может быть очень важна. Существует ли там внутренняя борьба? Ценится ли профессионализм, честность, работа в сверхурочное время?

5. Какие гарантии того, что компания будет успешной, у вас есть?

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

6. Расскажите мне о вашей структуре отчетности.

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

Вывод

Собеседования должны быть двусторонними. Убедитесь, что вы получили всю информацию, необходимую для принятия решения, если вас примут на работу. Удачи!