О чём стоит спрашивать людей на собеседовании, когда набираешь людей в команду
Когда дорастаешь до уровня, где тебе доверяют нанимать людей в команду, твоё отношение к собеседованию меняется кардинально. Если раньше казалось, что на хорошем собеседовании кандидата заваливают вопросами по внутреннему устройству хэш-таблиц или по памяти заставляют писать красно-чёрное дерево на доске.
Сейчас я смотрю на это иначе. Хард-скилы это конечно хорошо, это база. Если человек не умеет кодить он просто не дойдёт до тех интервью. Но когда мы сидим друг напротив друга, меня интересуют другие вещи.
Вот три главных вопроса, по которым я гоняю кандидатов:
1. Расскажи о самом ужасном куске кода, который тебе приходилось копать на прошлом проекте. Что ты сделал?
Важно, чтоб человек понимал, что любой проект старше полгода становится легаси. Мне нужен прагматизм. Понимает ли человек, почему этот код стал таким (бизнес-требования, спешка, нехватка ресурсов)? Переписал ли он всё втихаря, сломав прод, или точечно закрыл задачу, завёл тикет на техдолг и пошёл дальше?
Умение уважать чужой труд и договариваться с легаси - признак зрелости.
2. Представь, что тебе нужно объяснить менеджеру или клиенту, почему нам нужно потратить две недели не на новые фичи, а на рефакторинг базы данных. Как ты это сделаешь?
Я ищу человека, который сможет объяснить проблему через ценность бизнеса, не ссылаясь на сложные термины.
3. Расскажи про свой самый громкий факап. Когда по твой вине упал прод, удалилась база или утекли данные. Как разруливал?
Я смотрю на реакцию. Спокоен ли человек? Признаёт ли ответственность? Главный критерий - сделал ли он выводы. Если после факапа появились новые алерты, обновилась документация или изменился пайплайн деплоя, то человек растёт.
В конечном счёте, на собеседовании я ищу не ходячую энциклопедию, а коллегу. Если человек умеет признавать ошибки, не боится задавать глупые вопросы и понимает, зачем бизнес вообще платит нам, тогда мы сработаемся.