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

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. Начинаю не с папок, а с доменов, потоков данных, командного ownership и правил зависимостей.
  2. Для каждого домена задаю public API, запрещенные imports, owner, contract surface, shared UI boundary и правила изменения.
  3. Архитектура должна иметь guardrails: lint rules, module boundaries, review checklist, ADR и migration path.
  4. Production-риск: без границ появляется shared-свалка, feature teams меняют чужие internals, а регрессии становятся непредсказуемыми.
  5. Проверяю через architecture boundary map: domain, owner, public API, allowed dependencies, forbidden dependency, validation.

Мини-пример​

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

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

  1. Production-сценарий: checkout напрямую импортирует internals из catalog и pricing. Любое изменение цены ломает оформление заказа, потому что нет public contract.
  2. Edge-case: общий shared/utils быстро становится скрытым coupling. Для shared-кода нужен владелец, критерий добавления и reverse-dependency review.
  3. Trade-off: строгие boundaries замедляют мелкие изменения, но уменьшают цену масштабирования команд и регрессий.
  4. Практика: заполните boundary map для catalog, cart, checkout, profile, shared-ui и добавьте одну lint/CI guardrail.
  5. Readiness: вы можете показать artifact, который предотвратит forbidden import, а не только описать "чистую архитектуру".

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

  1. Проектируют структуру папок без ownership и правил зависимостей.
  2. Делают shared зоной без владельца и criteria.
  3. Путают слой UI-компонентов с доменной границей.
  4. Не добавляют automated guardrails, поэтому архитектура остается договоренностью в голове.

Follow-up вопросы​

  1. Как определить доменную границу, если две команды используют один UI flow?
  2. Что должно быть в public API домена?
  3. Какой automated guardrail защитит boundary?
  4. Когда shared module лучше, а когда нужен отдельный domain package?

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

  1. Frontend-архитектура: boundaries, ownership, dependency rules.
  2. Interview pattern taxonomy: quality-gate and render-ownership.
  3. Free-practice: architecture boundary map for five domains plus one lint rule.

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

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

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

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

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

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

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

  1. Микрофронтенды оправданы, когда команды должны независимо разрабатывать, релизить и владеть доменами с минимальной координацией.
  2. Нужны зрелые platform capabilities: routing/composition, shared auth/session, design system, observability, versioning, rollback, dependency policy.
  3. Не оправданы, если проблема только в большом bundle или плохой модульности внутри одной команды.
  4. Production-риск: дублирование зависимостей, несовместимые версии design system, разные UX-паттерны, сложный incident ownership.
  5. Проверяю через microfrontend decision matrix: team autonomy, release cadence, runtime integration, shared dependencies, rollback, owner.

Мини-пример​

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

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

  1. Production-сценарий: marketplace, payments и logistics имеют разные команды, SLA и release cadence. Микрофронтенды могут снизить coordination cost.
  2. Counter-case: один frontend team с монолитным dashboard хочет микрофронтенды из-за медленного build. Сначала нужны modularization, route splitting, ownership, CI optimization.
  3. Edge-case: shared singleton dependencies вроде React, auth client и design tokens должны иметь policy, иначе runtime composition ломается.
  4. Практика: заполните decision matrix и добавьте exit criteria: когда решение пересматривается или откатывается.
  5. Readiness: вы можете назвать цену platform layer и failure modes, а не только плюсы автономности.

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

  1. Используют микрофронтенды как лекарство от плохой модульности.
  2. Не назначают owner для shell, shared libraries и cross-app incidents.
  3. Не считают стоимость duplicated dependencies и runtime integration.
  4. Не фиксируют fallback: что происходит, если remote не загрузился.

Follow-up вопросы​

  1. Какие признаки говорят, что микрофронтенды преждевременны?
  2. Кто владеет shell и shared dependencies?
  3. Как откатить один remote, не ломая весь продукт?
  4. Какие альтернативы нужно попробовать до микрофронтендов?

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

  1. Frontend System Design: system boundaries and rollout strategy.
  2. Frontend-архитектура: ownership and module boundaries.
  3. Free-practice: microfrontend decision matrix for three product areas.

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

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

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

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

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

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

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

  1. Performance budget - это контракт качества: какие метрики и resource limits нельзя ухудшать без явного решения.
  2. Budget должен покрывать lab и field signals: bundle/resource size in CI, LCP/INP/CLS/RUM в production, route-level critical flows.
  3. Для каждого threshold нужен owner, источник данных, gate behavior и exception process.
  4. Production-риск: без gate performance деградирует маленькими изменениями, а команда замечает проблему только после падения conversion/UX.
  5. Проверяю через performance budget gate: metric, threshold, source, blocking?, owner, exception, rollback trigger.

Мини-пример​

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

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

  1. Production-сценарий: checkout route получает новый analytics SDK и image carousel. Bundle растет, INP ухудшается, но без budget это выглядит как обычный feature PR.
  2. Edge-case: lab budget может быть зеленым, а field data красным на слабых устройствах; нужен разный источник для CI gate и production monitoring.
  3. Trade-off: строгий blocking gate защищает UX, но может тормозить релизы; поэтому нужны exception owner, срок и follow-up.
  4. Практика: составьте budget gate для home, search, checkout, включая resource size, LCP, INP и rollback trigger.
  5. Readiness: вы можете объяснить, что блокирует PR, что алертит в проде, и кто принимает exception.

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

  1. Ставят budget только на Lighthouse score вместо конкретных route-level metrics.
  2. Не разделяют CI lab checks и production RUM.
  3. Не назначают owner и exception process.
  4. Оптимизируют React rerender, когда budget нарушен из-за images, third-party или bundle growth.

Follow-up вопросы​

  1. Какие метрики стоит блокировать в PR, а какие мониторить в production?
  2. Как обработать легитимное превышение budget?
  3. Почему Lighthouse score недостаточен как единственный budget?
  4. Как связать bundle budget с user-centric metrics?

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

  1. Rendering lesson 1: critical path and metrics.
  2. Interview pattern taxonomy: performance-budget.
  3. Free-practice: performance budget gate for three critical routes.

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

  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. Стратегия рендеринга выбирается по data freshness, personalization, SEO, cacheability, latency, operational cost и hydration risk.
  2. CSR подходит для приватных интерактивных зон; SSR - для динамического SEO/персонализированного HTML; SSG/ISR - для cacheable content с понятной стратегией обновления.
  3. Senior-уровень - это не выбрать один режим, а задать route-level policy и исключения.
  4. Production-риск: неправильный режим может раскрыть private data через cache, ухудшить first content или создать hydration mismatch.
  5. Проверяю через rendering strategy decision table: route, content freshness, SEO, auth/personalization, cache, mode, failure mode.

Мини-пример​

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

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

  1. Production-сценарий: product page должен индексироваться и обновлять цену. Можно выбрать SSR или ISR с clear invalidation, а private discounts догружать после auth.
  2. Edge-case: SSR с user-specific HTML требует строгой cache policy, иначе возможна утечка персональных данных.
  3. Edge-case: SSG без revalidation plan делает контент быстрым, но stale.
  4. Практика: заполните route decision table для landing, product, checkout, dashboard, docs.
  5. Readiness: вы можете объяснить policy по routes и назвать failure mode для каждого режима.

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

  1. Выбирают SSR как default "для SEO", не проверяя cache и personalization.
  2. Используют SSG для данных, где stale content неприемлем.
  3. Делают CSR для публичной страницы, где нужен indexable first content.
  4. Не учитывают hydration mismatch и browser-only state.

Follow-up вопросы​

  1. Какие route properties толкают к SSR, а какие к SSG/ISR?
  2. Где опасна персонализация server-rendered HTML?
  3. Как выбрать revalidation strategy?
  4. Как связаны rendering mode и hydration risk?

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

  1. Rendering lesson 1: CSR, SSR, SSG and critical path.
  2. Middle q-11..q-12: rendering modes and hydration mismatch.
  3. Free-practice: rendering strategy decision table for five routes.

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

  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. Сначала классифицирую state: server/cache state, local UI state, URL state, form draft, derived state, cross-route app state.
  2. Для каждого state задаю owner, lifetime, source of truth, invalidation, persistence, sync boundary и testing strategy.
  3. Server state обычно лучше держать в query/cache layer, UI draft - ближе к component, URL state - в router/search params.
  4. Production-риск: один global store для всего создает coupling, stale data, сложные invalidation bugs и лишние rerender.
  5. Проверяю через state ownership map: state, kind, owner, source of truth, lifetime, sync/invalidation, failure mode.

Мини-пример​

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

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

  1. Production-сценарий: checkout хранит cart server state, coupon draft, selected delivery, derived totals и URL step. Если все смешать в global store, rollback и refresh становятся непредсказуемыми.
  2. Edge-case: derived totals не должны быть отдельным mutable state, если их можно вычислить из cart and coupon.
  3. Edge-case: optimistic update требует rollback, conflict policy and idempotency, иначе UI уедет от server truth.
  4. Практика: заполните state ownership map для search page, checkout, profile settings, admin table.
  5. Readiness: вы можете объяснить, где state живет, как инвалидируется, что переживает refresh и какой failure mode защищаете.

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

  1. Складывают server state и UI draft в один global store.
  2. Хранят derived state как mutable source of truth.
  3. Не фиксируют invalidation strategy и получают stale screens.
  4. Выбирают state library до классификации state и ownership.

Follow-up вопросы​

  1. Как отличить server state от UI state?
  2. Что должно жить в URL state?
  3. Какой state переживает refresh, а какой нет?
  4. Какой rollback нужен для optimistic update?

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

  1. React lesson 3: state ownership and derived state.
  2. Мосты практики: React state and performance.
  3. Free-practice: state ownership map for one checkout or dashboard flow.

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

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

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

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

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

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

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

  1. Data-fetching layer задает единый request lifecycle: timeout, cancellation, retry policy, deduplication, cache, invalidation and error mapping.
  2. Разделяю reads, mutations, critical path and background refresh: у них разные retry, stale time, loading states and rollback behavior.
  3. Для idempotent requests можно включать bounded retry with backoff; для mutations нужен осторожный retry, idempotency и понятная ошибка.
  4. Production-риск: retry storm, stale response overwrite, вечный loading, разные error formats и рассинхронизация cache/UI.
  5. Проверяю через data-fetching policy table: operation, timeout, abort, retry, dedupe, cache, invalidation, error UI, owner.

Мини-пример​

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

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

  1. Production-сценарий: search page отправляет запрос на каждый ввод. Без abort/requestId медленный ответ на a может перетереть быстрый ответ на abc.
  2. Edge-case: retry безопасен для GET /products, но опасен для POST /orders, если нет idempotency key или защиты от двойного действия.
  3. Edge-case: cache помогает latency, но без invalidation после mutation пользователь видит stale данные.
  4. Практика: заполните policy table для search, profile, checkout submit, notifications background refresh.
  5. Readiness: вы можете объяснить, что происходит при timeout, abort, duplicate request, 500, offline и stale cache.

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

  1. Делают retry для всех запросов одинаково, включая неидемпотентные mutations.
  2. Не отменяют устаревшие запросы и получают stale response overwrite.
  3. Смешивают server state, loading flags и UI draft в одном глобальном store.
  4. Не стандартизируют error states: empty, partial, stale, unavailable и blocked выглядят одинаково.

Follow-up вопросы​

  1. Какие операции можно retry, а какие нельзя без idempotency?
  2. Чем abort отличается от игнорирования устаревшего response по requestId?
  3. Где живет invalidation policy?
  4. Как показать пользователю partial или stale data?

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

  1. React lesson 3: server state, UI state and derived state.
  2. React effect/state debug pack.
  3. Free-practice: data-fetching policy table for four operations and one stale response reproduction.

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

  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. Optimistic update оправдан, когда действие быстро обратимо, конфликтность низкая, а UX выигрывает от мгновенной реакции.
  2. Нужны snapshot previous state, optimistic patch, rollback on error, reconciliation on success, invalidation/refetch и conflict policy.
  3. Для mutations фиксирую idempotency/deduplication rule, disabled/double-click behavior и что показываем при rollback.
  4. Production-риск: UI показывает действие как успешное, server отклоняет mutation, а cache, totals или соседние вкладки остаются в разном состоянии.
  5. Проверяю через rollback plan: mutation, optimistic patch, snapshot, server response, rollback, conflict, refetch, user message.

Мини-пример​

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

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

  1. Production-сценарий: пользователь меняет количество товара в cart. UI сразу обновляет quantity and total, но server возвращает out of stock.
  2. Edge-case: derived totals нельзя патчить как independent source of truth; их нужно пересчитать из cart или заменить server response.
  3. Edge-case: два быстрых клика или две вкладки создают race; нужен порядок reconciliation или последний подтвержденный server state.
  4. Практика: составьте rollback plan для like, cart quantity, coupon apply, profile save.
  5. Readiness: вы можете показать, что увидит пользователь при success, validation error, network error, conflict and duplicate click.

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

  1. Делают optimistic update без snapshot и rollback.
  2. Не различают network error, validation reject and conflict.
  3. Патчат derived state, который должен вычисляться из server truth.
  4. Не инвалидируют связанные queries после подтверждения server response.

Follow-up вопросы​

  1. Когда optimistic update лучше заменить pessimistic flow?
  2. Что хранить в snapshot для rollback?
  3. Как обработать конфликт между optimistic patch и server response?
  4. Как защититься от duplicate mutation?

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

  1. Senior q-5: state ownership and invalidation.
  2. Мосты практики: React state and performance.
  3. Free-practice: optimistic update rollback plan for one cart or profile mutation.

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

  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. Design System - это platform product: tokens, primitives, components, patterns, documentation, accessibility, versioning and support model.
  2. Нужны ownership and governance: кто принимает component API, кто владеет tokens, как проходят breaking changes and migrations.
  3. Компоненты должны иметь contract: props, states, accessibility behavior, theming rules, composition limits and test coverage.
  4. Production-риск: продукт расходится по UX, команды копируют компоненты, breaking change ломает десятки экранов, а DS становится bottleneck.
  5. Проверяю через governance map: asset, owner, consumer, API stability, a11y requirement, versioning, migration, adoption signal.

Мини-пример​

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

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

  1. Production-сценарий: пять команд делают свои Button, Modal and DatePicker; UX расходится, accessibility fixes размножаются вручную.
  2. Edge-case: слишком низкоуровневый DS дает гибкость, но не снижает product inconsistency; слишком жесткий DS блокирует редкие продуктовые сценарии.
  3. Edge-case: token change кажется маленьким, но ломает contrast or spacing в consumer apps; нужен migration and visual/a11y check.
  4. Практика: заполните governance map для Button, Modal, FormField, Table, DatePicker.
  5. Readiness: вы можете объяснить contribution flow, release policy, deprecation path and how consumers report gaps.

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

  1. Называют Design System набором UI-компонентов без tokens, docs, governance and support.
  2. Публикуют breaking changes без migration path.
  3. Не проверяют accessibility behavior как часть component contract.
  4. Делают DS bottleneck: каждая продуктовая мелочь требует central team approval.

Follow-up вопросы​

  1. Что входит в contract компонента Design System?
  2. Как выпускать breaking change в популярном компоненте?
  3. Когда component должен быть в DS, а когда остаться product-local?
  4. Как измерить adoption без выдумывания vanity metrics?

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

  1. Frontend-архитектура: ownership, public API and dependency boundaries.
  2. Senior q-1: architecture boundary map.
  3. Free-practice: Design System governance map for five shared assets.

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

  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. Accessibility должна быть quality gate: requirements in design, component contract, code review, automated checks, keyboard testing and manual verification.
  2. Автоматические проверки ловят часть проблем, но не заменяют keyboard walkthrough, screen reader semantics and product-flow review.
  3. Для критичных компонентов фиксирую accessible name, role, focus behavior, error announcement, contrast risk and disabled/loading states.
  4. Production-риск: форма или modal визуально работают, но keyboard-only user не может пройти flow или screen reader не получает ошибку.
  5. Проверяю через a11y gate checklist: surface, semantic structure, name/role/value, keyboard path, focus, contrast, error, test, owner.

Мини-пример​

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

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

  1. Production-сценарий: checkout modal открывается, но focus остается за modal, Esc не закрывает окно, error message не связан с input.
  2. Edge-case: aria-label не спасает custom control, если keyboard behavior не соответствует ожидаемому interaction pattern.
  3. Edge-case: disabled button может скрыть причину ошибки; иногда лучше enabled action with validation message.
  4. Практика: пройдите DOM/a11y audit pack для login form, modal, table, menu.
  5. Readiness: вы можете показать keyboard-only path, accessibility tree observation and one automated assertion.

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

  1. Полагаются только на axe/linter и не проверяют реальный keyboard flow.
  2. Добавляют ARIA вместо исправления semantic HTML.
  3. Не описывают focus management for modal, menu, toast and validation errors.
  4. Проверяют accessibility в конце релиза, когда исправления уже дорогие.

Follow-up вопросы​

  1. Что automated a11y test не поймает?
  2. Как проверить modal без мыши?
  3. Когда ARIA ухудшает доступность?
  4. Где accessibility requirement должен появиться: design, component contract или QA?

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

  1. HTML/CSS lesson 1: semantic HTML and forms.
  2. DOM/a11y audit pack.
  3. Free-practice: accessibility quality gate checklist for one modal and one form.

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

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

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

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

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

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

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

  1. Frontend observability должна отвечать: что сломалось, у кого, на каком route/release/device, насколько часто, и какой owner реагирует.
  2. Сигналы: error tracking, web vitals/RUM, custom business-flow events, logs/breadcrumbs, traces/correlation id, release markers and alerts.
  3. Нужны taxonomy and sampling rules: severity, fingerprinting, PII policy, environment, feature flag, route and rollback trigger.
  4. Production-риск: есть тысячи ошибок без route/release context, нельзя отличить один noisy client bug от массовой деградации checkout.
  5. Проверяю через observability signal matrix: signal, source, tags, owner, alert?, dashboard, runbook, rollback trigger.

Мини-пример​

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

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

  1. Production-сценарий: после релиза checkout у части пользователей падает submit. Без release tag, route, browser, user flow breadcrumb and request correlation incident долго ищут вручную.
  2. Edge-case: слишком агрессивное логирование может утечь private data; observability должна иметь PII redaction and payload limits.
  3. Edge-case: алерт по каждой ошибке создает шум; alert нужен для user-impacting rate or critical flow, а не для каждого exception.
  4. Практика: заполните signal matrix для checkout submit, search empty results, login failure, slow product page.
  5. Readiness: вы можете объяснить, какой сигнал поднимет alert, какой попадет только в dashboard, и где лежит runbook.

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

  1. Ставят error tracker без release, route, feature and owner tags.
  2. Логируют raw payloads и private data.
  3. Не связывают frontend error с backend request/correlation id.
  4. Делают dashboards без runbook and rollback trigger.

Follow-up вопросы​

  1. Какие tags нужны для frontend exception?
  2. Что нельзя логировать на клиенте?
  3. Чем error tracking отличается от RUM and tracing?
  4. Когда сигнал должен alert, а когда оставаться dashboard-only?

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

  1. Frontend System Design: reliability, rollout and ownership.
  2. Interview pattern taxonomy: quality-gate and rollback decision.
  3. Free-practice: observability signal matrix for four critical frontend flows.

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

  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. На frontend я разделяю threat surfaces: user input/rendering, session storage, API calls, third-party scripts, browser policies and dependency supply chain.
  2. XSS контролируется context-aware escaping/sanitization, safe sinks, осторожным отношением к innerHTML, CSP как дополнительным слоем, а не единственной защитой.
  3. CSRF/AuthZ нельзя "починить фронтом": server должен проверять permission, token/cookie policy, origin/session rules and state-changing requests.
  4. Production-риск: один unsafe render или third-party script может привести к account takeover, token leakage, fraud action или утечке приватных данных.
  5. Проверяю через frontend threat model: surface, asset, attacker action, client control, server control, evidence, owner.

Мини-пример​

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

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

  1. Production-сценарий: rich text preview рендерит user HTML через unsafe sink. Framework escaping уже не помогает, нужен sanitizer, запрет опасных URL and CSP as defense-in-depth.
  2. Edge-case: localStorage удобен для client state, но не подходит для секретов при XSS-risk; HttpOnly cookie защищает от JS-read, но требует server-side CSRF/session controls.
  3. Edge-case: CORS не является авторизацией; он ограничивает browser reads, но server все равно обязан проверять permission.
  4. Практика: составьте threat model для login form, profile edit, rich text preview, third-party analytics script.
  5. Readiness: вы можете назвать, какой контроль на client, какой на server, и что считается blocked до утвержденного auth/error contract.

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

  1. Полагаются только на CSP и не исправляют unsafe sinks.
  2. Хранят секреты в доступном JS storage без threat model.
  3. Путают CORS, AuthN, AuthZ and CSRF.
  4. Описывают frontend validation как security boundary для прав доступа.

Follow-up вопросы​

  1. Где framework escaping перестает защищать от XSS?
  2. Почему CSP - не замена sanitization/output encoding?
  3. Что должен проверять server, даже если frontend уже спрятал кнопку?
  4. Какие данные нельзя логировать или хранить на клиенте?

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

  1. Security lesson 2: XSS, CSRF, storage and auth boundaries.
  2. Мосты практики: Browser storage and CORS.
  3. Free-practice: frontend threat model for four surfaces with explicit client/server controls.

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

  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. Release strategy задает, как изменение попадает к пользователям: quality gates, feature flags, canary/gradual rollout, monitoring, rollback and ownership.
  2. Для frontend важно разделять deploy and release: код может быть задеплоен, но feature включается по флагу, cohort, route или environment.
  3. У каждого rollout должен быть stop condition: error rate, critical flow failure, Web Vitals regression, support signal or owner decision.
  4. Production-риск: big-bang release ломает checkout всем пользователям, а команда не может быстро выключить feature без нового deploy.
  5. Проверяю через rollout/rollback plan: change, flag, cohort, gates, signals, stop condition, rollback action, owner, comms.

Мини-пример​

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

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

  1. Production-сценарий: новый checkout включается для 5% пользователей. Если растут submit errors или INP, feature flag выключается без rollback всего сайта.
  2. Edge-case: feature flag не заменяет backward compatibility; old frontend может говорить с new backend и наоборот.
  3. Edge-case: canary без достаточного traffic или без целевого critical-flow signal создает ложное чувство безопасности.
  4. Практика: составьте rollout plan для new checkout, new search ranking, design system modal migration, tracking SDK update.
  5. Readiness: вы можете объяснить, что блокирует merge, что блокирует rollout, что выключает feature, и кто принимает решение.

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

  1. Путают deploy, release and rollout.
  2. Добавляют feature flag без owner, cleanup date and kill-switch behavior.
  3. Не определяют stop condition до релиза.
  4. Делают rollback только через новый deploy, хотя feature можно было изолировать флагом.

Follow-up вопросы​

  1. Чем deploy отличается от release?
  2. Какие изменения нельзя безопасно спрятать только feature flag?
  3. Какие signals нужны для canary checkout?
  4. Когда rollback лучше, чем rollout pause?

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

  1. Frontend System Design: rollout, ownership and reliability.
  2. Interview pattern taxonomy: quality-gate and rollback decision.
  3. Free-practice: rollout/rollback plan for one critical frontend feature.

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

  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. Error budget связывает user-facing SLO с допустимым объемом деградации за окно времени и помогает принимать release/reliability decisions.
  2. Для frontend SLO должен быть измеримым через user journeys: successful checkout interaction, search results loaded, JS error-free sessions, acceptable Web Vitals.
  3. Budget burn влияет на поведение команды: можно продолжать rollout, замедлить feature delivery, усилить quality gates или заняться reliability work.
  4. Production-риск: без SLO команда спорит ощущениями - "страница иногда медленная" - вместо решения по user-impact and budget burn.
  5. Проверяю через frontend SLO table: journey, SLI, SLO, window, data source, exclusions, budget burn action, owner.

Мини-пример​

SLO: 99.9% successful checkout interactions / 30 days

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

  1. Production-сценарий: checkout SLO нарушается после серии frontend releases. Команда временно останавливает risky rollout и чинит submit errors/INP before new features.
  2. Edge-case: availability backend API и frontend journey success - разные SLI; пользователь может не завершить flow из-за JS error или client-side validation loop.
  3. Edge-case: слишком жесткий SLO блокирует delivery без реального user impact; слишком мягкий не защищает critical path.
  4. Практика: заполните SLO/error-budget table для checkout submit, search results, login, product page LCP.
  5. Readiness: вы можете объяснить, какой signal считается budget burn, какие исключения допустимы, и что команда делает при превышении.

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

  1. Называют SLO без SLI, окна измерения и data source.
  2. Берут только backend uptime и игнорируют frontend journey failures.
  3. Не связывают budget burn с конкретным action.
  4. Используют vanity metric вместо user-impacting signal.

Follow-up вопросы​

  1. Чем SLI отличается от SLO and error budget?
  2. Какие frontend journeys достойны SLO?
  3. Что делать, если budget burn ускорился после релиза?
  4. Какие события стоит исключить из SLO window?

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

  1. Senior q-10: observability signal matrix.
  2. Frontend System Design: reliability and rollout trade-offs.
  3. Free-practice: frontend SLO/error-budget table for four user journeys.

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

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

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

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

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

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

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

  1. Сначала определяю bottleneck: DOM node count, render cost, data size, network pagination, layout shifts, keyboard navigation or accessibility.
  2. Варианты: pagination, infinite scroll, virtualization/windowing, server-side filtering/sorting, memoized row rendering and progressive loading.
  3. Virtualization снижает DOM/render cost, но усложняет dynamic height, accessibility, find-in-page, SEO, scroll restoration and keyboard focus.
  4. Production-риск: таблица на 20k строк блокирует main thread, ломает INP, а screen reader/keyboard user теряет контекст в виртуализированном списке.
  5. Проверяю через large-list decision matrix: use case, row count, row height, SEO, a11y, interaction, data loading, mode, validation.

Мини-пример​

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

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

  1. Production-сценарий: admin table загружает 30k rows and complex cells. Решение: server pagination/filtering плюс virtualization for visible rows, not one huge DOM.
  2. Edge-case: variable-height rows требуют measurement/cache strategy; неверная оценка высоты создает scroll jump.
  3. Edge-case: public SEO list может быть плохим кандидатом для pure client virtualization; лучше pagination/SSR content strategy.
  4. Практика: заполните decision matrix для admin table, chat history, product grid, search results.
  5. Readiness: вы можете объяснить, как валидируете INP/render time, focus behavior, screen reader expectations and scroll restoration.

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

  1. Сразу ставят virtualization, хотя проблема в network payload or server filtering.
  2. Не проверяют keyboard navigation and screen reader behavior.
  3. Игнорируют dynamic row height and scroll restoration.
  4. Меряют только FPS на мощной машине, не проверяя slow CPU and real interactions.

Follow-up вопросы​

  1. Когда pagination лучше virtualization?
  2. Какие accessibility риски у windowed list?
  3. Как работать с dynamic row height?
  4. Какие метрики докажут, что список стал лучше?

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

  1. Rendering lesson 1: critical path and user-centric metrics.
  2. Senior q-3: performance budget gate.
  3. Free-practice: large-list rendering decision matrix plus one DevTools validation note.

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

  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. Web Worker нужен, когда CPU-heavy work блокирует main thread, но задачу можно выполнить без DOM access and with clear message boundary.
  2. Подходящие задачи: parsing, search/indexing, image/data processing, compression, diffing, expensive calculations; неподходящие - DOM rendering and direct React state updates.
  3. Нужно спроектировать protocol: input/output shape, cancellation, progress, error handling, transferable objects, worker lifecycle and fallback.
  4. Production-риск: перенос в worker не помогает, если bottleneck в DOM/render или если structured clone копирует огромные данные слишком дорого.
  5. Проверяю через worker boundary plan: task, main-thread pain, input, output, transferable?, cancel, error, fallback, validation.

Мини-пример​

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

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

  1. Production-сценарий: client импортирует CSV на 50MB. Parsing blocks typing and clicks; worker moves parsing off main thread and streams progress back.
  2. Edge-case: большой ArrayBuffer лучше передать как transferable, иначе copy cost может съесть benefit.
  3. Edge-case: worker не имеет прямого доступа к DOM; UI updates идут через messages and main thread state.
  4. Практика: составьте worker boundary plan для CSV import, image resize, full-text search, large JSON diff.
  5. Readiness: вы можете объяснить message protocol, cancellation, error path, fallback and how you prove main-thread responsiveness improved.

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

  1. Используют worker для проблемы, которая на самом деле в DOM/render.
  2. Передают огромные объекты без учета structured clone and transferables.
  3. Не проектируют cancellation and error handling.
  4. Завязывают worker protocol на UI internals вместо stable data contract.

Follow-up вопросы​

  1. Что нельзя делать внутри Web Worker?
  2. Когда transferable лучше structured clone?
  3. Как отменить долгую worker-задачу?
  4. Как доказать, что worker улучшил responsiveness?

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

  1. Rendering lesson 1: main thread, JavaScript cost and responsiveness.
  2. Senior q-14: bottleneck diagnosis before optimization.
  3. Free-practice: worker boundary plan for one CPU-heavy frontend task.

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

  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. CI gates должны быть risk-based: быстрые обязательные checks в PR, тяжелые проверки по расписанию или перед release.
  2. Базовый PR gate: formatting/lint, typecheck, unit/integration for changed area, content/build check, dependency/security checks by risk, smoke e2e for critical paths.
  3. Отдельно фиксирую gate behavior: blocking/non-blocking, owner, failure triage, flaky policy, timeout budget and exception process.
  4. Production-риск: слишком слабые gates пропускают regressions, слишком тяжелые gates убивают feedback loop и команда начинает обходить CI.
  5. Проверяю через CI gate matrix: gate, scope, blocking?, runtime, owner, failure action, flaky policy, release impact.

Мини-пример​

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

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

  1. Production-сценарий: checkout PR меняет price formatter. Unit tests проходят, но smoke e2e по checkout блокирует regression в итоговой цене.
  2. Edge-case: flaky e2e не должен просто игнорироваться; нужен quarantine, owner, issue, срок исправления and replacement signal.
  3. Edge-case: visual/performance/security checks могут быть non-blocking на PR, но blocking перед release для affected critical flow.
  4. Практика: заполните CI gate matrix для checkout, search, design system component, content-only docs change.
  5. Readiness: вы можете объяснить, почему каждый gate существует, что он не ловит, и какое действие следует при падении.

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

  1. Делают все проверки blocking и получают медленный PR loop.
  2. Игнорируют flaky tests вместо явной политики.
  3. Не связывают gate с user risk.
  4. Не различают PR gate, nightly gate and release gate.

Follow-up вопросы​

  1. Какие gates должны быть blocking в PR?
  2. Что делать с flaky e2e?
  3. Когда performance check должен блокировать release?
  4. Какие проверки нужны для content-only изменения?

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

  1. Testing lesson 1: test pyramid and risk-based coverage.
  2. Interview pattern taxonomy: quality-gate.
  3. Free-practice: CI gate matrix for one critical user flow.

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

  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. Тестовая стратегия должна начинаться с risk map: какие user journeys критичны, где деньги/данные/security, где исторически были regressions.
  2. Unit tests защищают pure logic; integration tests проверяют component + state + API boundary; e2e защищает critical user path; manual/monitoring закрывают то, что автоматикой дорого ловить.
  3. Для каждого риска нужен минимальный достаточный слой теста, expected assertion, data setup, owner and maintenance cost.
  4. Production-риск: много low-value snapshot tests дает ложную уверенность, а critical checkout failure остается без проверки.
  5. Проверяю через risk-based test plan: risk, user impact, test layer, assertion, data, negative path, a11y/perf?, owner.

Мини-пример​

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

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

  1. Production-сценарий: login form. Unit тестирует validators, integration проверяет error states/focus, e2e покрывает successful login and blocked account path.
  2. Edge-case: внешний auth/API нестабилен; e2e должен иметь controlled test data/mocks or reliable test environment.
  3. Edge-case: accessibility assertion важна для form/modal, но не заменяет keyboard walkthrough.
  4. Практика: заполните risk-based test plan для login, checkout step, search results, settings form.
  5. Readiness: вы можете объяснить, почему выбранный тестовый слой самый дешевый слой, который реально ловит риск.

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

  1. Пишут e2e на все и получают медленный нестабильный suite.
  2. Покрывают implementation details вместо user-visible behavior.
  3. Не добавляют negative path and boundary cases.
  4. Не удаляют или не переписывают тесты после изменения product behavior.

Follow-up вопросы​

  1. Когда unit test лучше e2e?
  2. Как выбрать минимальный smoke e2e набор?
  3. Что делать с тестом, который часто flaky?
  4. Какие риски нельзя полностью автоматизировать?

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

  1. Testing lesson 1-4: unit, integration, e2e and flaky risk.
  2. Testing strategy pack.
  3. Free-practice: risk-based test plan for one form and one critical flow.

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

  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. API contracts должны иметь source of truth: OpenAPI/schema/generated types/consumer contract tests, а не устные договоренности.
  2. Изменения делю на backward-compatible additive и breaking: новые optional fields обычно безопаснее, rename/remove/type change требуют deprecation window and migration plan.
  3. Frontend должен иметь DTO boundary: raw response -> runtime validation/mapping -> domain model -> UI state.
  4. Production-риск: backend меняет enum/field shape, старый frontend silently ломает экран или показывает неверные данные.
  5. Проверяю через API compatibility checklist: change, compatibility, consumer, fallback, validation, deprecation, rollout, contract test, owner.

Мини-пример​

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

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

  1. Production-сценарий: API меняет price: number на { amount, currency }. Старый frontend сортирует по price и получает broken table.
  2. Edge-case: добавление optional field обычно совместимо, но если frontend начинает считать его обязательным без fallback, появляется hidden breaking change.
  3. Edge-case: enum value expansion ломает exhaustive UI mapping, если нет unknown branch.
  4. Практика: заполните compatibility checklist для field add, field rename, enum expansion, pagination default change.
  5. Readiness: вы можете сказать, когда нужен change request, когда нужен deprecation window, и где frontend ставит runtime guard.

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

  1. Считают TypeScript types достаточной защитой после сети.
  2. Удаляют поле без migration window.
  3. Не имеют fallback for unknown enum value.
  4. Смешивают API DTO directly with UI state.

Follow-up вопросы​

  1. Какие изменения API backward-compatible?
  2. Когда нужен новый version или deprecation window?
  3. Где должна быть runtime validation?
  4. Как защититься от unknown enum value?

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

  1. TypeScript lesson 4: DTO/domain boundaries.
  2. TypeScript boundary pack.
  3. Free-practice: API compatibility checklist for four contract changes.

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

  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. Postmortem нужен не для поиска виноватого, а для восстановления timeline, user impact, contributing factors and durable prevention.
  2. Хороший postmortem включает impact, detection, timeline, root/contributing causes, what worked, what failed, action items with owner/due date and verification.
  3. Для frontend важны release marker, route, browser/device, feature flag state, frontend errors, Web Vitals, API correlation and rollback timeline.
  4. Production-риск: без action ownership incident повторяется, а команда лечит симптом вместо слабого gate/observability/contract.
  5. Проверяю через postmortem template: impact, timeline, trigger, detection gap, root cause, actions, owner, due date, verification.

Мини-пример​

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

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

  1. Production-сценарий: release broke checkout submit for Safari. Postmortem фиксирует timeline, missing browser coverage, weak canary signal and action to add targeted smoke.
  2. Edge-case: root cause редко один; "developer mistake" не action item, а слабый review/gate/test/observability процесс.
  3. Edge-case: action item без owner and verification превращается в TODO без эффекта.
  4. Практика: заполните postmortem template для checkout JS error, bad feature flag rollout, API contract mismatch, performance regression.
  5. Readiness: вы можете отличить symptom, trigger, root cause, contributing factor and prevention action.

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

  1. Пишут blame вместо system factors.
  2. Не считают user impact and detection gap.
  3. Делают action items без owner, due date and verification.
  4. Не связывают incident с улучшением gate, rollout or observability.

Follow-up вопросы​

  1. Чем trigger отличается от root cause?
  2. Какие frontend signals нужны для timeline?
  3. Как проверить, что action item реально снизил риск?
  4. Когда postmortem нужен, даже если rollback был быстрым?

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

  1. Senior q-10: observability signal matrix.
  2. Senior q-12: rollout and rollback plan.
  3. Free-practice: incident postmortem template for one frontend regression.

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

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

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

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

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

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

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

  1. Senior leadership - это повышать качество решений команды: clarify problem, choose trade-offs, align owners, reduce risk, mentor and create durable feedback loops.
  2. Senior не обязан быть единственным автором кода; он должен помогать команде принимать проверяемые решения and unblock delivery without hiding risks.
  3. Артефакты: decision log/ADR, boundary map, rollout plan, risk register, mentoring plan, review checklist and post-release learning.
  4. Production-риск: сильный индивидуальный contributor без ownership системы становится bottleneck, а команда не учится принимать решения самостоятельно.
  5. Проверяю через technical leadership decision log: problem, options, trade-off, decision, owner, risk, validation, communication, follow-up.

Мини-пример​

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

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

  1. Production-сценарий: команда спорит, переписывать ли checkout state. Senior формулирует options, риски, migration plan, guardrails and success criteria.
  2. Edge-case: "я сам быстрее сделаю" помогает сегодня, но создает bus factor; лучше pairing, review and documented decision.
  3. Edge-case: leadership без evidence превращается в мнение; нужны validation, rollout signal and retrospective.
  4. Практика: заполните decision log для state migration, design system adoption, testing strategy, performance budget.
  5. Readiness: вы можете показать, как решение стало понятнее команде, какие риски приняты, кто owner, и как проверится результат.

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

  1. Подменяют leadership личным hero coding.
  2. Не фиксируют trade-offs and decision context.
  3. Делают review только про стиль кода, не про risk and maintainability.
  4. Не растят ownership у Middle-разработчиков.

Follow-up вопросы​

  1. Как отличить Senior impact от количества написанного кода?
  2. Какие решения стоит фиксировать в ADR/decision log?
  3. Как снизить bus factor в критичной зоне?
  4. Как давать feedback Middle-разработчику после risky PR?

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

  1. Frontend-архитектура: ownership and boundaries.
  2. Frontend System Design: trade-offs, rollout and reliability.
  3. Free-practice: technical leadership decision log for one high-risk change.

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

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

Куда дальше​

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