Alex.Miller
New member
За годы работы в IT я провёл больше сотни собеседований — и как наёмный разработчик, и как сооснователь компании. Главная ошибка бизнеса в том, что он ищет не заботливого сотрудника, а «волшебника», который решит все проблемы. Иногда это приводит к абсурду: мы тратим часы на алгоритмические головоломки, но не проверяем, сможет ли человек работать в команде и думать в контексте продукта.
Нажать чтобы Перейти на сайт
Помню случай, когда кандидат блестяще решил тестовое задание и ответил на все вопросы по алгоритмам, но уже через месяц мы поняли, что он не способен обсуждать требования с менеджером. Он считал, что лучший код — тот, который написан «по правилам», а не тот, который решает задачу бизнеса. Тогда мы потеряли почти два месяца. А другой кандидат, который не прошёл наше собеседование из-за строгого чек-листа, позже проявил себя отлично в парном программировании — просто в стрессовой беседе он терялся.
Теперь я вместо испытаний на память использую мини-проекты. Даю реальную задачу из нашего продукта, прошу показать, как он будет проектировать решение, задаю вопросы про узкие места, прошу найти компромисс между скоростью и качеством. Это сразу показывает, как кандидат работает в условиях реальных ограничений: дедлайнов, технического долга и не всегда внятных требований.
Также важно понимать, что разработчик — это не только код. Он должен понимать, как его работа влияет на выручку, клиентов и команду. Поэтому я всегда спрашиваю об ошибках: что он сломал, как чинил, что сделал бы иначе. Это раскрывает больше, чем все тесты на логику. Бизнесу не нужен «звезда», который пишет красивый код в вакууме, нужен человек, который умеет принимать решения и объяснять их.
Узнать подробнее →
Процесс должен быть прозрачным: технари оценивают Hard Skills, бизнес — Soft Skills и ответственность, HR — мотивацию. Вместе мы составляем профиль идеального кандидата до интервью, а после — обсуждаем только факты и примеры поведения. И обязательно смотрим на испытательный срок: первые недели надо работать бок о бок или хотя бы ежедневно ревьюить код. Это лучшая проверка, чем все собеседования вместе взятые.
Поверьте, идеальных кандидатов не существует. Есть подходящие под задачу и контекст. Наша цель — не угадать по тесту, а снизить риск ошибки. Скажите честно: какая проверка кандидата сработала для вас лучше всего — тестовое задание, парное программирование или разговор о прошлом проекте?
По теме советую почитать: ИИ в малом бизнесе: мой опыт и реальные кейсы
Нажать чтобы Перейти на сайтПомню случай, когда кандидат блестяще решил тестовое задание и ответил на все вопросы по алгоритмам, но уже через месяц мы поняли, что он не способен обсуждать требования с менеджером. Он считал, что лучший код — тот, который написан «по правилам», а не тот, который решает задачу бизнеса. Тогда мы потеряли почти два месяца. А другой кандидат, который не прошёл наше собеседование из-за строгого чек-листа, позже проявил себя отлично в парном программировании — просто в стрессовой беседе он терялся.
Теперь я вместо испытаний на память использую мини-проекты. Даю реальную задачу из нашего продукта, прошу показать, как он будет проектировать решение, задаю вопросы про узкие места, прошу найти компромисс между скоростью и качеством. Это сразу показывает, как кандидат работает в условиях реальных ограничений: дедлайнов, технического долга и не всегда внятных требований.
Также важно понимать, что разработчик — это не только код. Он должен понимать, как его работа влияет на выручку, клиентов и команду. Поэтому я всегда спрашиваю об ошибках: что он сломал, как чинил, что сделал бы иначе. Это раскрывает больше, чем все тесты на логику. Бизнесу не нужен «звезда», который пишет красивый код в вакууме, нужен человек, который умеет принимать решения и объяснять их.
Узнать подробнее →Процесс должен быть прозрачным: технари оценивают Hard Skills, бизнес — Soft Skills и ответственность, HR — мотивацию. Вместе мы составляем профиль идеального кандидата до интервью, а после — обсуждаем только факты и примеры поведения. И обязательно смотрим на испытательный срок: первые недели надо работать бок о бок или хотя бы ежедневно ревьюить код. Это лучшая проверка, чем все собеседования вместе взятые.
Поверьте, идеальных кандидатов не существует. Есть подходящие под задачу и контекст. Наша цель — не угадать по тесту, а снизить риск ошибки. Скажите честно: какая проверка кандидата сработала для вас лучше всего — тестовое задание, парное программирование или разговор о прошлом проекте?
По теме советую почитать: ИИ в малом бизнесе: мой опыт и реальные кейсы