Загрузка…
Загрузка…
frontend / middle / system_design
Формат
online
Стадия
system_design
Когда
within_quarter
Длительность
—
01
Код
Решить несколько несложных задач на JavaScript (лайвкодинг)
Первый этап (тех-скрининг), упомянут в нарративе автора; сами задачи в этом транскрипте не приведены. Фидбэк положительный.
02
Поведенческий
Сталкивался ли с секцией системного дизайна раньше? Приходилось ли делать что-то похожее?
Вводный вопрос перед началом секции системного дизайна.
03
System design
Спроектировать mobile-first веб-приложение «Агрегатор новостей»: две страницы — лента новостей и страница новости, лайки/дизлайки (суммируются в рейтинг), источники новостей настраиваются через админку. Собрать функциональные и нефункциональные требования (SEO, скорость загрузки, гео-распределённость по СНГ, масштабирование) и нарисовать верхнеуровневую архитектуру (клиент, BFF на Next.js с SSR, бэкенд на Node.js, БД, S3-хранилище, CDN).
Основная задача секции. Интервьюер выступал в роли продакта/заказчика, кандидат рисовал на доске. Вводные: команда из 4 фронтов на React, бэкенд на Node.js у смежников, дедлайн 3-5 месяцев.
Заметки
Транскрипт видео с YouTube-канала о прохождении собеседований. Второй этап в компании ОКО (онлайн-кинотеатр, упоминается связь со Сбером; офисы в Питере и Москве) — секция системного дизайна: проектирование mobile-first агрегатора новостей. Первый этап (упомянут в нарративе) — несложные задачи на JavaScript, фидбэк положительный. После этой секции спустя несколько дней HR пригласила автора на финал с лидом команды кино. Фидбэк по секции обещали в начале следующей недели. Грейд не назван — автор предлагает зрителям угадать.
Стиль интервьюера
Интервьюер общался на «ты», выступал в роли продакта/заказчика, на вопросы по функциональности отвечал по ходу. Дружелюбный, направляющий стиль: постепенно углублял тему наводящими follow-up'ами (оптимизация контента, лайки без авторизации, безопасность, метрики, FPS, A/B-тесты), подсказывал при затруднениях (CSP вместо CSRF), охотно отвечал на вопросы кандидата о компании.
04
System design
Спроектировать схему базы данных: пройтись по сущностям (user, post), описать их поля, связи через id, обязательность полей, формат хранения контента (markdown строкой), выбор документоориентированной БД (MongoDB).
Часть основной задачи системного дизайна. Обсуждались роли пользователя (reader/author/admin), хранение лайкнутых постов, аватары разных размеров в S3.
05
System design
Спроектировать API (ручки) приложения: получение списка постов с пагинацией, получение пользователя, оценка поста (лайк/дизлайк), отзыв оценки.
Интервьюер явно попросил спроектировать ручки, так как бэкенд делается «по заказу». Обсуждалось: возврат нового рейтинга с бэка, флаг направления оценки, единая ручка rate/unrate.
06
System design
Как сделать так, чтобы пользователь видел, что лайк уже прожат, и не мог накрутить лайки (тумблер: лайк / дизлайк / ничего), с учётом того, что у пользователя может быть миллион лайкнутых постов и грузить их все на клиент неоптимально?
Follow-up интервьюера. Решение: обогащение сущности поста флагом liked на уровне BFF/ноды. Также обсуждались лайки для неавторизованных пользователей через localStorage.
07
System design
Как будет осуществляться переход со страницы ленты на страницу новости (роутинг, урлы, передача данных без дополнительного запроса)?
08
System design
При загрузке ленты грузится лишний контент новостей, который может быть внушительным — как это оптимизировать?
Решение: урезанная версия поста в списке + отдельная ручка get post content, дозапись контента в локальное состояние на клиенте для мгновенного повторного открытия.
09
Теория
Помимо инъекций через поля ввода, что ещё может пойти не так с точки зрения безопасности (например, если конкуренты встроят наше приложение на другой странице/урле)?
10
Теория
Что позволяет избежать настройка CORS? Как правильно настраивать CORS-политики (вайтлист хостов вместо звёздочки)?
11
Теория
Помимо CORS, какие ещё есть способы вставки содержимого/контента на другие страницы (iframe, выполнение скриптов) и как от этого обезопаситься?
Кандидат сначала назвал CSRF-токены, интервьюер подвёл к CSP (Content Security Policy), настраиваемому через заголовки.
12
Кейс
Представь, что этот проект приходит к тебе как задача: чего ещё не хватает в техническом задании, чтобы приступить к разработке?
Кандидат вывел разговор на мониторинги и отслеживание ошибок: Sentry и аналоги на фронте, сквозной trace id, Prometheus + Grafana на бэке, продуктовые метрики (Яндекс.Метрика/Google).
13
Теория
Как по метрикам понимать, что приложение быстро и плавно работает у пользователей на мобильных устройствах (не лагает, скролл без слайд-шоу)?
Обсуждались запись пользовательских сессий, тестирование на слабых девайсах и мобильном Safari, потребление памяти, экономия трафика, профилирование, React Profiler, Lighthouse.
14
Теория
Какие метрики можно измерить в браузере пользователя (не синтетические тесты), чтобы понять, что приложение действительно отзывчиво работает?
Ожидаемый ответ — Core Web Vitals (first input delay и др.); кандидат забыл аббревиатуру.
15
Теория
Какие кастомные метрики (поверх стандартных браузерных) мы могли бы сами померить в этом приложении?
Обсуждались: время загрузки списка, время открытия новости, FPS, отправка событий и измерение разницы между ними, добавление кастомных метрик в аналитические сервисы.
16
Теория
Время открытия новости — между какими событиями его измерять?
Ответ: от события клика до полного рендера компонента.
17
Теория
Как померить плавность скролла бесконечной ленты? Что можно назвать плавным скроллом?
18
Теория
На какое значение FPS ориентироваться, чтобы считать, что скролл работает плавно?
Ответ: 60 FPS — оптимальное значение, к которому стремимся.
19
Теория
У нас есть гипотеза по улучшению (например, уменьшить время загрузки страницы новости) — как понять, что внесённые изменения действительно положительно повлияли на пользователя?
Ответ: A/B-тесты на основе системы фичфлагов (отдельный сервис конфигов, разные группы пользователей, сравнение метрик).
20
Теория
Чем чревато большое количество фичфлагов в коде?
Ответ: код превращается в ifы, тяжело поддерживать; нужно заводить тикеты на выпил флагов.
21
Теория
Если запускать приложение для пользователей с ограниченными возможностями (accessibility) — что можно сделать, на что обратить внимание?
Обсуждались aria-теги/роли, поведение скринридеров при visually hidden элементах (opacity 0 vs display none), flex reverse, отдельный процесс тестирования accessibility.
22
Теория
Расскажи, как будешь делать ленивую дозагрузку новостей (lazy loading) в бесконечной ленте.
Также обсуждались пагинация и виртуализация списка (рендер только видимого окна) для экономии памяти на мобилках.
23
Теория
Какой якорь использовать как триггер дозагрузки следующей порции новостей?
Ответ: атрибут на последней (или предпоследней) картинке страницы, загрузка при попадании в зону видимости — чуть раньше, чем пользователь доскроллит.
24
Теория
Расскажи про CI/CD: как устроить пайплайны (линт, тайпчек, тесты, билд), процесс разработки (фичеветки, merge request, код-ревью, trunk-based development) и релизный процесс (релизные ветки, деплой на превью-стенд и продакшн).
Интервьюер явно обозначил CI/CD как недоразобранную тему и попросил рассказать.
25
Теория
Как разработчики могут помочь тестированию (тестировщикам)?
Ответ: юнит-тесты с метриками покрытия, e2e-тесты для автоматизации тесткейсов тестировщиков.
26
Теория
E2E-тесты — это автоматические тесты, где открывается браузер и нажимаются кнопки, или синтетические?
Ответ: проходят в headless-браузере, максимально эмулируя поведение пользователя.