🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Как же собеседовать эффективно?
Прошлый пост был об антипримерах. Сегодня же я расскажу, какой процесс тех-интервью зарекомендовал себя лучше.
Подготовительный этап
(Если вы-инженер, который проводит техническое интервью.)
Представьте, что вы джун с небольшим опытом. Понимаю, это сложно, сейчас рождаются мидлами, но постарайтесь.
- Откройте среду для разработки, но без подсказок компилятора;
- Сформулируйте задачу, которую необходимо решить. Допустим, это экран из приложения, на котором отправляется запрос в сеть, а данные отображаются в табличном представлении;
- Добавьте требования со звездочкой. Например, что-то закэшировать, преобразовать как-то данные или отсортировать по условиям;
- Напишите максимально джуновское решение. Намеренно сделайте ошибки, опечатки, используйте примитивные подходы и простую архитектуру. Часть задания можно вообще сделать неверно или пропустить.
Настало время интервью
- Кандидат получает текстовое описание вашей проблемы и ваш “джуновский код”;
- Его задача - затюнить это безобразие до наилучшего состояния;
- Вы легко можете направлять, обсуждать идеи, усложнять требования по ходу выполнения и смотреть, как кандидат реагирует на изменения;
- Заранее заготовить несколько фолоу аппов и в зависимости от перформанса и ожидаемого уровня от кандидата давать их как дополнительные задания.
Пример можно найти по ссылке, доступен всем.
Почему этот подход работает?
- Во-первых, я часто использовал этот способ на практике и пока не пожалел ни разу. Оценка грейда была точная и не вызывала вопросов у коллег или руководства;
- Возможность проверить сразу несколько аспектов. Умение решать задачу согласно требованиям, умение видеть проблемы/баги и исправлять их, уровень насмотренности. Также вы можете в любой момент попросить теоретическое обоснование принятых решений;
- Вы проверяете ту работу, которой действительно занимается разработчик бОльшую часть своего времени. Он видит код, читает его, пробует оптимизировать, исправить ошибки, добавляет новую логику;
- Большая свобода в интервью. Возможность подстроиться под уровень самостоятельности кандидата. Задачу можно сформулировать так, что она подойдет для оценки разработчика любого уровня и опыта;
- Не нужны узкие знания, чтобы кандидат решил задачу. Для него процесс будет комфортным и не травматичным, задание ведь уже решено вашим внутренним “джуном”. Если он не смог его улучшить - поздравляю, скорее всего перед вами джун! А пасхалки для гуру всегда можно прикопать поглубже.
Прошу заметить, что данный подход ориентирован на технические этапы.
Есть идеи, как избежать ошибок при найме? Может, просто поставить 5 этапов алгоритмических задач?
PS. Мемы в комментарии)