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/


> Модуль: Concurrency · Уровень: Senior

## TL;DR
`sync.Cond` — условная переменная: горутина под захваченным мьютексом вызывает `Wait`, чтобы заснуть до тех пор, пока другая горутина не вызовет `Signal` (разбудить одну) или `Broadcast` (разбудить всех). Нужна редко: почти всё решается каналами. Реальная ниша — широковещательное пробуждение многих ожидающих по изменению **разделяемого состояния**, где каналы неудобны. `Wait` **обязан** вызываться в цикле проверки условия из-за spurious-подобных пробуждений и гонок.

## Теория

### Контракт
```go
c := sync.NewCond(&sync.Mutex{})

// Ожидающая сторона
c.L.Lock()
for !condition() {   // ВСЕГДА в цикле, не if
    c.Wait()         // атомарно: Unlock(L) + park; при пробуждении: Lock(L)
}
useState()
c.L.Unlock()

// Сигнализирующая сторона
c.L.Lock()
changeState()
c.L.Unlock()
c.Signal()          // или c.Broadcast()
```

- `Wait()` атомарно отпускает мьютекс и паркует горутину; при пробуждении **снова захватывает** мьютекс перед возвратом. Поэтому Wait вызывается строго под Lock.
- `Signal()` будит **одну** ожидающую горутину (если есть).
- `Broadcast()` будит **все** ожидающие горутины.
- Сигнал/Broadcast можно вызывать с захваченным мьютексом или без — но менять защищаемое состояние нужно под мьютексом.

### Почему `for`, а не `if`
После пробуждения и повторного захвата мьютекса условие **может уже не выполняться**:
- между пробуждением и захватом мьютекса другая горутина могла «перехватить» состояние (например, при Broadcast разбудили всех, но ресурс достался первому);
- возможны нежелательные ранние пробуждения.

Поэтому `Wait` всегда внутри `for !condition()`: проснулись → проверили условие → если не выполнено, снова Wait. Это инвариант, нарушение которого — классический баг.

### Устройство под капотом
```go
type Cond struct {
    noCopy  noCopy
    L       Locker         // обычно *Mutex
    notify  notifyList     // список ожидающих в рантайме
    checker copyChecker    // ловит копирование Cond
}
```
- `notifyList` — структура рантайма с двумя счётчиками-тикетами (`wait`, `notify`) и списком парковки.
- `Wait`: берёт «тикет» (`runtime_notifyListAdd`), отпускает мьютекс, паркуется (`runtime_notifyListWait`), при пробуждении захватывает мьютекс.
- `Signal`/`Broadcast`: `runtime_notifyListNotifyOne`/`NotifyAll` пробуждают горутины по тикетам. Тикеты гарантируют, что сигнал не «потеряется» для уже добавленной в список горутины и не разбудит будущую.
- `copyChecker` хранит адрес самого Cond и паникует, если обнаруживает копирование (несовпадение адреса).

### Cond против каналов
Закрытие канала — это естественный broadcast: все, кто читает `<-done`, разблокируются. Это покрывает большинство сценариев и интегрируется с `select`/`context`.

| Критерий | sync.Cond | Каналы |
|---|---|---|
| Broadcast | `Broadcast()` | `close(ch)` (одноразово) |
| Повторные сигналы | да, многократно | канал-сигнал нужно пересоздавать после close |
| Интеграция с select/ctx | нет (Wait не selectable) | да |
| Передача данных | нет (только сигнал) | да |
| Связка с разделяемым состоянием | естественная (под общим мьютексом) | требует доп. синхронизации |
| Простота/безопасность | легко ошибиться (for, гонки) | идиоматичнее |

**Когда Cond оправдан:** много ожидающих, повторяющиеся изменения общего состояния, нужно будить выборочно (`Signal`) или всех (`Broadcast`) многократно, и заводить/закрывать каналы на каждое событие дорого/неудобно. Пример: пул ресурсов, ограниченная очередь (producer/consumer) с пробуждением по «появилось место»/«появился элемент».

```go
// Ограниченная очередь на Cond
type Queue struct {
    mu       sync.Mutex
    notEmpty *sync.Cond
    notFull  *sync.Cond
    items    []int
    cap      int
}

func (q *Queue) Push(x int) {
    q.mu.Lock()
    for len(q.items) == q.cap {
        q.notFull.Wait()
    }
    q.items = append(q.items, x)
    q.notEmpty.Signal()
    q.mu.Unlock()
}
```

## Подводные камни / gotchas
- **`if` вместо `for`** вокруг `Wait` — самый частый баг: проснулись по ложному/устаревшему сигналу, условие не выполнено, но идём дальше → работа со «свежим» состоянием, которого нет.
- **Изменение состояния без мьютекса** перед сигналом → гонка: ожидающий может проверить условие в момент между изменением и Signal и пропустить пробуждение. Меняйте состояние под `c.L`.
- **Потерянный сигнал (lost wakeup).** Если `Signal` вызван, когда никто ещё не в `Wait` (горутина не успела заснуть), сигнал «теряется». Защита — менять состояние под мьютексом и проверять условие в цикле перед Wait; тогда заснуть и пропустить уже изменённое состояние нельзя.
- **`Broadcast` + контеншн.** Broadcast будит всех, они все ломятся за мьютексом, большинство снова видит невыполненное условие и засыпает — «thundering herd». Если будить нужно одного, используйте `Signal`.
- **Копирование Cond** запрещено (copyChecker паникует в рантайме, go vet тоже ругается). Храните по указателю.
- **Не интегрируется с context/таймаутами.** `Wait` нельзя прервать таймаутом или отменой напрямую. Для отменяемого ожидания нужен дополнительный механизм (например, периодический Broadcast по таймеру + проверка ctx, или вообще каналы).

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

**В:** Что делает `Wait` под капотом?
**О:** Атомарно отпускает мьютекс и паркует горутину (добавив её в notifyList по тикету). При пробуждении заново захватывает мьютекс перед возвратом. Поэтому Wait вызывается только под захваченным L.

**В:** Почему `Wait` обязательно в цикле?
**О:** После пробуждения и повторного захвата мьютекса условие может уже не выполняться (другая горутина перехватила состояние, особенно при Broadcast; возможны ранние пробуждения). Цикл `for !cond()` перепроверяет и при необходимости снова Wait.

**В:** В чём разница Signal и Broadcast?
**О:** `Signal` будит одну ожидающую горутину, `Broadcast` — все. Signal — когда изменение состояния может удовлетворить лишь одного ждущего (положили один элемент). Broadcast — когда изменение касается всех (состояние закрыто/сброшено).

**В:** Что такое потерянный сигнал и как его избежать?
**О:** Если Signal послан до того, как горутина успела войти в Wait, пробуждение пропадает. Избегается тем, что состояние меняется под тем же мьютексом, а ожидающий проверяет условие в цикле перед Wait: либо он увидит уже изменённое состояние и не заснёт, либо заснёт до изменения и будет разбужен.

**В:** Когда Cond лучше каналов?
**О:** Когда нужно многократно и/или выборочно будить много горутин по изменению общего состояния, защищённого мьютексом, и пересоздавать каналы на каждое событие неудобно/дорого. Пример: bounded queue, пул ресурсов. В остальных случаях идиоматичнее каналы.

**В:** Почему Cond редко используют?
**О:** Каналы + close покрывают broadcast, select даёт таймауты/отмену, передачу данных. Cond не selectable, не отменяем, легко ошибиться (for, гонки, lost wakeup). Поэтому в идиоматичном Go его избегают, кроме узких ниш.

**В:** Можно ли отменить `Wait` по таймауту/контексту?
**О:** Напрямую нет. Обходные пути: будить всех периодическим Broadcast по таймеру и проверять ctx в цикле, либо отказаться от Cond в пользу каналов/select. Это одна из причин редкости Cond.

**В:** Что произойдёт при копировании Cond?
**О:** copyChecker в рантайме обнаружит несовпадение сохранённого адреса и вызовет панику; go vet также предупреждает. Cond нужно хранить и передавать по указателю.

## На что копают на senior+
- `notifyList` и тикетная схема (`wait`/`notify` счётчики): как она предотвращает потерю и «угон» сигнала между Add и Wait.
- Атомарность Unlock+park в Wait и почему без неё возможен lost wakeup.
- Thundering herd при Broadcast и стратегии (Signal vs Broadcast, повторная проверка условия).
- Почему Cond не интегрирован с runtime poller/select и как это влияет на дизайн (выбор каналов).
- Эквивалентность «bounded queue на Cond» и «bounded queue на буферизованном канале»: trade-offs производительности и читаемости.