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
Канал — типизированная очередь с синхронизацией, представленная структурой `runtime.hchan`. Отправка/приём блокируют горутины через парковку (`gopark`); рантайм поддерживает очереди ожидающих отправителей/получателей и кольцевой буфер. Закрытый канал отдаёт оставшиеся значения, затем нулевые с `ok=false`; отправка в закрытый — паника; операции с `nil`-каналом блокируются навсегда.

## Теория

### Структура hchan
```go
// src/runtime/chan.go (упрощённо)
type hchan struct {
    qcount   uint           // элементов в буфере сейчас
    dataqsiz uint           // размер буфера (cap)
    buf      unsafe.Pointer // кольцевой буфер (только для буферизованных)
    elemsize uint16
    closed   uint32
    elemtype *_type
    sendx    uint           // индекс записи в буфер
    recvx    uint           // индекс чтения из буфера
    recvq    waitq          // очередь ожидающих получателей (sudog)
    sendq    waitq          // очередь ожидающих отправителей (sudog)
    lock     mutex          // защищает ВСЕ поля
}
```
Каждый блокирующийся актёр оборачивается в `sudog` (G + указатель на элемент). `lock` — это рантаймовый мьютекс (не `sync.Mutex`), под ним выполняются все операции с каналом.

### Отправка (`chansend`)
1. **nil-канал** → блок навсегда (`gopark`).
2. Берётся `lock`.
3. **Есть ждущий получатель** (`recvq` непуст): значение копируется **напрямую** в стек получателя (`send` → `sendDirect`), минуя буфер. Получатель помечается готовым (`goready`). Это оптимизация: одно копирование.
4. **Есть место в буфере**: копируем в `buf[sendx]`, двигаем `sendx`, `qcount++`.
5. **Иначе**: отправитель оборачивается в `sudog`, кладётся в `sendq`, паркуется. Разбудит его получатель.
6. **Закрыт** → паника `send on closed channel`.

### Приём (`chanrecv`)
1. **nil-канал** → блок навсегда.
2. **Закрыт и буфер пуст** → возвращает нулевое значение, `ok=false`, **не блокирует**.
3. **Есть ждущий отправитель**: для небуферизованного — копия напрямую от него; для буферизованного — берём из головы буфера, а ждущего отправителя дописываем в хвост (сохраняя FIFO).
4. **Есть данные в буфере** → берём, `recvx++`, `qcount--`.
5. **Иначе** → паркуемся в `recvq`.

### Закрытие (`closechan`)
- `close(nil)` → паника.
- `close` уже закрытого → паника.
- Иначе: выставляет `closed=1`, **будит всех** в `recvq` (отдадут оставшиеся данные, затем нули) и всех в `sendq` (они получат панику). Поэтому закрывать должен **только отправитель** и только один.

### Семантика чтения/записи
| Операция | nil-канал | открытый пустой | закрытый |
|---|---|---|---|
| `<-ch` (recv) | блок навсегда | блок | нулевое значение, `ok=false` |
| `ch <- v` (send) | блок навсегда | блок (если нет места) | **паника** |
| `close(ch)` | паника | ok | **паника** (double close) |

```go
v, ok := <-ch
// ok == false  ⇒ канал закрыт И опустошён
for v := range ch { ... } // выходит, когда канал закрыт и пуст
```

### Направленные каналы
```go
func producer(out chan<- int) { out <- 1 } // только отправка
func consumer(in <-chan int)  { <-in }      // только приём
```
Направление — статическая проверка компилятора, в рантайме тот же `hchan`. Двунаправленный неявно конвертируется в направленный, обратно — нельзя. `close` допустим только на `chan` и `chan<-`, не на `<-chan`.

### Паттерны владения
- **Один владелец-отправитель**: тот, кто создал канал, тот пишет и закрывает. Получатели только читают. Закрытие — сигнал «данных больше не будет».
- **Возврат `<-chan`** из конструктора инкапсулирует владение: вызывающий не может ни писать, ни закрывать.
- **Не закрывать со стороны получателя** и **не закрывать с несколькими отправителями** напрямую — нужен координатор (`sync.Once` на закрытие, или отдельный done-канал).

## Подводные камни / gotchas
- **send on closed channel** — паника, частый источник падений при гонке закрытия и отправки.
- **double close** — паника. Защита: `sync.Once` либо архитектура с единственным владельцем.
- **range по незакрытому каналу** → дедлок/утечка: цикл ждёт вечно.
- **nil-канал** в `select` отключает кейс (полезно), но прямой `<-nilCh` вешает горутину навсегда — частая причина утечек.
- **Утечка отправителя**: получатель ушёл, а отправитель навсегда заблокирован в `sendq`. Используйте `select` с `ctx.Done()`.
- **Буфер не гарантирует доставку**: значения в буфере закрытого канала ещё читаются, но если получателей нет — теряются после сборки канала.
- Закрытие — это broadcast: удобный способ оповестить много получателей сразу (паттерн done-канала).

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

**В:** Что внутри у канала?
**О:** Структура `hchan`: кольцевой буфер (`buf`, `sendx`, `recvx`, `qcount`), флаг `closed`, тип элемента, две очереди ожидающих (`sendq`/`recvq` из `sudog`) и рантайм-мьютекс `lock`, под которым выполняются все операции.

**В:** Что происходит при отправке, если есть ждущий получатель?
**О:** Значение копируется напрямую в стек получателя, минуя буфер (`sendDirect`), и получатель помечается готовым. Это экономит одно копирование и обеспечивает rendezvous для небуферизованного канала.

**В:** Чтение из закрытого канала?
**О:** Если в буфере остались данные — они отдаются по очереди. После опустошения — нулевое значение типа и `ok=false`, без блокировки. Поэтому `for range` корректно завершается на закрытом канале.

**В:** Отправка в закрытый и nil канал?
**О:** В закрытый — паника `send on closed channel`. В nil — блокировка навсегда (как и приём из nil). Это используют, чтобы динамически отключать кейсы в `select`, обнуляя канал.

**В:** Кто должен закрывать канал?
**О:** Отправитель-владелец, и только один раз. Получатели не закрывают. При нескольких отправителях нужен координатор (отдельный done-канал или `sync.Once`), иначе риск double close и send on closed.

**В:** Как избежать утечки заблокированного отправителя?
**О:** Оборачивать отправку в `select` с `case <-ctx.Done()` или done-каналом, чтобы при уходе получателя отправитель мог выйти. Либо гарантировать, что получатель всегда дочитывает.

**В:** Чем направленные каналы полезны?
**О:** Они выражают и принуждают контракт владения на уровне типов: функция, принимающая `<-chan`, не может писать или закрывать. Это ловит ошибки компиляцией и документирует роль.

**В:** Сохраняется ли FIFO при смешении буфера и ждущих отправителей?
**О:** Да. При приёме из буферизованного канала с непустым `sendq` рантайм отдаёт голову буфера, а значение ждущего отправителя дописывает в хвост буфера, сохраняя порядок.

## На что копают на senior+
- Роль `sudog` и пулинг этих структур (`p.sudogcache`).
- Почему `lock` — рантайм-мьютекс, и как это взаимодействует с GC/преемпцией (на парковке безопасно).
- `sendDirect`/`recvDirect` и запись write-barrier при прямом копировании между стеками.
- Поведение `select` поверх `chansend`/`chanrecv` (двухфазный протокол с блокировкой нескольких каналов в порядке адресов во избежание дедлока).
- Гонки close vs send и идиоматические способы их исключить архитектурно.