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

Вы можете переживать, что собеседование full stack означает подготовку сразу к двум полноценным собеседованиям, frontend и backend, за то время, которое большинство кандидатов тратит на одно. Это опасение оправдано, и этот раздел показывает, почему работа на самом деле меньше, чем кажется. Интервьюеры редко повторяют отдельное специализированное собеседование по frontend или backend; они исследуют места, где слои соприкасаются, ведь именно там full stack инженеры доказывают, что заслуживают этого звания.

Большинство процессов сочетают четыре типа этапов:

• Код: задача на структуры данных или практическое задание вроде разбора, группировки или пагинации записей, часто на JavaScript, TypeScript, Python или Java.
• Создание функции: небольшая сквозная задача, например форма, которая сохраняет данные через API и показывает ошибки валидации, в общем редакторе или в репозитории для выполнения дома.
• Дизайн через весь стек: набросать функцию вроде комментариев или уведомлений, охватив схему, API, состояние на клиенте и что происходит при сбое сети.
• Поведенческий этап: рассказ о том, как вы вели функцию от тикета до продакшена, и о баге, который вы отслеживали через несколько слоёв.

Вопросы по конкретному слою по-прежнему встречаются, и отдельные подборки, включая отдельные страницы для frontend- и backend-разработчиков, находятся в центре вопросов для собеседований. Эта страница посвящена тому, что находится между ними.

API представляет собой контракт между двумя половинами вашей работы, поэтому интервьюеры спрашивают с обеих сторон:

• Как бы вы спроектировали endpoint'ы для функции и что каждый из них возвращает при успехе и при ошибке?
• Как изменить API, не сломав клиентов, уже работающих в продакшене? (Версионирование, аддитивные изменения, окна устаревания.)
• Пагинация по offset или по курсору: что бы вы использовали для ленты активности и почему?
• Как сделать POST безопасным для повторной отправки, если у клиента произошёл таймаут? (Ключи идемпотентности.)
• REST, GraphQL или RPC для конкретного клиента: что меняется в кэшировании, избыточных запросах и обработке ошибок?
• Где должна жить валидация: на клиенте, на сервере или в обоих местах, и что считается источником истины?
• Как избежать запроса N+1, когда endpoint списка возвращает вложенные данные?

Сильный ответ называет компромисс, а не только выбор. "Пагинация по курсору, потому что строки, вставленные во время прокрутки пользователем, сдвинут offset и продублируют элементы" звучит лучше, чем просто перечислить оба варианта и остановиться на этом.

Два типа вопросов отделяют full stack кандидатов от узких специалистов. Первый тип касается сквозной аутентификации: пройдите путь от момента, когда пользователь отправляет форму входа, до момента, когда аутентифицированный вызов API завершается успешно. Интервьюеры слушают, где хранится учётная запись (в куки или в хранилище на клиенте), как сервер её проверяет, почему куки HttpOnly устойчивы к доступу через скрипты, какая защита CSRF нужна сессии на основе куки, как CORS влияет на frontend с другим origin, и как обрабатываются выход из системы и истечение токена.

Второй тип вопросов посвящён отслеживанию: "Пользователь нажимает Сохранить, и ничего не происходит. Расскажите, как бы вы это отладили." Хороший ответ продвигается слой за слоем, от консоли браузера и вкладки network, к запросу и ответу, к логам сервера, вплоть до записи в базу данных, вместо того чтобы гадать.

Типичный пример: full stack разработчица проходит собеседование в компании SaaS среднего размера. На вопрос о том, как будет работать функция комментариев, она начала с таблицы (комментарии с ID поста, ID автора и временными метками, индексированные по посту), затем определила endpoint списка с пагинацией по курсору, описала оптимистичный рендеринг на клиенте с откатом при неудаче POST, и завершила тем, как она предотвратит двойную публикацию из-за двойного клика. Она держала каждый слой кратким, и уточняющие вопросы интервьюера пошли прямо к тем стыкам, которые она назвала.

Тренируйте отслеживание вслух. Выберите функцию из приложения, которым пользуетесь каждый день, и объясните её путь от схемы до экрана, а затем повторите это, добавив сбой: API работает медленно, запись выполняется лишь частично, пользователь выходит из системы посреди запроса. Запишите себя на видео или пройдите вопросы в пробном собеседовании с ИИ, который задаёт уточняющие вопросы на основе ваших устных ответов.

На живых этапах настольное приложение SubcueAI для macOS и Windows может транскрибировать интервьюера и предлагать структуру для ответов по дизайну и поведению там, где правила собеседования допускают помощь; расширение Chrome/Edge покрывает звонки во вкладке браузера, а приложение для iPhone слушает звонок, воспроизводимый на другом устройстве. Честное ограничение важнее всего именно на full stack собеседованиях: создание функции и этапы написания кода часто проходят на общем экране, а всё, что на общем экране, видно, поэтому помощь там не предусмотрена. Контролируемые онлайн-тестирования и устройства, управляемые компанией, также вне рамок. Настройка описана в руководстве.