Писал ли ты бэкенд на последнем проекте
Что проверяют
Насколько далеко вы заходите за границу браузера и не распадается ли у вас картина приложения на свой фронтенд и чёрный ящик сервера. Часто за вопросом стоит реальная потребность команды: некому держать слой на Node между клиентом и сервисами, писать серверный рендеринг или чинить контракт API.
Как отвечать
Не преувеличивайте. Честная градация звучит лучше расплывчатого «немного трогал»:
- писал серверный код фичами: маршруты, валидация входа, работа с базой;
- писал слой агрегации под клиент: сборка нескольких ответов API в один под конкретный экран, проксирование, кэширование;
- писал серверную часть фреймворка: загрузка данных на сервере, серверный рендеринг, обработка ошибок и редиректов;
- не писал, но плотно работал с бэкендом: согласовывал контракт, читал схему API, разбирал коды ответов, ловил проблемы с CORS и кэширующими заголовками.
Дальше один короткий пример с деталью, которая показывает, что вы понимали, что делаете: почему запрос уехал на сервер (ключ нельзя отдавать в браузер, лишние обращения по сети), как разделили ответственность, что делали с ошибками сети и повторами.
Хорошо добавить, где вы осознанно остановились: миграции базы, права доступа и очереди не трогали, потому что это зона бэкенд-команды, а вы отвечали за стык.
Где спотыкаются
Записывают в бэкенд любые вызовы fetch. Запросы к чужому API это фронтенд, и интервьюер слышит подмену сразу, после чего начинает перепроверять и остальные заявления.
Второе: раздувают опыт, а через два вопроса не могут объяснить, зачем нужен пул соединений или почему запрос в цикле убивает базу. Проверяется это дёшево, и завышенная самооценка бьёт по доверию ко всему рассказу целиком.
Третье: отвечают «нет» и закрывают тему. Даже без серверного кода есть что рассказать: где вы упирались в неудобный контракт, как договаривались о формате ошибок, что просили изменить в API и чем это обосновали.