backend.md

Список компетенций, оцениваемых на софт-интервью для Junior Backend developer

1. Мотивация и интерес к профессии
2. Способность к обучению и любознательность
3. Коммуникация и умение работать в команде
4. Ответственность и надежность
5. Самооценка

Вопросы по ключевым компетенциям

Мотивация и интерес к профессии

Цель: понять осознанность выбора, энтузиазм, готовность развиваться.

Как отвечать: подготовиться заранее и составить четкие критерии по мотивации на работу в профессии, в конкретной компании, а так же сформулировать представления о дальнейшем развитии. Построить рассказ о прошлом опыте, делая акцент на проектах, иcпользовать схему STAR (situation – tasks – action – results).

• Какие критерии важны при выборе работы? Что оцениваешь в первую очередь? Какие есть ред флаги?

  Как отвечать

  Проверяют осознанность и совпадение твоих ожиданий с реальностью компании.

  Назови 3–4 критерия, важных именно для тебя, и почему: задачи и продукт, инженерная культура (код-ревью, тесты, CI, отношение к техдолгу), команда и наличие наставника, процессы и предсказуемость, стек, формат работы, деньги и стабильность. Для джуна честно поставить на первое место обучение и менторство — это ожидаемый ответ.

  Ред флаги формулируй нейтрально и через факты: нет тестов и ревью, «у нас всё горит, но мы семья», овертаймы как норма, размытая роль без ответственных, невнятный процесс найма и затянутые ответы, серая зарплата, высокая текучесть. Заодно это повод задать встречные вопросы про процессы.

• Чем заинтересовала выбранная вакансия?

  Как отвечать

  Проверяют, готовился ли ты и не рассылаешь ли отклики веером.

  Как отвечать: до интервью посмотреть сайт и продукт, описание вакансии, стек, блог и соцсети компании, отзывы. В ответе связать это со своим интересом: что за продукт и аудитория, какая часть стека совпадает с твоим опытом, какие задачи выглядят интересными, что попробовал сам как пользователь. Достаточно трёх-четырёх конкретных фактов плюс один вопрос о продукте.

  Чего не делать: «увидел на hh, откликнулся» и общие слова про «интересные задачи и сильную команду», которые подойдут любой компании.

• Расскажи, как ты пришел во бэкенд-разработку? Что тебя в этом больше всего привлекает?

  Как отвечать

  Короткая честная история с точкой перелома: что попробовал, что зацепило, что сделал дальше (курсы, пет-проекты, первая работа). Важно, чтобы прозвучал момент выбора, а не «так получилось».

  Что привлекает в бэкенде: логика и данные, проектирование API, ответственность за целостность и надёжность, интеграции, производительность и нагрузка — то есть «невидимая» часть, где решения имеют долгие последствия. Хорошо привести конкретный случай: разбирался, почему ручка отвечает 5 секунд, делал интеграцию с платёжной системой, писал обработку очереди.

  Чего не делать: «фронтенд не пошёл, потому что не люблю верстать» без положительной мотивации и «потому что платят больше».

• Какие технологии или направления в бэкенде тебе наиболее интересны и почему?

  Как отвечать

  Проверяют осознанность интереса и совпадение со стеком компании.

  Назови 2–3 конкретные темы и причину, желательно из опыта: базы данных и оптимизация запросов («упирался в медленные ручки и захотел понять план запроса»), архитектура и проектирование API, очереди и асинхронная обработка, надёжность и наблюдаемость, безопасность, высокие нагрузки. Хорошо, если хотя бы одна тема есть в стеке вакансии.

  Чего не делать: перечислять модные аббревиатуры без объяснения (Kubernetes, Kafka, микросервисы — «потому что это круто») и говорить «мне всё интересно».

• Есть ли у тебя собственные пет-проекты, не с курсов? Расскажи о самом интересном из них.(если нет, то какой самый интересный учебный проект был и почему?)

  Как отвечать

  Проверяют самостоятельность и живой интерес к профессии.

  Если есть: рассказать по схеме «задача → почему делал → стек и решения → что было сложным → результат и что бы сделал иначе». Ценится не масштаб, а осмысленность: почему выбрал такую схему данных, как решал аутентификацию, что вынес из ошибок. Полезно иметь ссылку на репозиторий с README.

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

• В каких технологиях ты бы хотел себя прокачать и почему? В каком направлении видишь свое развитие?

  Как отвечать

  Проверяют способность к развитию и то, совпадают ли планы с тем, что компания может дать.

  Как отвечать: 2–3 темы с причиной из практики, а не «всё подряд». Например: глубже PostgreSQL и оптимизация запросов, потому что упирался в медленные ручки; очереди и асинхронная обработка, потому что делал отправку писем прямо в контроллере и понял, чем это плохо; тесты и CI, чтобы уверенно рефакторить.

  Про развитие: горизонт 1–2 года, через рост ответственности и компетенций — уверенно закрывать задачи целиком, включая проектирование; вырасти до middle и вести фичи; глубже в архитектуру или конкретный домен. Не стоит заявлять о планах уйти в другую профессию или в менеджмент через год.

• Что, на твой взгляд, самое сложное в бэкенд-разработке?

  Как отвечать

  Проверяют глубину понимания: ответ показывает, с чем ты реально сталкивался.

  Хорошие варианты (выбрать один-два и раскрыть): согласованность данных и работа с конкурентным доступом (гонки, транзакции, идемпотентность); проектирование API и схемы данных, которые придётся поддерживать годами и менять без простоя; распределённые системы, где сеть ненадёжна и «упало у соседа» становится твоей проблемой; отладка проблем, которые воспроизводятся только на проде и под нагрузкой; баланс между скоростью разработки и техдолгом; работа с неполными требованиями.

  Слабый ответ — «выучить много фреймворков» или «сложного нет». Сильный — привести пример из своего опыта, где сложность проявилась.

• Как видишь своё профессиональное развитие через 1-2 года?

  Как отвечать

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

  Отвечать через рост ответственности и компетенций, а не должностей: уверенно закрывать задачи целиком, включая проектирование и оценку; разобраться в предметной области продукта; вырасти до middle и вести фичу от требований до прода; глубже уйти в базы, нагрузку или архитектуру. Можно упомянуть интерес к менторству, если это правда.

  Чего не делать: заявлять горизонт 10 лет, обещать «стать техлидом за год» или говорить про смену профессии. И полезно спросить, как в компании устроен рост и есть ли грейды — это показывает серьёзность интереса.

Способность к обучению и любознательность

Цель: Оценить, склонен ли кандидат делать выводы и менять поведение исходя из обратной связи и своего опыта, насколько заинтересован в обучении по профессии

Как отвечать: демонстрировать готовность принимать чужую критику, совершать ошибки. Важно показывать, что ты поменял в последствии, если дальше были похожие ситуации, какие выводы сделал. А так же подготовить список самостоятельно изученных материалов (книг, статей, блогов и тд)

• Опиши ситуацию, когда ты получил код-ревью с большим количеством правок. Как ты отреагировал? Что было сложнее всего принять?

  Как отвечать

  Проверяют реакцию на критику и способность делать выводы, а не сам факт правок.

  Как отвечать: конкретный случай по схеме «ситуация → как отреагировал → что сделал → что изменил в дальнейшем». Правильная реакция: разобрать замечания, задать вопросы там, где непонятно, согласиться с обоснованным, аргументированно обсудить спорное, поблагодарить за подробное ревью. Хорошо признать эмоцию честно: «сначала было неприятно, потом понял, что это самый быстрый способ научиться».

  Сильная часть ответа — что поменялось после: стал сам перечитывать диф перед отправкой, разбивать PR на маленькие, добавил линтер и тесты, начал заранее обсуждать подход, чтобы не переделывать целиком. Чего не делать: «ревьюер был неправ» и «у меня таких ситуаций не было».

• Расскажи о самой большой ошибке или неудаче в учебном проекте. Что ты из этого вынес?

  Как отвечать

  Проверяют рефлексию и умение признавать ошибки.

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

  Чего не делать: отвечать «ошибок не было», сваливать всё на других, выбирать «ошибку», которая на самом деле похвала.

• Ты показывал свой код более опытному человеку (ментору, коллеге)? Какую самую полезную правку ты получил?

  Как отвечать

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

  Как отвечать: да — рассказать, кому показывал (ментор на курсах, коллега, сообщество, ревью в open source) и привести конкретную правку, которая изменила подход: вынести бизнес-логику из контроллера в сервис, перестать ловить все исключения подряд, использовать транзакцию и уникальный индекс вместо проверки в коде, называть переменные по делу. Ценится не сама правка, а то, что ты понял принцип за ней.

  Если такого опыта не было — честно сказать и добавить, как получал обратную связь иначе: разбор чужого кода, статьи, линтеры, самопроверка. И что ждёшь ревью на новой работе как способ роста.

• Какие ресурсы (курсы, книги, блоги) ты используешь для обучения? Что изучал в последнее время?

  Как отвечать

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

  Как отвечать: назвать то, чем реально пользуешься, и что вынес: официальная документация (это сильный сигнал — джуны часто её игнорируют), курсы и платформы, книги (например, «Чистый код», «Совершенный код», «Высоконагруженные приложения» Клеппмана, книги по SQL), блоги и рассылки, доклады с конференций, телеграм-каналы, разбор чужого кода в open source, задачи на Codewars и LeetCode.

  Обязательно добавить свежий пример: что изучал в последние недели и зачем — под рабочую задачу или как пробел в базе. Чего не делать: перечислять книги, которые не читал, — спросят содержание.

• Представь, ты не знаешь, как решить задачу. Каковы будут твои действия?

  Как отвечать

  Проверяют самостоятельность и умение вовремя просить помощь — важен именно порядок действий.

  Разумная последовательность: убедиться, что понимаю задачу и ожидаемый результат (иначе решаю не то); декомпозировать и понять, какая именно часть непонятна; прочитать документацию и код проекта, посмотреть, как похожее сделано рядом; воспроизвести проблему на минимальном примере; поискать в интернете и в истории репозитория; сформулировать гипотезы и проверить их; параллельно фиксировать, что уже пробовал. И если через разумное время (обычно 30–60 минут для джуна) прогресса нет — обратиться к коллеге с подготовленным вопросом: что делаю, что пробовал, где застрял.

  Ключевые мысли: не сидеть в тупике день и не молчать до дейли; но и не спрашивать сразу, не попробовав. Про ИИ и советы из интернета уместно сказать, что решение всё равно нужно понять и проверить.

• Расскажи, как ты подходишь к отладке (debugging) сложной проблемы на бэкенде, например, когда сервер возвращает 500 ошибку, а в логах нет очевидной причины?

  Как отвечать

  Проверяют системность мышления, а не знание конкретной команды.

  Порядок: воспроизвести проблему (окружение, данные, запрос, пользователь) и зафиксировать симптом; найти следы — request id и trace id, логи приложения и веб-сервера, трейсы и мониторинг, метрики в момент сбоя, ошибки в Sentry; посмотреть, что менялось (последний деплой, миграция, конфигурация, обновление зависимости, изменение данных); сузить область — какой слой отвечает ошибкой (прокси, приложение, база, внешний сервис); сформулировать гипотезу и проверить одну за раз; при необходимости повысить уровень логирования или добавить логи в подозрительное место; проверить на стенде с похожими данными.

  Если в логах ничего нет — это отдельный симптом: значит либо исключение проглочено, либо процесс упал (OOM, таймаут, падение воркера), либо ошибка на уровне прокси или базы, либо логи не собираются. Помогают 500 без стектрейса → проверить обработчик ошибок, статус процесса, dmesg, лимиты памяти, таймауты, соединения с базой.

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

• Как ты убеждаешься, что твой код не только работает, но и работает эффективно?

  Как отвечать

  Проверяют, думаешь ли ты о производительности и умеешь ли измерять, а не угадывать.

  Что назвать: посмотреть, какие запросы уходят в базу (нет ли N+1, есть ли индексы под фильтры и сортировку, что показывает EXPLAIN ANALYZE); оценить сложность алгоритма и объём данных, на которых код будет работать (на 100 записях всё быстро, на миллионе — нет); проверить пагинацию и отсутствие выборок «всего»; вынести долгие операции (письма, внешние вызовы, отчёты) в фоновые задачи; добавить кэш там, где это оправдано; измерить время ответа ручки и профилировать, а не оптимизировать наугад; посмотреть метрики и логи после релиза.

  Правильная формулировка: сначала измеряю (профайлер, логи запросов, нагрузочный тест), потом оптимизирую самое дорогое; преждевременная оптимизация вредна, но очевидные вещи вроде отсутствия индекса и запросов в цикле проверяю всегда.

Коммуникация и умение работать в команде

Цель: понять, насколько кандидат ясно излагает мысли, умеет ли работать с другими

Как отвечать: ориентироваться на принцип «всё можно обсудить и договориться», показывать, что готов слушать мнение другого и обоснованно аргументировать своё. Нормально показывать, что какие-то ситуации могут раздражать, важно при этом показать, как ты из них выходишь.

• Опиши свой вклад в командный проект (если опыт есть). Как было организовано взаимодействие?

  Как отвечать

  Проверяют, умеешь ли работать в команде и говорить «я» вместо «мы».

  Как отвечать: контекст (что за проект, размер команды, роль), затем свой вклад конкретно — какие части делал, какие решения принимал, что было сложным, чем помогал другим. Потом — как было организовано взаимодействие: задачи в трекере, ветки и pull request'ы, код-ревью, дейли и планирование, обсуждение спорных решений, договорённости по контрактам API с фронтендом, документация.

  Если командного опыта не было: сказать честно и привести близкое — учебный проект в паре, вклад в open source, работа с ментором, участие в хакатоне; и рассказать, как представляешь себе командную работу и почему она удобнее одиночной.

• Как ты будешь объяснять техническую проблему не-техническому специалисту (например, менеджеру)? Приведи пример такой ситуации

  Как отвечать

  Проверяют коммуникацию и умение видеть чужой контекст.

  Принципы: начать с того, что важно собеседнику — влияние на пользователей, сроки и деньги, а не с технических деталей; говорить на языке аналогий и без жаргона; сначала вывод («оплата у части пользователей не проходит с утра»), затем причина в одном предложении, затем варианты решения со сроками и последствиями; предложить решение и назвать риски; закончить вопросом, что важнее для бизнеса.

  Пример: вместо «в базе не хватает индекса, и запрос делает seq scan по таблице на 20 миллионов строк» — «список заказов открывается 5 секунд, потому что база каждый раз перебирает все заказы вместо готового указателя. Можно ускорить за день, тогда будет меньше секунды; можно отложить, но с ростом данных станет ещё медленнее».

  Чего не делать: заваливать деталями, обвинять «они не понимают», обещать сроки без оценки.

• Как ты отреагируешь, если фронтенд-разработчик или продукт-менеджер запросит API-метод, который технически очень сложно или неэффективно реализовать?

  Как отвечать

  Проверяют умение не говорить «нет», а решать задачу.

  Правильная последовательность: сначала выяснить задачу, а не обсуждать предложенное решение — какой сценарий пользователя закрывается, какие данные реально нужны, как часто вызывается, какой объём. Часто выясняется, что нужно не то, что попросили. Затем объяснить ограничение на языке последствий: «в таком виде запрос будет собирать данные из четырёх таблиц по каждому элементу списка и займёт секунды; при 100 пользователях ручка положит базу». Затем предложить альтернативы: другой формат ответа, пагинация и фильтры, агрегированное поле, денормализация или предрасчёт, кэш, асинхронный вызов с уведомлением, отдельная ручка под конкретный экран (BFF), поэтапная реализация — быстрый вариант сейчас и правильный позже.

  И зафиксировать решение письменно: что делаем, чего не делаем и почему, какие сроки. Если договориться не удаётся — эскалировать к техлиду, а не тихо делать плохое решение или молча отказывать.

• Как ты решаешь вопросы или конфликты при взаимодействии с коллегами? Приведи пример из прошлого опыта

  Как отвечать

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

  Подход: сначала выяснить факты и позицию другого (часто расхождение из-за разного контекста, а не из-за злого умысла); обсудить лично и по существу проблемы, а не человека; искать объективный критерий — данные, замеры, требования, стандарт команды; если согласия нет — эскалировать к техлиду и принять командное решение; зафиксировать договорённость письменно. И привести конкретный пример, желательно такой, где ты оказался неправ и признал это.

  Чего не делать: говорить «конфликтов у меня не бывает» (звучит неправдоподобно) и рассказывать историю, где коллега выставлен идиотом.

• Что для тебя комфортный уровень общения в команде?

  Как отвечать

  Проверяют совместимость с культурой команды: сколько тебе нужно общения, контроля и обратной связи.

  Как отвечать честно и конкретно: общение на «ты» и без формальностей; письменная асинхронная коммуникация в трекере и чате плюс короткие звонки, когда нужно быстро договориться; регулярные дейли как синхронизация, а не отчёт; ревью по делу и без сарказма; нормально задавать вопросы и не сидеть в тупике сутками; понятно, к кому идти с каким вопросом. Уместно уточнить, как принято в компании — это нормальный встречный вопрос.

  Чего не делать: «работаю один, не трогайте меня» и, наоборот, «нужно, чтобы мне всё время подсказывали».

• Какие люди или какое поведение тебя может вывести из себя?

  Как отвечать

  Проверяют самоосознание и то, как ты справляешься с раздражением, — признать, что что-то раздражает, нормально.

  Как отвечать: назвать поведение (а не типы людей) и сразу — как ты с этим справляешься. Безопасные и честные варианты: когда договорённости не выполняются и об этом молчат до дедлайна; когда на вопрос отвечают «сам разберись»; когда правки просят без объяснения причины; когда обсуждение переходит на личности; когда важные решения принимаются в личке и не фиксируются. И следом: «в таких случаях я проговариваю ситуацию напрямую, прошу зафиксировать договорённость в тикете, при повторении — обсуждаю с лидом».

  Чего не делать: отвечать «меня ничего не раздражает» (звучит неискренне) и устраивать разбор конкретных бывших коллег.

Ответственность и надежность

Цель: понять уровень самостоятельности кандидата, сделать вывод, можно ли ему доверять задачи, требующие самостоятельности

Как отвечать: желательно использовать примеры из своего опыта. Делать акцент на самостоятельных действиях (чтение документации, поиск ответов в спец.статьях, собственные решения) и только потом - обращаться к более опытным коллегам и ИИ. Но при этом показывать важность коммуникации с командой.

• Расскажите о проекте или задаче, которую вы вели от начала и до конца. Как вы убедились, что результат полностью готов?

  Как отвечать

  Проверяют самостоятельность и понимание, что «готово» — это не «код написан».

  Структура: контекст и задача, что решал, какие решения принимал, что было сложным, результат. Дальше самое важное — как убедился, что готово: критерии приёмки согласованы с постановщиком; написаны и проходят тесты; проверены граничные случаи и негативные сценарии; код прошёл ревью; работает не только локально, но и на стенде; применены миграции; посмотрел логи и метрики после релиза; обновил документацию; передал знание команде и поддержке.

  Хороший ответ включает и то, что пошло не по плану, и как ты это заметил вовремя. Слабый — «сдал задачу, дальше не знаю».

• Что вы делаете, если понимаете, что не успеваете к дедлайну? Опишите ваши действия.

  Как отвечать

  Проверяют не героизм, а умение вовремя сообщить и предложить варианты.

  Действия: как только риск стал понятен (а не в последний день) — сообщить менеджеру и команде; объяснить причину и новую оценку; предложить варианты — сократить объём и выпустить главное, сдвинуть срок, разделить на этапы, взять помощь, убрать необязательные части за фичефлаг; уточнить приоритеты и дать решить бизнесу; после — разобрать причину, чтобы оценка в следующий раз была точнее.

  Ключевая мысль: раннее предупреждение ценится выше подвига. Чего не делать: молча пытаться дотянуть, работать ночами и сообщить о срыве в день сдачи.

• Как вы поступаете, когда вам нужно уйти с работы (или завершить рабочий день), а задача еще не выполнена?

  Как отвечать

  Проверяют ответственность и умение передавать контекст, а не готовность работать сверхурочно.

  Что сказать: сначала оценить, критично ли это — если задача блокирует релиз или инцидент, я останусь или предупрежу и подключу коллег. В обычной ситуации: довести работу до безопасного состояния (не оставлять сломанный стенд и незакоммиченные изменения), зафиксировать статус в тикете — что сделано, что осталось, где остановился, какие есть открытые вопросы; при необходимости запушить ветку с пометкой WIP; предупредить в чате, если кто-то ждёт результат; спланировать, с чего продолжу утром.

  Ключевая мысль: важно не «сидеть до победы», а не терять контекст и не блокировать других. Постоянные переработки — признак проблем с планированием, и об этом стоит говорить, а не молча их компенсировать.

• Как вы организуете свою работу, чтобы ничего не упустить и не забыть о поставленных задачах? (Планировщики, списки, заметки)

  Как отвечать

  Проверяют самоорганизацию и то, нужно ли за тобой присматривать.

  Описать свою реальную систему: задачи только в трекере (Jira, YouTrack) и с актуальным статусом, декомпозиция крупной задачи на подзадачи, планирование дня утром и приоритизация по влиянию и блокировкам, отдельный список мелочей и «вопросов на потом», заметки по ходу работы (Obsidian, Notion, комментарии в тикете), календарь с блоками на сосредоточенную работу, чеклист перед отправкой задачи на ревью, буфер времени на ревью и внезапное.

  Полезно добавить, что записываешь всё, что пришло не в момент работы над задачей, чтобы не держать в голове, и что регулярно возвращаешься к списку. Простая, но настоящая система звучит убедительнее красивой на словах.

• Что ты будешь делать, если требования к задаче непонятны или отсутствуют?

  Как отвечать

  Проверяют, начнёшь ли ты писать код по догадкам.

  Порядок: сначала попробовать восстановить контекст самостоятельно — посмотреть похожие места в продукте и коде, макеты, историю тикетов, спросить, есть ли аналогичная функциональность; сформулировать своё понимание задачи и ожидаемого результата письменно и показать постановщику («правильно ли я понимаю, что…»); задать конкретные вопросы, а не «расскажите подробнее»: что должно происходить в граничных случаях, какие роли имеют доступ, что делать при ошибке внешнего сервиса; при недоступности постановщика — зафиксировать допущения в тикете и согласовать их с лидом, а не молча выбрать любое поведение.

  Ключевые мысли: неясные требования — самый дешёвый момент найти проблему; договорённости и допущения фиксируются письменно; для крупной задачи полезно согласовать критерии приёмки до начала работы.

• Как ты оцениваешь время на выполнение задачи и расставляешь приоритеты, если задач несколько?

  Как отвечать

  Проверяют реалистичность оценок и умение работать с несколькими задачами.

  Про оценку: сначала разобраться в задаче и декомпозировать её на шаги (оценивать «фичу целиком» бессмысленно); оценивать по опыту похожих задач; закладывать не только код, но и тесты, ревью, правки после ревью, деплой и проверку; учитывать неизвестное — если в задаче есть незнакомая часть, сначала выделить время на исследование (spike) и потом оценить; давать диапазон или называть допущения, а не одно число; сообщать сразу, если по ходу видно, что оценка была не той.

  Про приоритеты: по влиянию на пользователей и бизнес и по блокировкам (что мешает другим — вперёд); срочное и критичное (упал прод, блокер релиза) выше важного и несрочного; согласовывать приоритеты с лидом или менеджером, а не решать в одиночку; не держать пять задач в работе одновременно.

• Представьте, что вы обнаружили ошибку в своем коде уже после того, как задача была сдана. Ваши дальнейшие шаги?

  Как отвечать

  Проверяют честность и умение действовать по инциденту, а не прятать проблему.

  Действия: оценить влияние — попала ли правка в прод, сколько пользователей затронуто, есть ли потеря данных или денег; сразу сообщить команде и лиду, не пытаясь тихо починить; при критичном влиянии — отключить фичу флагом или откатить релиз; завести тикет с описанием и шагами воспроизведения; исправить, добавив тест, который воспроизводит ошибку; проверить, нет ли похожей проблемы в других местах; после — разобрать причину без поиска виноватых: почему не поймали на ревью и тестах, что добавить в чеклист или автотесты.

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

• Опишите ситуацию, когда вам пришлось выполнять не очень интересную или рутинную задачу. Как вы мотивировали себя ее завершить?

  Как отвечать

  Проверяют зрелость: рутина есть в любой работе, и важно, как ты с ней обходишься.

  Как отвечать: привести конкретный пример (перенос данных, однотипные правки в сотне мест, разбор старого кода, оформление документации) и рассказать, что помогло: понять, зачем это нужно и кому станет легче — рутинная задача обычно кому-то важна; разбить на части и видеть прогресс; поставить себе временные рамки; автоматизировать повторяющееся (скрипт, кодогенерация, миграция) — это самый сильный вариант ответа для разработчика; договориться о чередовании с интересными задачами; довести до конца и не оставлять «почти готово».

  Чего не делать: говорить, что рутинных задач у тебя не было, или что ты их бросаешь и переключаешься.

• Что для вас значит фраза «взять ответственность за задачу»?

  Как отвечать

  Проверяют, как ты понимаешь границы своей роли.

  Хороший ответ: довести задачу до результата, а не до «я свою часть сделал» — уточнить требования, если они неполные; проверить решение самому до передачи в тестирование; следить за задачей на всех этапах (ревью, тестирование, деплой) и не терять её из вида; вовремя сообщать о рисках и блокерах, а не молчать; после релиза посмотреть, что всё работает; признать и исправить, если сломалось; просить помощь, когда нужно, — это тоже часть ответственности, а не её отсутствие.

  Полезно добавить формулировку: ответственность — это не «я виноват, если что-то пойдёт не так», а «я обеспечиваю, чтобы задача дошла до результата, и делаю проблемы видимыми вовремя».

Самооценка и ожидания

Цель: узнать, насколько объективно и адекватно оценивает себя кандидат.

Как отвечать: подготовить ответ заранее, опираться на требования компаний, упоминать и софт-скилы и харды.

• Назови 3 плюса и 3 минуса себя, как бэкенд-разработчика (Вариант формулировки: Назови свои сильные и слабые стороны/зоны роста)

  Как отвечать

  Проверяют адекватность самооценки: и завышенную, и заниженную видно сразу.

  Про сильные стороны: назвать 3 конкретные и подтвердить примером — не «я ответственный», а «доводил задачу до прода и следил за метриками после релиза»; «быстро разбираюсь в незнакомом коде — за неделю вошёл в проект и закрыл первую задачу»; «пишу тесты и не ломаю соседнюю функциональность». Хорошо, если сильные стороны релевантны вакансии.

  Про зоны роста: назвать настоящие, но не критичные для этой роли, и обязательно сказать, что с ними делаешь: мало опыта с высокими нагрузками — читаю Клеппмана и делаю пет-проект с очередями; неглубоко знаю Kubernetes — прошёл курс, разбираюсь на своём стенде; иногда слишком долго пытаюсь решить сам — договорился с собой о правиле «час и спрашиваю».

  Чего не делать: «минусов нет», «я перфекционист и трудоголик» (клише) и признания, которые ставят под сомнение работу («не люблю писать тесты», «путаюсь в SQL» на вакансию с SQL).

• Почему мы должны взять именно тебя на эту вакансию джун-бэкендера?

  Как отвечать

  Проверяют, умеешь ли ты соотнести себя с требованиями вакансии, а не просто хвалить себя.

  Как отвечать: коротко и по делу, связав три вещи — что нужно компании (из описания вакансии и разговора), что у тебя есть (опыт, стек, конкретные примеры) и какая у тебя мотивация. Для джуна честный и сильный ответ строится на обучаемости и надёжности: «стек совпадает — писал на этом пет-проект и учебные задачи; быстро вхожу в новое, вот пример; довожу задачи до конца и не боюсь спрашивать; мне интересен именно ваш домен, потому что…».

  Чего не делать: сравнивать себя с другими кандидатами («я лучше остальных» — ты их не видел), говорить общими словами («я быстро учусь и стрессоустойчив») без примеров и заявлять «я сделаю у вас всё» — переобещание считывается легко.

• Какие у тебя зарплатные ожидания?

  Как отвечать

  Проверяют адекватность ожиданий рынку и то, готовился ли ты.

  Как отвечать: назвать диапазон, основанный на исследовании рынка (вакансии на своём уровне и стеке, обзоры зарплат, разговоры с коллегами), и уточнить, что речь про фикс на руки или гросс — это стоит проговорить прямо. Формулировка: «на позиции джуна с моим стеком вижу диапазон X–Y; ориентируюсь на середину, но готов обсуждать в зависимости от задач, грейда и условий». Уместно спросить про вилку в компании и что нужно, чтобы двигаться по ней.

  Чего не делать: отвечать «сколько предложите» (лишаешь себя переговорной позиции), называть цифру заметно выше рынка без обоснования или заметно ниже (создаёт впечатление неуверенности), торговаться на первом же скрининге до понимания задач.