Senior Frontend

Экспресс-шпаргалка 20/20

1. Архитектура должна задавать границы доменов, ownership, правила зависимостей и предсказуемую эволюцию системы, а не только структуру папок.
2. Микрофронтенды полезны при высокой автономности команд и разных циклах поставки, но вредят, если добавляют сложность быстрее, чем приносят бизнес-выгоду.
3. Performance budget - это численные пороги по ключевым метрикам и размеру ресурсов, которые контролируются автоматически в CI и в проде.
4. Стратегия рендеринга выбирается по типу контента, требованиям к SEO/персонализации, SLA по latency и стоимости эксплуатации.
5. Нужно разделить server state, UI state и derived state, задать ownership и хранить состояние максимально близко к месту использования.
6. Надежный слой данных должен стандартизировать ретраи, таймауты, отмену, дедупликацию и единый формат ошибок для UI и мониторинга.
7. Оптимистичные обновления ускоряют UX, но без rollback, idempotency и обработки конфликтов приводят к рассинхронизации данных.
8. Design System - это продукт с API, версионированием, токенами, governance и метриками внедрения, а не набор разрозненных компонентов.
9. Accessibility должна быть частью Definition of Done и CI-процесса, а не ручной проверкой в конце релиза.
10. Observability включает метрики, логи, ошибки, трассировку и runbooks, чтобы быстро находить и устранять причины деградаций.
11. Базовый набор: защита от XSS/CSRF, безопасное хранение сессии, CSP, контроль third-party скриптов и регулярный аудит зависимостей.
12. Release strategy должна обеспечивать управляемый rollout, быстрый rollback и контроль качества через метрики.
13. Error budget - это допустимый объем деградаций относительно SLO, который помогает балансировать скорость доставки и стабильность.
14. Комбинировать виртуализацию, пагинацию и оптимизацию рендера с учетом доступности и UX-навигации.
15. Когда CPU-heavy вычисления мешают интерактивности main thread и их можно выполнить без прямого доступа к DOM.
16. CI должен комбинировать быстрые обязательные проверки в PR и расширенные прогоны по расписанию, сохраняя быстрый feedback loop.
17. Тестирование должно быть risk-based: защищать критичные пользовательские потоки минимально достаточным набором unit/integration/e2e.
18. Эволюция контрактов должна быть управляемой: schema как source of truth, окно деприкации и автоматическая проверка совместимости.
19. Postmortem должен быть blameless, с root-cause анализом и измеримыми action items с владельцами и сроками.
20. Senior отвечает не только за код, но и за качество инженерных решений, развитие команды и влияние на продуктовые результаты.

1. Как проектировать frontend-архитектуру крупного продукта?

Теги: architecture, modularity, ownership, scaling Сложность: Senior

Короткий ответ

Архитектура должна задавать границы доменов, ownership, правила зависимостей и предсказуемую эволюцию системы, а не только структуру папок.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В проектировании модулей, границ ответственности и поддерживаемой архитектуры продукта.
2. Главный риск: Размытые границы повышают связанность, замедляют изменения и увеличивают цену регрессий.
3. Как проверяете решение: Оформляю решение через ADR, затем проверяю ключевой trade-off на прототипе и эксплуатационных метриках.

Мини-пример

// eslint rule idea: domain imports only from public API
import { createOrder } from '@/domains/orders/public-api';

Углубление (2-3 минуты)

1. Свяжите тему "Как проектировать frontend-архитектуру крупного продукта?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Зафиксируйте границы ответственности между модулями и причины такого разделения.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Смешивают границы модулей и получают высокий coupling.
2. Оптимизируют локально, ухудшая глобальную архитектуру.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Где проходит boundary между модулями в этом кейсе?
2. Какое решение вы зафиксируете в ADR и какие альтернативы отвергнете?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Артефакт ADR или эквивалентный документ решения.
2. Ключевые trade-offs и причины выбранного решения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

2. Когда микрофронтенды оправданы, а когда вредят?

Теги: architecture, microfrontends, platform, governance Сложность: Senior

Короткий ответ

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

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В проектировании модулей, границ ответственности и поддерживаемой архитектуры продукта.
2. Главный риск: Размытые границы повышают связанность, замедляют изменения и увеличивают цену регрессий.
3. Как проверяете решение: Оформляю решение через ADR, затем проверяю ключевой trade-off на прототипе и эксплуатационных метриках.

Мини-пример

// Module Federation (концептуально)
const Header = React.lazy(() => import('shell/Header'));

Углубление (2-3 минуты)

1. Свяжите тему "Когда микрофронтенды оправданы, а когда вредят?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Назовите trade-offs: скорость изменений, надежность, стоимость сопровождения.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Оптимизируют локально, ухудшая глобальную архитектуру.
2. Не фиксируют критерии выбора решения и теряют историю trade-offs.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какое решение вы зафиксируете в ADR и какие альтернативы отвергнете?
2. Как проверите, что архитектура выдержит рост команды и нагрузки?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Dependency map и границы ownership.
2. Ключевые trade-offs и причины выбранного решения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

3. Как управлять performance budget в продукте?

Теги: performance, budget, cwv, observability Сложность: Senior

Короткий ответ

Performance budget - это численные пороги по ключевым метрикам и размеру ресурсов, которые контролируются автоматически в CI и в проде.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

{
  "budgets": [
    { "metric": "LCP", "threshold": 2500 },
    { "metric": "INP", "threshold": 200 }
  ]
}

Углубление (2-3 минуты)

1. Свяжите тему "Как управлять performance budget в продукте?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Переусложняют мемоизацию там, где нет измеримой проблемы.
2. Не проверяют сценарий на медленных устройствах и сетях.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
2. Что выберете: простоту кода или оптимизацию, и по какому критерию?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Критический путь рендера и метрики LCP/INP/CLS.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

4. Как выбирать стратегию рендеринга (CSR/SSR/SSG/ISR)?

Теги: rendering, csr-ssr-ssg-isr, caching, strategy Сложность: Senior

Короткий ответ

Стратегия рендеринга выбирается по типу контента, требованиям к SEO/персонализации, SLA по latency и стоимости эксплуатации.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Снимаю baseline в профайлере/DevTools, применяю изменение и подтверждаю эффект по LCP/INP/CPU time.

Мини-пример

// next.js idea
export const revalidate = 120;

Углубление (2-3 минуты)

1. Свяжите тему "Как выбирать стратегию рендеринга (CSR/SSR/SSG/ISR)?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите влияние темы на user-centric метрики (LCP, INP, CLS) и perceived performance.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Переусложняют мемоизацию там, где нет измеримой проблемы.
2. Не проверяют сценарий на медленных устройствах и сетях.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
2. Как будете валидировать эффект на медленных устройствах?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Профилирование рендера до/после изменения.
2. Критический путь рендера и метрики LCP/INP/CLS.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

5. Как строить state-management стратегию на Senior уровне?

Теги: state-management, architecture, scalability, ownership Сложность: Senior

Короткий ответ

Нужно разделить server state, UI state и derived state, задать ownership и хранить состояние максимально близко к месту использования.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В проектировании модулей, границ ответственности и поддерживаемой архитектуры продукта.
2. Главный риск: Размытые границы повышают связанность, замедляют изменения и увеличивают цену регрессий.
3. Как проверяете решение: Оформляю решение через ADR, затем проверяю ключевой trade-off на прототипе и эксплуатационных метриках.

Мини-пример

// server state -> query cache, ui state -> local/component
const { data } = useQuery(['profile', id], fetchProfile);

Углубление (2-3 минуты)

1. Свяжите тему "Как строить state-management стратегию на Senior уровне?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Зафиксируйте границы ответственности между модулями и причины такого разделения.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Оптимизируют локально, ухудшая глобальную архитектуру.
2. Не фиксируют критерии выбора решения и теряют историю trade-offs.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как проверите, что архитектура выдержит рост команды и нагрузки?
2. Какое решение вы зафиксируете в ADR и какие альтернативы отвергнете?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Ключевые trade-offs и причины выбранного решения.
2. Артефакт ADR или эквивалентный документ решения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

6. Как проектировать надежный data-fetching слой?

Теги: data-layer, reliability, api, resilience Сложность: Senior

Короткий ответ

Надежный слой данных должен стандартизировать ретраи, таймауты, отмену, дедупликацию и единый формат ошибок для UI и мониторинга.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Прогоняю нагрузочный кейс, фиксирую лимиты (timeout/concurrency/retry) и проверяю стабильность сервиса.

Мини-пример

const api = createApiClient({ timeoutMs: 8000, retries: 2 });

Углубление (2-3 минуты)

1. Свяжите тему "Как проектировать надежный data-fetching слой?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите границы request path и вынос тяжелых операций в фон.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Держат тяжелую обработку в синхронном request path.
2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какие метрики покажут деградацию раньше инцидента?
2. Что вынесете в фон, чтобы не блокировать critical path?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Границы Event Loop/I-O/CPU и backpressure.
2. Runbook деградации внешней зависимости.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

7. Какие риски у optimistic updates и как их контролировать?

Теги: optimistic-update, consistency, rollback, ux Сложность: Senior

Короткий ответ

Оптимистичные обновления ускоряют UX, но без rollback, idempotency и обработки конфликтов приводят к рассинхронизации данных.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример

onMutate: async (payload) => {
  const prev = queryClient.getQueryData(['items']);
  queryClient.setQueryData(['items'], optimisticPatch(prev, payload));
  return { prev };
}

Углубление (2-3 минуты)

1. Свяжите тему "Какие риски у optimistic updates и как их контролировать?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите минимальные quality gates и критерии rollback.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют проверки в CI без учета времени обратной связи команды.
2. Деплоят без заранее описанного rollback-плана.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как измерите влияние изменения на lead time и CFR?
2. Какой сигнал в мониторинге станет trigger для rollback?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Структуру CI/CD и обязательные quality gates.
2. Метрики процесса: lead time, CFR, flaky rate.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

8. Как подходить к разработке Design System?

Теги: design-system, platform, versioning, governance Сложность: Senior

Короткий ответ

Design System - это продукт с API, версионированием, токенами, governance и метриками внедрения, а не набор разрозненных компонентов.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Оформляю решение через ADR, затем проверяю ключевой trade-off на прототипе и эксплуатационных метриках.

Мини-пример

export const Button = createComponent<ButtonProps>('Button', tokens.button);

Углубление (2-3 минуты)

1. Свяжите тему "Как подходить к разработке Design System?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите, какие решения документируете в ADR и почему.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Оптимизируют локально, ухудшая глобальную архитектуру.
2. Не фиксируют критерии выбора решения и теряют историю trade-offs.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как проверите, что архитектура выдержит рост команды и нагрузки?
2. Где проходит boundary между модулями в этом кейсе?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Dependency map и границы ownership.
2. Артефакт ADR или эквивалентный документ решения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

9. Как встроить accessibility в процесс разработки?

Теги: accessibility, process, ci, quality Сложность: Senior

Короткий ответ

Accessibility должна быть частью Definition of Done и CI-процесса, а не ручной проверкой в конце релиза.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Проверяю на двух контрпримерах (где работает/где ломается) и закрепляю мини-задачей в песочнице.

Мини-пример

expect(await axe(container)).toHaveNoViolations();

Углубление (2-3 минуты)

1. Свяжите тему "Как встроить accessibility в процесс разработки?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Назовите признак, по которому поймете, что решение сработало в реальном проекте.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Путают терминологию и не фиксируют критерий проверки.
2. Не проговаривают ограничения и edge-cases.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какой минимальный тест докажет корректность подхода?
2. Где граница применимости этого решения?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Базовые определения темы и 2 контрпримера (где работает и где ломается).
2. Связанный вопрос из Банка вопросов для закрепления.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

10. Что входит в frontend observability?

Теги: observability, monitoring, tracing, incident-response Сложность: Senior

Короткий ответ

Observability включает метрики, логи, ошибки, трассировку и runbooks, чтобы быстро находить и устранять причины деградаций.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Проверяю на двух контрпримерах (где работает/где ломается) и закрепляю мини-задачей в песочнице.

Мини-пример

captureException(error, { tags: { release, route, feature }, extra: { traceId } });

Углубление (2-3 минуты)

1. Свяжите тему "Что входит в frontend observability?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Назовите признак, по которому поймете, что решение сработало в реальном проекте.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Дают определение, но не объясняют, как это использовать в рабочем коде.
2. Не проговаривают ограничения и edge-cases.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как поведет себя решение на edge-case и почему?
2. Какой минимальный тест докажет корректность подхода?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Связанный вопрос из Банка вопросов для закрепления.
2. Базовые определения темы и 2 контрпримера (где работает и где ломается).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

11. Какие ключевые security-практики во фронтенде?

Теги: security, xss-csrf-csp, auth, threat-model Сложность: Senior

Короткий ответ

Базовый набор: защита от XSS/CSRF, безопасное хранение сессии, CSP, контроль third-party скриптов и регулярный аудит зависимостей.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В авторизации, хранении данных и безопасной работе клиента с API.
2. Главный риск: Ошибки здесь приводят к уязвимостям, утечкам данных и инцидентам безопасности.
3. Как проверяете решение: Проверяю threat model на конкретном endpoint, прогоняю негативные кейсы и сверяю audit-логи до/после.

Мини-пример

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'

Углубление (2-3 минуты)

1. Свяжите тему "Какие ключевые security-практики во фронтенде?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Опишите, где контроль должен стоять на сервере, а где на клиенте.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Ориентируются только на client-side защиту без серверной проверки.
2. Путают CORS, аутентификацию и авторизацию как один механизм.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какой abuse-case вы проверите первым?
2. Какие данные/операции требуют серверной валидации независимо от клиента?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Негативные тесты на abuse-сценарии.
2. Разницу между AuthN/AuthZ, CORS, CSRF и XSS.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

12. Как выстраивать release strategy на фронтенде?

Теги: release, feature-flags, canary, rollback Сложность: Senior

Короткий ответ

Release strategy должна обеспечивать управляемый rollout, быстрый rollback и контроль качества через метрики.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример

if (flags.newCheckout && canaryBucket <= 10) {
  enableNewCheckout();
}

Углубление (2-3 минуты)

1. Свяжите тему "Как выстраивать release strategy на фронтенде?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как решение сокращает lead time или снижает change failure rate.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
2. Деплоят без заранее описанного rollback-плана.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как измерите влияние изменения на lead time и CFR?
2. Какие quality gates обязательны перед релизом этой зоны?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. План rollout/rollback и критерии остановки релиза.
2. Метрики процесса: lead time, CFR, flaky rate.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

13. Что такое error budget и зачем он фронтенду?

Теги: reliability, slo, error-budget, governance Сложность: Senior

Короткий ответ

Error budget - это допустимый объем деградаций относительно SLO, который помогает балансировать скорость доставки и стабильность.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Провожу design review по критериям (масштаб, надежность, сопровождение) и валидирую через spike/POC.

Мини-пример

SLO: 99.9% successful checkout interactions / 30 days

Углубление (2-3 минуты)

1. Свяжите тему "Что такое error budget и зачем он фронтенду?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Назовите trade-offs: скорость изменений, надежность, стоимость сопровождения.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Оптимизируют локально, ухудшая глобальную архитектуру.
2. Не фиксируют критерии выбора решения и теряют историю trade-offs.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как проверите, что архитектура выдержит рост команды и нагрузки?
2. Какое решение вы зафиксируете в ADR и какие альтернативы отвергнете?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Артефакт ADR или эквивалентный документ решения.
2. Ключевые trade-offs и причины выбранного решения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

14. Как рендерить очень большие списки?

Теги: performance, virtualization, ux, accessibility Сложность: Senior

Короткий ответ

Комбинировать виртуализацию, пагинацию и оптимизацию рендера с учетом доступности и UX-навигации.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Проверяю целевой сценарий под slow network/CPU throttling и подтверждаю улучшение цифрами, а не ощущением.

Мини-пример

<VirtualList itemCount={rows.length} itemSize={40} renderItem={Row} />

Углубление (2-3 минуты)

1. Свяжите тему "Как рендерить очень большие списки?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как изменение влияет на рендер и стоимость JavaScript.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не проверяют сценарий на медленных устройствах и сетях.
2. Переусложняют мемоизацию там, где нет измеримой проблемы.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как будете валидировать эффект на медленных устройствах?
2. Как эта тема влияет на LCP/INP/CLS в реальном интерфейсе?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Профилирование рендера до/после изменения.
2. Границы SSR/CSR/SSG/ISR (если применимо).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

15. Когда использовать Web Workers?

Теги: web-workers, concurrency, performance, architecture Сложность: Senior

Короткий ответ

Когда CPU-heavy вычисления мешают интерактивности main thread и их можно выполнить без прямого доступа к DOM.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В производительности интерфейса: рендер, загрузка ассетов, отзывчивость и стабильность UX.
2. Главный риск: Неправильная реализация дает лишние ререндеры, рост LCP/TTI и деградацию пользовательского пути.
3. Как проверяете решение: Оформляю решение через ADR, затем проверяю ключевой trade-off на прототипе и эксплуатационных метриках.

Мини-пример

worker.postMessage(buffer, [buffer]); // transferable

Углубление (2-3 минуты)

1. Свяжите тему "Когда использовать Web Workers?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Назовите trade-offs: скорость изменений, надежность, стоимость сопровождения.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Смешивают границы модулей и получают высокий coupling.
2. Оптимизируют локально, ухудшая глобальную архитектуру.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Где проходит boundary между модулями в этом кейсе?
2. Какое решение вы зафиксируете в ADR и какие альтернативы отвергнете?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Артефакт ADR или эквивалентный документ решения.
2. Dependency map и границы ownership.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

16. Какие quality gates должны быть в CI для фронтенда?

Теги: ci-cd, quality-gates, testing, delivery Сложность: Senior

Короткий ответ

CI должен комбинировать быстрые обязательные проверки в PR и расширенные прогоны по расписанию, сохраняя быстрый feedback loop.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример

pr: [lint, typecheck, unit, smoke-e2e]
nightly: [full-e2e, performance, security-scan]

Углубление (2-3 минуты)

1. Свяжите тему "Какие quality gates должны быть в CI для фронтенда?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Покажите, как решение сокращает lead time или снижает change failure rate.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Добавляют проверки в CI без учета времени обратной связи команды.
2. Деплоят без заранее описанного rollback-плана.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как измерите влияние изменения на lead time и CFR?
2. Какие quality gates обязательны перед релизом этой зоны?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. План rollout/rollback и критерии остановки релиза.
2. Метрики процесса: lead time, CFR, flaky rate.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

17. Как выстраивать тестовую стратегию фронтенда?

Теги: testing, strategy, risk-based, quality Сложность: Senior

Короткий ответ

Тестирование должно быть risk-based: защищать критичные пользовательские потоки минимально достаточным набором unit/integration/e2e.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Собираю короткий воспроизводимый пример, прогоняю edge-case и объясняю результат без подсказок.

Мини-пример

Smoke e2e: login -> search -> checkout
Integration: pricing rules
Unit: pure formatters/parsers

Углубление (2-3 минуты)

1. Свяжите тему "Как выстраивать тестовую стратегию фронтенда?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Назовите признак, по которому поймете, что решение сработало в реальном проекте.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не проговаривают ограничения и edge-cases.
2. Путают терминологию и не фиксируют критерий проверки.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какой минимальный тест докажет корректность подхода?
2. Где граница применимости этого решения?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Базовые определения темы и 2 контрпримера (где работает и где ломается).
2. Мини-код, который воспроизводит поведение и проверяется за 1-2 минуты.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

18. Как работать с эволюцией API-контрактов?

Теги: api-contracts, evolution, compatibility, versioning Сложность: Senior

Короткий ответ

Эволюция контрактов должна быть управляемой: schema как source of truth, окно деприкации и автоматическая проверка совместимости.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Проверяю сценарий под пиковым трафиком: latency, saturation и поведение при деградации зависимости.

Мини-пример

OpenAPI deprecation marker:
User:
  properties:
    legacyField:
      deprecated: true

Углубление (2-3 минуты)

1. Свяжите тему "Как работать с эволюцией API-контрактов?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Разберите поведение системы под пиковым трафиком и деградацией внешних зависимостей.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Запускают изменения без наблюдаемости и runbook.
2. Не ограничивают ресурсы (конкурентность, очередь, таймауты).
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Какие метрики покажут деградацию раньше инцидента?
2. Что вынесете в фон, чтобы не блокировать critical path?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Границы Event Loop/I-O/CPU и backpressure.
2. Runbook деградации внешней зависимости.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

19. Как проводить postmortem после фронтенд-инцидента?

Теги: incident-management, postmortem, reliability, process Сложность: Senior

Короткий ответ

Postmortem должен быть blameless, с root-cause анализом и измеримыми action items с владельцами и сроками.

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В архитектурных решениях и технической стратегии команды на уровне продукта.
2. Главный риск: Архитектурный долг накапливается, команда теряет предсказуемость поставки и качество релизов.
3. Как проверяете решение: Делаю ручную проверку сценария + мини-тест, чтобы подтвердить поведение в реальном коде.

Мини-пример

Incident -> Timeline -> Root causes -> Actions(owner, due date, KPI)

Углубление (2-3 минуты)

1. Свяжите тему "Как проводить postmortem после фронтенд-инцидента?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Разложите ответ на «механика -> применение -> ограничение», чтобы показать не только теорию, но и практику.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Дают определение, но не объясняют, как это использовать в рабочем коде.
2. Не проговаривают ограничения и edge-cases.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Как поведет себя решение на edge-case и почему?
2. Какой минимальный тест докажет корректность подхода?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Связанный вопрос из Банка вопросов для закрепления.
2. Базовые определения темы и 2 контрпримера (где работает и где ломается).
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design

20. Что ожидается от Senior в техническом лидерстве?

Теги: leadership, architecture, mentoring, strategy Сложность: Senior

Короткий ответ

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

Что сказать на интервью (30-60 секунд)

1. Где это применяется: В проектировании модулей, границ ответственности и поддерживаемой архитектуры продукта.
2. Главный риск: Размытые границы повышают связанность, замедляют изменения и увеличивают цену регрессий.
3. Как проверяете решение: Сверяю dependency map и проверяю, что изменения не ломают критический пользовательский поток.

Мини-пример

Initiative -> Hypothesis -> Delivery plan -> Metrics impact -> Retrospective

Куда дальше

1. Вернитесь в модуль: Frontend System Design.
2. Сверьтесь с картой темы: Frontend System Design.
3. Продолжайте по маршруту: Senior трек.
4. Закрепите один ответ на практике в Песочнице.

Углубление (2-3 минуты)

1. Свяжите тему "Что ожидается от Senior в техническом лидерстве?" с одним production-сценарием и объясните, почему она влияет на результат.
2. Назовите trade-offs: скорость изменений, надежность, стоимость сопровождения.
3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки

1. Не фиксируют критерии выбора решения и теряют историю trade-offs.
2. Смешивают границы модулей и получают высокий coupling.
3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы

1. Где проходит boundary между модулями в этом кейсе?
2. Какое решение вы зафиксируете в ADR и какие альтернативы отвергнете?
3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить

1. Артефакт ADR или эквивалентный документ решения.
2. Ключевые trade-offs и причины выбранного решения.
3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта

1. Обучение: Frontend-архитектура
2. Обучение: Frontend System Design
3. Карта подготовки: Frontend System Design