Было ли прошлое место работы первым на Go

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

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

Как отвечать

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

Затем покажите, что переход был осознанным. Хорошо звучит рассказ о том, что пришлось перестроить:

• ошибки как значения: явный if err != nil, обёртка через fmt.Errorf с %w, проверка через errors.Is и errors.As вместо исключений;
• конкурентность: горутины и каналы, context.Context для отмены и таймаутов, errgroup, поиск гонок через go test -race;
• интерфейсы: реализуются неявно, получаются маленькими и объявляются на стороне потребителя, наследования нет;
• инструменты: модули, табличные тесты, pprof для профилирования, линтер golangci-lint.

Назовите, на чём работали: gRPC или REST, PostgreSQL через pgx, Kafka, Kubernetes. Результаты приводите свои, с цифрами, которые выдержат уточняющий вопрос.

Если коммерческого опыта на Go нет совсем, не маскируйте это. Скажите, откуда знания: пет-проект, внутренний инструмент, написанный на Go в прошлой компании, вклад в открытый проект. И объясните, что переносится из вашего основного языка: проектирование API, работа с базой, мониторинг в продакшене.

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

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

Переносят старые привычки: геттеры на каждое поле, огромные интерфейсы рядом с реализацией, panic вместо возврата ошибки. Если вы признаёте это как пройденный этап, это скорее плюс.

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