Регулярно имею дело с собеседованиями: как прохожу, так и провожу их. Расскажу, что с ними не так и как это можно исправить.
Давайте поговорим сегодня на тему технических собеседований в IT. Я хотел бы поделиться своим опытом, рассказать, каким я вижу хорошее собеседование, остановиться на проблемах и ошибках, совершаемых различными компаниями при организации процесса собеседования, и дать набор рекомендаций по улучшению данного процесса. Но сначала давайте знакомиться.
Меня зовут Михаил, я занимаюсь frontend-разработкой, на момент написания статьи работаю в Альфа-Банке. С собеседованиями имею дело регулярно и бываю по разные стороны баррикад: и прохожу собеседования, и провожу их. Проходил собеседования в разных по масштабу компаниях — от стартапов и небольших проектов до больших компаний в индустрии. Случалось также выступать собеседующим в качестве независимого эксперта, помогая товарищам в поиске идеального кандидата. Также регулярно выступаю в роли интервьюера на своем рабочем месте и провел суммарно около 60 собеседований.
Дисклеймеры
Прежде чем перейти к обсуждению проблемы, хочу оговорить некоторые важные моменты во избежание недопонимания:
Без теории. Пишу только о том, с чем сталкивался лично сам, и обязательно подкрепляю тезисы примерами из практики.
Только российский рынок. Что касается собеседований в эталонных иностранных компаниях, то здесь у меня опыт такой: либо собеседование проводили русские сотрудники на русском языке, либо русские сотрудники на английском языке, либо сама компания основана выходцами из России. Так что не считается.
Критикуешь — предлагай. Один из важнейших пунктов этого списка: не ныть, а высказать критику и предложить альтернативу.
Кому будет полезна данная статья:
Интервьюерам она позволит взглянуть на проблему с противоположной стороны и подсмотреть альтернативные практики, которые можно интегрировать в процесс.
Руководители найма увидят новый вектор развития HR-бренда, что будет им чрезвычайно полезно.
Соискатели, я за вас! Отлично понимаю эмоции, которые мы испытывали, и выскажу слова поддержки.
В этой статье не будет:
Обсуждения матрицы скилов для оценки кандидата.
Рекомендаций по организации процесса найма от А до Я, даже в разрезе технической части.
Случай #1 Алгоритмы
Большинство собеседований я проваливаю по одной причине — из-за алгоритмических задач. Моя проблема в том, что нерешенные задачи производят самоусиливающийся эффект: чем чаще я их проваливаю, тем глубже в моем подсознании укореняется мысль, что я никогда не смогу их решить. На данном этапе собеседования начинаю нервничать, и получается швах.
Разумеется, было бы в разы проще, если бы я занялся подготовкой, благо существует масса ресурсов (leetcode, codewars), где можно отточить сей навык. Собственно, я и пытался этим заняться и пришел к следующим выводам:
Трачу много времени на решение. Будучи человеком импульсивным, могу генерировать идеи или решения быстро. Но в отношении алгоритмических задач это не работает. Нужно подумать, порисовать, попробовать, потыкать. Глядишь — и выходной уже прошел.
Через пару дней все вылетает из башки: непрактикуемый навык слабеет. Также считаю навык бесполезным, так как он не применим в моей практике, и сильного желания попасть на работу в FAANG у меня нет.
Многие компании практикуют алгоритмическую секцию в собеседованиях, причем независимо от уровня и масштаба самой компании. Назревает вопрос, откуда появилась такая страсть к алгоритмам на собеседованиях? Думаю, это было как-то так:
В индустрии существует ряд компаний-камертонов, задающих стандарты. Данные стандарты или шаблоны хороши тем, что уменьшают время и когнитивную нагрузку при выполнении операции, а также служат примером, на который можно ориентироваться.
Большие технологические компании, например Google, нанимают на работу высококвалифицированных спецов. Судя по их hr-процессу, кандидат должен уметь вообще все:
computer science,
алгоритмы и структуры данных,
свое направление (frontend, backend, …),
систему задизайнить,
а еще коммуникативные навыки должны быть на пределе.
А что остальные? Создается следующее впечатление: когда речь заходит о формировании процесса найма, то ответственные люди, не желая тратить много времени, копируют схемы других компаний или специалистов. Рассуждают так: ребята знают, что делают, и мы сделаем так же.
Вот в этом суть проблемы: инструмент-то нужно подбирать под конкретную задачу и конкретные условия.
В моей практике, только один провал алгоритмического собеседования не вызвал у меня негативных эмоций. Команда занималась написанием различных парсеров документов для своего продукта — онлайн-учебника. Это явно не моя специальность. Но порадовало то, что ко мне пришел сам собеседующий с честным и объективным фидбеком.
Приведу интересный разговор с моим коллегой по поводу алгоритмических задач на собеседованиях. На своем первом месте работы я спросил коллегу: “Почему на junior позицию постоянно гоняют по алгоритмам, а меня ты не спрашивал? Мы просто беседовали и смотрели мой код. Почему не было задач или чего-то похожего?”
В ответ я услышал, что мол, junior-ов часто гоняют по алгоритмам, потому что собеседующий понятия не имеет, о чем еще говорить с человеком подобного уровня. Свой же подход к собеседованию он описал так: “Мне было важно узнать две вещи: способен ли ты писать код и готов ли ты учиться. Большего и не надо”.
Альтернатива #1 Подмена
В собеседование при поступлении в Альфа-Банк была включена алгоритмическая секция. И что удивительно — я этого не заметил. Мой мозг был легко обманут тем, что мне дали алгоритмическую задачу под видом рабочей, часто встречающейся в практике.
Суть задачи проста: имеется коллекция объектов денежных операций, нужно отсортировать их по датам и составить хеш-таблицу с этими операциями, где даты являются ключами. Просто? Так оно и есть.
Потом я осознал, что на собеседовании абсолютно не нервничал и не боялся провала. Просто в момент решения я переключился в рабочее состояние, будто выполняю рядовую операцию. Данный подход хорош тем, что способен значительно снизить уровень тревоги кандидата. Этот метод я взял на вооружение.
К сожалению, впоследствии, я часто видел задачи на переворачивание матриц, на подсчет лучших ходов на шахматной доске и прочее занудство, вгоняющее меня как в ступор, так и в уныние.
Альтернатива #2 Ну-ка, что ты там написал?
В ходе того же собеседования в Альфа-Банк я увидел еще один интересный тип задач. И уже впоследствии, когда я сам проводил собеседования в Альфу, мне этот тип задач понравился еще больше. Итак, задача — провести код-ревью.
import React from "react";
const ReviewMe = () => {
const [taskText, setTaskText] = React.useState("");
const [tasks, setTasks] = React.useState([]);
const [taskCount, setTaskCount] = React.useState(0);
React.useLayoutEffect(() => {
document.addEventListener("keydown", (event) => {
if (event.keyCode === 13) {
addTask(taskText);
}
});
});
const addTask = React.useCallback((text) => {
const newTask = { id: taskCount, text: text };
setTasks([...tasks, newTask]);
setTaskCount(taskCount + 1);
setTaskText("");
});
return (
<div>
<input
type="text"
value={taskText}
onChange={(e) => setTaskText(e.target.value)}
placeholder="Enter a new task"
/>
<button onClick={() => addTask(taskText)}>Add Task</button>
<div>
{tasks.map((task) => (
<div>{task.text}</div>
))}
</div>
<p>Total Tasks: {taskCount}</p>
</div>
);
};
export default ReviewMe;Мне нравится давать такие задания на интервью по нескольким причинам. Во-первых, кода в подобных задачах — кот наплакал, из-за этого не рассеивается внимание кандидата. Да и вам будет не трудно наклепать таких задач с десяток. Во-вторых, хоть самого кода и мало, но скользких моментов в нем очень много, что позволяет довольно быстро понять, где кандидат буксует и насколько он внимателен. В-третьих, код-ревью — это рутинная задача большинства разработчиков, что позволяет взглянуть на разработчика в условиях, приближенных к боевым. Это тебе не матрицу разворачивать, переворачивать и выворачивать.
Дам совет. Кандидату лучше сразу сказать, чтобы он отнесся к этой задаче как к реальному код-ревью. Он должен высказать все мысли, которыми поделился бы с коллегой.
Таким образом, мы можем:
составить реальный портрет кандидата;
избежать фраз в подведении итогов по задаче типа: “Ой, да я забыл” или ”Да, я хотел сказать, но решил не говорить”.
Рекомендации
Следование моде и бездумное копирование — не самое лучшее решение. Отсеивать кандидата из-за 2–3 нерешенных алгоритмических задач за отведенное время, при том что его основными задачами будут всевозможные перекраски кнопок, на мой взгляд, выглядит не совсем честно.
Не лицемерьте — предоставляйте кандидату реальные задачи или те задачи, которые ему предстоит выполнять в его потенциальной рабочей деятельности. Так будет больше шансов получить объективную картину навыков кандидата, что даст больше фактического материала для оценки его уровня и принятия в отношении его решения.
Случай #2 Тестовые задания
Однажды по ошибке я получил резюме php-разработчика для ознакомления перед собеседованием. Пробежавшись по тексту, я задержал внимание на фразе, которая четко отпечаталась в памяти: “Не присылайте тестовые задания, так как все свои экзамены, лабораторные и курсовые я уже сдал в молодости.”
Концептуально у меня нет претензий к тестовым заданиям — это хороший способ проверить кандидата в деле по следующим причинам:
кандидат имеет больше времени на решение, стресс-фактор минимален;
весь рабочий инструментарий под рукой;
можно посмотреть как кандидат пишет код, выдерживает ли структуру, как документирует код, пишет/не пишет тесты и как их пишет.
Проблема не в самих тестовых задания, в тех, кто эти задания дает и проверяет.
За свою карьеру мне пришлось выполнить около 6 полноценных тестовых заданий, и я столкнулся с однотипными проблемами.
Так что вам надо-то?
Когда собеседовался в JetBrains, моим тестовым заданием было создать react компонент table of content:
К слову, репозиторий с заданием и реализацией.
Задача решаема, но в глаза бросается оформление самого задания. Мне выдали google doc с:
основными заданиями;
дополнительными заданиями;
двумя ссылками: на дизайн документацию и дубль части документации, но в виде pdf.
Дизайн документация и ее pdf-аналог в некоторых моментах противоречили друг другу. Мелочь? Да, но она показывает подход людей к работе. Зачем нужна pdf-ка, если есть спецификация в figma?
В ходе написания статьи я проверил все эти документы: они выглядели по-прежнему. Значит, они не придали значения моим комментариям по этому поводу.
Условия были поставлены следующие: временные рамки на выполнение не ограничены, я волен потратить хоть несколько недель. Я решил сделать только обязательную часть задания, так как не хотел тратить недели своего личного времени на то, по чему даже адекватного фидбека не дадут (я уже имел опыт и сразу почувствовал неладное).
Выполнив задание за 3 дня, послал его и ждал обратной связи около трех недель.
Обратная связь оказалось такой: вы не выполнили даже обязательные задания (но какие — они умолчали) и не справились с дополнительными заданиями, хотя ваше время было не ограничено.
Конец.
Рекомендации
Прежде чем давать кандидату тестовое задание, потратьте время на его грамотное оформление или актуализируйте. Это снизит когнитивную нагрузку на кандидата и уменьшит временные затраты на понимание условий задачи. А вы не будете выглядеть глупо.
Четко оговорите сроки. Нет смысла предоставлять много времени на тестовое задание: уважайте личное время человека. Вряд ли кому-то понравится кодить вечерами ваше задание. Строго говоря, за потраченное на тестовые задания время надо платить.
Предоставьте четкую и объективную обратную связь. Лучше всего — обсуждение выполнения кандидатами тестовых заданий напрямую. Это позволит понять, почему кандидат выбрал данную реализацию и обсудить спорные моменты, причиной которых могло стать: взаимное недопонимание, некорректные формулировки и т.д.
Определитесь. Строго определите список обязательных задач: если задание указано как необязательное, то и не требуйте его непременного выполнения. Делов-то.
Случай #3 Скажи то, что я хочу услышать
Однажды собеседовался в Tele2. В технической его части мне предстояло решить две задачки: одна на переворачивание матрицы (-_-), а вторая — на рефакторинг небольшого приложения. Так как первая задача меня не впечатлила, то рассчитывал разгуляться во второй, ведь это как раз то, что я делаю каждый день.
Задача: есть небольшое todo приложение (не поверите, но тут тоже можно включить фантазию и придумать что-то новенькое), в котором допущены различные ошибки — от верстки до логики. Есть фиксированный список проблем, которые нужно устранить. Начали мы с верстки.
Нужно было привести карточки в порядок (добавить отступы элементам списка) и выровнять контент карточек по горизонтали. Условие одно — нельзя изменять верстку.
Разметка каждой карточки следующая:
<div className="todoCard">
<input type="checkbox" checked={completed} />
<div>{todo}</div>
<div className="removeBtn">x</div>
</div>Мое решение выглядело так: сделать todoCard flex-контейнером и задать removeBtn отступ слева со значение auto. Легко — подумал я. Но интервьюер стал настойчиво задавать вопрос за вопросом, пытаясь выяснить, а какие еще есть способы решения проблемы. Ответ: “Я бы мог все-таки изменить верстку, объединив первые два элемента в блок, и с помощью space-between развести блоки в сторону”, — его не устроил (правила же!). Почесав репу, я признался, что пока ничего в голову не приходит, и интервьюер разочарованно вздохнул.
Позднее я догадался, что можно сделать через grid-ы, но дал комментарий, что это чересчур: так как grid удобнее использовать для создания крупной сетки. Этим комментарием я удивил собеседующего — ему эта идея не казалась странной. Мой social credit продолжал падать.
Далее мы перешли к обработке формы. В своих рабочих проектах я использую библиотеки для работы с формами. В пет-проектах либо сам костылю обработку (через useState), либо беру готовые решения.
Не успел я приступить к написанию кода, как тут же услышал осуждающие комментарии: “А что, без useState не можешь?”, “А там, по-твоему, зря стоит form элемент?”.
К тому моменту я уже привык к формату проведения встречи и понял, что от меня ждут “правильного” решения, которое выглядит так:
...
const AddTodoForm = () => {
const { addTodo } = React.useContext(TodoContext);
const onSubmitHandler = (evt) => {
evt.preventDefault();
const value = evt.target.elements["todo-name"].value;
if (value) {
addTodo(value);
evt.target.reset();
}
};
return (
<div className="addTodoForm">
<form onSubmit={onSubmitHandler}>
<input name="todo-name" type="text" />
<input type="submit" />
</form>
</div>
);
};
...Пришлось воспользоваться логами, так как давно не обрабатывал формы таким образом, но, помня, что такое возможно, реализовал требуемое. Так как реализовал не с наскока и поскольку к тому моменту мой street credibility был уже слишком низок, ребята решили прервать собеседование. Встреча закончилась, но осадочек остался.
Проводя интервью, я стараюсь свести его к диалогу. Мне нравится, когда кандидат рассказывает о собственных решениях и причинах, по которым он сделал именно так. Моя цель — узнать, понимает ли кандидат суть проблемы, ее причины и ограничения выбранного решения. Мне важно услышать ход мыслей кандидата и понять, насколько глубоки его знания. Я не жду от него идеального решения.
К примеру, мне не очень интересно, знает ли кандидат устройство event loop. Когда речь заходит об асинхронности, мы говорим о проблеме, которую асинхронность решает. Спрашиваю, какие еще подходы есть для решения этой проблемы? Какие ограничения у этих подходов? Таким образом копаю вглубь.
Вывод
Искреннее убежден, что в ходе беседы можно многое узнать о человеке. Допрос не требуется. Дайте кандидату объяснить принятые решения, а сами следите за ходом его мыслей и аргументацией. Задавайте вопросы и, если нужно, возражайте. Главное — понять: способен ли кандидат рассуждать и принимать обоснованные решения.
В боевых условиях не всегда рядом окажется коллега с перечнем правильных решений возникшей проблемы. А бизнесу, которому выполненная задача требовалась еще вчера, будет по барабану, как и что вы там нативненько обработали.
Случай #4 Обратная связь
Регулярное прохождение и проведение собеседований могут быть крайне полезными, ведь это возможность для обеих сторон узнать что-то новое.
В ходе интервью, ошибившись, я прошу собеседующего объяснить, в чем была моя ошибка, и рассказать, как следовало сделать и почему. Если собеседование провожу я, то после каждого задания мы с кандидатом разбираем ошибки и недочеты в выполнении задания, или же я высказываю свое мнение по поводу ответа кандидата на теоретический вопрос.
В конце встречи подводятся итоги. Я привык к схеме, практикующейся в банке: есть табличка навыков, которую вы с напарником должны заполнить, оценивая каждый навык по пятибалльной шкале. Также каждый интервьюер пишет обратную связь по кандидату.
Матрица скилов, матрица навыков для собеседования и способы их оценки — отдельные большие темы, выходящие за рамки данной статьи. Там тоже есть свои проблемы, но они другого характера.
Четкого стандарта ОС нет, поэтому каждый пишет, что хочет, но, в основном, это общие впечатление о кандидате, отзыв о его коммуникативных и технических навыках. Подобные комментарии полезны:
командам, в которых открыта вакансия, так как можно понять, насколько им подходит кандидат;
самому кандидату, ведь часть этой информации hr-ы передают как ОС.
Проблема в том, что большинство аспектов собеседования стандартизированы, за исключением самого важного — обратной связи.
Обратная связь важна больше, чем вы думаете, так как она являет собой результат всей вашей работы в направлении найма. Если вы не можете дать четкую и понятную ОС, то по каким критериям тогда вы оценивали кандидата? Если вы понимаете, по какой причине кандидат вам не подходит, то почему бы не структурировать свои выводы и не передать их? Зачем заставлять кандидата гадать, что вам не понравилось? Почему бы не помочь человеку стать лучше? А вы также задумывались над тем, с каким посылом кандидат уйдет от вас?
Последние два вопроса особенно интересны. Не секрет, что IT-компании заботятся о своем hr-бренде и стараются продвигать его всеми силами. Забавно, но за пару дней до написания статьи, я был участником презентации обновленной спецификации по проведению интервью в JS дирекции. По факту, новая версия спецификации была приукрашенной версией предыдущего варианта. Около часа комьюнити собеседующих слушали, как один человек зачитывает эту спеку. В конце прозвучала мысль о важности как данной встречи, так и работ по улучшению процесса проведения интервью, так как одна из целей компании — улучшение и продвижение hr-бренда. К сожалению, до блока обратной связи мы так и не дошли из-за нехватки времени. Жаль, ведь именно этот блок мог бы помочь в продвижении hr-бренда компании.
В случае отказа кандидат всегда испытывает негативные эмоции. Но в ваших силах снизить уровень негатива и направить его в правильное русло. Если предоставить кандидату перечень четких критериев, по которым он не подошел, и список рекомендаций, то это покажет, что:
вам не плевать на него;
конечная оценка была не от балды.
Помните: кандидат может не подойти как вовсе, так и из-за нехватки конкретных навыков. К примеру, вы ищете человека с глубоким пониманием движка, а этот момент отсутствует. И это непременно следует подсветить при обратной связи.
Рекомендации
Протяните руку. Потратьте немного своего времени для написания по возможности развернутой обратной связи по кандидату. Выделите понравившиеся вам моменты, обратите внимание на слабые места и дайте нужные рекомендации. Это охарактеризует вас с лучшей стороны, а сарафанное радио сделает свое дело.
Без воды. Некоторые перечисляют абстрактные рекомендаций в ОС по типу: почитай про архитектуру, настройка CI/CD и прочее, хотя на собеседовании об этом либо речь не шла вовсе, либо кандидат сказал, что этим не занимался. Совет подтянуть все и сразу — абсолютно никчемная рекомендация. Говоря начистоту, в квалификации любого инженера можно найти изъяны, а тем более составить список тем, которые ему следовало бы подтянуть.
Случай #5 Что читаешь?
Крайне редко слышал подобный вопрос на собеседованиях, а жаль, ведь очень важно выяснить у кандидата, какими способами он прокачивает свои профессиональные навыки, помимо выполнения рабочих задач. Благо, таких вариантов масса:
статьи или видео;
курсы;
пет-проекты;
книги;
конференции или митапы.
Данный вопрос чрезвычайно важен, так как показывает уровень мотивации, вовлеченности и стремления к карьерному росту, а также дает представление об психологическом складе человека.
Можно возразить, что и соврать нетрудно. Это справедливое замечание, но в большинстве случаев кандидаты, не занимающиеся самосовершенствованием, отвечают искренне:
“Да я вот научился использовать <НАЗВАНИЕ_ФРЕЙМВОРКА>, и мне большего не надо”;
“Да как-то не интересно все это”;
”Нет, не интересуюсь, а зачем?”;
“Я редко что-то читаю, stack overflow достаточно”.
Понимаю ли я таких людей? Да, так как ситуации бывают разными. Кто-то устал от вечной гонки технологий и решил притормозить, кто-то занялся нашим ремеслом, чтобы заработать денег, а профессиональная сфера ему не слишком интересна. Некоторые и вовсе безамбициозны: выполняют небольшой набор функций, и им этого вполне достаточно.
Это не хорошо и не плохо, потому что разным проектам нужны разные разработчики. Кому-то требуются перекладыватели json-ов, кому-то — формошлепы, а кому-то — разработчики, готовые брать на себя больше ответственность, драйвить разработку.
В любом случае, полезно обратиться к данной тематике, чтобы понять, что за человек перед вами. Обычно я задаю следующие вопросы:
читаешь статьи?
– на каких площадках?
– какая из статей запомнилась больше всего? Почему? Расскажи о своих мыслях после прочтения.
– писал ли сам статьи? Хотел бы? Какие идеи были?какие конференции или митапы посещаешь?
– можешь рассказать о запомнившихся докладах? Чем запомнились?
– был ли доклад, который помог в практике?
– какие спикеры тебе нравятся больше всего? Почему?
– посещаешь ли конференции других направлений? Каких? Почему? Что нового узнал?
– есть ли идея для собственного доклада?занимаешься ли пет-проектами?
– если да, то какими: учебными или бизнес-проектами?
– какие новые технологии опробовал на таких проектах? Какие плюсы и минусы выделил?
– если бизнес-проект, то чему научился в ходе создания? Что удалось, а что нет?
– сможешь показать?
Задача данных вопросов — копнуть поглубже, чтобы узнать какую программу обучения выстроил для себя кандидат. При этом помните: правильного ответа нет, ибо все люди разные, и вовсе не у всех есть потребность постоянно учиться. Исходите из реалий и требований проекта.
Итак
Статья вышла достаточно большой, поэтому резюмирую кратко, как можно улучшить процесс проведения технического интервью:
Не лицемерьте. Составьте набор заданий, максимально приближенных к будущей реальной работе кандидата. Это позволит вам понять его профессиональный уровень и принять решение, подходит ли он вам.
Интервью — диалог, а не допрос. Спорьте и обсуждайте, чем больше вы выясните, тем лучше.
Обратная связь — лицо компании. Наравне с другими процессами найма стоит создать форму и стандарты ОС. Это выставит вас в более выгодном свете на фоне сотен других работодателей как добросовестных и доброжелательных нанимателей.
Спасибо, что дочитали до конца. Надеюсь, вы смогли подчерпнуть для себя что-то новое.
Делитесь своими впечатлениями о технических собеседованиях. Каким вы видите хорошее техническое собеседование? Какие моменты подмечаете в процессе прохождения интервью? Какой у вас какой опыт прохождения технических интервью?
Буду рад вашим комментариям и с удовольствием отвечу на все вопросы.
