Собеседования — как очередь в муниципальной больнице: все там были, но мало кто потом вспоминает с теплом.
Кто-то берет «100 каверзных вопросов для собеседования» из интернета, кто-то топит за знание фреймворков, кто-то спрашивает разницу между интерфейсом и абстрактным классом. А потом начинается:
-
человек не встраивается в команду,
-
валится на задачах, которые казались элементарными,
-
через три месяца выгорает и уходит,
-
и вы снова открываете вакансию, которую с таким трудом закрывали почти пол года.
И вроде бы «собес прошёл нормально». Ну я что то вроде спрашивал. А он не спрашивал. Ну да, поспорили немножко. Ну да, не понял, зачем DI — но «вроде норм». А потом становится не норм.
Если вы это проходили — читайте дальше.
Это статья — не о том, «как правильно», а о системном, практическом подходе, который помогает:
-
понять, кто вам реально нужен;
-
сформулировать, что и как проверять;
-
провести осмысленное интервью;
-
сделать выводы, основанные не на эмоциях, а на данных.
Один раз — от начала и до конца. Чтобы потом просто адаптировать под роль.
1. Сначала — поймите, кого вы ищете
Первая и самая частая ошибка — непонимание, кого вы ищете. Тогда вам понравится любой, кто не тупит и шутит со старта. Особенно если вы устали и хотите уже закрыть эту вакансию.
Вторая ошибка — искать самого себя. Хочется такого же, как вы, только с перламутровыми пуговицами. Это ловушка. Команды, собранные по образу и подобию одного человека, становятся гомогенным болото: мышление одинаковое, подход одинаковый — и баги, кстати, тоже одинаковые.
Сильная команда — это не клон-фабрика. Это экосистема.
Кто-то глубже в архитектуре, кто-то сильнее в коммуникации, кто-то — быстрее всех локализует баг, который остальные копают полдня.
Третья ошибка — пытаться уместить всё за час. Получается ни о чём: по верхам, бессистемно. Как будто просто поболтали. Хорошо если связано и осмысленно.
Четвертая — ориентироваться только на впечатление. Вроде норм. Не бесит. Окей.
Да, химия важна, но ее легко спутать с привычным паттерном. Нужны структура и сравнимость.
Спросите себя прямо:
Что важнее всего в этой конкретной роли?
-
Харды (глубина, архитектура, практика, инструменты)?
-
Софты (командность, культура, зрелость, умение объяснять)?
-
Стабильность и мотивация (будет ли человек с нами через полгода)?
Часто важны все три. Но почти всегда один из блоков — ключевой.
Например:
-
На поддержку легаси важно: стабильность, усидчивость, выдержка. Харды — на уровне «не накосячь». Софты — чтобы не ссорился с командой.
-
В R&D критичны харды и умение докопаться до сути. Софт — по остаточному принципу.
-
Тимлид без зрелости и без навыков объяснять? Лучше не тратьте время (и команду).
И помните, идеальные кандидаты бывают! На бумаге, у вас в голове, фантазиях HR’а, но не в реальной жизни. И каждый раз, когда вы будете ждать 10 из 10 по всем направлениям, вы будете терять тех, кто подходит на 8, но с потенциалом дорасти до 11.
Ищите не идеального, а подходящего. Под контекст. Под проект. Под команду.
Это не про «снизить планку». Это про «перестать верить в единорога».
Найм — это привычная вам инженерная задача с функциональными требованиями и ограничениями. И лучше взять сильного 80%-кандидата сегодня, чем продолжать ждать мифического идеала и сжигать свою команду без поддержки.
На практике люди чаще жалеют не о том, что наняли «не идеального», а о том, что ждали слишком долго. Пока ждали «того самого» — нормальные, живые, подходящие — ушли в другие команды. Где умеют принимать решения и не верят в сказки.
2. Что вы пытаетесь увидеть: три блока компетенций
Собеседование — это не экзамен и точно не место, где вы можете потешить свое чувство собственной важности. Это инструмент который поможет разобраться «а усилит ли он нашу команду?»
Есть три оси, по которым смотрим:
1. Харды: инженерный подход, мышление, зрелость
-
как думает в незнакомой ситуации,
-
как диагностирует баги,
-
как выбирает решение и почему,
-
насколько прагматичен: не делает из архитектуры фетиш, но понимает, где важно,
2. Софт-скиллы: общение, адекватность, зрелость
-
аргументация без давления,
-
умение принимать критику,
-
объяснение сложного простыми словами,
-
способность договариваться без токсичности,
-
чувствуется ли внутренняя устойчивость.
3. Мотивация и устойчивость: не только «что умеет», но и «куда движется»
-
зачем он вообще здесь?
-
что его драйвит?
-
учится ли? зачем и чему?
-
чего хочет через год?
-
как относится к рутине?
Блок с мотивацией зачастую игнорируют, считают недостаточно важным чтобы потратить 5 минут из драгоценного часа. Человек может пройти по хардам, понравиться по софтам, но потом — погаснет. Не потому что слабый и не тянет. А потому что ожидания и реальность не совпали
3. Готовим вопросы: поведенческие и открытые
Не задавайте вопросов с одним правильным ответом. Вынуждайте кандидата разговаривать с вами.
Поведенческие — это вопросы о том, что человек уже делал или как бы повёл себя в ситуации.
Открытые — это вопросы, на которые нельзя ответить «да/нет».
Плохо: «Ты знаешь, что такое SOLID?»
Хорошо: «Расскажи, где принцип открытости/закрытости реально тебе помог. Или наоборот — не помог. Почему?»
Плохо: «Ты командный игрок?» Хорошо: «Вспомни, как не согласился с решением команды. Что сказал? Что не стал говорить? Чем закончилось?»
Я люблю начинать с 3 китов. Это очень просто и всем знакомо. Но меня не интересуют определения, их можно выучить за 15 минут до собеса. Меня интересует «Зачем?».
«Зачем вообще нужна инкапсуляция?»
А дальше — ещё 3–5 раз «зачем» к каждому ответу. Пока не станет ясно, понимает ли человек суть. Можно и от обратного, «а если не использовать, что будет? а почему это плохо?».
4. Примеры вопросов: по каждому блоку
Харды
-
«Опиши реальный баг, с которым долго возился. Как нашёл, как фиксил, почему именно так?»
-
«Тебе достался легаси, без тестов, без документации, без живых свидетелей. Что будешь делать?»
-
«Как обеспечиваешь качество кода (кроме «я пишу аккуратно»)?»
Софты
-
«Твое решение в ревью раскритиковали. Что сделал?»
-
«Объясни мне, как менеджеру, зачем нужен DI. (Постарайся уложиться в минуту)»
-
«Что для тебя важно в атмосфере команды?»
Мотивация
-
«Что тебя заряжает в разработке?»
-
«Что последнее изучал просто из интереса?»
-
«Какие у тебя цели на год, и как эта роль в них вписывается?»
Не читайте с листа. Подготовьте 5-7 вопросов на каждый блок. Перефразируйте под свой стиль, они должны звучать естественно из ваших уст.
5. Мини-техассессмент: покажите плохой код
Один из лучших коротких форматов.
Берем фрагмент кода — или от нейросети, или из реального проекта (обезличенный, конечно). В идеале он должен нарушать все что только можно (или нужно).
И просто спрашиваем:
«Что здесь не так? Что бы ты сделал?»
Что даёт:
-
как человек читает код,
-
на что обращает внимание,
-
что начинает фиксить первым,
-
как рассуждает в процессе.
Это не экзамен. Это как будто вы вместе на код-ревью. Слушайте не «что знает», а как думает.
6. Как вести интервью
-
Слушайте больше, чем говорите. Это не ваше выступление.
-
Оставляйте место тишине: пусть думает.
-
Задавайте уточняющие: «а почему?», «а как бы ты сделал иначе?», «зачем / для чего?»
-
Обращайте внимание не только на то что говорит, но и как говорит.
-
Слушайте интуицию. Если что то зацепило — там точно что то есть, просто вы еще не поняли что.
7. После интервью — фиксация, матрица, выводы
Заранее потратьте время на составление матрицы компетенций под вашу вакансию. Это не мелочь — это основа объективного найма.
Выберите систему оценки, которая вам ближе:
-
шкала от 1 до 5 или от 1 до 10;
-
вербальная: «не разбирается / плавает / знает / может объяснить / может научить»;
-
или бинарно: «есть / нет» (для must-have требований).
Главное — одна система для всех кандидатов. Так вы получите сравнимые оценки, не зависящие от настроения или памяти.
И заполняйте матрицу на каждом собеседовании, даже если кандидат «не ваш».
|
Навык |
Оценка |
Комментарий |
Red Flag |
|
Архитектура |
3 |
Неуверенно рассуждает |
|
|
Умение объяснять |
5 |
Отлично рассказал про DI |
|
|
Фидбек |
2 |
Не принял замечания в ревью |
Игнор фидбека |
Матрицу можно заполнять по ходу беседы (коротко), а после — дописать. Это станет основой для принятия решения и основой для фидбека.
Храните матрицы. И по отказам тоже. Через год этот человек может снова постучаться — и вы увидите прогресс (или не увидите).
8. Red Flags: отказывайте быстро
Есть сигналы, при которых не нужно думать. Они не «минус», а «не надо»:
-
Не умеет объяснять даже простые вещи.
-
Обесценивает тесты, ревью, документацию.
-
Вечно виноваты «бизнес», «менеджер», «тимлид».
-
Нет ни одного встречного вопроса.
-
Не может обосновать свои решения.
-
Путается в базовых концепциях.
Если что-то зазвенело — запишите. Потом будет понятно, почему.
9. Как начать и применять
-
Идете впервые и страшно? Это такой же навык как и любой другой, и точно так же нарабатывается практикой. Зафакапите ли вы первый собес? Наверняка. Второй? Если отрефлексировали первый — скорее всего нет. Где взять первый собес который «можно зафакапить»? Идете в любой чат с трейни/джунами и спрашиваете кому провести мок собеса с фидбеком. Лучше 2. 5 еще лучше, уйдет мандраж, запомнятся вопросы.
-
Сложно делать все сразу? Попробуйте вдвоем. Но заранее распределите роли. Один ведет, второй подстраховывает, слушает и фиксирует.
-
Храните матрицы. Confluence / Notion / папка — неважно.
-
Раз в квартал делайте ретро по собесам. Что сработало? Почему взяли / не взяли? Какие вопросы дают слабые сигналы?
-
«Не уверен — не бери». Но не ищите 100% попадание. 80% без флагов — часто лучшее, что вы найдёте.
-
Главное — не «правильные ответы», а мышление, подход, зрелость.
-
Помните что собеседование — это зеркало. Оно показывает не только кандидата, но и вас.
Что делать после прочтения
-
Составьте портрет кандидата. Кто нужен на позицию, почему именно он, какие боли он должен закрыть. Иначе это пальба наугад.
-
Составьте матрицу компетенций для этой роли. Потратьте один раз полчаса — работать будет годы. Заполняйте не позже чем через час после окончания. В идеале — в процессе или сразу же. Это поможет обоснованно выбирать и давать развернутый фидбек, а не «как у всех».
-
Подготовьте вопросы, которые помогут понять глубину хардов, софтов и мотивации. Подготовьте чуть больше, на случай если кандидат отвечает односложно и не идет на контакт.
-
Поймите, зачем вы задаете вопросы из предыдущего пункта. Что именно вы хотите узнать из ответа? Что он говорит о человеке?
-
Скорее всего, не удастся уместить все в один час. Это нормально. Разбейте на две сессии. Первая — та, где вы тратите меньше мысленного топлива или где отсеивается большинство. Вторая — для тех, кто прошел. Обычно это хард- и софт-сессии. Если речь о синьорах — можно добавить архитектурную, но это не обязательно.
-
Проведите пилот. Это снимет страхи, выявит недочеты, даст пищу для размышлений.
-
Проведите реальные собеседования, но теперь уже не наобум, а четко и с фиксированным результатом.
-
Верните фидбек всем, кто не прошел. Они тоже потратили свое время. Им было волнительно, но они пришли. А еще они запомнят, что вы — одни из немногих, кто дает обратную связь. И помните про blameless.
-
Выбирайте кандидата на основе подготовленных матриц и портрета. Спокойно, рассудительно, без мук. Отправьте оффер и наслаждайтесь усилением команды.
-
Подпишитесь на мой Telegram-канал CTO: Порядок из хаоса — там еще больше полезных разборов и инструментов, которые можно брать и внедрять.
-
Добавьте ссылку в закладки, скиньте ее тимлиду, в чат команды — и, самое главное, HR’у из той компании, где у вас был самый отвратительный собес. Пусть и они станут чуточку лучше.
И не забывайте:
Хороший найм — это когда вы через год смотрите на команду и думаете: «черт, как же мне с вами повезло». А не: «где ж я так нагрешил?»
ссылка на оригинал статьи https://habr.com/ru/articles/924228/
Добавить комментарий