11 промтов, которые превратили мою подготовку к собеседованию в инженерный пайплайн — от LeetCode до System Design
Полгода назад я сидел над задачей Two Sum третий вечер подряд и понимал: я не готовлюсь — я перелистываю решения. Классический цикл «прочитал разбор → через неделю забыл → снова открыл разбор» съедал десятки часов, а прогресс не ощущался. Тогда я решил перестать использовать LLM как генератор ответов и начать использовать её как инженерный инструмент: тренажёр, ревьюера и архитектурного оппонента одновременно.
За следующие месяцы я собрал набор промтов, которые закрывают весь маршрут подготовки: от разбора паттернов задач до защиты архитектуры на System Design интервью. Это не «магия» — это структурированные запросы, каждый из которых решает конкретную проблему: где я застрял, что именно я не понимаю и как проверить, что понял.
Ниже — 11 сценариев с готовыми к копипасту промтами. Я привожу их в том порядке, в котором сам прохожу подготовку: сначала паттерны и структуры данных, затем поведенческие и System Design, затем финальная симуляция интервью. Для каждого промта — зачем он нужен, как выглядит и что вы получите на выходе.
1. Разбор задачи LeetCode через паттерн, а не через решение
Проблема: большинство решает задачу и сразу смотрит editorial, теряя главное — классификацию паттерна.
Промт:
Ты — тренер по алгоритмам. Я даю задачу: [название или условие].
Не пиши решение целиком. Вместо этого:
1. Определи, к какому паттерну относится задача (two pointers, sliding window, BFS/DFS, DP, binary search и т.д.), и почему.
2. Назови 2–3 сигнала в условии, которые выдают этот паттерн.
3. Задай мне 3 наводящих вопроса, чтобы я сам пришёл к решению.
4. Только после моего ответа покажи решение с анализом сложности.
Пример использования: для задачи «Longest Substring Without Repeating Characters» модель отвечает: паттерн — sliding window, сигналы — «подстрока», «без повторов», «максимальная длина». Затем спрашивает: «Что произойдёт с окном, если новый символ уже внутри?». Я отвечаю — и только потом получаю код.
Результат: вы учите распознаванию, а не запоминанию. На интервью вы не вспоминаете решение — вы узнаёте паттерн.
2. Генератор вариаций одной задачи
Проблема: решив задачу один раз, вы закрепляете поверхностно. Мозгу нужны вариации.
Промт:
Возьми задачу [название] и сгенерируй 4 её вариации:
- одна с изменённым ограничением (например, массив отсортирован/не отсортирован);
- одна с изменённой целью (минимум вместо максимума);
- одна с дополнительным требованием по памяти O(1);
- одна, где исходный паттерн не работает и нужен другой.
Для каждой укажи: меняется ли паттерн и почему. Решения не давай — только условия и подсказку.
Пример: для «Two Sum» вариация «массив отсортирован» переводит задачу с хеш-таблицы на two pointers, а вариация «нужно вернуть все пары» требует аккуратной работы с дубликатами.
Результат: вы перестаёте «узнавать» задачу и начинаете видеть пространство решений вокруг неё.
3. Структуры данных: объяснение через аналогию + проверка
Проблема: формальные определения («хеш-таблица — это структура, отображающая ключи в значения») не помогают на интервью.
Промт:
Объясни структуру данных [название] так, как если бы я готовился к интервью и мне нужно было:
1. Объяснить её вслух за 60 секунд.
2. Назвать 3 реальных инженерных сценария, где она решает проблему.
3. Назвать 2 сценария, где она — плохой выбор, и почему.
4. Задать мне один вопрос на понимание внутреннего устройства (например, про коллизии, амортизацию, балансировку).
Пример: для хеш-таблицы модель объясняет коллизии, load factor и амортизированную сложность O(1), приводит пример кеша сессий и честно говорит, что для упорядоченного обхода она проигрывает дереву поиска.
Результат: вы готовы не к определению, а к follow-up вопросам интервьюера.
4. Симуляция интервьюера, который копает вглубь
Проблема: на реальном интервью после рабочего решения начинаются уточнения — и именно там сыпятся кандидаты.
Промт:
Ты — строгий интервьюер в крупной tech-компании. Задай мне одну алгоритмическую задачу уровня LeetCode Medium.
Правила:
- Не подсказывай сразу.
- После моего решения задай минимум 3 follow-up вопроса: про граничные случаи, сложность, альтернативы.
- Если я ошибаюсь, не давай ответ — задай наводящий вопрос.
- В конце дай оценку по шкале: понимание, коммуникация, код, граничные случаи.
Пример: после решения задачи про слияние интервалов интервьюер спрашивает: «Что если интервалы приходят потоком?», «Как изменится решение при миллионе интервалов?», «Что если нужно вернуть не объединённые, а пересекающиеся?».
Результат: вы тренируете не решение, а разговор вокруг решения — то, что реально оценивают.
5. Ревью моего кода как на код-ревью в команде
Проблема: свой код всегда кажется правильным, пока его не прочитает кто-то другой.
Промт:
Вот моё решение задачи [название]:
[вставь код]
Сделай код-ревью как senior-инженер:
1. Корректность: есть ли баги и непокрытые граничные случаи?
2. Сложность: реальная временная и пространственная, с обоснованием.
3. Читаемость: имена, структура, можно ли упростить.
4. Что бы ты спросил на интервью, глядя на этот код?
Не переписывай код целиком — укажи конкретные строки и проблемы.
Пример: модель замечает, что в решении с двумя указателями я не обработал случай пустого массива и использовал len(nums) внутри цикла, что мелочь, но на интервью выглядит небрежно.
Результат: вы ловите свои типичные ошибки до того, как их поймает интервьюер.
6. Декомпозиция System Design задачи
Проблема: на System Design вопрос «спроектируйте Twitter» вводит в ступор, потому что нет рамки.
Промт:
Помоги мне декомпозировать System Design задачу: [например, «спроектировать ленту новостей»].
Разбей на этапы и по каждому задай мне вопрос, на который я должен ответить сам:
1. Функциональные и нефункциональные требования.
2. Оценка нагрузки: QPS, объём данных, read/write ratio.
3. API-контракт.
4. Модель данных и выбор хранилища.
5. Компоненты и их взаимодействие.
6. Узкие места и масштабирование.
Ответы не давай — только вопросы и критерии хорошего ответа.
Пример: для ленты новостей модель спрашивает: «Какой QPS на чтение при 10 млн DAU и 20 открытиях ленты в день?», «Push или pull модель обновления?», «Что кешируем и на каком уровне?».
Результат: у вас появляется повторяемый каркас ответа на любой System Design вопрос.
7. Архитектурный спор: модель защищает другое решение
Проблема: вы учите одно решение как «правильное» и не умеете защищать выбор под давлением.
Промт:
Я спроектировал систему так: [кратко опиши архитектуру].
Ты — архитектор, который выбрал противоположный подход. Приведи 5 аргументов против моего решения:
- по надёжности,
- по стоимости,
- по сложности поддержки,
- по масштабируемости,
- по времени выхода на рынок.
После каждого аргумента спроси, что я отвечу. В конце скажи, какие аргументы я не смог парировать.
Пример: я выбрал монолит с PostgreSQL, модель защищает микросервисы и Kafka, аргументируя независимым масштабированием и изоляцией сбоев.
Результат: вы готовы к вопросу «а почему не наоборот?» — самому частому на System Design.
8. Trade-off таблица для выбора технологии
Проблема: интервьюеры любят спрашивать «PostgreSQL или MongoDB?» и ждут не ответа, а рассуждения.
Промт:
Составь таблицу сравнения [технология A] и [технология B] для сценария [опиши сценарий].
Колонки: критерий, A, B, когда выбирать A, когда выбирать B.
Критерии: модель данных, консистентность, масштабирование, операционная сложность, стоимость, зрелость экосистемы.
После таблицы задай мне вопрос: какой вариант я выберу для моего сценария и почему.
Пример: для сценария «хранение профилей пользователей с гибкой схемой» таблица показывает, что документная БД выигрывает на старте, но реляционная — при сложных связях и транзакциях.
Результат: вы учитесь говорить о компромиссах, а не о «лучшей технологии».
9. Поведенческие вопросы через STAR с разбором
Проблема: ответы на «расскажите о конфликте в команде» звучат заученно и без структуры.
Промт:
Задай мне поведенческий вопрос, который часто спрашивают на интервью уровня [junior/middle/senior].
После моего ответа:
1. Разбери его по схеме STAR (Situation, Task, Action, Result) и покажи, каких блоков не хватает.
2. Укажи, где я говорю «мы» вместо «я» и где не хватает измеримого результата.
3. Предложи, как переформулировать слабые места.
Оценку не ставь — только разбор.
Пример: на вопрос о сорванном дедлайне мой ответ содержал только описание ситуации; модель указала, что нет конкретного действия и результата, и предложила добавить метрику.
Результат: ваши истории становятся структурными и проверяемыми.
10. Ежедневный план подготовки на основе слабых мест
Проблема: непонятно, что учить сегодня — LeetCode, теорию или System Design.
Промт:
Вот мой текущий статус подготовки:
- решено задач: [число], из них Medium/Hard: [число];
- слабые темы: [список];
- до интервью: [число] дней;
- доступно часов в день: [число].
Составь план на 7 дней: каждый день — 1 тема, 2 задачи, 1 блок теории и 1 короткое повторение.
Формат: таблица с колонками «день, тема, задачи, теория, проверка».
Не добавляй мотивационные фразы — только конкретика.
Пример: модель ставит DP на понедельник и среду, графы на вторник и четверг, а пятницу отводит на mock-интервью и разбор ошибок.
Результат: подготовка перестаёт быть хаотичной и становится измеримой.
11. Финальная симуляция полного интервью
Проблема: отдельные навыки есть, а цельного интервью — нет.
Промт:
Проведи полную симуляцию интервью на позицию [название] уровня [уровень].
Этапы:
1. Короткое intro и вопрос о мотивации.
2. Одна алгоритмическая задача Medium.
3. Один System Design вопрос.
4. Два поведенческих вопроса.
5. Мои вопросы к тебе как к интервьюеру.
После каждого этапа — короткая обратная связь. В конце — итоговая оценка по 5 критериям и топ-3 слабых места.
Пример: симуляция занимает около часа и выявляет, что я трачу слишком много времени на уточнения в начале и не успеваю закончить код.
Результат: вы входите на реальное интервью с ощущением, что уже проходили его.
Что осталось за кадром
Все 11 промтов работают только при одном условии: вы отвечаете сами, до того как модель покажет решение. LLM здесь — не оракул, а тренажёр, который задаёт неудобные вопросы и не даёт списать. Именно этот режим — «сначала мой ответ, потом разбор» — и дал основной прирост: задачи перестали быть набором трюков и стали системой паттернов, а System Design — разговором о компромиссах, а не заучиванием архитектур.
Начните с двух промтов: №1 для алгоритмов и №6 для System Design. Прогоните по одному сценарию каждый и посмотрите, где вы на самом деле застреваете. Дальше добавляйте остальные — и подготовка перестанет быть перелистыванием решений.
Комментарии