Как подготовиться к техническому собеседованию

Из чего на самом деле состоит разговор

Техническая секция ощущается как экзамен по всему сразу, а по составу она устроена куда проще. Возьмём одну выгрузку целиком — 5010 вопросов с 96 собеседований по Java. Из них около 1150 — про опыт, проекты и мотивацию: их задают в начале и они не про знание предмета. Ещё 141 — задачи с кодом, то есть примерно полторы на встречу. Всё остальное, а это три четверти разговора, — теоретические вопросы по стеку.

Отсюда первое следствие, которое переворачивает типичный план подготовки: разговор состоит в основном из теории по вашему стеку. Не из алгоритмов, не из проектирования систем, не из головоломок. Из вопросов вида «как это устроено и что будет, если».

Второе следствие менее очевидно. Списки «100 вопросов» создают впечатление, что темы равнозначны — сто пунктов, у каждого свой номер. Реальное распределение устроено иначе: спрос сконцентрирован. В дедуплицированном срезе по Go верхние пять подтем из двадцати дают 90 вопросов из 234 — почти сорок процентов разговора приходится на четверть тем. В Python верхние три темы из десяти дают тот же примерно порядок. Хвост из редких тем длинный, но лёгкий.

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

В каком порядке готовиться

Порядок задаётся частотностью, и он устроен в три слоя.

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

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

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

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

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

Сколько на самом деле весят алгоритмы

Совет «прорешайте сотню задач» — самый частый в подборках по подготовке, и он подаётся без оговорок. Оговорки у него есть.

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

Теперь про долю. В выгрузке по Java задач с кодом — 141 на 96 собеседований, то есть около полутора на встречу и меньше трёх процентов всех заданных вопросов. Задача на собеседовании есть почти всегда, но она одна из многих составляющих, а не основное содержание разговора.

Из этих двух фактов вместе следует не «алгоритмы не нужны», а кое-что более полезное:

• если в процессе выбранной компании есть выделенная алгоритмическая секция — готовьтесь к ней всерьёз, отдельно и заранее;
• если её нет, а задача идёт внутри общей технической секции, то сотня решённых задач вытесняет из плана подготовки те самые верхние темы стека, которые займут три четверти разговора.

Различие между этими двумя случаями узнаётся одним вопросом рекрутёру о составе этапов — и это, пожалуй, самая дешёвая по затратам часть подготовки.

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

Почему выученное не превращается в ответ

Самый обидный сценарий подготовки выглядит так: тема прочитана, устройство понятно, а на вопросе про неё ответ рассыпается. Это не провал памяти, а разрыв между двумя разными навыками.

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

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

Проверять стоит и на уточняющих. Хороший признак готовности — способность ответить на «а что будет, если» после собственного ответа, не заглядывая обратно в текст.

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

Как понять, что вы готовы по теме

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

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

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

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

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

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

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