Расскажите про специфику проекта, над которым работаете

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

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

Как отвечать

Сначала предметная область, потом техника. Одним абзацем: что за система, кто пользователь, что сломается у бизнеса, если сервис полежит час. Дальше контур:

• сколько сервисов и как они общаются: HTTP, gRPC, брокер, где синхронно, а где через очередь;
• где лежит состояние, какая база, есть ли кэш и как он инвалидируется;
• ваш кусок: какие пакеты на вас, что вы в них делали за последние месяцы;
• как в проекте живёт Go: context со сквозными таймаутами и отменой, корректное завершение по сигналу, генерация кода из описаний API, линтеры в пайплайне, table-driven тесты и прогон с -race;
• как выкатываете и что смотрите после выката.

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

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

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

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

Знают только свой модуль. На вопрос, что происходит с запросом до вашего сервиса и после него, начинается «это делает другая команда». Такой ответ закрывает разговор про senior-уровень мгновенно.