Какая у вас сейчас роль в команде

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

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

Как отвечать

Опишите роль через то, чем вы владеете и за что отвечаете, когда что-то ломается:

• команда: размер, есть ли тимлид и отдельные SRE, сколько сервисов на команду;
• ваши сервисы: что делают, какая нагрузка (RPS, объём данных), как общаются: gRPC, REST, Kafka или NATS;
• стек руками: Go, PostgreSQL через pgx или database/sql, Redis, Docker и Kubernetes, генерация кода из protobuf;
• эксплуатация: дежурите ли, какие метрики и алерты завели в Prometheus и Grafana, есть ли трейсинг через OpenTelemetry, разбирали ли инциденты;
• влияние на команду: код-ревью, шаблон сервиса, внедрение golangci-lint, наставничество, участие в дизайн-ревью.

Результаты подкрепляйте цифрами, которые можете объяснить: снизили p99 с 400 до 120 мс, найдя через pprof лишние аллокации; нашли и закрыли утечку горутин; ускорили CI с 15 до 6 минут. Такие цифры вызывают технические вопросы, и вы к ним готовы. «Производительность выросла на 30%» без метрики и причины вызывает только недоверие.

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

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

Отвечают одной строкой: «бэкенд-разработчик на Go». Название должности не отвечает на вопрос о роли.

Рассказывают только про код и молчат про эксплуатацию. В продуктовой команде ответственность за сервис в проде обычно входит в роль Go-разработчика.

Называют себя архитектором системы, а на вопрос «почему gRPC, а не REST» отвечают «так было до меня». Расхождение между заявленной ролью и знаниями бьёт сильнее, чем скромная формулировка.