> Что хотел бы поменять в профессии или работе (Go)

Короткий ответ

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

Подробное объяснение

В профессии backend-разработчика на Go есть несколько аспектов, которые хотелось бы изменить:

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

• Процесс code review: хотелось бы, чтобы ревью было более глубоким и фокусировалось не только на корректности, но и на производительности, идиоматичности Go и долгосрочной поддерживаемости.

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

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

• Инструментарий и окружение: хотелось бы больше влиять на выбор инструментов - линтеров, CI-пайплайнов, подходов к тестированию, чтобы команда работала эффективнее.

На практике

На практике это выглядит так:

• В спринте выделяется отдельная задача на рефакторинг или погашение технического долга, а не только на фичи.
• В code review добавляется чек-лист, который включает проверку на идиоматичность Go, отсутствие гонок данных, корректную обработку ошибок.
• Внедряются генераторы кода (например, для gRPC-сервисов или миграций), чтобы убрать рутину.
• Раз в неделю проводится техническая сессия, где разбираются сложные кейсы или новые паттерны.
• Разработчик участвует в планировании архитектуры на уровне сервиса, а не только в оценке задач.

Пример кода

Пример того, как можно автоматизировать рутину - генерация обработчика ошибок для HTTP-сервиса на Go:

GO
// вместо повторяющегося кода обработки ошибок
func handleUser(w http.ResponseWriter, r *http.Request) {
    user, err := getUser(r.Context(), r.URL.Query().Get("id"))
    if err != nil {
        writeError(w, err) // общая функция
        return
    }
    writeJSON(w, user)
}

// можно использовать middleware для централизованной обработки
func withErrorHandler(next func(w http.ResponseWriter, r *http.Request) error) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        if err := next(w, r); err != nil {
            writeError(w, err)
        }
    }
}

Такой подход убирает дублирование и делает код чище.

Как отвечать на собеседовании

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

• Назовите 1-2 ключевых аспекта, которые хотите изменить.
• Объясните, почему это важно для вас и для команды.
• Приведите пример, как вы уже пытались это внедрить или как бы это сделали.
• Подчеркните, что понимаете trade-off между скоростью и качеством.

Не говорите "мне не нравится текущая работа" - говорите "я вижу возможности для улучшения процессов".

Что проверяет интервьюер

Интервьюер оценивает:

• Зрелость: видит ли кандидат системные проблемы, а не только личные неудобства.
• Проактивность: предлагает ли решения, а не просто критикует.
• Понимание процессов: знает ли, как устроен цикл разработки, code review, планирование.
• Мотивацию: что движет кандидатом - рост, качество, влияние на продукт.
• Культурную совместимость: насколько его взгляды совпадают с ценностями команды.

Типичные ошибки

• Жалоба без предложений: "мне не нравится legacy-код" без вариантов, как с ним работать.
• Уход в личное: "начальник не даёт мне интересные задачи" - звучит незрело.
• Игнорирование бизнес-контекста: "хочу только писать новый код" без понимания, почему legacy существует.
• Расплывчатость: "хочу больше развития" без конкретики.
• Отрицание trade-off: "нужно всегда делать идеально" - показывает непонимание реальности разработки.