Этап 17 из 19 · ≈ 16 ч

Frontend system design

Основа с Senior

Проектирование интерфейса целиком — требования, компоненты, данные, производительность, доступность.

Секция frontend system design проверяет, как вы строите интерфейс целиком, а не отдельный компонент.

Структура ответа

Требования: функции, устройства, объём данных, офлайн, доступность, SEO.
Компоненты и их ответственность.
Данные: модель, API, кэш, нормализация, пагинация, реальное время.
Рендеринг: CSR, SSR, стриминг, виртуализация.
Производительность: бюджеты, ленивые загрузки, Core Web Vitals.
Доступность и интернационализация.
Наблюдаемость и обработка ошибок.

Типовые задачи: автодополнение, лента новостей, чат, таблица на миллион строк, совместный редактор, загрузка файлов.

Критерии освоения

Senior ≈ 16 ч

Проводит секцию frontend system design — требования, компоненты, модель данных, API, производительность, доступность
Обсуждает компромиссы (рендеринг, кэш, реальное время) с оценкой последствий
Планирует постепенную миграцию legacy-фронтенда на новый стек

Практика. Разобрать письменно 3 задачи frontend system design (автодополнение, лента с бесконечной прокруткой, совместный редактор) по единой структуре и пройти пробное собеседование.

Проверка знаний

Войдите, чтобы пройти тест: сданный тест отмечает тему пройденной на карте и в ИПР.

Вопросы с собеседований

Смотреть все

Спроектируйте компонент поиска с автодополнением.Senior

Уточнить требования (источник данных, объём, задержка, мобильные, офлайн), затем: debounce ввода (~150–300 мс), отмена устаревших запросов (AbortController) и защита от гонок ответов, кэш результатов по запросу, минимальная длина запроса, клавиатурная…

Полный разбор

Как держать производительность большого фронтенд-приложения под контролем?Senior

Производительность деградирует незаметно — по килобайту в каждом PR. Удержать её помогают бюджеты (размер JS на маршрут, LCP, INP) с проверкой в CI, которая блокирует превышение, мониторинг реальных пользователей (RUM) по маршрутам и устройствам с алертами…

Полный разбор

Как постепенно переписать большое legacy-приложение на новый стек?Senior

Переписывать всё с нуля — главный риск: годы без новых функций и вечная погоня за старой системой. Работает постепенная замена (strangler fig): новый стек встраивается в старое приложение — по страницам или виджетам, — новые функции пишутся сразу на новом…

Полный разбор

Как построить дизайн-систему и библиотеку компонентов для нескольких продуктов?Senior

Дизайн-система — общий язык дизайна и кода: токены (цвета, типографика, отступы) в CSS-переменных, библиотека компонентов с доступностью из коробки, документация и песочница (Storybook), версионирование по semver с журналом изменений и процесс — кто владеет…

Полный разбор

Как организовать архитектуру большого фронтенд-приложения?Senior

Цель — чтобы изменение в одной функции не задевало остальные и новый человек быстро находил код. Основа — разделение по функциональности (features, страницы, сущности), а не по типу файлов (components, utils, hooks), явные публичные API модулей, направление…

Полный разбор

Что такое микрофронтенды и когда они оправданы?Senior

Микрофронтенды — разделение интерфейса на части, которые разные команды разрабатывают и выкатывают независимо, а оболочка собирает их в одно приложение (Module Federation, импорт-карты, iframe, серверная композиция). Это организационное решение: оправдано…

Полный разбор

Зачем фронтенду монорепозиторий и как его организовать?Senior

Монорепозиторий хранит несколько приложений и пакетов (дизайн-система, клиент API, утилиты) в одном репозитории: атомарные изменения сразу во всех потребителях, единые версии зависимостей и инструменты. Работает на workspaces пакетного менеджера (pnpm) и…

Полный разбор

← Вся карта «Frontend-разработчик»

Партнёр платформы

Разбор собеседования с sotto

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

Разбор собеседования