Насколько погружен в архитектуру и задачи проекта

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

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

Как отвечать

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

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

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

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

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

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

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