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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из этих двух фактов вместе следует более полезный вывод:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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