Senior Go Interview Prep

- Core Go: https://go.vbloher.org/docs/01-core-go/
- Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/
- Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/
- Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/
- Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/
- Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/
- Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/
- panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/
- Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/
- Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/
- Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/
- Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/
- Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/
- Concurrency: https://go.vbloher.org/docs/02-concurrency/
- sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/
- Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/
- Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/
- Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/
- Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/
- sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/
- context: https://go.vbloher.org/docs/02-concurrency/context/
- Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/
- sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/
- sync.Once: https://go.vbloher.org/docs/02-concurrency/once/
- Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/
- Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/
- Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/
- select: https://go.vbloher.org/docs/02-concurrency/select/
- sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/
- Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/
- Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/
- Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/
- Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/
- Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/
- GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/
- Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/
- Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/
- Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/
- pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/
- Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/
- Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/
- Тестирование: https://go.vbloher.org/docs/04-testing/
- testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/
- Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/
- Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/
- Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/
- Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/
- Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/
- Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/
- Backend: https://go.vbloher.org/docs/05-backend/
- Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/
- Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/
- gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/
- JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/
- Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/
- net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/
- OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/
- OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/
- Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/
- REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/
- Сети и протоколы: https://go.vbloher.org/docs/06-networking/
- Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/
- DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/
- Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/
- TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/
- TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/
- UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/
- WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/
- Базы данных: https://go.vbloher.org/docs/07-databases/
- Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/
- Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/
- Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/
- Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/
- MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/
- Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/
- Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/
- Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/
- Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/
- Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/
- Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/
- Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/
- Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/
- CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/
- Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/
- Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/
- Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/
- Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/
- Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/
- Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/
- Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/
- Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/
- RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/
- Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/
- Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/
- Observability: https://go.vbloher.org/docs/09-observability/
- Grafana: https://go.vbloher.org/docs/09-observability/grafana/
- Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/
- OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/
- Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/
- SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/
- Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/
- Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/
- System Design: https://go.vbloher.org/docs/10-system-design/
- Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/
- Chat System: https://go.vbloher.org/docs/10-system-design/chat/
- Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/
- Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/
- Order Service: https://go.vbloher.org/docs/10-system-design/order-service/
- Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/
- Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/
- URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/
- DevOps: https://go.vbloher.org/docs/11-devops/
- CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/
- Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/
- Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/
- GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/
- Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/
- Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/
- Алгоритмы: https://go.vbloher.org/docs/12-algorithms/
- Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/
- Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/
- Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/
- Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/
- Behavioral: https://go.vbloher.org/docs/13-behavioral/
- Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/
- Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/
- Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/
- Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/


> Модуль: Тестирование · Уровень: Middle+/Senior

## TL;DR
Table-driven тесты — идиоматичный для Go способ покрыть множество входов/выходов одной логикой проверки: срез структур-кейсов + цикл. `t.Run` создаёт subtests — изолированные узлы дерева тестов с собственным именем, фильтрацией (`-run Foo/case_x`) и независимым fail. `t.Parallel()` помечает тест как параллельный: он приостанавливается, пока не завершатся последовательные тесты родителя, затем запускается одновременно с другими параллельными. Главная историческая ловушка — захват переменной цикла замыканием (`tc`); в Go < 1.22 это давало все кейсы с последним значением. В 1.22+ переменная цикла per-iteration, ловушка ушла, но на собеседовании про неё всё равно спрашивают.

## Теория

### Базовая форма
```go
func TestSplit(t *testing.T) {
    tests := []struct {
        name  string
        input string
        sep   string
        want  []string
    }{
        {name: "simple", input: "a,b,c", sep: ",", want: []string{"a", "b", "c"}},
        {name: "no_sep", input: "abc", sep: ",", want: []string{"abc"}},
        {name: "empty", input: "", sep: ",", want: []string{""}},
        {name: "trailing", input: "a,", sep: ",", want: []string{"a", ""}},
    }

    for _, tc := range tests {
        t.Run(tc.name, func(t *testing.T) {
            got := strings.Split(tc.input, tc.sep)
            if !reflect.DeepEqual(got, tc.want) {
                t.Errorf("Split(%q, %q) = %#v, want %#v", tc.input, tc.sep, got, tc.want)
            }
        })
    }
}
```

Ключевые элементы:
- **`name`** в каждом кейсе — без него subtests получают автогенерируемые имена `#0`, `#1`, и при падении непонятно, какой кейс упал. Имя с пробелами превращается в `_` в пути теста.
- **Карта vs срез.** Срез сохраняет порядок и детерминирован. `map[string]struct{...}` иногда используют, чтобы имя кейса было ключом, но порядок итерации рандомизирован — это плюс для выявления неявных зависимостей между кейсами, но минус для воспроизводимости вывода. Для большинства случаев берите срез.

### Subtests: зачем `t.Run`
`t.Run(name, func(t *testing.T))` запускает вложенный тест синхронно (если внутри нет `t.Parallel`) и возвращает `bool` — прошёл ли. Что это даёт:
- **Изоляция падений.** Без subtests `t.Fatal` в середине цикла прервёт весь тест и оставшиеся кейсы не выполнятся. С `t.Run` падение одного кейса не мешает остальным — `t.Fatalf` завершает только горутину subtest.
- **Точечный запуск.** `go test -run 'TestSplit/trailing'` — регэксп по сегментам пути, разделённым `/`. `-run 'TestSplit/^empty$'` — точное совпадение.
- **Setup/teardown на группу.** Можно вкладывать `t.Run` в `t.Run` и делать общий setup на уровне группы.

```go
func TestUserService(t *testing.T) {
    db := setupDB(t)
    t.Cleanup(func() { db.Close() }) // вызовется после ВСЕХ subtests

    t.Run("create", func(t *testing.T) { /* ... */ })
    t.Run("update", func(t *testing.T) { /* ... */ })
}
```

`t.Cleanup` — предпочтительнее `defer` в setup-хелперах: он привязан к жизненному циклу `*testing.T` и корректно работает с subtests и параллельностью (LIFO порядок).

### Параллельные тесты
```go
func TestParallel(t *testing.T) {
    tests := []struct {
        name string
        in   int
        want int
    }{
        {"a", 1, 2},
        {"b", 2, 4},
    }
    for _, tc := range tests {
        tc := tc // НЕ нужно в Go 1.22+, обязательно в <1.22
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            got := double(tc.in)
            if got != tc.want {
                t.Errorf("double(%d) = %d, want %d", tc.in, got, tc.want)
            }
        })
    }
}
```

**Как работает `t.Parallel()`:**
1. Когда subtest вызывает `t.Parallel()`, он немедленно **приостанавливается** и возвращает управление родителю.
2. Родительская функция дорабатывает свой код (цикл запускает все subtests, каждый паркуется на `t.Parallel`), затем **родитель возвращается**.
3. Только после возврата функции-родителя рантайм **возобновляет** все припаркованные параллельные subtests одновременно.

Это объясняет классический баг: setup, размещённый ПОСЛЕ цикла в родителе, или ресурсы, которые родитель освобождает по `defer`, исчезнут к моменту реального запуска параллельных детей:

```go
func TestBad(t *testing.T) {
    srv := startServer()
    defer srv.Close() // ВЫПОЛНИТСЯ до запуска параллельных subtests!
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            // srv уже закрыт здесь
        })
    }
}
```
Решение: `t.Cleanup(srv.Close)` вместо `defer`, либо обернуть параллельную группу во внешний `t.Run`, который не вернётся, пока дети не закончат.

**Степень параллелизма** регулируется `-parallel N` (по умолчанию `GOMAXPROCS`). Тесты из разных пакетов и так идут параллельно (`-p N`), `t.Parallel` — про параллельность внутри одного пакета.

### Ловушка с замыканием (loop variable capture)
До Go 1.22 переменная цикла `for _, tc := range tests` была **одной** на весь цикл. При `t.Parallel` тело subtest исполнялось ПОСЛЕ завершения цикла, когда `tc` уже держала последний элемент — все параллельные кейсы проверяли один и тот же (последний) вход. Лечилось `tc := tc` (shadowing) или `tt := tc` внутри цикла, либо передачей через параметр `t.Run(tc.name, func(...) { run(t, tc) })`.

В **Go 1.22+** семантика изменилась: переменная цикла создаётся заново на каждой итерации (`GOEXPERIMENT=loopvar` стал дефолтом). Строчка `tc := tc` теперь no-op. Но: ловушка проявлялась только при `t.Parallel` или при сохранении замыканий за пределы итерации — в синхронном table-driven её не было и до 1.22.

На собеседовании ожидается, что вы:
- знаете, что ловушка была и почему (синхронный vs отложенный запуск),
- знаете, что 1.22 её устранил для loop variables,
- понимаете, что аналогичная проблема всё ещё есть с `defer` в цикле, с захватом любых не-loop переменных, и с `errgroup`/`go func(){...}()`.

## Подводные камни / gotchas
- **`defer` после цикла в параллельных тестах** освобождает ресурс раньше времени. Используйте `t.Cleanup`.
- **`t.Fatal` из другой горутины** не работает корректно — `FailNow` обязан вызываться из горутины самого теста. В параллельном/конкурентном коде собирайте ошибки и проверяйте в основной горутине теста, либо используйте `t.Error` (он горутино-безопасен для пометки fail, но всё равно вызывать его из чужой горутины — ошибка).
- **Общее изменяемое состояние между параллельными кейсами** (общая мапа, счётчик, глобал) → гонки. Запускайте `-race`.
- **Пустое имя кейса или дубликаты имён.** Дубликаты получают суффикс `#01`. Делайте имена уникальными.
- **Имена с `/` и пробелами** ломают `-run` фильтрацию: пробел → `_`, а `/` интерпретируется как разделитель уровней.
- **Слишком толстый кейс.** Когда в структуре кейса появляются поля-функции (`setup func()`, `assert func()`), table-driven вырождается — проще написать отдельные тесты. Таблица хороша для гомогенной логики.
- **`reflect.DeepEqual` на временах/флоатах/protobuf** даёт ложные несовпадения. Используйте `cmp.Diff` с опциями (`cmpopts.EquateApprox`, `protocmp.Transform`).

## Вопросы на собеседовании

**В:** В чём была ловушка с переменной цикла в параллельных table-driven тестах и как её чинили?
**О:** До Go 1.22 переменная `tc` была одна на весь цикл. `t.Parallel()` откладывает выполнение тела subtest до возврата родителя, к этому моменту `tc` держит последний элемент — все параллельные кейсы тестировали последний вход. Чинили локальной копией `tc := tc` или передачей значения параметром. В 1.22+ переменная цикла per-iteration, ловушка устранена.

**В:** Объясни порядок выполнения при `t.Parallel()`.
**О:** Вызов `t.Parallel()` паркует subtest и возвращает управление родителю. Родитель доводит свою функцию до конца (запустив и припарковав всех детей) и возвращается. Только после возврата родителя рантайм одновременно возобновляет все параллельные subtests. Поэтому ресурсы, освобождённые через `defer` в родителе, к моменту запуска детей уже мертвы.

**В:** Когда использовать срез кейсов, а когда мапу?
**О:** Срез — детерминированный порядок, читаемый вывод, дефолтный выбор. Мапа — рандомизированный порядок итерации, что помогает ловить скрытые зависимости между кейсами, и имя кейса становится ключом. Минус мапы — нестабильный порядок вывода и невозможность кейсов, зависящих от порядка.

**В:** Чем `t.Cleanup` лучше `defer` в тестах?
**О:** `t.Cleanup` привязан к жизненному циклу `*testing.T`/`*testing.B`, корректно отрабатывает с subtests и параллельностью (срабатывает после завершения всех зависимых параллельных детей), вызывается в LIFO. `defer` в родителе исполняется при возврате функции — то есть до запуска параллельных subtests.

**В:** Как точечно запустить один кейс table-driven теста?
**О:** `go test -run 'TestName/case_name'`. Аргумент — регэксп по сегментам пути теста, разделённым `/`. Для точного совпадения — якоря: `-run 'TestName/^case_name$'`. Пробелы в имени кейса заменяются на `_`.

**В:** Почему нельзя вызывать `t.Fatal` из горутины внутри теста?
**О:** `t.FatalNow`/`t.Fatal` вызывает `runtime.Goexit` на текущей горутине, помечая тест проваленным. Если вызвать из не-тестовой горутины, завершится только она, а тест продолжит выполнение с неопределённым состоянием. Документация требует вызывать `FailNow`-семейство только из горутины теста. Из других горутин — `t.Error` + синхронизация (через канал/WaitGroup) и проверка в основной горутине.

**В:** Когда table-driven перестаёт быть удачным выбором?
**О:** Когда кейсы гетерогенны и в структуру лезут поля-функции setup/assert, ветвления по типу кейса — логика проверки перестаёт быть общей. Тогда читаемее отдельные именованные тесты или хелперы. Таблица оптимальна для одинаковой проверки разных данных.

## На что копают на senior+
- **Понимание планировщика тестов:** дерево T, как Parallel взаимодействует с Cleanup, почему cleanup параллельной группы ждёт детей.
- **Воспроизводимость и флаки:** детерминированность порядка, отсутствие общего состояния, обязательный `-race` на параллельных тестах в CI.
- **Сравнение значений:** отказ от `reflect.DeepEqual` в пользу `go-cmp` с опциями, кастомные `Equal` методы, диффы вместо «got X want Y».
- **Генерация кейсов:** комбинаторные таблицы, property-based на стыке с fuzzing, golden-кейсы.
- **Масштаб:** организация больших таблиц (вынос в `testdata`, генерация), баланс между «одна таблица на всё» и читаемостью, именование как часть контракта (`-run` в CI-шардинге).