Какие вопросы задавать программистам на собеседовании

Часто, при собеседовании кандидатов на позиции программистов, сосредотачиваются на технических вопросах, типа «Зачем нужен виртуальный деструктор?», предлагают разобрать какую-нибудь кусочек кода с хитрым синтаксисом, который редко встречается в реальной жизни, или просто дают тестовое задание. В результате какой-нибудь студент-олимпиадник может отлично пройти интервью, а человек с 10 годами работы нет. Между тем, далеко не факт, что студент, начитавшийся книжек, будет эффективно работать, а не тратить время на рассказы неразумному начальству «как правильно программировать» и разработку очередного красивого четырехколесного велосипеда.

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

Список моих вопросов при собеседовании программистов ниже:

1. Попросить рассказать о разрабатываемом ранее продукте, зачем он и для чего/кого. Если человек реально работал над проектом, то он должен хорошо понимать зачем он, кто его пользователи и т.п.
2. Что сделал на прошлых местах работы? В резюме часто просто пишут про проект целиком. Возможно, соискатель разрабатывал его архитектура и писал ядро, а может просто нарисовал About диалог.
3. Какая была роль в команде? Чем занимались другие люди? Интересно узнать, как человек видит себя в проекте и команде.
4. Какие были процессы разработки? Общий вопрос для начала, чтобы понять направление дальнейшего диалога.
5. Были ли требования к продукту? Откуда они брались? Были ли аналитики, product manager и т.п.? Оценка умения работать по требованиям, а не городить отсебятину по принципу «я лучше знаю».
6. Кто осуществлял декомпозицию больших задач на подзадачи? Сразу понятно, какая роль была на прошлой работе.
7. Кто оценивал трудозатраты по задачам? Часто ли ошибались? Выясняем опыт разработчика в оценке задач, если такого опыта нет, то это не очень хорошо.
8. Использовались ли Unit Tests? На мой взгляд это полезная практика, уменьшающая число багов. Хорошо, если кандидат ее использовал. К сожалению, часто приходится слышать на собеседовании ответ: «Да я хотел использовать, но времени на написание тестов никогда не выделяли.»
9. Были ли ночные билды, ночные прогоны автотестов? Показывает, что разработка была не совсем коленочная. Скорее всего, есть привычка не ломать сборку своими коммитами.
10. Мнение о той или иной процедуре в процессе разработки. Интересно послушать мнение о процессах. Если ответ в стиле: «Начальство самодуры, только мешают работать со своими кодревью», то имеет смысл задуматься 🙂
11. Были ли процедуры code review? Приходилось ли быть ревьювером? Если ревьювером быть не приходилось, это показатель не самого высокого уровня.
12. Использовалась ли система контроля версий? Была ли разработка отдельных фичей в отдельных ветках? Если не использовали совсем, то какой-то совсем анахронизм. Если все делали в одной ветке, то можно предположить проблемы с мержами в будущем и боязнь использования веток.
13. Что такое TDD? Не все такой подход одобряют, но можно задать кандидату вопрос: «Почему это хорошо это или плохо?»
14. Были ли процедуры типа Gated check-in, проверка собираемости или тестов при коммитах? Дает понять насколько зрелый процесс разработки был на прошлом месте работы соискателя.
15. На собеседовании имеет смысл спросить соискателя про отношение к «шаблонам по Александреску» и подобным стили программирования. Принцип KISS никто не отменял 🙂
16. Что сам кандидат спросит про работу и процесс в конторе? Показывает заинтересованность в работе, что реально интересует кандидата в новой работе. Некоторым важен процесс разработки, некоторым продукт, некоторым график работы, а есть такие, которым на все пофиг, лишь бы взяли.

Все новости сайта в телеграм канале: @CTO_in_Action