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
Fuzzing — автоматическая генерация входных данных, нацеленная на расширение покрытия кода (coverage-guided), чтобы найти входы, на которых код паникует, виснет или нарушает инварианты. С Go 1.18 fuzzing встроен в `testing`: функция `FuzzXxx(f *testing.F)`, seed corpus через `f.Add`, тело — `f.Fuzz(func(t *testing.T, ...){...})`. Движок мутирует входы, отслеживая покрытие; найденный падающий вход автоматически минимизируется и сохраняется в `testdata/fuzz/FuzzXxx/` как регрессионный кейс. Лучше всего ловит панику на парсерах/декодерах, нарушения round-trip инвариантов (encode→decode) и расхождения с reference-реализацией (differential). Запуск: `go test -fuzz=FuzzXxx`; без `-fuzz` fuzz-тест прогоняет только seed corpus как обычный тест.

## Теория

### Структура fuzz-теста
```go
func FuzzParseQuery(f *testing.F) {
    // seed corpus — примеры валидных/интересных входов
    f.Add("a=1&b=2")
    f.Add("")
    f.Add("key=%20value")

    f.Fuzz(func(t *testing.T, raw string) {
        // не должно паниковать ни на каком входе
        v, err := ParseQuery(raw)
        if err != nil {
            return // ошибка — ок, паника/виснет — нет
        }
        _ = v
    })
}
```
- **`f.Add(args...)`** добавляет seed — стартовые входы. Типы аргументов `f.Add` ДОЛЖНЫ совпадать с типами параметров `f.Fuzz` (после `*testing.T`).
- **`f.Fuzz(fn)`** — фаззинг-таргет. Первый параметр всегда `*testing.T`, дальше — фаззируемые аргументы.
- **Поддерживаемые типы аргументов:** `[]byte`, `string`, `int`/`int8..64`, `uint`/..., `float32/64`, `bool`, `rune`, `byte`. Структуры/срезы напрямую нельзя — кодируйте сложные входы в `[]byte` и десериализуйте внутри.

### Два режима запуска
1. **Без `-fuzz`** (обычный `go test`): fuzz-функция выполняется как обычный тест — прогоняется **только seed corpus** (из `f.Add` + файлов в `testdata/fuzz/...`). Это делает fuzz-тесты частью CI как регрессионные тесты, без бесконечной генерации.
2. **С `-fuzz`** (`go test -fuzz=FuzzParseQuery`): запускается движок мутаций, генерирующий новые входы бесконечно (или до `-fuzztime=30s` / `-fuzztime=1000x`). Работает с одним пакетом и одной fuzz-функцией за раз.

```bash
go test -fuzz=FuzzParseQuery -fuzztime=30s ./...
```

### Corpus: seed vs generated
- **Seed corpus** — то, что вы пишете руками (`f.Add`) и кладёте в `testdata/fuzz/FuzzXxx/`. Версионируется в git, обязателен в CI.
- **Generated corpus** — кэш «интересных» входов (расширивших покрытие), который движок копит в `$GOCACHE/fuzz/`. Не версионируется, локален, переживает между прогонами на машине разработчика.
- Когда фаззер находит падение, он **минимизирует** вход (урезает до минимального воспроизводящего) и сохраняет файл в `testdata/fuzz/FuzzXxx/<hash>`. Этот файл — теперь регрессионный кейс: его нужно закоммитить, и при следующем обычном `go test` он автоматически прогонится.

Формат файла corpus:
```
go test fuzz v1
string("a=1&b=\x00")
```

### Что искать фаззингом: классы инвариантов
**1. Отсутствие паники / зависания** — базовый минимум для любого парсера, декодера, входа из недоверенной сети.

**2. Round-trip (encode/decode идемпотентность):**
```go
func FuzzMarshalRoundTrip(f *testing.F) {
    f.Add([]byte(`{"a":1}`))
    f.Fuzz(func(t *testing.T, data []byte) {
        var v Config
        if err := json.Unmarshal(data, &v); err != nil {
            return
        }
        out, err := json.Marshal(v)
        if err != nil {
            t.Fatalf("marshal of valid value failed: %v", err)
        }
        var v2 Config
        if err := json.Unmarshal(out, &v2); err != nil {
            t.Fatalf("re-unmarshal failed: %v", err)
        }
        if !reflect.DeepEqual(v, v2) {
            t.Errorf("round-trip mismatch: %#v != %#v", v, v2)
        }
    })
}
```

**3. Differential (сравнение с эталоном):** новая оптимизированная реализация должна давать тот же результат, что старая/reference на любом входе.
```go
f.Fuzz(func(t *testing.T, in []byte) {
    if got, want := FastParse(in), SlowReferenceParse(in); !bytes.Equal(got, want) {
        t.Errorf("divergence on %q", in)
    }
})
```

**4. Инварианты предметной области:** результат `Sort` отсортирован и содержит ту же мультимножество элементов; после `Validate` всегда выполняется некий предикат, и т.п.

### Минимизация
При падении движок пытается сократить вход, сохраняя факт падения, — это и про размер (меньше байт), и про «простоту» (печатные символы). Минимизированный кейс гораздо удобнее для отладки. Можно отключить/настроить через `-fuzzminimizetime`.

### Интеграция в CI
- **Seed corpus** прогоняется любым `go test ./...` — бесплатная регрессия.
- **Активный fuzzing** долгий и недетерминированный по времени → выносят в отдельный nightly/scheduled job с `-fuzztime`, а не в основной PR-pipeline. Найденные кейсы коммитятся обратно в `testdata`.
- OSS-Fuzz и подобные сервисы дают непрерывный фаззинг с откормленным corpus.

## Подводные камни / gotchas
- **Типы `f.Add` обязаны совпадать с сигнатурой `f.Fuzz`** — иначе паника при запуске.
- **Ограниченный набор фаззируемых типов.** Сложные структуры кодируйте в `[]byte`/`string` и парсите внутри; иначе придётся самому конструировать вход из примитивов.
- **`-fuzz` гоняет ровно одну функцию в одном пакете.** Нельзя зафаззить весь репозиторий разом.
- **Generated corpus не версионируется** — он в `GOCACHE`. На другой машине/в CI его нет; воспроизводимость держится на seed + закоммиченных кейсах из `testdata`.
- **Недетерминированность и время.** Fuzzing без `-fuzztime` бесконечен. Без бюджета времени он не подходит как блокирующий шаг PR.
- **Таргет должен быть детерминированным и без сайд-эффектов** (сеть, файлы, время, рандом, общее состояние). Иначе «падение» невоспроизводимо и движок не сможет минимизировать.
- **Медленный таргет = мало итераций.** Фаззинг эффективен на тысячах входов/сек; тяжёлый I/O в таргете убивает coverage-рост.
- **Coverage-guided ≠ всезнающий.** Фаззер хорош на байтовых/строковых входах с богатой структурой ветвлений; для глубоких семантических инвариантов нужны хорошие seed и проверки (assertions) внутри таргета — без них он лишь проверяет «не паникует».
- **OOM/таймауты как «находки».** Аллокация по размеру входа без лимита приведёт к OOM на больших мутациях — иногда это реальный баг (DoS), иногда нужно ограничить размер входа в начале таргета.

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

**В:** Чем fuzzing отличается от property-based и table-driven тестов?
**О:** Table-driven проверяет конкретные заранее заданные входы. Property-based проверяет инварианты на случайных входах из заданного генератора. Fuzzing — это coverage-guided генерация: движок мутирует входы, отслеживая покрытие кода, чтобы целенаправленно достигать новых веток и находить crash-входы. На практике Go-фаззинг совмещает оба: вы задаёте инварианты (как в property-based), а движок умно генерирует входы.

**В:** Что происходит при обычном `go test` без флага `-fuzz`?
**О:** Fuzz-функция выполняется как обычный тест и прогоняет только seed corpus: входы из `f.Add` и файлы в `testdata/fuzz/FuzzXxx/`. Генерация новых входов не запускается. Это делает найденные ранее crash-кейсы регрессионными тестами в CI.

**В:** Где живёт corpus и что коммитить в git?
**О:** Seed corpus (`f.Add` + `testdata/fuzz/...`) версионируется. Generated corpus движок кэширует в `$GOCACHE/fuzz` и его не коммитят. Когда фаззер находит падение, он минимизирует вход и кладёт файл в `testdata/fuzz/FuzzXxx/` — этот файл нужно закоммитить как регрессию.

**В:** Какие классы багов хорошо ловит fuzzing?
**О:** Паники и зависания на недоверенном входе (парсеры, декодеры), нарушения round-trip (encode→decode≠original), расхождения с эталонной реализацией (differential), нарушения доменных инвариантов (сортировка, валидация). Плюс OOM/DoS на неограниченных по размеру входах.

**В:** Какие типы можно фаззить и что делать со сложными входами?
**О:** Примитивы: `[]byte`, `string`, целые/беззнаковые, `float32/64`, `bool`, `rune`, `byte`. Структуры напрямую нельзя — кодируют сложный вход в `[]byte`/`string` и десериализуют внутри таргета, либо собирают из нескольких примитивных аргументов.

**В:** Почему fuzz-таргет должен быть детерминированным?
**О:** Движку нужно надёжно воспроизводить падение, чтобы минимизировать вход и сохранить регрессию. Недетерминизм (сеть, время, рандом, общее состояние, конкурентность) делает падение невоспроизводимым и ломает минимизацию.

**В:** Как встроить fuzzing в CI без бесконечного прогона?
**О:** В PR-pipeline гонять только seed corpus обычным `go test` (регрессия, быстро). Активный фаззинг с `-fuzztime` вынести в nightly/scheduled job или внешний сервис (OSS-Fuzz), а найденные кейсы коммитить обратно в `testdata`.

## На что копают на senior+
- **Дизайн таргета:** какие инварианты выбрать (round-trip, differential, доменные), как сделать таргет детерминированным и быстрым, как ограничить размер входа против OOM.
- **Coverage-guided внутри:** понимание, что движок инструментирует код и оптимизирует покрытие; почему seed corpus критичен для проникновения в глубокие ветки.
- **Corpus management:** разделение seed/generated, версионирование регрессий, кэш в GOCACHE, перенос corpus между машинами.
- **Интеграция:** место фаззинга в pipeline, nightly vs PR, OSS-Fuzz, бюджеты времени, триаж находок.
- **Сравнение инструментов:** нативный go-fuzz vs исторический dvyukov/go-fuzz, libFuzzer-подход; когда фаззинг бессилен (семантика без хороших assertions).
- **Безопасность:** фаззинг как защита для всего, что парсит недоверенный вход (сетевые протоколы, форматы файлов, десериализация).