Сколько ещё задачек на LeetCode нужно решить, если готовитесь к собеседованию на сеньора

«Технические навыки — ставка, чтобы сесть за стол. Они пускают вас в игру, но партию выигрывают не они», — пишет Хьюинь в The Pragmatic Engineer, одной из самых читаемых рассылок об IT-индустрии.

Бросать алгоритмы при этом рано. Гергей Орош, автор этой рассылки, в своём гайде по подготовке пишет, что задачи на код и алгоритмы встретятся на собеседовании любого уровня, а системный дизайн важнее для сеньоров и выше. «Чем выше позиция, тем больше начинает значить реальный опыт».

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

Почему так тянет решить ещё одну задачу

У LeetCode честная обратная связь. Решил задачу, загорелась зелёная галочка, счётчик подрос, и прогресс виден каждый вечер. С системным дизайном и рассказами о прошлых проектах так не выйдет: никто не сообщит, что сегодня вы стали на 3% убедительнее.

Сеньора от мидла при этом отличает вовсе не скорость. В карьерной лестнице Dropbox, уже на уровне IC3 инженер сам находит решения для неясных задач без готового ответа. А на IC4, последней ступени перед Staff, он отвечает за цели команды на полгода-год, умеет выбрать решение там, где приходится жёстко расставлять приоритеты, и его влияние начинает выходить за пределы команды.

Сто первая задача на LeetCode ни к одному из этих пунктов не приближает.

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

Сколько LeetCode мне хватит?

Зависит от того, куда вы идёте. В крупных компаниях алгоритмы спрашивают. Meta в официальном гайде по собеседованиям (общем для трёх уровней, вплоть до Staff) называет три типа раундов: кодинг, дизайн и поведенческий. На кодинге за 40 минут ждут решения примерно двух задач, а задач на динамическое программирование, по словам компании, не дают. Amazon начинает отбор уровня SDE II с онлайн-теста, где есть две технические задачи.

Убиваться с сотнями решений для этого не требуется. Так считает Янгшун Тэй, бывший Staff-инженер Meta и автор Blind 75, списка из 75 задач для подготовки к собеседованиям. «Ни у кого нет времени решать сотни задач на LeetCode, — пишет он. — И хорошая новость: чтобы получить работу в FAANG, столько и не нужно». В более новом списке Тэя, Grind 75, потолок 169 задач, и дальше, по его словам, идти вряд ли нужно.

Весной 2025 года Хэмилтон Грин, бывший инженер Meta, искал работу сеньором и расписал свой день подготовки. Две задачи средней сложности (Medium), каждая быстрее 20 минут. Один-два системных дизайна. Около 40 минут поведенческих ответов вслух. За два месяца у него набралось пять офферов.

LeetCode Грин не бросал, он держал его в пропорции. Если Medium у вас уже укладываются в эти 20 минут, время, похоже, пора отдавать другим раундам.

Тот же вопрос, что и в заголовке, в мае 2026 года задал на Reddit инженер с девятью годами опыта. Задача у него занимает час, и он сомневается, стоит ли дожимать:

Сам кодинг-раунд тоже меняется. На многих собеседованиях в Meta теперь встроен AI-помощник с Claude, ChatGPT, Gemini и моделями Meta, и кандидат должен им пользоваться. Так собеседование, по словам компании, ближе к настоящей работе: на нём смотрят, как вы решаете задачу, пишете и отлаживаете код и сотрудничаете с другими. Сундар Пичаи, глава Google, обещал ввести хотя бы один очный раунд, чтобы «убедиться, что основы на месте», а в 2026 году компания пробует раунд с AI-помощником для младших и средних грейдов в части команд в США.

Canva в 2025 году в пилотном режиме заменили у бэкендеров и фронтендеров раунд по основам информатики раундом, где код пишут вместе с AI. Саймон Ньютон, который руководит в Canva платформенной разработкой, объяснил, что без AI-инструментов в компании сейчас не обойтись и в обычной работе.

В некоторых компаниях вместо задач чинят настоящие баги. Платёжная компания Stripe в своём гайде для основателей стартапов описывала раунд Bug Squash. Кандидат и интервьюер садятся рядом и чинят реальную старую ошибку в open-source-проекте, на языке, который выбрал кандидат. Вопросы на собеседовании, как объясняет Stripe, нужны, чтобы понять, как человек подходит к настоящим задачам, а не проверить «экзотические навыки, которые показывают у доски».

Почему заученная схема не спасает на системном дизайне

Многие на этом раунде рисуют по памяти идеальную схему с Kafka, Redis и микросервисами. Алекс Сюй, автор книги «System Design Interview» и основатель обучающей платформы ByteByteGo, описывает этот раунд как работу двух коллег над расплывчатой задачей. Ответа из учебника там нет. «Итоговая схема важна меньше, чем работа, которую вы вложили в проектирование», — пишет он.

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

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

Инженер, который за три месяца получил три оффера на сеньора, подробно рассказал на Reddit, как искал вакансии и готовился к собеседованиям:

Как рассказать о проекте, чтобы вас услышали как сеньора

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

Ласло Бок, бывший глава HR Google, ещё в 2013 году рассказывал New York Times, что головоломки вроде «сколько мячей для гольфа влезет в самолёт» ничего не предсказывают. Работают, по его словам, структурированные поведенческие интервью. Они начинаются с просьбы вроде «приведите пример, когда вы решили аналитически сложную задачу», а оценивают всех кандидатов по одним правилам.

Ответ на такую просьбу удобно строить по схеме STAR. Amazon называет её одним из способов, но не единственным.

• Ситуация (Situation). Контекст в двух-трёх предложениях.
• Задача (Task). За что отвечали лично вы.
• Действия (Action). Самая длинная часть: что вы сделали технически и с кем договорились.
• Результат (Result). Что изменилось, в цифрах, если они есть.

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

Так звучит мидл: «У клиента была старая CRM, и она не могла подключиться к нашему API. Мне сказали сделать так, чтобы всё заработало. Я написала конвертер токенов, всё заработало, клиент доволен».

Так звучит сеньор: «Клиент из банковского сектора сидел на старой CRM с OAuth 1.0, а наша платформа работала только с OAuth 2.0. Я взялась спроектировать шлюз для аутентификации так, чтобы не ослабить требования безопасности. Сделала прослойку для обмена токенов с ротацией ключей, повторными попытками с растущей паузой и отдельной очередью для вебхуков, которые не удалось доставить. Всё согласовала со службой безопасности банка. Интеграцию закончили за десять дней вместо запланированных четырёх недель».

Проект в обоих ответах один и тот же. Разница в том, видно ли, что решала и делала именно она.

Бэкенд-разработчик с шестью годами опыта и пятью сотнями решённых задач рассказывал на Reddit, что офферы пошли, когда он перестал говорить «мы внедрили» и начал говорить «я предложил и довёл»:

«Легко написать „я выпустил фичу“ и забыть продолжение: „…и благодаря этому случилось то-то“», — предупреждает Джулия Эванс, разработчица и автор зинов о программировании. Поэтому она советует вести brag document, буквально «хвастливый список»: что вы сделали и к чему это привело. Эванс писала о нём для оценки работы и повышений, но к собеседованию он пригодится так же: цифры и детали проще собирать заранее, чем вспоминать накануне. В тот же список стоит складывать проектные документы (RFC), записи архитектурных решений (ADR) и метрики: их можно показать интервьюеру.

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

Если вы целитесь в Staff

Подчинённых у Staff-инженера по-прежнему нет, зато масштаб другой. В лестнице Dropbox Staff-инженер (IC5) уже задаёт техническую стратегию на годы вперёд для нескольких команд и решает, что делать и как.

Уилл Ларсон, технический директор финтех-компании Imprint и автор книги «Staff Engineer», замечает, что многие компании собеседуют Staff как «сеньора, который чуть лучше во всём», хотя такие инженеры пишут код меньше сеньоров и на скоростных задачах обычно медленнее.

На этом уровне, пишет Ларсон, это почти тревожный знак, если кандидат не просит подробностей. А если на собеседовании нет глубокого разговора о ваших прошлых проектах, обосновать оффер на Staff трудно. Значит, к такому разговору нужна история о проекте шире одной команды.

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

С кем потренироваться

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

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

Что поможет вам подготовиться

Если проседает системный дизайн

Mastering the System Design Interview — курс Фрэнка Кейна на Udemy. Кейн девять лет проработал в Amazon и IMDb старшим инженером и менеджером, был bar raiser, то есть интервьюером с правом вето на найм, и, по его словам, провёл больше тысячи собеседований.

Курс начинается с того, как масштабировать системы: шардирование баз, кэши, отказоустойчивость, CAP-теорема. Есть раздел о проектировании систем с генеративным AI. Дальше стратегии на самом интервью и шесть записанных пробных собеседований: сокращатель ссылок, веб-краулер, видеосервис, поисковик и другие. Всего около пяти часов видео; объём курса может поменяться.

Может подойти, если опыт в архитектуре у вас есть и его нужно собрать в метод для раунда. Поведенческой части в курсе немного, уровня Staff нет, а часть примеров (Hadoop) устарела.

Если хочется понять, чего ждут на следующем уровне

The Software Engineer’s Guidebook — книга Гергея Ороша, бывшего инженерного менеджера Uber. Книга идёт по карьере от начинающего разработчика до Staff и principal: чего ждут на каждом уровне, как устроены оценка работы и повышения, как менять работу и готовиться к собеседованиям.

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

С чего начать

Стив Хьюинь советует простую пропорцию: если собираетесь потратить на подготовку 80 часов, переложите 10 из них на нетехническую часть. По его словам, десять часов на истории могут полностью изменить исход поведенческих раундов.

• Проверьте кодинг. Если Medium у вас укладываются в 20 минут, гнаться за счётом незачем: поддерживайте форму, а основное время отдайте другим раундам.
• Соберите пять историй из раздела о рассказе о проекте, разложите каждую по STAR и добавьте цифры и документы.
• Разберите два-три системных дизайна по шагам Сюя: вслух, с уточняющими вопросами и поиском сбоев.
• Пройдите хотя бы одно пробное собеседование с живым человеком до настоящего.