О технических собеседованиях

Часть 3. Еще немного идей

4 min readNov 30, 2021

В этой статье я продолжаю фиксировать свое видение хороших техсобеседований. Это идеи, которые мне показались интересными. Большинство я подсмотрел, некоторые сформулировал сам.

Эта серия состоит из трех частей:

Предпосылки
Пример собеседования
Еще немного идей (вы здесь)

code review

В этой секции мы отсеиваем людей без ч̶у̶в̶с̶т̶в̶а̶ ̶п̶р̶е̶к̶р̶а̶с̶н̶о̶г̶о̶ понимания, какой код нормальный для дальнейшего развития.

Итак, нам нужно небольшое количество кода. Буквально на один-два экрана. Код должен компилироваться. И работать в простейшем кейсе. Проблема кода должна быть в том, что он плохой. Но не слишком сильно :-)

Возможные варианты:

Создание табличек в базе данных с явным нарушением нормализации просто так.
Код с запашком. Например, метод с пятью параметрами. Или метод с большим количеством if, которые спокойно переписываются в guard clause.
Неидиоматичный код. Например, валидация, сделанная через исключения.
Тест-кейс, который на самом деле ничего не проверяет.

Пример плохого, но не слишком:

⚠️ Как мне кажется, при наличии секции “coding”, секция “code review” в таком виде бессмысленна. Разве что увеличить количество кода до полноценного проекта, но в тайм-лимит тогда можно не влезешь :-(

У меня есть небольшое соображение, что расширенная секция code review может быть полезна для собеседований senior/lead уровней. Ведь им нужно уметь делать ревью. При этом многие не умеют. Кто-то может давать фидбек слишком негативно (я страдал таким раньше), кто-то может вообще не давать фидбек почти никогда.

Подробнее о подходе можно узнать здесь: “Семён Старостин — Техсобес программиста на максималках”

database review

Аналогично ревью кода. Описывается задача, которую решают. Описывается схема бд под эту задачу. Просим найти ошибки.

Какие “ошибки” можно сделать:

Задублировать информацию между таблицами;
Создать словарную таблицу;
Использовать int или uuid в качестве primary key;
Пропустить важный индекс.

Как мне кажется, review требует меньше умственной работы, но в большей степени отображает текущее мировоззрение и навыки человека. Т.е. так проще оценить инженерную культуру, а не умственные способности человека. А это довольно полезно.

Тестовое задание с тайм-лимитом

Это такая версия тестового задания, которую придумали хорошие нормальные ребята. Расскажу как примерно это выглядит.

Вариант наивный. Кандидат договаривается с эйчаром о времени решения тестового задания. Эйчар высылает тестовое задание в назначенное время. Кандидат через два часа высылает решение. Сколько успел, столько и высылает.

Вариант продвинутый. Используется сервис типа hackerrank, где задается ограничение по времени. Из минусов, hackerrank подходит только для кодирования.

Этот вариант куда лучше, чем обычное тестовое задание. Потому что если вы ошиблись с эстимейтом, то с тайм-лимитом все кандидаты будут в равных условиях. Иначе часть кандидатов воспримет всерьез ваши слова “ну там на пару часов”; а остальные будут мучаться днями, доводя решение до идеала.

Кроме того, полу-перфекционистам отсутствие тайм-лимита дает еще большую подлянку. Обычно, когда решаешь задачу — ты можешь оценить, насколько важно сделать её идеально. Но не с тестовым. С тестовым нет никаких ориентиров. В итоге вы заставляете нервничать хорошего человека.

Чтобы еще больше скомпенсировать неравенство кандидатов, сделайте несколько компонентов в тестовом задании. Тогда никому не будет достаточно сильно везти, чтобы его навыки очень совпали с тестовым.

Текстовая коммуникация

Эта штука идеальна для distributed-команд и фанов async-общения.

Выглядит это так:

Кандидату на емейл высылается задача “нужно спроектировать такой-то продукт”. И в письме пометка: постарайтесь не приходить с конкретным решением, мы будем интерактивно обсуждать проект в чате.
Естественно, кандидат, если хочет, может сразу задать уточняющие вопросы.
В назначенное время кандидата добавляют в слак. И начинают крутить-вертить задачу. По сути, это design-секция, но в текстовом режиме.

Я когда увидел такое собеседование вживую — очень сильно удивился и обрадовался. Это невероятно клевая идея даже для обычных команд.

Ведь если у вас хоть немножечко правильно построены процессы, то ощутимая часть вашего общения — это текстовое emails-jira-github-slack. И на удивление, встречаются люди, которые не способны в текстовое общение. Появление таких персонажей — это серьезная проблема для компании. Почему бы их не отсеять?

⚠️ Впрочем, я очень не уверен, стоит ли отсев таких кандидатов затрат на проведение такого интервью.

Эстимирование

Это мне попалось на одном из собеседований для senior+/lead. Суть задания. Дается краткое описание системы, немного набросков UI. Кандидат должен прислать эстимейт с пояснениями. Задача офлайн.

Естественно, главное в подобной проверке — не совпадение чисел. А следующие вещи:

Как хорош навык декомпозиции?
Насколько учитываются все роли (dev, ops, qa, ba/po, pm etc)?
Есть ли базовое понимание статистики?

Если надо поиздеваться, то можно спросить не “сколько это займет?”, а “к какой дате это будет готово, если начать сегодня?”.

⚠️ В очень многих компаниях отсутствует культура эстимирования. И не всегда из-за плохих причин. Поэтому выдавая это задание, нужно очень хорошо проговаривать, какие именно цели вы преследуете при проверке.

Инженерная культура

Эта идея рассчитана скорее на lead/architech, но и к senior тоже немного подходит. Увы, у меня не получается сейчас додумать идею до конца.

Пока что получается всего лишь теоретический вопрос, ответ на который можно заучить. Вопрос выглядит так:

Вы или некто другой некоторое время работали над проектом в одиночку. Проект выстрелил. Теперь на него добавляют ресурсы. Соответсвенно, придет N людей. Нужно подготовить проект таким образом, чтобы дальше можно было активно его развивать командой. Какие вещи нужно сделать/проверить?

Суть этой секции — убедиться, что человек понимает как сделать так, чтобы проект не рассыпался от количества людей и от времени.

Тесты

Экспериментальная идея. Видел один раз как подсекцию, но не срослось. Для некоторых может быть очень актуально.

Нужно попросить человека написать тесты для заданного кода. Если недостаточно сложно, то код должен быть не тестабельным.

Зачем нужна такая секция? Имхо, у людей очень слабые навыки в деле написания тестов, карго-культ везде. Вам действительно критична хорошая инженерная культура? Значит навык писать хорошие тесты вам критичен. И в такой секции также автоматически проверите навык кодирования, так что может coding-секция не нужна.

⚠️ Не давайте слишком простой код для тестирования. Если у человека закономерно возникает вопрос “а будет ли выгода от покрытия этого тестами?”, то у него будет куда меньше мотивации выполнять такое задание

⚠️ Я боюсь, что это слишком строгий отсев для рынка Украины.

Дополнительные материалы

Чужие материалы, которые я нашел:

Также вы можете прочесть другие мои статьи про найм с другого ракурса: