Собеседование Middle Golang: вопросы, темы и критерии оценки

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

Чем Middle отличается от Junior

Самостоятельность

Middle берет задачу в формате user story и доводит до продакшена. Он сам разбирается в требованиях, проектирует решение, реализует, покрывает тестами и раскатывает в production. Вам не нужно расписывать каждый шаг — достаточно обозначить цель и ожидаемый результат.

Архитектурное мышление

Middle думает о структуре модулей, зависимостях, тестируемости и масштабируемости. Он видит систему целиком, понимает как его код встраивается в общую архитектуру, и может предложить альтернативные решения с обоснованием trade-offs.

Понимание бизнес-контекста

Middle спросит: «Зачем нужна эта фича? Как она влияет на метрики продукта? Может, есть альтернативное решение, которое быстрее доставит ценность?» Он понимает, что код — это средство доставки бизнес-ценности, а не самоцель.

Техническая глубина

Middle понимает, КАК работают горутины, планировщик, сборщик мусора. Он может профилировать производительность приложения, находить узкие места и оптимизировать их с измерениями до и после. Он не угадывает, а измеряет и принимает решения на основе данных.

Коммуникация

Middle проактивно коммуницирует: сообщает о блокерах, рисках, предлагает альтернативные решения. Он может объяснить техническое решение нетехническому человеку — PM, заказчику, руководителю — на понятном языке без избыточного жаргона.

На что обращать внимание при найме Middle

При собеседовании Middle-разработчика оценивайте не только технические навыки, но и способность мыслить как владелец продукта. Задавайте себе вопросы:

• Может ли он спроектировать микросервис с нуля? От выбора технологий до структуры репозитория, от API дизайна до observability.
• Способен ли вести техническую дискуссию с аргументацией всех «за» и «против»? Не «я так думаю», а «вариант А дает нам X, но стоит Y; вариант Б дает Z, но требует дополнительно W».
• Понимает ли он компромиссы? Производительность и читаемость, сложность и гибкость, time-to-market и техдолг.
• Готов ли взять ответственность за целый модуль или сервис? Не просто написать код, а владеть им: поддерживать, мониторить, реагировать на инциденты.
• Может ли объяснить техническое решение менеджеру или заказчику? Без жаргона. Простым языком, фокусируясь на ценности для бизнеса.
• Думает ли он о доставке ценности, а не только о написании кода? Спрашивает ли о приоритетах, предлагает ли урезать объём работ ради скорости, понимает ли что такое MVP.

Middle — это будущий Senior или Tech Lead. Вложения времени и денег в правильного Middle’а окупается кратно, потому что через год-два он способен стать опорой команды.

Темы (кратко)

Технические темы (8 штук)

1. Конкурентность и синхронизация — горутины, каналы, select, context, race conditions, deadlock, примитивы синхронизации. Ожидается понимание модели конкурентности Go, и умение применять правильные инструменты для решения задач.

2. Управление памятью и производительность — стек против кучи, escape analysis, профилирование (через pprof), бенчмаркинг, оптимизация аллокаций, понимание работы сборщика мусора.

3. Работа с базами данных — database/sql, lib/pq, pgx, sqlx, транзакции, пулы соединений, миграции, понимание ACID и уровней изоляции.

4. Паттерны проектирования и архитектура — чистая архитектура, DDD основы, SOLID принципы в Go, инъекция зависимостей, интерфейсы как контракты, разделение на слои (handlers, services, repositories).

5. Протоколы и API дизайн — лучшие практики REST и GRPC, middleware, context propagation, graceful shutdown, rate limiting, аутентификация и авторизация, идемпотентность.

6. Тестирование в Go — табличные тесты, моки (testify, gomock), покрытие тестами, интеграционное тестирование, бенчмарки.

7. Обработка ошибок и устойчивость — оборачивание ошибок (errors.Is, errors.As), retry паттерны, экспоненциальный backoff, circuit breaker, graceful degradation.

8. Observability и диагностика — структурированные логи (slog), метрики (Prometheus), трейсинг (OpenTelemetry), health проверки, readiness пробы, мониторинг производительности.

Soft skills и бизнес-ориентация (4 темы)

9. Декомпозиция задач и оценка сроков — умение разбить фичу на подзадачи, реалистичная оценка с учетом рисков, понимание треугольника scope-time-quality, коммуникация при сдвиге сроков.

10. Коммуникация с заказчиком — выявление реальных требований и проблем (техника «5 почему»), управление ожиданиями, объяснение технических ограничений нетехническому человеку, проактивность в коммуникации.

11. Приоритизация и фокус на ценности — понимание MVP vs полнофункциональная версия, умение отказаться от over-engineering, выбор решения исходя из бизнес-целей, time-to-market против совершенства кода.

12. Код ревью и командная работа — опыт ревью кода (как автор и ревьювер), конструктивная критика кода, менторинг джуниоров, работа в распределенной команде, линтеры.

Темы (подробно)

1. Конкурентность и синхронизация

Что проверяем: Понимание модели конкурентности Go, умение выбрать правильный примитив синхронизации для конкретной задачи, знание типичных проблем (race conditions, deadlocks, утечка рутин), практический опыт с отмены context’а операций.

Критерии оценки:

Примеры вопросов/задач:

1. Теория: Чем отличается горутина от потока ОС? Что произойдет, если создать миллион горутин?

2. Практика: Напишите worker pool, который обрабатывает задачи из канала с ограничением количества воркеров. Как корректно завершить все воркеры при получении сигнала остановки?

3. Диагностика: Дан код с race condition — найдите и исправьте:

   var counter int
   for i := 0; i < 100; i++ {
       go func() {
           counter++ // race!
       }()
   }
   

4. Пакет context: Как использовать context.Context для отмены долгих операций? Когда использовать WithTimeout vs WithDeadline vs WithCancel? Приведите пример HTTP-хендлера, который прерывается при отмене запроса от клиента.

5. Продвинутое: Что такое deadlock? Приведите пример кода, который гарантированно приведет к deadlock. Как диагностировать deadlock в production?

На что обращать внимание:

• Упоминает ли race detector (go test -race)
• Знает ли про утечки горутин и как их избежать (всегда закрывать каналы, использовать context)
• Понимает ли разницу работы и реализации между буферизированным и не буферизированным каналом
• Может ли объяснить, когда использовать sync.Mutex, когда sync.RWMutex, а когда atomic операции
• Знает ли про context.WithValue и его ограничения

Полезные ссылки и материалы (Go 1.23-1.25):

• Go 1.24: новые методы T.Context() и B.Context() для тестов с автоматической отменой
• Go 1.25: WaitGroup.Go() для удобного запуска горутин без ручного Add/Done
• Ссылки: Data Race Detector, Context package

2. Управление памятью и производительность

Что проверяем: Понимание модели памяти Go: стек, куча, сборщик мусора, escape analysis. Что это, зачем, как влияет на производительность, умение бенчить, профилировать и оптимизировать код.

Критерии оценки:

Примеры вопросов/задач:

1. Теория: Когда переменная попадает на стек, а когда на кучу? Что такое escape analysis? Как компилятор принимает решение?

2. Практика: Даны два варианта функции — какой быстрее и почему?

   // Вариант 1
   func process1() *Result {
       r := Result{}
       return &r  // escapes to heap
   }
   
   // Вариант 2
   func process2() Result {
       r := Result{}
       return r  // может остаться на стеке
   }
   

3. Профилирование: Как найти, какая функция в вашем сервисе потребляет больше всего CPU/RAM? Опишите шаги использования pprof.

4. Бенчмарки: Напишите бенчмарк для функции конкатенации строк. Как убедиться, что компилятор не оптимизировал код (dead code elimination)? Что такое b.N/b.Loop() и как Go подбирает это значение?

5. Тонкая настройка GC: В каких случаях имеет смысл настраивать GOGC? Приведите пример сценария. Какие есть альтернативы настройке GC?

На что обращать внимание:

• Упоминает ли go build -gcflags="-m" для проверки escape analysis
• Знает ли про pprof (CPU, memory, goroutine)
• Понимает ли компромисс между производительностью и читаемостью
• Умеет ли оценить, стоит ли оптимизация затраченного времени
• Знает ли про sync.Pool для переиспользования объектов
• Упоминает ли benchstat как инструмент статистического анализа результатов

Полезные ссылки и материалы (Go 1.24-1.25):

• Go 1.24: новая реализация map на базе Swiss Tables (2-3% прирост производительности)
• Go 1.24: b.Loop() для защиты от dead code elimination в бенчмарках
• Статья: Бенчмарки и оптимизация в Go
• Официальное руководство по диагностике Go программ: Diagnostics

3. Работа с базами данных

Что проверяем: Практический опыт с PostgreSQL/MySQL из Go, понимание database/sql, lib/pq, pgx, sqlx — когда что использовать, знание про транзакции, уровни изоляции, пуллинг соединений, умение избежать типичных проблем (SQL инъекции, утечка соединений).

Критерии оценки:

Примеры вопросов/задач:

1. Теория: В чем разница между database/sql, pgx и sqlx? Когда что использовать? Какие преимущества дает pgx над pq?

2. Транзакции: Как правильно обернуть несколько операций в транзакцию в Go? Что делать при ошибке в середине транзакции? Покажите пример с rollback и commit.

3. Connection pooling: Как настроить размер пула соединений? Что такое MaxOpenConns, MaxIdleConns и ConnMaxLifetime? Как выбрать правильные значения для высоко-нагруженного сервиса?

4. Миграции: Какие инструменты для миграций знаете (например goose)? Как откатывать миграции? Как организовать миграции в production с минимальным простоем?

На что обращать внимание:

• Знает ли про context.Context в database/sql для таймаутов и отмены запросов
• Понимает ли prepared statements и защиту от SQL инъекций (параметризованные запросы)
• Может ли объяснить ACID и уровни изоляции (Read Uncommitted, Read Committed, Repeatable Read, Serializable)
• Упоминает ли про индексы, EXPLAIN ANALYZE для оптимизации запросов
• Знает ли про graceful shutdown для закрытия соединений с БД

Полезные ссылки и материалы:

• database/sql context support (доступен с Go 1.8+)
• pgx v5 — текущая мажорная версия, значительно быстрее database/sql
• Статья: Database/SQL Tutorial, pgx GitHub

4. Паттерны проектирования и архитектура

Что проверяем: Знание базовых паттернов (репозиторий, инъекция зависимостей, фабрика), понимание SOLID принципов применительно к Go, умение структурировать код (слоистая архитектура и чистая архитектура), опыт рефакторинга.

Критерии оценки:

Примеры вопросов/задач:

1. SOLID: Объясните принцип единственной ответственности. Приведите пример нарушения в Go-коде. Как его исправить?

2. Инъекция зависимостей: Как внедрять зависимости в Go, где располагать интерфейсы? Покажите на примере структуры с несколькими зависимостями.

3. Паттерн репозиторий: Зачем нужен? Как выглядит интерфейс репозитория для User? Какие методы должны быть? Что должно возвращаться при ошибках?

4. Архитектура: Как бы вы структурировали REST API сервис на Go? (handlers, services, repositories, models). Какие слои и зачем? Как будут зависеть друг от друга?

5. Рефакторинг: Даётся «God Object» (1000+ строк, 20+ методов, все в одном файле) — как разбить на модули? С чего начать? Какие метрики использовать для оценки качества рефакторинга?

На что обращать внимание:

• Использует ли интерфейсы для абстракций (инверсия контроля)
• Понимает ли принцип «принимает интерфейсы, возвращаем структуры»
• Знает ли про циклические зависимости и как их избежать
• Упоминает ли про package-oriented design
• Понимает ли компромиссы между простотой и гибкостью

Полезные ссылки и материалы:

• Effective Go — обязательное чтение для Middle
• Go Proverbs — философия языка
• Статья: Монолит vs микросервисы

5. HTTP и API дизайн

Что проверяем: Опыт построения REST API или gRPC сервисов, знание middleware, понимание graceful shutdown, rate limiting, аутентификация, авторизация, HTTP/2 особенности.

Критерии оценки:

Примеры вопросов/задач:

1. Лучшие практики REST: Как бы вы спроектировали CRUD API для блога? (ручки, HTTP методы, статус-коды). Какой метод будем использовать для получения списка постов? Для создания? Для обновления?

2. Middleware: Напишите middleware для логирования всех HTTP запросов (метод, URL, продолжительность, статус). Как передать ID запроса через цепочку middleware?

3. Graceful shutdown: Как корректно остановить HTTP сервер при получении SIGINT или SIGTERM, не оборвав существующие запросы?

4. Rate limiting: Как реализовать простой rate limiter на уровне приложения? (token bucket, sliding window). Где хранить состояние? Что возвращать клиенту при превышении лимита?

5. Аутентификация: JWT или сессии — плюсы и минусы каждого подхода? Где хранить JWT на клиенте? Как обрабатывать refresh tokens?

На что обращать внимание:

• Знает ли про context для передачи специфичных для запроса данных (user ID, request ID, трейсинг)
• Понимает ли идемпотентность HTTP методов (GET, PUT — идемпотентны, POST — нет)
• Упоминает ли CORS, HTTPS, заголовки (CSP, X-Frame-Options, HSTS)
• Знает ли про HTTP/2, HTTP/3 особенности в Go (переиспользование соединений)
• Понимает ли versioning (через URL или через заголовок)

Полезные ссылки и материалы:

• net/http: https://pkg.go.dev/net/http
• Go 1.22+ улучшенный роутинг (ServeMux паттерны с поддержкой {id} плейсхолдера)
• Graceful shutdown пример: httpServer.Shutdown(ctx)

6. Тестирование в Go

Что проверяем: Практика написания юнит-тестов, табличные тесты (идиома Go), использование моков (testify/mock, gomock), интеграционные тесты, понимание покрытия тестами и ограничений.

Критерии оценки:

Примеры вопросов/задач:

1. Табличные тесты: Напишите табличные тесты для функции, которая валидирует email адреса. Как организовать тестовые случаи? Что делать с негативными кейсами?

2. Моки: Как протестировать сервис, который ходит в БД и внешний API, не поднимая реальные зависимости? (интерфейсы + моки). Покажите пример с testify/mock.

3. Покрытие: Как измерить покрытие тестами? Какой процент покрытия считается хорошим? Почему 100% покрытия не гарантирует отсутствие багов?

4. Интеграционные тесты: Как бы вы тестировали HTTP сервер с реальной БД? Когда имеет смысл писать интеграционные тесты, а когда достаточно юнит-теста?

На что обращать внимание:

• Использует ли testify или пишет чистый testing (оба подхода валидны)
• Знает ли про t.Parallel() для параллельных тестов и когда его не стоит использовать
• Понимает ли разницу между unit, integration и e2e тестами
• Упоминает ли про testcontainers для интеграционных тестов с реальными БД
• Знает ли про бенчмарки и их связь с производительностью

Полезные ссылки и материалы:

• Go 1.24: T.Context() и B.Context() для контекста в тестах с автоматической отменой
• testing package: https://pkg.go.dev/testing
• Статья: Бенчмарки и оптимизация в Go

7. Обработка ошибок и устойчивость

Что проверяем: Понимание обработки ошибок в Go (error как значение, не исключение), error wrapping (errors.Is, errors.As) с Go 1.13+, retry patterns, exponential backoff, circuit breaker, graceful degradation и fallback механизмы.

Критерии оценки:

Примеры вопросов/задач:

1. Error wrapping: В чем разница между fmt.Errorf("%w", err) и fmt.Errorf("%v", err)? Когда использовать каждый вариант?

2. Sentinel errors: Что это? Приведите пример из стандартной библиотеки (io.EOF, sql.ErrNoRows).

3. Retry pattern: Реализуйте функцию retry с экспоненциальным backoff и максимальным количеством попыток. Как обрабатывать context cancellation во время retry?

4. Circuit breaker: Что это и когда применять? Приведите пример сценария (внешний API недоступен). Какие состояния у circuit breaker?

5. Паника или ошикба: Когда в Go использовать panic, а когда возвращать error? Что делать с panic из сторонних библиотек?

На что обращать внимание:

• Знает ли errors.Is() и errors.As() (Go 1.13+) и разницу между ними
• Понимает ли context.Cause() для извлечения причины отмены (Go 1.20+)
• Упоминает ли fallback механизмы (кэширование старых данных при недоступности API)
• Может ли объяснить fail-fast и fault-tolerant подходы, когда и что применять
• Знает ли про библиотеки для retry (cenkalti/backoff, avast/retry-go)
• Понимает ли кастомные error типы и когда их использовать

Полезные ссылки и материалы:

• errors package: https://pkg.go.dev/errors
• Go 1.23: context.AfterFunc() для cleanup операций
• Go blog: Working with Errors in Go 1.13

8. Observability и диагностика

Что проверяем: Структурированные логи (slog в Go 1.21+), метрики (Prometheus), трейсинг (OpenTelemetry), health checks, readiness probes (для Kubernetes), понимание трёх столпов наблюдаемости.

Критерии оценки:

Примеры вопросов/задач:

1. Структурированные логи: Чем отличается от обычного текстового? Покажите пример с slog. Какие уровни логирования использовать и для чего?

2. Метрики: Какие метрики вы бы собирали для HTTP сервиса? (latency, throughput, errors). В чем разница между counter, gauge, histogram, summary?

3. Health checks: Как реализовать /health (liveness) и /ready (readiness) endpoints для Kubernetes? В чем разница? Что проверять в каждом?

4. Трейсинг: Что такое trace, span, trace ID? Зачем нужно распределенный трейсинг? Как передавать trace context между сервисами?

5. Уровни логов: Когда использовать DEBUG vs INFO vs WARN vs ERROR? Что логировать в production, а что только в dev/stage среде?

На что обращать внимание:

• Знает ли slog (стандартная библиотека с Go 1.21)
• Понимает ли типы метрик в Prometheus и когда какой использовать
• Может ли объяснить сэмплинг в трейсинге (не трейсить 100% запросов для снижения издержек)
• Знает ли про три столпа наблюдаемости (logs, metrics, traces)
• Понимает ли компромиссы наблюдаемости (компромисс издержек и прозрачности)

Полезные ссылки и материалы:

• пакет slog: https://pkg.go.dev/log/slog
• OpenTelemetry Go: https://opentelemetry.io/docs/languages/go/
• Prometheus client: https://github.com/prometheus/client_golang

9. Декомпозиция задач и оценка сроков

Что проверяем: Умение разбить задачу на подзадачи, реалистичная оценка с учетом рисков, понимание что «быстро» не равно «хорошо», коммуникация при сдвиге сроков, понимание треугольника scope-time-quality.

Критерии оценки:

Примеры вопросов/задач:

1. Практика: Задача — «Добавить фильтрацию пользователей по ролям в REST API». Разбейте на подзадачи и оцените время на каждую. Что может пойти не так?

2. Риски: Какие риски вы учитываете при оценке задачи? (неопределенность, зависимости от других команд, технический долг, незнакомые технологии)

3. Неопределенность: Как оценивать задачу, если не знаете технологию или предметную область? (spike, time-boxing, исследование, proof of concept)

4. MVP мышление: Как бы вы приоритизировали функции для MVP версии продукта? Что включить в первую итерацию, что отложить на v1, что на v2?

5. Задержка: Понимаете, что не успеваете в срок. Что делаете? (сообщить заранее, предложить урезать объём, перенести дедлайн, обосновать решение)

На что обращать внимание:

• Задает ли уточняющие вопросы перед оценкой (формализация требований)
• Упоминает ли тестирование, документацию, код-ревью как часть работы (а не только кодинг)
• Понимает ли разницу между прогнозом и обещанием
• Может ли объяснить компромисс между объёмом работы и сроками (треугольник scope-time-quality)
• Понимает ли, что чем дальше в будущее, тем больше неопределенность
• Закладывает ли буфферы для непредвиденных проблем

10. Коммуникация с заказчиком

Что проверяем: Умение выявлять реальные требования (не принимать постановку на веру), управление ожиданиями, объяснение технических ограничений нетехническому человеку, проактивность в коммуникации, техника «5 почему».

Критерии оценки:

Примеры вопросов/ситуаций:

1. Выявление требований: Заказчик говорит «Мне нужна быстрая система». Какие вопросы зададите? (быстрая — это сколько мс? для какого сценария? сколько пользователей? что критичнее — задержка или пропускная способность?)

2. Объяснение ограничений: Как объясните, что «добавить эту кнопку» займет неделю? (рефакторинг, тесты, интеграции, ревью безопасности, деплой)

3. Альтернативы: Заказчик хочет фичу за 2 дня, но это нереалистично. Ваши действия? (предложить упрощенную версию, фича-тогглы, инкременты ценности)

4. Демо: Как проводите демонстрацию новой фичи? (готовите сценарий, подготовленные данные, фокус на ценности, а не на технических деталях)

5. Обратная связь: Заказчик недоволен результатом. Как реагируете? (слушаем, уточняем ожидания, предлагаем улучшения, не защищаемся)

На что обращать внимание:

• Использует ли технику «5 почему» для выявления причин запроса (почему нужна эта фича? какую проблему решаем?)
• Может ли объяснить техдолг без жаргона (не «рефакторинг монолита», а «ускорим добавление новых фич»)
• Предлагает ли поэтапную доставку ценности вместо «всё разом» (показывать прогресс раньше, для ранней обратной связи)
• Понимает ли разницу между «что хочет заказчик» и «что ему реально нужно»
• Упоминает ли про циклы обратной связи и итеративность
• Умеет ли сказать «нет» с обоснованием и альтернативами

11. Приоритизация и фокус на ценности

Что проверяем: Понимание разницы MVP и полнофункциональной версии, умение отказаться от over-engineering, выбор решения исходя из бизнес-целей, понимание компромисса time-to-market и совершенства кода, YAGNI принцип.

Критерии оценки:

Примеры вопросов/ситуаций:

1. MVP: Что вы включите в MVP для интернет-магазина? Что отложите на v2? (каталог, корзина, оплата — обязательно; избранное, отзывы, рекомендации — v2)

2. Техдолг: Когда можно взять задачи на техдолг (быстрая доставка критична, конкурентное преимущество), а когда нельзя (платежная система, безопасность, комплаенс)?

3. Over-engineering: Приведите пример, когда вы отказались от «красивого» решения в пользу простого. Почему? Какие были компромиссы?

4. Компромиссы: Микросервисы или монолит — как принять решение для стартапа из 5 человек? (монолит проще, быстрее MVP, меньше операционных издержек)

5. Бизнес-ценность: Как оценить, принесет ли оптимизация (ускорение на 100ms) бизнес-ценность? (зависит от сценария: страница оплаты — критично, админ-панель — не важно)

На что обращать внимание:

• Понимает ли что «хорошо» важнее «идеально» (80/20 правило, парето принцип)
• Может ли объяснить, что каждая неделя задержки = упущенная выручка
• Упоминает ли про циклы обратной связи и итеративную разработку (лучше запустить простое и улучшить, чем долго делать идеальное)
• Понимает ли YAGNI (You Aren’t Gonna Need It) — не делать того, что не нужно сейчас
• Может ли обосновать выбор через бизнес-метрики, а не только через технические критерии

12. Ревью кода и командная работа

Что проверяем: Опыт ревью кода (как автор и как ревьювер), конструктивная критика кода, менторинг джуниоров, работа в распределенной команде и CI/CD интеграции.

Критерии оценки:

Примеры вопросов/ситуаций:

1. Процесс кодревью: Как вы проводите ревью? На что обращаете внимание? (логика, тесты, читаемость, безопасность, производительность)

2. Конструктивная критика: Что скажете на плохой код, не демотивируя автора? (фокус на код, не на человека; объяснить почему; предложить альтернативы)

3. Менторинг: Джуниор написал код с проблемами. Как поступите? (объясняете почему проблема, даете ссылки на лучшие практики, примеры)

4. Конфликт: Коллега не согласен с вашим комментарием в ревью. Ваши действия? (обсуждаем, приводим аргументы, идем на компромисс, эскалируем если нужно)

5. Лучшие практики: Какие практики ревью вы считаете обязательными? (автоматизация, чек-листы, фокус на важное, асинхронность)

На что обращать внимание:

• Упоминает ли про автомтизаицю (golangci-lint, staticcheck, CI/CD пайплайны) — автоматизация рутины
• Понимает ли разницу между мелочами и критичными замечаниями (логика, безопасность)
• Знает и понимаем асинхронную коммуникацию в распределенных командах (подробные комментарии в PR, не «давай созвонимся»)

Теги:

• golang
• management