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

Привет! Меня зовут Дмитрий. У меня за плечами сотни собеседований в поисках талантов, и я хочу поделиться своим богатым опытом и подходами к проведению собеседований, внедрению в проекты и развитию разработчиков. В этой статье мы обсудим собеседования.

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

Последнюю сотню собеседований я провел удаленно, поэтому акцент будет несколько смещен на онлайн‑собеседования.

Поехали!

Этикет и первое впечатление в общении

Первое впечатление в общении — играет ключевую роль. Если кандидат вызвал у вас интерес, важно, чтобы и вы произвели на него положительное впечатление. Это взаимный процесс, и начинать его следует с первых секунд общения.

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

Вот несколько ключевых моментов:

• Визуальный контакт
  
  Общение с реальным человеком всегда более продуктивно и приятно. Поэтому стоит включать камеру во время собеседований. Общаться с черным квадратиком — не самое интересное занятие.

• Позитивное настроение
  
  Дружелюбное и отзывчивое общение создает комфортную атмосферу для обеих сторон. Никто не любит общаться с кем‑то, кто выглядит раздраженным или отвлеченным.

• Внимание к собеседнику
  
  Уважайте время кандидата. Не отвлекайтесь на другие дела, особенно когда кандидат отвечает на ваши вопросы.

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

Лично я перед подключением к собеседованию — выдыхаю, в голове — все рабочее оставляю в стороне, меня ждет общение с новым человеком, возможно даже очень крутым и интересным.

И помните — возможно вам придется продавать свою вакансию кандидату, и если к концу собеседования (высоко оценив кандидата) вы начнете в позитив — может быть поздно.

Дополнительно в последние несколько лет видеовстречи стали неотъемлемой частью разработки, поэтому важно уделить внимание техническому оснащению. Рекомендуется обзавестись качественной веб‑камерой и микрофоном.

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

Начало общения

Часто на начальном этапе интервью HR или я просим кандидата представиться и рассказать о своем опыте. Это помогает установить контакт и создать рабочую атмосферу. Однако важно уметь корректно переключить внимание, если кандидат углубляется в детали.

Один из вариантов — прервать с целью доуточнить что‑то, что упомянул собеседник и что подразумевает краткий ответ, и после ответа уже повести кандидата в своем направлении. Фасилитируйте интервью.

К примеру — кандидат долго рассказывает о своем опыте работы с задачами в jira/gitlab/symfony/etc:

—  вы «извини, прерву тебя — ты упомянул что использовал jira/gitlab/symfony, а какая версия?»
 —  кандидат не помню / не знаю / версия ххх
 —  вы ок, понял, давай тогда перейдем к теме Х

Моя цель на интервью — создать дружелюбную и открытую атмосферу.
Я предпочитаю общение вместо формального допроса.

Чтобы сделать общение более неформальным, я часто предлагаю перейти на «ты», спрашивая: «Не против если перейдем на ты?» иногда добавляю «для упрощения общения». Реакция кандидата на такое предложение позволяет понять его степень комфорта и открытости.

В конце концов, если я решу пригласить человека в команду, мне важно, чтобы нам было комфортно работать вместе.

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

Технические вопросы

Многие, включая меня на моих первых собеседованиях (когда я был юн и зелен), допускают ошибку, пытаясь «поставить в тупик» кандидата или «переиграть/завалить» его, акцентируя внимание на узкоспециализированных вопросах. Однако настоящая цель — помочь кандидату демонстрировать свои сильные стороны.

Каждый из нас имеет свой уникальный набор знаний, опыта и компетенций.
 Поэтому «переиграть» друг друга (исключая начинающих специалистов) может быть несложно. Главное — определить готовность кандидата к развитию, его стремление к знаниям и активность в рабочем процессе.

Моя цель — понять общий уровень кандидата: какие знания и опыт он приобрел за время своей карьеры. Насколько ему интересно развиваться? Есть ли у него жажда новых знаний?

Даже если кандидат не знаком с конкретными инструментами X и Y, но у него богатый опыт и глубокие базовые знания — то это не проблема. Ведь многие специалисты способны быстро и эффективно обучаться.

Так что же спрашивать?

Тут я начну со своего негативного опыта успешных кандидатов:

Теоретики

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

Мой вариант решения:

Важно не знание теории, а умение ее применять и привычка ее применять. А как ты пишешь новые свойства — приватными/публичными/защищенными? А почему так? А как ты понимаешь, когда надо завести новый класс или писать в старом, вот прям в текущем твоем проекте — какие критерии?

Сильные харды, слабые софты

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

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

Мой вариант решения:

Если есть сомнения — то я начинаю задавать вопросы из рабочей жизни:

• Ты считаешь что твой код правильный, но на ревью тебе поставили замечания и ты с ними не согласен — как ты будешь это решать? И потом дополнительные вопросы, в зависимости от ответов — Доказывать? А как? Как долго? Привлекать арбитра? А кого? А как потом не допускать таких кейсов?

• Тебе пришла задача, но ты ее не понимаешь полностью — что ты будешь делать? И потом дополнительные вопросы, в зависимости от ответов — Отложишь? А вдруг она важная? Спросишь? А у кого и как? А если заказчик в отпуске? А если заказчик игнорит?

Умею только кодить

Кандидат отлично все знает по языку разработки. А потом оказывается, что рабочие задачи не ограничиваются языком разработки. Оказывается (сейчас про бек в большей степени, но фронты не далеко ушли) надо знать SQL, уметь в Docker, уметь в Linux, чтобы банально выдать права на директорию, проверить свободное место на диске, погрепать логи своего продукта, понимать очереди и событийные модели. Если кандидат этого не умеет — он замучает команду и лида этими простыми вопросами.

Мой вариант решения:

Разработчик должен иметь широкое видение, естественно в рамках своего джуно‑мидло‑сеньор уровня.

Структура моего собеседования

Временные рамки

У меня выделено 1 час на интервью. Из них:

• 10 минут — вступление, знакомство и переход к техническим вопросам.

• До 40 минут в среднем — обсуждение технических аспектов.

• Оставшиеся 10 минут — рассказ о вакансии и ответы на вопросы кандидата.

Почему именно так?

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

Моя стратегия собеседования

• Темы для опроса
  
  У меня есть определенные темы, которые я обсуждаю с кандидатами. Например, по бекенду (go/php/python) это язык разработки, подходы в разработке, SQL, базовый Linux, понимание Docker (от уровня — слышал, до пишу Dockerfile), понимание как работают очереди, событийные модели, как дебажить и какие инструменты есть/знает.

• Структура вопросов
  
  Я начин аю с базовых вопросов и постепенно усложняю их, чтобы понять глубину знаний кандидата. Например по SQL — вопрос по джойнам → вопрос на группировку и работу с ней (Group BY + Having) → а как делать пейджинг и чем плох limit/offset → а какие варианты пейджинга есть еще → что такое индекс и как готовить → составные индексы → что такое селективность индекса → etc.

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

Заключительная часть:

Если кандидат произвел на меня впечатление, я предлагаю ему обсудить (именно обсудить, не писать код) конкретные задачи, чтобы понять его подход к решению проблем и глубину мышления.

Пример задач:

• Нам надо написать систему деплоя, понятное дело, что в реальности мы возьмем jenkins/gitlab/etc, но давай попробуем порассуждать, как сделать это на php/go/etc. Вот прям от репозитория, до релиза на 100 серверов без даунтайма.

• А давай напишем свою очередь? Понятно дело, что в жизни мы возьмем pgq, rabbit, kafka, но давай попробуем написать свою систему? Что для этого нам надо? БД? Окей, а как работать с ней? Окей, а если у нас 20 вычитывателей и надо чтобы не было дублирования обработки данных?

• А давай напишем свою систему управления фоновыми скриптами? Вот чтобы отказоустойчиво, серверо‑распределенно и так далее.

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

Полемика и обучение во время интервью: Как реагировать?

Когда вы задаёте вопрос на тему Х и понимаете, что ответ кандидата не соответствует действительности, каков ваш следующий шаг?

• Спорить с кандидатом? Это может вызвать оборонительную или негативную реакцию. Нужно ли вам это?

• Обучать на месте? Стоит ли, тратя своё время и усилия, и не всегда получая адекватный ответ в стрессовой ситуации?

Я пришёл к выводу, что обучение во время интервью не всегда оправдано, потому что:

1. Интервью — равноправное общение
   
   Интервью — это диалог между двумя профессионалами. Один предлагает свои навыки и время, другой — деньги и задачи. Это не отношения учитель‑ученик. Исключением является собеседование стажеров и начинающих специалистов, где наоборот, может быть интересно и полезно наблюдать за реакцией кандидата на обучение.

2. Разные реакции на обучение
   
   Не все кандидаты адекватно воспринимают попытки обучения. Некоторые могут реагировать негативно из‑за стресса, другие могут начать спорить, третьи могут воспринимать это лично.

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

4. Стресс
   
   Если кандидат ошибается, акцентирование внимания на этом может только усилить его стресс.

Тем не менее, иногда я делаю исключения. Если я чувствую, что мои комментарии будут полезны для кандидата или если я хочу увидеть его реакцию на критику, я могу высказать своё мнение.

На что еще смотреть

Манера общения

Посмотреть на манеру общения, особое внимание на (кажется что это мелочи, но они очень важные):

• Слова-паразиты
  
  За 60 минут собеседования — они может быть и не помешают, но когда это будешь слышать каждый день в работе — это будет напрягать. Пример «нууууу типа это», «как бы это сказать».

• Четкость мысли
  
  Если там небылинные (прям фантастические) рассказы про приключения или постоянный смех, поток шуток и подобные странности — это тревожный звоночек и возможно не стоит связываться.

• Легкость общения
  
  Иногда клещами не вытянешь информацию — хотите ли вы каждый день заниматься вытягиванием информации?

• Энтузиазм
  
  Видно ли вам, что у кандидата глаза горят? Или, наоборот, он выгорел и устал от своей специализации и придет к вам в команду делиться выгоранием?

С этим человеком ведь предстоит общаться вам очень долгое время и много!

Соответствие знаний и обучаемость

Убедитесь, что знания кандидата соответствуют вашим текущим задачам. Например, разработчик может знать все о сложных аспектах баз данных, но не понимать основ, которые вы используете каждый день.

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

Конец собеседования

Если НЕ подходит

Тут я веду стандартно — «У меня вопросы кончились, давай кратко расскажу тебе о вакансии, и отвечу на твои вопросы». Я кратко рассказываю о вакансии и кратко отвечаю на вопросы.

Суть — уважение. Человек потратил свое время, отвечал на мои вопросы, надо ответить взаимностью. Уважение — важная штука, она должна быть постоянно с нами.

Если подходит

Тут все интереснее — кандидат мне себя продал. Теперь моя задача — продать мою вакансию кандидату.

Как продать?

Для себя я вывел такие пункты:

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

• Четкость информации
  
  Надо уметь четко рассказать о проекте и задачах. Чтобы не экать, не мекать, не вспоминать мучительно долго — какие задачи у вас там были, а какие можно говорить, какие нет, а как их преподнести человеку без контекста? Тут важно сразу сделать себе заготовку — прописать то, что вы расскажете о проекте и компании.

• Полный обзор и широта
  
  Не просто «нуууу мыы это — на пехапе кодим, вот да. Будешь с нами?»
  
  А, к примеру (для php бекенда) — у нас php почти самый свежий, redis, postgresql, pgq, фреймворк symfony, брокер kafka, следуем стандартам psr, работаем с api как по rest, так и по grpc….
  
  Рассказать по инфраструктурные сервисы — у нас полный пакет atlassian — jira, как таск‑трекер, bitbucket для кода и кодревью, confluence для базы знаний, есть teamcity, sentry, docker, sonarqube, vault…..
  
  Рассказать про процесс разработки — у нас скрам/канбан, есть ретроспективы командные/личные, есть кодревью, проверка кодстайла……
  
  Рассказать о команде — у нас столько то разработчиков в команде, есть QA/дизайнеры/аналитики/овнеры/эксплуатация/дба/админы. Показать, что человек не будет оркестром, а есть большая команда профи.
  
  Отметить, что компания довольно большая, и у нас много команд разработки на разных языках.
  
  Рассказать пару примеров крутых задач, которые у вас стоят или были.

• Подача информации
  
  Важно максимально красиво подать вакансию, но так, чтобы это было правдой. Лучше не акцентировать внимание на негативных аспектах, таких как бюрократия, поскольку:
  

  • минусы есть везде и у всех

  • не минусами живут продажи вакансий

  • ну и мы же работаем над устранением минусов? Значит это временная недоработка ?

ЛайфХаки

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

Помогалка вопросов

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

Я провожу собеседования с кандидатами на позиции php/go/python/js/devops, иногда у меня бывает по 3–4 интервью в день, и они идут одно за другим по разным специализациям. В такие моменты настоящим спасением становятся заготовленные списки тем для обсуждения.

В моем случае — это набор Google Doc файлов. Для разработчиков, для devops, для ml.
 Краткий пример файла для разработчиков (покажу как некоторые пункты выглядят в реальности у меня):

• PHP

  • что такое Exception, и чем он лучше или хуже, чем return false/null? Как устроена конструкция try, какие блоки там есть?

  • интерфейсы/приватные данные — в текущем своем проекте, как ты понимаешь, когда надо новый интерфейс завести или пометить данные приватными?

  • ….

• GO

  • горутины — что это? чем отличаются от системных потоков? как работает? как идет обмен данных между процессами?

  • ….

• Python

  • …..

• JS

  • …..

• SQL

  • …..

• Linux

  • …..

• Docker

  • …..

• Софт‑скилы:

  • у тебя на доске задача с непонятной тебе постановкой — что будешь делать? А если заказчик/лид в отпуске или не отвечают? А если задача срочная?

  • конфликт на код ревью (по обе стороны баррикад) — ты написал код, у коллег появились к нему замечания, что будешь делать? А если считаешь замечания не справедливыми? А если наоборот — ты написал замечания, а на них не отреагировали?

  • пришли замечания от тестировщиков по задаче — что ты будешь делать? А если там замечания, которые к задаче не относятся?

  • …..

• и т.д.

В зависимости от опыта кандидата, от языка разработки - по каким то блокам идем, какие то пропускаем.

Помогалка по вакансии/проекту

Также крайне полезно иметь под рукой информацию о текущем техническом стеке и задачах, которые вы можете предложить кандидату. Эти детали часто интересуют кандидатов и могут сыграть важную роль в процессе «продажи» вакансии.

Вместо того чтобы вспоминать на лету и метаться в памяти, думая: «У нас есть Git, Jira, Redis... Что еще? А, да, Elastic и наш собственный S3, что же еще я забыл?....», гораздо проще быстро взглянуть на подготовленный список. Это позволяет дать четкий и уверенный ответ без лишних пауз и «эээ...».

Четкость и уверенность в речи создают профессиональное впечатление и помогают установить доверительные отношения с кандидатом.

Для себя я такой список вывел по разным вакансиям, держу его в GoogleDocs, чтобы он всегда был у меня под рукой с любого устройства.

Если будет интересно — могу попробовать отдельной статьей показать и рассказать об этих помогалках.

Помогалка в оценке кандидата или «скоринг»

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

И тут на помощь приходит «скоринг» — система оценки кандидата.

Если подходить формально, то можно составить список заранее определенных критериев, в качестве шаблона. И по мере прохождения собеседования — отмечать пункты как пройденные, или проваленные. Желательно это делать незаметно для кандидата, чтобы не раздражать и не сбивать с толку.

Можно использовать систему баллов, где за каждую тему/критерий/вопрос можно выдавать некоторое количество баллов. К примеру — минимально приемлемый ответ — 1 балл, а максимально крутой — 3 балла. Сумма баллов — будет оценкой кандидату.

В своей практике я пришел к следующему варианту — либо распечатываю суть резюме кандидата на 1 странице, с 1 стороны, либо в бумажном блокноте на отдельном листе записываю фамилию и имя кандидата.

Далее, по мере прохождения вопросов — оставляю краткие заметки на этих листках, типа:

Иванов Иван
php -> Exception +, private ++, interface -,
sql -> having ~, offset -, пейджинг - -
активный, быстрые ответы, ….

По сути — это краткие ссылки‑ключи на мой Docs файл с вопросами, и простыми оценками хороший ответ (+), супер отличный (++), или плохой (‑), а может быть «так себе, пойдет»(~).

По итогу ряда собеседований у меня остается набор листков, с заметками по каждому кандидату. В случае распечатки — еще и с резюме, зачастую с фото, что упрощает восстановление визуальной памяти собеседов ания.

Помогалка «фильтр».

Помогалка «фильтр» — это предварительный небольшой тест, который оказывается особенно полезным, когда нужно быстро закрыть несколько вакансий, а времени на полноценное собеседование всех кандидатов не хватает.

Процесс начинается, когда HR находит подходящих кандидатов. Далее, важно связаться с ними заранее, предпочтительно через телефонный звонок или веб‑созвон, поскольку текстовая коммуникация в этом случае часто оказывается менее эффективной. HR описывает вакансию, и если кандидат заинтересован, ему задают 5–10 простых вопросов. Ответы на эти вопросы позволяют отсеять явно не подходящих кандидатов. Эти вопросы могут касаться опыта работы с определёнными технологиями или базовых знаний. Например, вопросы могут быть следующими:

1. что значит having в sql?
Ищем в ответе “фильтрация результатов группировки”

2. с какими no-sql БД есть опыт?
Ищем в ответе “redis / mongo”

3. какие методы есть в rest api?
Ищем в ответе “GET POST DELETE PUT PATCH”

4. как посчитать количество 404 ошибок в логе на сервере?
Ищем в ответе “grep wc”, если слышим “awk cut пайп” - тоже не плохо

Если 50–80% этих вопросов успешно закрыты — тогда ставим кандидату уже основное собеседование.

Важно, чтобы тест был относительно простым (оценивать будет HR, который не является разработчиком) и быстрым для прохождения — длительностью на пару/несколько минут.

Напоминаю, что наша цель — выявить подходящих кандидатов, дать им возможность проявить себя, а не отсеивать их на раннем этапе. Потому фильтр должен отсеивать прям совсем не подходящих кандидатов.

Что я сознательно пропустил

Онлайн-коддинг

Я не сторонник данного подхода. В обычной жизни у нас своя любимая IDE, со своими настройками, плагинами. Мы можем использовать AI помощников, stackoverflow и прочее. В общем — настроенное окружение и изученный проект.

В условиях онлайн‑редактора на собеседовании доступа ко всем этим ресурсам может не быть, что лишь усиливает стресс.

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

Тестовые задания «на дом»

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

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

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

• Возможность использования AI-инструментов, таких как ChatGPT, при решении заданий ставит под вопрос ценность такой оценки. Что именно мы тогда оцениваем?

Итоги

Собеседование — это больше, чем проверка навыков; это важное взаимодействие, формирующее будущее компании и карьеры кандидата.

Каждый кандидат — уникальная личность, и ваша задача — помочь раскрыть их потенциал.

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