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