Full Stack разработчик: вопросы на собеседовании

Образец ответа

Критичную бизнес-логику я оставляю на сервере: валидацию, авторизацию, расчётные правила, проверку прав доступа и всё, что влияет на целостность данных. На клиенте я держу только то, что улучшает UX: предварительную проверку форм, optimistic UI, локальные подсказки и форматирование. Если часть правил неизбежно дублируется, я стараюсь вынести схемы или типы в общий контракт, чтобы не расходились версии. Главное правило простое: сервер — источник истины.

Образец ответа

Сначала я уточняю бизнес-цель, ограничения и критерии приёмки, чтобы не строить лишнее. Затем набрасываю data flow, структуру API и изменения в модели данных, после чего делю работу на небольшие вертикальные срезы. Реализую backend-часть с валидацией и тестами, потом подключаю frontend, не забывая про loading, empty и error states. Перед релизом добавляю logging, метрики, при необходимости feature flag и проверяю, как фича ведёт себя в production.

Образец ответа

Я сознательно держу один-два сильных направления, где у меня есть настоящая глубина, например React и API design, а остальное поддерживаю на рабочем уровне. Когда вхожу в менее знакомую область, не притворяюсь экспертом: читаю документацию, уточняю риски, обсуждаю решения с коллегами и быстро закрываю пробелы. Такой подход помогает не распыляться и при этом оставаться полезным на всём стеке. Для меня Full Stack — это понимание системы целиком и умение принимать хорошие решения на стыках.

Образец ответа

У меня был кейс с real-time комментариями: понадобились новая таблица в БД, API для чтения и записи, WebSocket-обновления и интерфейс с optimistic UI. Я спроектировал схему так, чтобы быстро получать ветвящиеся треды, затем добавил backend-рассылку событий и синхронизацию состояния на клиенте. Перед общим релизом выкатывал фичу на небольшую аудиторию через feature flag. Это помогло поймать race condition до полного запуска.

Образец ответа

Я опираюсь на единые conventions, линтеры, formatter и проверки в CI/CD, чтобы стиль не зависел от вкуса конкретного разработчика. Стараюсь держать границы ответственности между UI, API и data layer, чтобы изменения можно было локализовать. Там, где это оправдано, пишу integration tests, потому что они лучше всего ловят поломки между слоями. Плюс фиксирую архитектурные решения в документации, чтобы новым людям было проще входить в проект.

Браузер валидирует поля на клиенте, сериализует данные и отправляет HTTP request на сервер. Сервер проверяет аутентификацию, валидирует payload, применяет бизнес-правила и при необходимости пишет в БД в рамках transaction. Затем он возвращает response с подходящим status code. Клиент получает ответ и обновляет UI, учитывая success, validation errors и возможные сетевые ошибки.

После логина сервер выдаёт credential — чаще всего session cookie или signed token. Я предпочитаю httpOnly cookie, если это возможно, потому что так сложнее украсть токен через XSS; при этом добавляю CSRF protection. На каждом защищённом запросе backend сам проверяет сессию, роль и права пользователя, не полагаясь на то, что клиент «честно» передал идентичность.

CORS — это браузерный механизм, который ограничивает cross-origin запросы, если сервер явно не разрешил их через response headers. Обычно с ним сталкиваются, когда frontend и API живут на разных origin. Решение — настроить сервер так, чтобы он возвращал корректные Access-Control-Allow-Origin и связанные заголовки только для доверенных источников. Отключать CORS «в лоб» нельзя: это ломает модель безопасности браузера.

Сначала я проверю query plan и добавлю подходящие indexes, если проблема в самом запросе. Затем ставлю timeout, чтобы запрос не держал connections слишком долго, и настраиваю connection pool с лимитами. Если чтение часто повторяется, использую caching, а тяжёлые операции выношу в background job, чтобы не блокировать request path.

Server-side rendering генерирует HTML на сервере, поэтому пользователь быстрее видит контент, а поисковые системы лучше его индексируют. Client-side rendering отдаёт JS bundle, который строит интерфейс уже в браузере; это удобно для сильно интерактивных приложений, но старт может быть медленнее. На практике часто используют гибридный подход: hydration, pre-rendering или static generation, чтобы сбалансировать скорость и интерактивность.

Я бы начал с воспроизведения бага и проверки network trace, чтобы понять, корректно ли уходит запрос и что возвращает сервер. Если frontend отправляет правильные данные, значит нужно смотреть backend и БД. В похожем кейсе проблема оказалась в конфликте параллельных обновлений: одно изменение затирало другое. Я добавил optimistic locking через version field и показал пользователю понятную ошибку при конфликте.

В такой ситуации я жёстко режу scope до must-have сценариев и не пытаюсь сделать идеальную платформу вместо работающего продукта. Беру знакомый stack, использую готовые компоненты, ORM и проверенные библиотеки, чтобы не тратить время на изобретение базовых вещей. Сначала довожу до рабочего состояния весь путь пользователя, потом — polish. Обязательно оставляю понятную документацию, чтобы проект можно было поддерживать дальше.

Я в первую очередь защищаю надёжность. Если есть риск падения, потери данных или критичной ошибки в логике, это важнее визуального полировки. На практике я бы честно проговорил команде, что именно успеваем к дедлайну, а что переносим в следующий sprint. Пользователь простит более простой интерфейс, но не простит потерю данных или crash на демо.

Один из самых полезных шагов — собрать локальный запуск в одну команду через containerization и предсказуемую конфигурацию. Я также добавлял seed data, make targets для тестов и понятный README по типовым сценариям. После этого новые коллеги перестали тратить дни на настройку окружения и начали приносить пользу почти сразу. Для Full Stack команды это особенно важно, потому что поломка среды бьёт сразу по всем слоям.