Техническое собеседование: как проходит и как подготовиться

Как проходит техническое собеседование: этапы

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

1. Скрининг. Короткий разговор с рекрутером или инженером: опыт, стек, ожидания, иногда несколько быстрых вопросов по основам или онлайн-тест. Цель — понять, есть ли смысл звать вас на полноценное интервью.
2. Теория. Вопросы по языку и технологиям из вакансии: коллекции и их сложность, работа с памятью, исключения, базы данных и SQL, HTTP, многопоточность. Чаще спрашивают не определения, а «почему так» и «когда что выбрать».
3. Live coding и алгоритмы. Одна-две задачи в общем редакторе: массивы и строки, хеш-таблицы, два указателя, деревья. На ход рассуждений смотрят не меньше, чем на итоговый код.
4. System design — для мидлов и выше. Нужно спроектировать сервис: сокращатель ссылок, ленту новостей, чат. Обсуждают требования, нагрузку, хранение данных, API и то, как система будет расти.
5. Код-ревью. Дают фрагмент кода и просят найти проблемы: ошибки в логике, необработанные случаи, лишние запросы к базе, уязвимости, неудачные имена. Проверяют, как вы читаете чужой код и как формулируете замечания.
6. Встреча с командой. Руководитель или будущие коллеги рассказывают о задачах и спрашивают о вашем опыте, работе в команде и мотивации. Здесь же вы задаёте свои вопросы — общие вопросы этого этапа разобраны в подборке «Вопросы на собеседовании».

У аналитиков вместо алгоритмов чаще SQL, статистика и продуктовые кейсы, у тестировщиков — тест-дизайн, API и SQL, у фронтендеров — JavaScript, вёрстка и фреймворк. Типовые вопросы с короткими ответами собраны по специальностям: Python, Java, Frontend и JavaScript, 1С-программист, DevOps-инженер, Тестировщик (QA), SQL, Аналитик данных, Системный аналитик.

Что оценивает интервьюер

• Понимание основ. Не заученное определение, а умение объяснить, почему это работает именно так и когда что выбрать.
• Процесс решения. Уточняете ли вы условие, начинаете ли с простого решения, оцениваете ли сложность, проверяете ли код сами.
• Качество кода. Понятные имена, разбиение на функции, обработка граничных случаев — даже в учебной задаче.
• Коммуникацию. Как вы объясняете ход мысли, слышите ли подсказки, можете ли честно сказать «не знаю».
• Соответствие уровню. От джуна ждут уверенной базы и готовности учиться, от мидла — самостоятельности и аргументированных решений, от сеньора — компромиссов, архитектуры и опыта в сложных ситуациях.

Как рассуждать вслух

Интервьюер оценивает не только ответ, но и путь к нему, а путь виден, только если вы его проговариваете. Удобная последовательность: пересказать задачу → задать вопросы → назвать простое решение и его сложность → улучшить → писать код, объясняя каждый блок → проверить на примере. Фразы ниже — образцы на задаче «найти два числа с заданной суммой», а не текст для заучивания; числа и ограничения в примерах условные.

1. Уточнить условие

   «Правильно понимаю, что массив может быть пустым, а числа — отрицательными? Вернуть нужно индексы или сами значения?»

2. Назвать простое решение и его сложность

   «Первое, что приходит в голову, — перебрать все пары. Это O(n²): если n около 10⁵, будет медленно. Сначала напишу перебор, потом попробую ускорить.»

3. Предложить улучшение

   «Если хранить уже просмотренные числа в хеш-таблице, хватит одного прохода: O(n) по времени и O(n) по памяти. Пойду так?»

4. Объяснять код по ходу

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

5. Проверить решение на примере

   «Прогоню на маленьком примере: [2, 7, 11], цель 9. Для 2 в таблице пусто — запоминаю её. Для 7 нахожу в таблице 2 — ответ [0, 1]. Теперь пустой массив: цикл не выполнится, вернём пустой результат.»

6. Сказать, что застряли

   «Не уверен, как обработать повторяющиеся числа. Вижу два варианта: хранить список индексов или проверять пару до записи в таблицу. Склоняюсь ко второму — объясню почему.»

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

Если задача незнакомая

1. Не молчите и не паникуйте. «С такой задачей раньше не сталкивался, давайте разберусь» — нормальное начало.
2. Решите маленький пример руками. Три-четыре элемента на бумаге или в редакторе часто подсказывают закономерность.
3. Сведите к знакомому. Поможет ли сортировка? Хеш-таблица? Можно ли представить данные как граф? Похожа ли задача на ту, что вы уже решали?
4. Напишите перебор. Работающее медленное решение с честной оценкой сложности лучше пустого редактора, и от него проще двигаться к быстрому.
5. Просите подсказку конкретно. Не «я не знаю», а «вижу два пути — через сортировку и через хеш-таблицу; в правильную ли сторону я думаю?». Умение работать с подсказкой тоже оценивают.

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

System design и код-ревью: порядок действий

System design

1. Уточните требования: что система должна делать и чего не должна, сколько у неё пользователей, что важнее — скорость ответа или надёжность записи.
2. Прикиньте нагрузку грубо, с точностью до порядка: запросы в секунду, объём данных за год. Точные цифры не нужны, нужна логика оценки.
3. Опишите API и модель данных: какие сущности есть и как они связаны.
4. Нарисуйте простую схему: клиент, сервис, база. Только потом добавляйте кэш, очереди и реплики — и объясняйте, какую проблему решает каждый элемент.
5. Назовите узкие места и компромиссы: что сломается первым при росте нагрузки и чем вы готовы пожертвовать.

Код-ревью

• Сначала — корректность: граничные случаи, обработка ошибок, ошибки на единицу в границах цикла, работа с null.
• Затем — безопасность и данные: SQL-инъекции, секреты в коде, гонки при параллельном доступе.
• Потом — производительность: запросы к базе в цикле, лишние проходы по данным, квадратичные алгоритмы на больших входах.
• В конце — читаемость: имена, длина функций, дублирование, тесты.
• Формулируйте замечания как на настоящем ревью: что не так, почему это важно и как исправить.

План подготовки на 2 недели

1. Дни 1–2. Разведка. Разберите вакансию и выпишите стек. Спросите у рекрутера формат этапов: будет ли live coding и system design, на каком языке, в каком редакторе. Повторите оценку сложности и основные структуры данных.
2. Дни 3–6. Алгоритмы. Хеш-таблицы, два указателя, скользящее окно, стек, бинарный поиск, обход дерева. По 2–3 задачи в день — вслух и с таймером на 30 минут. Приёмы — в разборе live coding.
3. Дни 7–9. Теория по стеку. Язык, базы данных и SQL, HTTP, многопоточность — то, что указано в вакансии. На каждый вопрос сформулируйте ответ в 3–4 предложения и проговорите его вслух.
4. Дни 10–11. Проектирование и ревью. Мидлам и сеньорам — разобрать 2–3 типовые системы по шагам из раздела выше. Джунам стоит потренироваться в код-ревью: возьмите свой старый код или чужой пул-реквест и выпишите замечания.
5. Дни 12–13. Пробные собеседования. Один-два созвона с другом: теория, задача, разбор. Подготовьте рассказ о себе и две истории о проектах: что было сложно и что вы сделали.
6. День 14. Повтор и техника. Никаких новых тем: пройдитесь по заметкам, проверьте камеру, микрофон и демонстрацию экрана — чек-лист в материале «Онлайн-собеседование». Выспитесь.

Идёте на стажировку? Там к техническим интервью обычно добавляется контест или онлайн-тест — как устроен отбор в Яндексе, Т-Банке и Сбере, разобрано в материале «Стажировки в IT». Общий порядок подготовки к любому собеседованию — в плане «Как подготовиться к собеседованию».

Типичные ошибки

• Сразу писать код. Без уточнения условия легко решить не ту задачу.
• Молчать. Интервьюер не видит, что вы почти нашли решение, — он видит паузу.
• Пропускать подсказки. Если интервьюер задаёт наводящий вопрос, скорее всего, вы ушли в сторону. Остановитесь и подумайте над ним.
• Выдумывать ответ. Честное «не знаю, но рассуждал бы так» лучше уверенной ошибки.
• Не проверить код. Ошибка, которую вы нашли сами, — хороший сигнал; найденная интервьюером — уже минус.
• Переусложнять system design. Десяток сервисов и очередей до разговора о требованиях — тревожный сигнал, а не признак опыта.
• На код-ревью замечать только стиль. Отступы и имена важны, но пропущенный баг или уязвимость важнее.
• Не задать вопросов команде. Вопросы о задачах, релизах и код-ревью показывают, что вам интересна работа, а не только офер.

Где пригодится Суфлер AI

Решать задачу вслух, когда на вас смотрят, — навык, который нарабатывается только практикой. В приложении Суфлер AI есть бесплатное трёхминутное демо «Первый звонок»: ИИ-интервьюер Анна задаёт вопрос по теории, даёт задачу на live coding и фрагмент кода на ревью — короткая репетиция технического собеседования. На пробных созвонах и на самом интервью Суфлер слышит вопрос и показывает 2–3 тезиса ответа, разбирает задачу или чужой код по снимку экрана, а запись встречи с выжимкой помогает потом найти места, где вы замолчали или ушли в сторону. Окно с подсказкой не видно при демонстрации экрана — подробнее на странице скрытого помощника на собеседовании.