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