Что проверяют собеседования бэкенд-инженеров

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

Далее — структура процесса и то, что на самом деле слушает человек напротив.

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

Для позиции middle или senior backend в компании с более чем пятьюдесятью инженерами собеседование обычно включает:

1. Скрининг с рекрутером, 20–30 минут. Стек, уровень, срок уведомления, локация и виза, ожидания по зарплате, есть ли сейчас дежурства и готовы ли вы к ним.
2. Звонок с менеджером, 30–45 минут. Чем владеете, что поставили, почему уходите. Иногда лёгкая техническая проверка.
3. Задача на кодирование. Вживую в общем редакторе, вживую в вашем репозитории в паре с инженером, или тестовое задание, которое вы присылаете и затем разбираете.
4. Раунд системного дизайна, 45–60 минут, доска или чистый холст Excalidraw.
5. Глубокое обсуждение того, что вы построили, иногда объединяют с дизайном, иногда отдельно.
6. Поведенческий или кросс-функциональный раунд, часто с инженером из другой команды или продакт-менеджером.

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

Кто на самом деле в комнате

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

Раунд дизайна чаще проводит staff или principal инженер, или опытный senior, который делает это часто. У этого человека есть мнения об очередях, и его будили в 04:00 из-за чего-то, что вы сейчас опишете вскользь.

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

Это важно, потому что один и тот же ответ оценивается по-разному в зависимости от того, кто спрашивает. "Мы использовали Kafka" — это факт для рекрутера, отправная точка для менеджера, и для staff-инженера это приглашение спросить, почему не SQS, какой был ключ партиционирования и что случилось с порядком при переобработке.

Задача на кодирование и что она на самом деле оценивает

Доминируют три формата, и они оценивают разное.

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

Реалистичная задача. Всё чаще встречается в средних компаниях. Распарсить этот файл и выдать по HTTP. Реализовать ограничитель запросов. Добавить эндпоинт в существующий репозиторий. Здесь оценка ближе к настоящему код-ревью: обрабатываете ли вы ошибки или проглатываете, валидируете ли ввод, разумны ли имена, написали ли тест, заметили ли неоднозначность в спецификации и спросили, а не угадали.

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

Во всех трёх возникает вопрос языка. Если выберете Go, ждите вопросов об отмене контекста, утечках горутин или почему вы использовали канал там, где проще мьютекс. Если выберете Java, ждите JVM: куча против внекучевой памяти, что пауза полной сборки мусора делает с p99, размер пула потоков и что-то Spring-образное про области видимости бинов или границы транзакций. Python приглашает GIL и вопрос, не остановил ли ваш блокирующий вызов цикл событий. Node приглашает тот же вопрос в другой одежде. Выбирайте язык, на котором действительно пишете, а не тот, который звучит senior.

Системный дизайн: вопросы внутри вопроса

Задание будет широким — спроектировать сокращатель URL, сервис уведомлений, систему бронирования билетов, что угодно, что интервьюер прогонял сорок раз. Задание — это не тест. Тест — это набор уточнений, и они довольно предсказуемы, потому что это то, что реально ломается в продакшене.

Идемпотентность. "Клиент вызывает POST /payments, получает таймаут и повторяет. Что теперь?" Хороший ответ тянется к ключу идемпотентности, предоставленному клиентом, уникальному ограничению в базе и решению, что возвращать при дубликате. Очень хороший ответ упоминает транзакционный outbox, потому что вы собираетесь публиковать событие об этом платеже, а запись и публикация не атомарны.

Семантика доставки. Почти каждая очередь, которую вы назовёте — at-least-once. Итак: как не списать с клиента дважды, какое окно дедупликации, где живёт состояние дедупликации и что происходит, когда оно истекает. Если скажете "exactly-once" без немедленной оговорки, что имеете в виду, вы подали интервьюеру следующий вопрос.

Распространение отказов. "Ваш сервис вызывает нижележащий сервис, который стал медленным — не упал, медленным." Ответ, который они хотят, проходит по цепочке: запросы держат соединения дольше, пул насыщается, ваша очередь растёт, ваша задержка растёт, ваши вызывающие получают таймауты и повторяют, а повторы усиливают нагрузку на то, что уже испытывало трудности. Затем смягчения: таймауты, которые реально установлены, бюджеты вместо таймаутов на вызов, экспоненциальная задержка с джиттером, circuit breakers, bulkheads, load shedding. Фраза "шторм повторов" даёт вам очки, потому что показывает, что вы видели один.

Данные. Ждите вопросов об индексах, сформулированных как симптомы, а не теория: запрос, который был быстрым месяц назад и медленный сейчас без изменений кода. Смена плана, устаревшая статистика, предположение о селективности, которое перестало держаться по мере роста таблицы, конфликт блокировок, раздувание и поведение vacuum в Postgres. Ждите вопроса о миграции схемы — переименование или разделение столбца без простоя — где ожидаемый ответ expand and contract: добавить новый столбец, двойная запись, заполнение батчами, перенос чтений, прекращение записи старого, удаление позже.

Кеширование. "Добавить кеш" — это начало разговора. Уточнения — стратегия инвалидации, TTL против явного вытеснения, что происходит с источником, когда горячий ключ истекает и приходит тысяча запросов одновременно, и готовы ли вы отдавать устаревшие данные и как долго.

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

Глубокое обсуждение вашей работы

Этот раунд решает уровень старшинства чаще, чем раунд кодирования. Задание — некая версия "расскажите о системе, которую спроектировали или существенно изменили". Затем:

• Какие были альтернативы и почему вы их отвергли?
• Что вы сделали неправильно?
• Что сломалось после релиза?
• Как вы узнали, что это работает?
• Что бы вы сделали иначе сейчас?
• Кто с вами не согласился и что случилось?

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

Подготовьте детали развёртывания. Feature flag или процентный rollout, какой был kill switch, какую метрику отслеживали, каков был план отката и пришлось ли его использовать. Подготовьте один инцидент, в котором вы были причиной. Blameless — это культура; признание ошибки без театральности — это сигнал.

Как звучит поверхностный ответ

С другой стороны стола это признаки:

• "Мы использовали Kafka, потому что она масштабируется." Нет ключа партиционирования, нет группы потребителей, нет упоминания, какая гарантия порядка вам была нужна или потеряна.
• "Мы бы добавили Redis." Кеш заявлен как решение, без истории инвалидации, без TTL, без мысли о stampede.
• "Микросервисы." Предлагается как архитектура, а не как компромисс — нет упоминания транзакции, которую вы только что потеряли, сетевого вызова, который только что добавили, или как вы теперь развёртываете их вместе в любом случае.
• "Мы бы проиндексировали этот столбец." Без понимания мощности, стоимости записи или будет ли запрос его вообще использовать.
• "Это eventually consistent." Используется как ответ, а не как описание проблемы, которую затем нужно обработать в UI или в работе сверки.
• "Это было быстро, около 50 миллисекунд." Среднее, при какой нагрузке, измерено где.
• "У нас стопроцентное покрытие тестами." Заявлено без рассказа, что тесты на самом деле проверяют, запускаются ли они против реальной базы или как обрабатываются нестабильные тесты.
• "Мне нужно это посмотреть." Нормально для детали синтаксиса. Не нормально как ответ на вопрос, что происходит, когда нижележащий сервис вашего сервиса замедляется.

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

Что делать дальше

Четыре вещи в порядке того, насколько они сдвинут стрелку.

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

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

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

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