За одиннадцать лет в разработке я сидел по обе стороны стола: сам ходил на собеседования, когда выгорал и искал новые вызовы, и проводил их сам, наверное, около трёхсот раз. И вот что я заметил: сильнее всего сыпятся не джуны и не мидлы, а именно сеньоры. Причём не на алгоритмах и не на вопросе про переопределение equals. Они падают там, где нужно говорить о цене собственных решений.
Причина проста. Джун отвечает на вопрос, мидл отвечает и объясняет, а сеньора просят защитить выбор перед лицом неопределённости и чужих интересов. Это уже не проверка знаний, а проверка мышления, и заготовки из интернета тут не работают. Ниже — те пятнадцать вопросов, которые я чаще всего задаю сам и на которых чаще всего вижу, как уверенный кандидат начинает заметно плыть.
Первый блок — про решения и компромиссы. Почему в вашем проекте именно эта база данных, а не альтернатива? Что вы сознательно потеряли, выбрав этот подход? Где ваше решение перестанет работать при росте в десять раз? Меня всегда удивляет, когда человек рассказывает про архитектуру как про святую истину. Сеньор знает, что любое решение — это обмен, и умеет назвать цену: сложность эксплуатации, время выхода на рынок, стоимость найма людей под стек.
Второй блок — про деньги и метрики, и здесь сыпется больше всего народу. Сколько стоит час вашей команды? Какой была ваша самая дорогая ошибка и во сколько она обошлась бизнесу? Как вы понимаете, что ваша работа приносит пользу, а не просто закрывает тикеты? Недавно я сам срезался на вопросе про ROI от рефакторинга: честно рассказал про читаемость и меньшее число багов, а интервьюер ждал цифр и связи с выручкой. Было обидно, но справедливо — я говорил языком разработчика, а слушали меня языком бизнеса. Именно после того случая я стал заканчивать ответы фразой о том, что это даёт компании, а не только команде.
Третий блок — про провалы и техдолг. Расскажите про самый крупный факап, который был именно вашей виной. Как вы решаете, что пора платить по счетам техдолга, а что можно потерпеть ещё год? Что вы сделали после разбора инцидента, чтобы он не повторился? Тут важно не наличие ошибки, а её разбор. Кандидат, у которого в анамнезе нет ни одного крупного провала, обычно либо не работал на реальных нагрузках, либо не признаёт своей роли в случившемся.
Четвёртый блок — про людей, коммуникацию и умение держать удар. Прод упал в пятницу вечером, ваши действия? Как вы объясните руководителю без технического бэкграунда, почему релиз надо сдвинуть? Как поступите, если тимлид настаивает на решении, которое вы считаете ошибочным? Кого вы вырастили за последний год? Заметьте, почти ни один из этих вопросов не про синтаксис. Зато каждый — про зрелость и способность договариваться.
Что я советую делать, если вы идёте на такие интервью. Первое: соберите не список технологий, а пять историй — про победу, про провал, про спор, про спасённый проект и про наставничество. Второе: считайте. Хоть приблизительно знайте бюджеты, сроки, размеры команд и метрики, которые двигали. Третье: не бойтесь говорить, что не знаете, но рассуждали бы так. Честность вместе с ходом мысли ценится выше уверенного блефа. Четвёртое: задавайте встречные вопросы про контекст, без него любой ответ превращается в гадание. И пятое: уточните заранее грейд, вилку и то, кто принимает финальное решение, чтобы не гадать уже после.
В итоге я давно перестал воспринимать такие собеседования как экзамен и стал воспринимать их как разговор двух взрослых людей о работе. Это сильно снижает тревогу и, как ни странно, повышает шансы: ты начинаешь звучать как коллега, а не как студент на защите. А теперь вопрос к вам, форумчане: какой вопрос на собеседовании однажды застал вас врасплох — и чему он вас в итоге научил?
Причина проста. Джун отвечает на вопрос, мидл отвечает и объясняет, а сеньора просят защитить выбор перед лицом неопределённости и чужих интересов. Это уже не проверка знаний, а проверка мышления, и заготовки из интернета тут не работают. Ниже — те пятнадцать вопросов, которые я чаще всего задаю сам и на которых чаще всего вижу, как уверенный кандидат начинает заметно плыть.
Первый блок — про решения и компромиссы. Почему в вашем проекте именно эта база данных, а не альтернатива? Что вы сознательно потеряли, выбрав этот подход? Где ваше решение перестанет работать при росте в десять раз? Меня всегда удивляет, когда человек рассказывает про архитектуру как про святую истину. Сеньор знает, что любое решение — это обмен, и умеет назвать цену: сложность эксплуатации, время выхода на рынок, стоимость найма людей под стек.
Второй блок — про деньги и метрики, и здесь сыпется больше всего народу. Сколько стоит час вашей команды? Какой была ваша самая дорогая ошибка и во сколько она обошлась бизнесу? Как вы понимаете, что ваша работа приносит пользу, а не просто закрывает тикеты? Недавно я сам срезался на вопросе про ROI от рефакторинга: честно рассказал про читаемость и меньшее число багов, а интервьюер ждал цифр и связи с выручкой. Было обидно, но справедливо — я говорил языком разработчика, а слушали меня языком бизнеса. Именно после того случая я стал заканчивать ответы фразой о том, что это даёт компании, а не только команде.
Третий блок — про провалы и техдолг. Расскажите про самый крупный факап, который был именно вашей виной. Как вы решаете, что пора платить по счетам техдолга, а что можно потерпеть ещё год? Что вы сделали после разбора инцидента, чтобы он не повторился? Тут важно не наличие ошибки, а её разбор. Кандидат, у которого в анамнезе нет ни одного крупного провала, обычно либо не работал на реальных нагрузках, либо не признаёт своей роли в случившемся.
Четвёртый блок — про людей, коммуникацию и умение держать удар. Прод упал в пятницу вечером, ваши действия? Как вы объясните руководителю без технического бэкграунда, почему релиз надо сдвинуть? Как поступите, если тимлид настаивает на решении, которое вы считаете ошибочным? Кого вы вырастили за последний год? Заметьте, почти ни один из этих вопросов не про синтаксис. Зато каждый — про зрелость и способность договариваться.
Что я советую делать, если вы идёте на такие интервью. Первое: соберите не список технологий, а пять историй — про победу, про провал, про спор, про спасённый проект и про наставничество. Второе: считайте. Хоть приблизительно знайте бюджеты, сроки, размеры команд и метрики, которые двигали. Третье: не бойтесь говорить, что не знаете, но рассуждали бы так. Честность вместе с ходом мысли ценится выше уверенного блефа. Четвёртое: задавайте встречные вопросы про контекст, без него любой ответ превращается в гадание. И пятое: уточните заранее грейд, вилку и то, кто принимает финальное решение, чтобы не гадать уже после.
В итоге я давно перестал воспринимать такие собеседования как экзамен и стал воспринимать их как разговор двух взрослых людей о работе. Это сильно снижает тревогу и, как ни странно, повышает шансы: ты начинаешь звучать как коллега, а не как студент на защите. А теперь вопрос к вам, форумчане: какой вопрос на собеседовании однажды застал вас врасплох — и чему он вас в итоге научил?