Что не так с техническими собеседованиями в IT?

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

Давайте поговорим сегодня на тему технических собеседований в 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-ов, кому-то — формошлепы, а кому-то — разработчики, готовые брать на себя больше ответственность, драйвить разработку.

В любом случае, полезно обратиться к данной тематике, чтобы понять, что за человек перед вами. Обычно я задаю следующие вопросы:

• читаешь статьи?
  – на каких площадках?
  – какая из статей запомнилась больше всего? Почему? Расскажи о своих мыслях после прочтения.
  – писал ли сам статьи? Хотел бы? Какие идеи были?

• какие конференции или митапы посещаешь?
  – можешь рассказать о запомнившихся докладах? Чем запомнились?
  – был ли доклад, который помог в практике?
  – какие спикеры тебе нравятся больше всего? Почему?
  – посещаешь ли конференции других направлений? Каких? Почему? Что нового узнал?
  – есть ли идея для собственного доклада?

• занимаешься ли пет-проектами?
  – если да, то какими: учебными или бизнес-проектами?
  – какие новые технологии опробовал на таких проектах? Какие плюсы и минусы выделил?
  – если бизнес-проект, то чему научился в ходе создания? Что удалось, а что нет?
  – сможешь показать?

Задача данных вопросов — копнуть поглубже, чтобы узнать какую программу обучения выстроил для себя кандидат. При этом помните: правильного ответа нет, ибо все люди разные, и вовсе не у всех есть потребность постоянно учиться. Исходите из реалий и требований проекта.

Итак

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

• Не лицемерьте. Составьте набор заданий, максимально приближенных к будущей реальной работе кандидата. Это позволит вам понять его профессиональный уровень и принять решение, подходит ли он вам.

• Интервью — диалог, а не допрос. Спорьте и обсуждайте, чем больше вы выясните, тем лучше.

• Обратная связь — лицо компании. Наравне с другими процессами найма стоит создать форму и стандарты ОС. Это выставит вас в более выгодном свете на фоне сотен других работодателей как добросовестных и доброжелательных нанимателей.

---

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

Делитесь своими впечатлениями о технических собеседованиях. Каким вы видите хорошее техническое собеседование? Какие моменты подмечаете в процессе прохождения интервью? Какой у вас какой опыт прохождения технических интервью?

Буду рад вашим комментариям и с удовольствием отвечу на все вопросы.