Кто выбирал бэкенд в проекте: ты или бэкендер

Что проверяют

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

Как отвечать

Скажите честно, кто выбирал. Затем покажите, в чём было ваше участие, опираясь на свой опыт:

• контракт API: REST или GraphQL, формат пагинации (курсорная или по смещению), единый формат ошибок, как передаются даты и деньги. Хорошо, если контракт описан в OpenAPI и типы на клиенте генерируются автоматически, например через openapi-typescript или orval;
• авторизация: токен в памяти или сессия в cookie с флагом HttpOnly, как обновляется токен, настройки CORS и SameSite;
• производительность: сколько запросов уходит на одну страницу, нужен ли BFF или агрегирующий эндпоинт, кэширование через ETag и Cache-Control;
• рендеринг: если фронтенд на Next.js или Nuxt с серверным рендерингом, часть запросов идёт с сервера, и это влияет на авторизацию и таймауты.

Если бэкенд выбирали вы, например в фулстек проекте на Node.js, назовите критерии: что знала команда, какие были требования к нагрузке, что уже работало в инфраструктуре. «Мне так привычнее» не довод.

Если вас вообще не спрашивали, это тоже нормально. Расскажите, как вы договаривались о контракте или добивались правок, когда API оказывался неудобным для интерфейса.

Где спотыкаются

Приписывают себе выбор стека, чтобы звучать солиднее. На вопросе «а почему не Go» это рассыпается.

Говорят «бэкенд не моя зона, что дали, с тем и работал». Интервьюер слышит, что вы не влияете на неудобный API, а обкладываете его костылями на клиенте.

Сравнивают технологии без критериев: «Node.js быстрый, Django удобный». Без контекста нагрузки, команды и сроков это не аргументы.