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

Что хотим услышать

• var с функциональной областью, let и const с блочной
• var поднимается с undefined, let/const попадают в TDZ
• var можно объявить повторно, let/const нет
• const запрещает переприсваивание, но не изменение объекта
• var на верхнем уровне скрипта становится свойством window
• По умолчанию const, let для изменяемых, var не использую

Если ответил, копните глубже

Что хотим услышать

• any выключает проверку в обе стороны: на нём можно вызвать что угодно и присвоить его куда угодно
• any заразен: свойства и результаты вызовов на нём тоже any, ошибка уходит далеко от источника
• Замена для неизвестных данных: unknown с сужением или валидацией
• Замена для «любого, но одного и того же»: дженерик
• Защита: noImplicitAny в strict и правило линтера no-explicit-any

Если ответил, копните глубже

Что хотим услышать

• эффект запускается после коммита и отрисовки
• пустой массив - один раз при монтировании
• без массива - после каждого рендера
• возвращённая функция - очистка, вызывается перед следующим запуском и при размонтировании
• зависимости сравниваются поверхностно через Object.is
• в StrictMode в разработке эффект намеренно запускается дважды

Если ответил, копните глубже

Что хотим услышать

• textContent возвращает весь текст, включая скрытый, без учёта CSS
• innerText учитывает стили, возвращает видимый текст и при чтении вызывает пересчёт layout
• innerHTML читает и пишет разметку, присваивание парсит HTML
• Пользовательские данные через innerHTML вставлять нельзя: это XSS
• Перезапись innerHTML пересоздаёт потомков и теряет обработчики и состояние полей
• По умолчанию для текста выбирать textContent

Если ответил, копните глубже

Что хотим услышать

• block занимает всю доступную ширину и начинается с новой строки
• inline течёт в строке, игнорирует width и height
• У inline вертикальные margin не сдвигают соседей
• inline-block стоит в строке, но принимает размеры и отступы как блок
• Примеры: <p> и <div> блоки, <a> и <span> строчные, кнопка-тег inline-block
• Сегодня для раскладки в ряд чаще берут flex, а не inline-block

Если ответил, копните глубже

Что хотим услышать

• Same-origin policy: скрипт не может читать ответы другого origin (схема, хост, порт)
• CORS: сервер заголовками Access-Control-Allow-* разрешает конкретным origin читать ответы
• Проверяет браузер, сервер отвечает всегда; вне браузера CORS не действует
• Простые запросы уходят сразу, остальные после preflight OPTIONS
• С куками нужен credentials: 'include', Allow-Credentials: true и точный origin вместо *

Если ответил, копните глубже

Что хотим услышать

• Называет, что такое n (и m, если входов несколько)
• Считает циклы: вложенные перемножаются, последовательные складываются
• Помнит скрытые циклы: includes, indexOf, slice, sort, spread
• Отдельно оценивает память, включая стек рекурсии
• Сравнивает с ограничениями: при n до 10⁵ O(n²) уже не годится

Если ответил, копните глубже

Что хотим услышать

• debounce создаётся заново на каждом рендере - откладывание не работает
• нужен useMemo или useRef, чтобы функция пережила рендер
• нет отмены отложенного вызова при размонтировании
• q не экранирован через encodeURIComponent
• нет отмены предыдущего запроса - остаётся гонка
• проще перенести задержку в эффект с зависимостью от value

Если ответил, копните глубже

Что хотим услышать

• граф зависимостей от точки входа
• трансформация: TS, JSX, современный синтаксис, CSS
• резолв пакетов из node_modules
• склейка в чанки, минификация, tree shaking
• хеши в именах для долгого кеша
• dev-сервер с HMR и source maps

Если ответил, копните глубже

Что хотим услышать

• Колбэки error-first: просто, но вложенность и легко потерять ошибку
• Промисы: цепочки, единая обработка ошибок, комбинаторы all/allSettled/race/any
• async/await: синтаксис над промисами, код читается как синхронный, try/catch
• await приостанавливает только свою функцию, продолжение идёт микрозадачей
• async-функция всегда возвращает промис
• util.promisify и промис-версии модулей (fs/promises)

Если ответил, копните глубже

Что хотим услышать

• WHERE фильтрует строки до группировки, HAVING фильтрует группы после
• В WHERE нельзя агрегаты, в HAVING можно
• Порядок: FROM, WHERE, GROUP BY, HAVING, SELECT
• Условия без агрегатов лучше писать в WHERE: меньше строк до группировки
• Пример: WHERE status = 'paid' и HAVING SUM(total) > 10000

Если ответил, копните глубже

Что хотим услышать

• Вертикальное: мощнее машина, код не меняется, есть предел и единая точка отказа
• Горизонтальное: больше узлов, нужен stateless или распределённое состояние
• Stateless-сервисы приложения масштабируют горизонтально в первую очередь
• БД часто сначала масштабируют вертикально и репликами, шардирование позже
• Горизонтальное даёт отказоустойчивость, но добавляет сложность

Если ответил, копните глубже

Что хотим услышать

• async function*, внутри цикл по страницам с await fetch
• yield* по элементам страницы или yield поштучно
• Условие остановки: нет курсора next или пустая страница
• Ленивость: следующая страница грузится только когда потребитель дошёл до конца текущей
• Досрочный break у потребителя завершает генератор, запросы прекращаются; finally для очистки
• Ошибки и отмена: try/catch у потребителя, AbortSignal в параметрах

Если ответил, копните глубже

Что хотим услышать

• Голый параметр в T extends U даёт распределение по членам объединения
• На этом построены Exclude, Extract, NonNullable
• never как пустое объединение даёт never в результате
• Отключение: [T] extends [U], нужно для IsNever и проверок всего объединения
• Распределение срабатывает только для параметра типа, а не для конкретного объединения, записанного прямо в условии

Если ответил, копните глубже

Что хотим услышать

• Зависимости: всё, от чего зависит запрос, например id
• Гонки: в очистке AbortController или флаг ignore
• Состояния загрузки и ошибки, AbortError не считать ошибкой
• StrictMode в dev отправит запрос дважды, это нормально при корректной очистке
• Нет кеша, дедупликации, повторов и предзагрузки: каждый компонент грузит сам, возникают водопады
• В проекте: TanStack Query, SWR, загрузчики роутера или серверные компоненты

Если ответил, копните глубже

Что хотим услышать

• INP складывается из задержки ввода, времени обработчиков и задержки отрисовки
• Задержку ввода создают длинные задачи, которые уже идут в момент клика
• Разбивать работу и уступать главный поток: scheduler.yield или setTimeout
• Сначала дать визуальный отклик, тяжёлое делать после
• Сокращать JS, гидрацию и ререндеры: код-сплиттинг, startTransition, мемоизация, виртуализация
• Мерить в поле с атрибуцией, чтобы знать конкретные медленные взаимодействия

Если ответил, копните глубже

Что хотим услышать

• Реконнект с экспоненциальной задержкой и джиттером, сброс задержки после успеха
• Heartbeat: ping/pong с таймаутом, при пропуске закрыть и переподключиться
• Нумерация сообщений: после реконнекта клиент сообщает последний id, сервер досылает пропущенное
• Очередь исходящих сообщений с клиентскими id, идемпотентность на сервере против дублей
• Реакция на online/offline и видимость вкладки, повторная авторизация при истёкшем токене

Если ответил, копните глубже

Что хотим услышать

• Требования: список чатов, история, отправка, статусы, «печатает», уведомления, офлайн и плохая сеть
• Оценка: тысячи чатов, длинная история, в групповом чате десятки сообщений в секунду, долгоживущая вкладка
• API: WebSocket для событий (message.new, typing, read), REST для истории с курсором вверх, загрузка файлов отдельно
• Данные: сообщения по чатам с клиентским id, нормализация, IndexedDB для кеша и офлайн-очереди
• Компоненты: ChatList, ChatWindow с виртуализацией в обратном порядке, Composer, MessageBubble
• Узкие места: порядок и дедупликация, переподключение с догрузкой пропущенного, батчинг обновлений, утечки памяти, позиция скролла при подгрузке истории

Если ответил, копните глубже

Что хотим услышать

• начать с самого рискованного и ценного для бизнеса: оплата, вход, ключевые сценарии
• несколько e2e smoke-тестов на критичные пути
• unit-тесты на чистую логику: расчёты, форматирование, утилиты
• интеграционные тесты компонентов и API на новых и изменяемых местах
• тесты в CI как обязательная проверка PR
• регрессионный тест на каждый найденный баг, борьба с флаки

Если ответил, копните глубже

Что хотим услышать

• Middleware: низкоуровневое, до роутинга (логирование, cors, raw body), как в Express
• Guards: решение «пускать или нет» (аутентификация, роли), имеют ExecutionContext и метаданные хендлера
• Interceptors до хендлера и после: трансформация ответа, тайминги, кеш, таймауты (RxJS вокруг вызова)
• Pipes: валидация и преобразование аргументов (ValidationPipe, ParseIntPipe)
• Хендлер контроллера вызывает сервисы; исключения ловят Exception filters и превращают в ответ
• Порядок уровней: глобальные, потом контроллера, потом метода

Если ответил, копните глубже

Что хотим услышать

• UPDATE создаёт новую версию строки, старая остаётся с xmax; DELETE только помечает версию
• Каждая транзакция видит версии по своему снимку, поэтому чтение не блокирует запись и наоборот
• VACUUM удаляет версии, которые уже никому не видны, обновляет visibility map и замораживает старые строки
• Долгие транзакции и забытые слоты репликации мешают очистке и раздувают таблицы
• Autovacuum настраивают по таблицам: autovacuum_vacuum_scale_factor, лимиты стоимости; мониторинг через pg_stat_user_tables
• HOT-обновления и fillfactor уменьшают нагрузку на индексы

Если ответил, копните глубже

Что хотим услышать

• Требования: личные и групповые чаты до 1 000 участников, доставка онлайн и офлайн (push), история, статусы «доставлено» и «прочитано»; порядок сообщений в чате; медиа и сквозное шифрование вне рамок
• Оценка нагрузки: 50 млн DAU по 40 сообщений ≈ 2 млрд в сутки ≈ 20 000 RPS записи, в пике ~60 000; 10 млн одновременных соединений, ~100 000 на gateway → ~100 gateway; 2 млрд × 200 байт ≈ 400 ГБ в сутки, ~150 ТБ в год без реплик
• API: WebSocket: send {chat_id, client_msg_id, text}, ack {msg_id}, события new_message, read; HTTP: GET /chats/{id}/messages?before=...
• Данные: чаты и участники в PostgreSQL, сообщения в Cassandra/ScyllaDB с ключом партиции chat_id и сортировкой по msg_id, реестр user_id → gateway в Redis с TTL
• Компоненты: gateway-серверы с соединениями, сервис сообщений (сохранить, присвоить id, разослать), сервис присутствия, push-сервис для офлайн, очередь для фан-аута в группах
• Узкие места: большие группы (фан-аут через очередь), дубли при переотправке (client_msg_id для идемпотентности), переподключения и догрузка пропущенного, горячие чаты, падение gateway

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести и уточнить симптом: таймаут, refused, ошибка TLS, 5xx
• DNS: dig +short, правильный ли IP, не истёк ли домен
• Сеть и порт снаружи: curl -v, nc -zv host 443; refused или timeout
• На сервере: слушает ли процесс и на каком адресе (ss -tlnp), отвечает ли локально
• Фаервол на хосте и в облаке, балансировщик и его health checks
• Логи прокси и приложения, сертификат и его срок

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже