Вопросы на собеседовании Fullstack-разработчика

Пример сильного ответа

В JavaScript один поток выполнения, поэтому асинхронность строится на очереди задач. Синхронный код идёт в стеке, а колбэки попадают в очереди: макротаски — таймеры и события, микротаски — промисы. После каждого колбэка стек опустошается, и движок сначала полностью разбирает очередь микротасок, и только потом берёт следующую макротаску. Поэтому setTimeout с нулевой задержкой срабатывает позже, чем промис: промис — микротаска, таймер — макротаска. На практике это помогает объяснять порядок выполнения: у нас два независимых запроса объединялись в один батч обновления состояния, и время до первой отрисовки сократилось примерно на 40%.

• Чёткое разделение макро- и микротасок
• Сравнение на примере setTimeout и промисов
• Есть личный результат с цифрой

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Замыкание — это функция вместе со своей лексической областью видимости. На практике это основа приватного состояния: счётчики, кэш внутри модуля, дебаунс в поиске, обработчики с сохранённым контекстом. Например, в поиске по каталогу через замыкание держу таймер задержки, и число запросов к API упало с сотен до десятков за сессию. Утечка возникает, когда замыкание живёт дольше, чем нужно: подписка или таймер не отписаны, обработчик ссылается на крупный DOM-узел или большой массив, и сборщик мусора не может их освободить. Лечится снятием слушателей в cleanup и обнулением ссылок.

• Сразу дано рабочее определение
• Польза показана на конкретном приёме
• Названы причины утечек и способы борьбы

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

TypeScript даёт статическую проверку типов до запуска, поэтому часть ошибок ловится на этапе сборки, а не в проде. Плюс код становится самодокументируемым: по типам видно контракт функции. Чаще всего использую строгий режим с запретом any, интерфейсы для DTO и пропсов, дженерики в утилитах и API-клиентах, union-типы для состояний и discriminated union вместо набора флагов, utility-типы вроде Partial и Pick. Ещё в CI подключены проверка типов и линтер. На одном проекте такой набор правил срезал число ошибок в рантайме примерно вдвое, а правки перед ревью стали быстрее.

• Ответ идёт от пользы, а не от синтаксиса
• Перечислены реально применяемые возможности
• Есть измеримый результат для команды

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Хуки позволяют переиспользовать логику состояния и жизненного цикла без классов: useState хранит состояние, useEffect синхронизирует компонент с внешним миром. Массив зависимостей — это список значений, от которых эффект зависит. Если он пустой, эффект выполняется один раз; если в нём не хватает переменной, эффект работает с устаревшим замыканием; если добавить объект или функцию, создаваемые заново на каждом рендере, эффект зацикливается. Мне приходилось разбирать такой цикл из-за объекта в зависимостях — помогли мемоизация и вынос стабильных значений. В итоге лишние перерисовки и запросы ушли.

• Объяснена суть, а не только синтаксис
• Показаны три сценария поведения массива
• Есть живой пример из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сначала измеряю: профайлер показывает, какие компоненты рендерятся и почему, а также число рендеров и время коммита. Дальше ищу типичные причины: частое обновление состояния в родителе, нестабильные пропсы-объекты и функции, слишком широкий контекст, тяжёлые вычисления прямо в рендере. Лечу точечно: мемоизирую значения, колбэки и компоненты, разделяю контекст по смыслу, выношу вычисления, длинные списки виртуализирую. На одном интерфейсе с таблицей на несколько тысяч строк такой разбор ускорил отклик примерно втрое. Результат обязательно проверяю тем же профайлером.

• Сначала диагностика, потом правки
• Названы конкретные типовые причины
• Есть цифра ускорения и проверка результата

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В больших приложениях я разделяю состояние на слои: локальное — в компонентах, серверное — в React Query, глобальное — в Redux Toolkit или Zustand. Для форм беру React Hook Form, для URL — роутер. Здесь важны нормализация данных и селекторы, чтобы не тянуть лишние ререндеры. В проекте с 40+ экранами и командой из шести человек такой подход помогает держать рассинхрон данных под контролем: число связанных багов падает примерно на треть. Главное — не делать всё глобальным и держать единый источник правды для каждой сущности.

• Показан конкретный стек и разделение слоёв
• Есть цифра: 40+ экранов, команда из шести
• Видно понимание антипаттерна «всё в глобальный store»

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В Node.js событийный цикл состоит из фаз: timers, pending callbacks, poll, check, close. Между фазами выполняются микротаски, а process.nextTick имеет приоритет над промисами. В браузере цикл привязан к рендерингу: после задач появляется кадр, requestAnimationFrame, layout и paint. В Node нет DOM и rAF, зато есть setImmediate и явные фазы ввода-вывода. В одном проекте мне приходилось искать причину задержки ответа API: тяжёлая синхронная операция блокирует цикл на двести миллисекунд, и вынос её в worker снимает проблему.

• Чётко названы фазы и микротаски
• Показано отличие от браузера
• Есть личный пример с числом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Ресурсы делаю во множественном числе: /products, /categories, /carts, /orders, /users. Для коллекции — GET с пагинацией, фильтрами и сортировкой, POST для создания; для элемента — GET, PATCH, DELETE, реже PUT. Коды: 200 и 204 — успех, 201 — создание, 400 и 422 — ошибка валидации, 401 и 403 — доступ, 404 — нет ресурса, 409 — конфликт, 429 — лимит. Версионирование через /v1. В каталоге на пятьдесят тысяч товаров такая схема даёт предсказуемые ответы и удобную документацию в OpenAPI.

• Названы ресурсы, методы и коды
• Есть пагинация, версии и OpenAPI
• Цифра: каталог на 50 тысяч товаров

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Пароли храню только в виде хеша — Argon2 или bcrypt с солью. Сессию строю на паре токенов: короткоживущий access и refresh в httpOnly, Secure, SameSite-cookie, с ротацией и списком отзыва. Это защищает от кражи через XSS и позволяет разлогинивать. Дополнительно — CSRF-токен, лимиты на попытки входа и HTTPS. В проекте с аудиторией около двадцати тысяч пользователей такая схема снижает число инцидентов с доступом почти до нуля. Роли и права проверяю на бэкенде, а не только в интерфейсе.

• Названы хеширование, токены и cookie-флаги
• Есть CSRF, лимиты и разлогин
• Цифра: аудитория около 20 тысяч

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

PostgreSQL выбираю там, где важны транзакции и целостность: заказы, платежи, склад, отчёты. Он даёт ACID, джойны, индексы и сложные выборки. MongoDB подходит для документов с плавающей структурой — каталог с разными атрибутами, профили, логи. Redis беру как кэш, хранилище сессий, очереди и лимитер. В проекте с нагрузкой около двух тысяч запросов в секунду кэш в Redis сокращает время ответа с трёхсот до сорока миллисекунд. Часто это не «или», а комбинация: основная база плюс Redis.

• Чёткие критерии выбора каждой СУБД
• Есть пример с нагрузкой и ускорением
• Показано, что технологии комбинируются

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Показан системный порядок диагностики, а не догадки
• Есть конкретный измеримый результат оптимизации
• Названы профилактические меры против повторения

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Транзакция — это набор операций, который выполняется целиком или не выполняется вовсе, с гарантиями атомарности, согласованности, изоляции и долговечности. Уровни изоляции управляют тем, какие аномалии видны параллельным транзакциям: грязное чтение, неповторяющееся чтение, фантомы. Классический пример — перевод средств между счетами: списание и зачисление должны быть в одной транзакции, иначе при сбое посередине деньги исчезнут или продублируются. В моей практике был похожий случай на интернет-магазине: списание товара со склада и создание заказа шли отдельными запросами, и при пиковой нагрузке несколько клиентов покупали последнюю единицу. После переноса в одну транзакцию с блокировкой строки число расхождений в остатках упало до нуля, а повторные продажи прекратились.

• Термины раскрыты без заучивания, своими словами
• Живой пример из практики вместо учебного
• Есть измеримый итог: расхождения упали до нуля

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Для нового продукта я чаще выбираю модульный монолит: он быстрее в разработке, проще в деплое и не требует инфраструктуры под сервисы, пока неясны требования и нагрузка. Микросервисы дают независимое масштабирование и разделение команд, но добавляют сетевые сбои, распределённые транзакции и наблюдаемость. Логика такая: пока команда меньше пятнадцати человек и продукт только ищет рынок, монолит с чёткими модулями выгоднее. На прошлом проекте переход на сервисы делался только после того, как нагрузка выросла в разы и появились отдельные команды. При этом архитектура с самого начала проектируется так, чтобы выделить сервис было недорого.

• Ответ с условием, а не догматичный выбор
• Учтены размер команды и стадия продукта
• Показано, как сохранить путь к развитию

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Качество держится на трёх вещах: автоматические тесты, обязательное код-ревью и статический анализ в пайплайне. У меня в проекте юнит-тесты покрывают ключевую бизнес-логику, на интеграционные тесты уходят API и работа с базой, а критичные сценарии закрыты сквозными тестами. Код-ревью — обязательное условие мержа, минимум один апрув, и я стараюсь смотреть не только корректность, но и читаемость. Линтеры и проверка типов ломают сборку при ошибках. Такой подход дал результат: доля дефектов, которые доходили до продакшена, снизилась примерно на 40 процентов, а время на разбор инцидентов сократилось.

• Названы три конкретных инструмента контроля
• Показана личная роль в ревью
• Результат измерен в процентах

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сборка и деплой у меня описаны как код: для фронтенда собирается бандл и статика, для бэкенда — артефакт или образ, дальше миграции базы и запуск. Всё это живёт в CI: на каждый пул-реквест прогоняются тесты и линтеры, а на основную ветку — сборка образа и автоматический деплой на стейдж. В продакшен выкатка идёт поэтапно, с возможностью отката за пару минут. Конфигурация и секреты — через переменные окружения, отдельно для каждой среды. В одном проекте такая схема позволила выпускать релизы несколько раз в день вместо раза в неделю, а время от мержа до продакшена сократилось до пятнадцати минут.

• Показан полный путь от кода до продакшена
• Есть откат и разделение сред — зрелость процесса
• Результат в релизах и минутах убеждает цифрами

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом — измерения: профилирование запросов, APM, slow query log, чтобы понять, где именно узкое место. Часто картина такая: пара тяжёлых запросов и N+1. Дальше по шагам: индексы и переписывание запросов, кэш горячих данных, пул соединений, вынос тяжёлых операций в очереди, реплики для чтения. Только после этого — горизонтальное масштабирование приложения, иначе оно просто добьёт базу. В одном проекте такая последовательность позволила снизить p95 с 900 до 150 миллисекунд при кратном росте трафика и обойтись без шардирования. Шардирование и партиционирование держу как следующий шаг, когда реплики и кэш уже не вытягивают.

• Начинает с диагностики, а не с модных инструментов
• Показывает порядок шагов и понимание предела
• Есть измеримый результат из личного опыта

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Обычно работаю по коротким веткам от основной: одна задача — одна ветка, живёт день-два, PR небольшой, до 300–400 строк, иначе ревью превращается в формальность. В PR — описание задачи, скриншоты для интерфейса, пройденный CI. Ревью воспринимаю как диалог: замечания по существу, а не по вкусу, стиль закрывает линтер. Конфликты стараюсь ловить рано: регулярно подтягиваю изменения из основной ветки, поэтому они мелкие. Если конфликт сложный, иду к автору смежных правок и разбираюсь вместе, а не перезаписываю своей версией. В основной ветке всегда зелёный билд, релиз — из тега.

• Конкретика по размеру веток и PR
• Ревью подано как диалог, а не контроль
• Конфликты решаются общением и ранним слиянием

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.