Перейти к основному содержимому

Playbook ответов

Как использовать​

  1. Найдите в списке проблему, которая у вас повторяется.
  2. Возьмите готовую формулировку и адаптируйте под свой проект.
  3. Прогоните мини-дрилл, пока ответ не станет коротким и структурным.

Универсальный шаблон сильного ответа​

  1. Что это и как работает внутри.
  2. Где вы это применяли на практике.
  3. Какие ограничения и риски у подхода.
  4. Как проверяли, что решение действительно работает.

1. Определение без механики​

Сигнал проблемы​

Ответ звучит как пересказ термина без понимания выполнения.

Как усилить ответ​

  • Добавьте внутреннюю механику.
  • Приведите короткий пример поведения в коде.

Рабочая формулировка​

"Event Loop: сначала синхронный стек, затем microtasks, потом macrotask. Поэтому Promise.then обычно выполнится раньше setTimeout."

Мини-дрилл​

Объясните этот же пример без терминов microtask/macrotask и потом добавьте их обратно.

2. Уверенность без практики​

Сигнал проблемы​

Есть уверенный тон, но нет ни одного реального кейса.

Как усилить ответ​

  • Назовите контекст задачи.
  • Покажите, что именно сделали и какой был результат.

Рабочая формулировка​

"Оптимизацию ререндеров делал после React Profiler: стабилизировал callback-пропсы и убрал лишний state выше по дереву. После этого commit duration в проблемном экране снизился."

Мини-дрилл​

Для 3 последних тем, которые повторяли, добавьте по одному кейсу "контекст -> действие -> эффект".

3. Нет trade-offs​

Сигнал проблемы​

Ответ звучит как "всегда делаем X" без ограничений.

Как усилить ответ​

  • Назовите, когда подход хорош.
  • Назовите, когда он вреден.

Рабочая формулировка​

"SSR помогает SEO и first content, но добавляет стоимость эксплуатации и риски TTFB. Для контентных страниц обычно выбираю SSG/ISR, для персонализированных экранов - SSR/CSR hybrid."

Мини-дрилл​

Добавьте к каждому архитектурному ответу фразу "когда этот подход не подходит".

4. Пересказ документации вместо решения задачи​

Сигнал проблемы​

Вы правильно объясняете API, но не отвечаете на "что делать в проде".

Как усилить ответ​

  • Сразу связывайте с реальным сценарием.
  • Добавляйте антипример ошибки.

Рабочая формулировка​

"В useEffect держу реальные зависимости и отменяю старые запросы через AbortController, иначе можно показать устаревшие данные при быстрых переключениях."

Мини-дрилл​

Перед каждым ответом задайте себе вопрос: "Какой прод-баг это предотвращает?"

5. Путаете термины и базовые понятия​

Сигнал проблемы​

Ответ противоречит базовым определениям.

Как усилить ответ​

  • Дайте точное определение.
  • Приведите один edge-case.

Рабочая формулировка​

"== делает приведение типов, === — нет. Поэтому базовое правило — ===, а value == null можно использовать как осознанную проверку на null и undefined."

Мини-дрилл​

Соберите свой мини-словарь из 20 терминов, которые чаще всего спрашивают на вашем уровне.

6. Нет связи с продуктом и метриками​

Сигнал проблемы​

Ответ технически верный, но непонятно, зачем это бизнесу.

Как усилить ответ​

  • Привяжите решение к пользовательскому пути.
  • Назовите метрику, которая должна улучшиться.

Рабочая формулировка​

"Оптимизация бандла была на главном мобильном входе в продукт. Снизили начальный JS-вес и улучшили скорость первого взаимодействия в целевом сценарии."

Мини-дрилл​

К каждому ответу добавляйте одну фразу: "Это важно для пользователя, потому что..."

7. Нет стратегии управления рисками​

Сигнал проблемы​

Ответ заканчивается на "внедрили", но нет rollout/rollback.

Как усилить ответ​

  • Добавьте план постепенного запуска.
  • Назовите условия отката.

Рабочая формулировка​

"Релиз запускаем через feature flag и canary. Если растут ошибки или деградирует ключевая метрика, включаем kill-switch и возвращаемся на стабильный путь."

Мини-дрилл​

Для двух последних релизов опишите: "как запускали" и "по какому сигналу откатывали".

8. Архитектурный ответ без контекста команды​

Сигнал проблемы​

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

Как усилить ответ​

  • Назовите организационные предпосылки.
  • Дайте пилот, а не "большой взрыв".

Рабочая формулировка​

"Микрофронтенды оправданы при высокой автономности команд и независимых циклах релизов. Начинать лучше с пилота и измеримых критериев, а не с полной миграции."

Мини-дрилл​

Добавьте в архитектурные ответы фразу: "Для нашей команды это подойдет, если..."

9. Фокус на инструменте вместо принципа​

Сигнал проблемы​

Ответ строится вокруг названия библиотеки, а не вокруг задачи.

Как усилить ответ​

  • Сначала формулируйте принцип и ограничения.
  • Инструмент называйте только после этого.

Рабочая формулировка​

"Сначала разделяем state на server/UI/derived и задаем ownership. После этого выбираем инструмент, который лучше закрывает именно эти требования."

Мини-дрилл​

Переформулируйте 3 ответа без названий библиотек. Потом добавьте инструмент в конце.

10. Нет структуры ответа​

Сигнал проблемы​

Длинный поток мыслей, в котором интервьюер теряет нить.

Как усилить ответ​

  • Говорите по фиксированной структуре.
  • Ограничивайте ответ 3-4 логическими блоками.

Рабочая формулировка​

  1. Механика.
  2. Практика.
  3. Ограничения.
  4. Проверка результата.

Мини-дрилл​

Возьмите любой вопрос из банка и ответьте по этой структуре в 4 коротких пунктах.

Чек перед ответом​

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

Куда дальше​

  1. Вернитесь в модуль: Обучение.
  2. Сверьтесь с картой темы: Карта подготовки.
  3. Продолжайте по маршруту: Треки подготовки.
  4. Закрепите один ответ на практике в Песочнице.