Andrew.White
New member
За последние семь лет я провёл больше двухсот технических интервью и сам сходил примерно на сорок. И честно скажу: каждый раз, когда я открывал задачу про переворот бинарного дерева или поиск цикла в графе, мне хотелось закрыть ноутбук и уйти. Потому что мы нанимали не олимпиадников, а людей, которые будут читать чужой код, спорить на код-ревью и чинить прод в пятницу вечером. Именно поэтому два года назад я переписал весь процесс собеседования под формат, который укладывается в два часа и не содержит ни одной задачи с LeetCode.
Главная беда алгоритмических секций в том, что они измеряют навык, который в реальной работе нужен примерно никогда. Да, иногда приходится думать о сложности, но гораздо чаще ты разбираешься, почему у клиента падает интеграция, и почему тесты проходят локально, но не проходят в CI. Ещё один минус: сильные кандидаты с десятилетним опытом просто отказываются тратить вечер на подготовку к задачкам. Я потерял так минимум трёх отличных инженеров, пока не понял, что фильтр работает против меня.
Мой формат выглядит так. Первые двадцать минут — обычный разговор про опыт: что делал, за что отвечал, что было самым сложным решением за последний год. Дальше сорок минут живого кодинга, но не в вакууме, а на нашей реальной кодовой базе. Я беру небольшой баг или маленькую фичу и прошу кандидата сделать её в паре со мной. Потом тридцать минут код-ревью: показываю настоящий пул-реквест и слушаю, что человек о нём думает. И последние двадцать минут отдаю кандидату — пусть спрашивает про команду, процессы, техдолг и то, как мы принимаем решения.
Что я смотрю в эти два часа? В первую очередь — как человек задаёт вопросы. Хороший инженер не бросается писать код, он сначала выясняет контекст, границы задачи и странности в требованиях. Дальше смотрю на поведение в незнакомом коде: умеет ли он ориентироваться по тестам, логам и истории коммитов или ждёт, что я всё объясню. И наконец — на честность. Фраза «я не знаю, но вот как я бы это выяснил» стоит для меня дороже уверенного наугад ответа.
Практические советы тем, кто захочет повторить. Дайте кандидату его привычный редактор, а не свой, и разрешите гуглить и смотреть документацию — это ровно то, что он будет делать на работе. Делайте задачу слегка двусмысленной, как в жизни, и смотрите, как он уточняет. Обязательно работайте в паре: молчаливое кодирование в тишине не показывает ничего, кроме стрессоустойчивости. И держите тайминг жёстко, иначе разговор уползёт в приятную болтовню и вы ничего не проверите.
Чего точно не стоит делать — так это белых досок, задачек на смекалку и домашних проектов на восемь часов без оплаты. Последнее ещё и просто неуважительно: вы просите бесплатно сделать кусок работы, а потом удивляетесь плохой репутации компании на рынке. И не превращайте интервью в допрос: кандидат тоже вас оценивает, и это нормально.
Результатами я доволен. За два года по такой схеме я нанял двенадцать человек, и ни один из них не оказался ошибкой найма. Отказов на этапе интервью стало заметно меньше, а те, кому мы не подошли, всё равно уходили с хорошим впечатлением и иногда рекомендовали нас знакомым. Экономия времени тоже ощутимая: два часа вместо трёх раундов и тестового задания. Самое ценное, что мы получаем, — это разговор о работе, а не экзамен по учебнику.
Если вы до сих пор гоняете кандидатов по алгоритмам просто потому, что так делают все, попробуйте один раз провести двухчасовое интервью на реальной задаче. Думаю, вы удивитесь, сколько полезного узнаете о человеке. А теперь вопрос к форумчанам: какая задача или вопрос на собеседовании лучше всего раскрыли перед вами настоящего инженера — и в какую сторону, хорошую или не очень?
Главная беда алгоритмических секций в том, что они измеряют навык, который в реальной работе нужен примерно никогда. Да, иногда приходится думать о сложности, но гораздо чаще ты разбираешься, почему у клиента падает интеграция, и почему тесты проходят локально, но не проходят в CI. Ещё один минус: сильные кандидаты с десятилетним опытом просто отказываются тратить вечер на подготовку к задачкам. Я потерял так минимум трёх отличных инженеров, пока не понял, что фильтр работает против меня.
Мой формат выглядит так. Первые двадцать минут — обычный разговор про опыт: что делал, за что отвечал, что было самым сложным решением за последний год. Дальше сорок минут живого кодинга, но не в вакууме, а на нашей реальной кодовой базе. Я беру небольшой баг или маленькую фичу и прошу кандидата сделать её в паре со мной. Потом тридцать минут код-ревью: показываю настоящий пул-реквест и слушаю, что человек о нём думает. И последние двадцать минут отдаю кандидату — пусть спрашивает про команду, процессы, техдолг и то, как мы принимаем решения.
Что я смотрю в эти два часа? В первую очередь — как человек задаёт вопросы. Хороший инженер не бросается писать код, он сначала выясняет контекст, границы задачи и странности в требованиях. Дальше смотрю на поведение в незнакомом коде: умеет ли он ориентироваться по тестам, логам и истории коммитов или ждёт, что я всё объясню. И наконец — на честность. Фраза «я не знаю, но вот как я бы это выяснил» стоит для меня дороже уверенного наугад ответа.
Практические советы тем, кто захочет повторить. Дайте кандидату его привычный редактор, а не свой, и разрешите гуглить и смотреть документацию — это ровно то, что он будет делать на работе. Делайте задачу слегка двусмысленной, как в жизни, и смотрите, как он уточняет. Обязательно работайте в паре: молчаливое кодирование в тишине не показывает ничего, кроме стрессоустойчивости. И держите тайминг жёстко, иначе разговор уползёт в приятную болтовню и вы ничего не проверите.
Чего точно не стоит делать — так это белых досок, задачек на смекалку и домашних проектов на восемь часов без оплаты. Последнее ещё и просто неуважительно: вы просите бесплатно сделать кусок работы, а потом удивляетесь плохой репутации компании на рынке. И не превращайте интервью в допрос: кандидат тоже вас оценивает, и это нормально.
Результатами я доволен. За два года по такой схеме я нанял двенадцать человек, и ни один из них не оказался ошибкой найма. Отказов на этапе интервью стало заметно меньше, а те, кому мы не подошли, всё равно уходили с хорошим впечатлением и иногда рекомендовали нас знакомым. Экономия времени тоже ощутимая: два часа вместо трёх раундов и тестового задания. Самое ценное, что мы получаем, — это разговор о работе, а не экзамен по учебнику.
Если вы до сих пор гоняете кандидатов по алгоритмам просто потому, что так делают все, попробуйте один раз провести двухчасовое интервью на реальной задаче. Думаю, вы удивитесь, сколько полезного узнаете о человеке. А теперь вопрос к форумчанам: какая задача или вопрос на собеседовании лучше всего раскрыли перед вами настоящего инженера — и в какую сторону, хорошую или не очень?