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

Начните с ресурса, сценария и контракта, затем уточните валидацию, ошибки, auth, pagination, идемпотентность и эволюцию. API не должно копировать структуру базы данных.

Объясните, почему общей ACID-транзакции обычно нет, и выберите устойчивый процесс: локальная транзакция с outbox, идемпотентный потребитель, saga и компенсация. Назовите дубликаты и наблюдаемость.

Аутентификация устанавливает личность, авторизация проверяет право на действие. Расскажите о проверке на сервере, сессии или токене, сроке жизни, обновлении, CSRF/XSS и принципе наименьших привилегий.

Разделите локальное UI-состояние, серверные данные и состояние отправки. Нужны валидация, disabled/retry, показ ошибки и защита от повторной отправки без скрытия причины пользователю.

Кеш нужен при измеримой нагрузке или задержке, не как рефлекс. Укажите source of truth, ключ, TTL, invalidation после записи и приемлемость устаревших данных для сценария.

Исходите из реальных фильтров, сортировки и плана запроса. Индекс ускоряет чтение ценой записи и памяти, поэтому проверяйте селективность, составной порядок и не добавляйте их вслепую.

Добавляйте поля и сохраняйте старую семантику, версионируйте при необходимости, измеряйте использование и задавайте срок депрекации. Клиент и сервер выкатывают так, чтобы смешанные версии работали.

Unit-тесты покрывают логику, интеграционные — API и БД, e2e — критичный путь пользователя. Выберите минимальный набор, который поймает регресс между слоями без медленной хрупкой пирамиды.

Разделите время загрузки, API, БД, рендер и внешние зависимости, опирайтесь на tracing и метрики. Не оптимизируйте на глаз и свяжите изменение с измерением p95 или пользовательской метрики.

Покажите сценарий, контракт и личную ответственность, риски миграции, тестирование и результат. Не скрывайте участие других специалистов и принятые компромиссы.