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

Привет, Хабр! Меня зовут Роман. Я Senior Java-разработчик в SENSE, больше 7 лет работаю в enterprise-разработке. Занимаюсь созданием высоконагруженных распределённых систем — в госсекторе, медицине и банковской сфере. За это время прошел десятки интервью сам и провёл более 20 собеседований: от junior до senior позиций.

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

Главные редфлаги на собеседовании

1. Интервью как демонстрация власти

У меня был случай на одном собеседовании, когда интервьюер начал разговор с позиции силы: «Я тут провожу, а не вы». На мои ответы он закатывал глаза, а когда я спросил: «Какой ответ вы ожидали? Или в чём именно я не прав?», вместо объяснения последовало холодное: «Вас собеседуют. Здесь вопросы задаю я». После этого диалог перешел на пассивно-агрессивные ноты, а единственным желанием было закрыть ноутбук и уйти. 

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

2. Отсутствие подготовки у собеседующего 

Другая распространённая история — интервьюер приходит без подготовки: он не открывал ни резюме, ни описание вакансии. На одном из собеседований меня спрашивали про Kotlin, хотя в описании вакансии об этом не было ни слова. Я готовился к одним задачам и стеку, а меня спрашивали о технологиях, с которыми я не должен был работать.

Минимум подготовки меняет ситуацию полностью, а занимает всего 10–15 минут:

• открыть резюме;

• посмотреть на опыт, проекты, достижения;

• выделить темы для обсуждения.

Самый абсурдный случай в моей жизни — интервьюер что-то перепутал, открыл резюме другого кандидата. Мы 20 минут говорили о чужом опыте. Я не понимал, почему меня спрашивают о том, с чем я не работал, а интервьюер — почему человек «не соответствует». Как итог, впустую потраченное время. 

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

• Как вы решали проблему X в проекте Y? 

• Вы работали с технологией Z — с какими трудностями столкнулись? 

• Какой самый сложный технический вызов был в вашей прошлой команде?

Но подготовка — это не только про резюме. Интервьюер должен понимать продукт, команду, текущие задачи и какой тип инженера нужен. Если кандидат из схожей сферы, то логично обсудить это глубже. Если нет — дать контекст, а не списывать заранее как «неподходящего». Например, собеседование в core-команду предполагает более глубокие технические вопросы. Но и в этом случае важно объяснить, зачем они задаются и как связаны с реальными задачами.

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

3. Фидбек — это уважение

Фраза «вы нам не подходите» без объяснения причин — худший финал собеседования. Такой ответ не даёт ни понимания, ни возможности стать лучше. Он просто ставит точку. Хотя иногда достаточно пары предложений:

• чего именно не хватило — опыта, глубины, конкретных навыков;

• уровень задач не совпал с ожиданиями;

• или нужен другой тип мышления и подход к работе.

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

HR не обязан давать фидбек после собеса, но может, если захочет.

И я выберу того, кто захочет.

Алгоритмические задачи: зачем они, если они ничего не показывают?

Алгоритмические задачи – самая спорная часть интервью для многих. Тот самый момент, когда просят решить задачу уровня middle «оптимально, без ошибок, за двадцать минут» и смотрят, как человек нервно печатает. 

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

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

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

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

Шаблонные вопросы: шпаргалки для интервьюера и кандидата

Мы так привыкли к собеседованиям по чек-листу, что перестали замечать, насколько они мертвые. Интервьюер задаёт технический вопрос — кандидат выдает правильный ответ по шаблону. Список вопросов кочует из компании в компанию. Иногда они не отличаются между позициями: junior ты или senior, всё равно спросят про hash map. Однажды я оказался на собеседовании, где интервьюер прямо при мне начал искать файл с вопросами, нашёл его, расшарил экран и начал зачитывать по списку. Никакого диалога и интереса к моему опыту — всё выглядело как заполнение анкеты. Честно, это можно было сделать ещё на этапе HR-скрининга — эффект был бы тем же.

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

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

• Как вы читали данные из топика и как записывали?

• С какими проблемами столкнулись?

• Что именно предприняли, чтобы их решить?

Человек, который работал с технологией, расскажет свой путь и реальные решения. Можно пойти дальше и дать реальный кейс. Например, у команды была сложная техническая проблема, которую долго разбирали. И спросить: «Как бы вы рассуждали? Что бы попробовали? Где могли бы быть риски?». Он не обязан ответить за пять минут, но именно в процессе размышлений проявляется его инженерное мышление.

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

Вывод: что делать и как быть

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

А какие у вас были самые неприятные, кринжовые или смешные случаи на собеседованиях? Давайте обсудим в комментариях!