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/


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

## TL;DR
- Поведенческое интервью проверяет, как ты реально действовал в прошлом, а не как «считаешь правильным». Прошлое поведение — лучший предиктор будущего.
- Используй метод STAR: **S**ituation → **T**ask → **R**esult, через **A**ction. 70% времени ответа — на Action и Result.
- На senior уровне важны не сами факты, а демонстрация **владения (ownership), влияния (impact) и рефлексии**: что ты решил, почему, чему научился, что измерил.
- Готовь заранее 6–8 «историй» из опыта и переиспользуй их под разные вопросы. Одна сильная история закрывает 3–4 темы.
- Цифры и trade-off'ы продают senior'а. «Снизили p99 latency с 1.2s до 180ms» сильнее, чем «улучшили производительность».

## Теория / Подход

### Что на самом деле оценивают
Поведенческая секция — это не «проверка на адекватность». Интервьюер собирает сигналы по компетенциям, которые у компании прописаны в гайде. Для senior это обычно:
- **Ownership** — берёшь ли ответственность за результат, а не за «свой кусок».
- **Impact / scope** — масштаб влияния: на свою задачу, на команду, на организацию.
- **Collaboration & influence** — умеешь ли двигать решения без формальной власти.
- **Dealing with ambiguity** — действуешь ли в условиях неопределённости и неполных данных.
- **Self-awareness** — видишь ли свои ошибки, рос ли ты на них.

Senior отличается от middle тем, что в его историях есть **второй порядок мышления**: не «я сделал фичу», а «я понял, что фича не нужна в таком виде, и предложил альтернативу, которая сэкономила квартал работы».

### Метод STAR (и его расширение STAR-L)
- **Situation** (10–15%) — контекст коротко. Где, какая система, какой масштаб, какая проблема. Без воды.
- **Task** (10%) — что именно было твоей задачей/ответственностью. Чётко вычлени своё «я» из «мы».
- **Action** (50%) — что *ты* конкретно делал. Это ядро. Решения, альтернативы, почему выбрал так, как координировал людей.
- **Result** (20%) — измеримый итог. Цифры, бизнес-эффект, что изменилось.
- **Learning** (5–10%) — что вынес. Особенно критично для вопросов про факапы.

> Частая ошибка: кандидат тратит 80% времени на Situation («у нас был такой сервис, он работал так, и ещё был другой сервис...») и не доходит до Action. Интервьюер слышит «контекст» вместо «тебя».

### Как готовить банк историй
Составь таблицу: 6–8 ситуаций × теги тем. Пример тегов: сложная техническая задача, конфликт, факап/инцидент, лидерство, влияние на решение, дедлайн/давление, обратная связь, неоднозначность.

Каждая история должна:
1. Быть про **тебя** (не «команда сделала»).
2. Содержать **конкретное решение и trade-off**.
3. Иметь **измеримый результат**.
4. Допускать **рефлексию** («сейчас я бы сделал иначе...»).

Хорошо, если 1–2 истории относятся к недавнему опыту (последний год) — это снимает подозрение, что ты живёшь прошлыми заслугами.

### Формулировки: как звучит senior
Сравни:
- ❌ «Мы переписали сервис, стало быстрее.»
- ✅ «Я заметил, что p99 в платёжном сервисе деградировал до 1.2s под нагрузкой. Снял профиль pprof, нашёл, что аллокации в горячем пути на сериализации съедали CPU. Я предложить заменить encoding/json на ручной маршалинг для двух критичных структур и ввести sync.Pool для буферов. До раскатки прогнал бенчмарки и нагрузочное в staging. p99 упал до 180ms, что позволило отложить горизонтальное масштабирование на квартал — сэкономили примерно $4k/мес на инфраструктуре.»

Второй ответ показывает: диагностику, владение инструментами Go, осознание trade-off (ручной маршалинг = поддержка vs скорость), измерение, бизнес-эффект.

### Истории про факап (самое важное на senior)
Senior без факапов не существует — отсутствие факапа в ответе читается как «не брал на себя ничего серьёзного» или «не признаёт ошибок».

Структура хорошего ответа про факап:
1. **Признай ошибку прямо**, без размывания вины на других.
2. **Объясни механизм** — почему так вышло (системно, не «я был невнимателен»).
3. **Что сделал немедленно** — митигация, коммуникация, ownership инцидента.
4. **Что изменил системно**, чтобы это не повторилось (постмортем, алерты, процесс).
5. **Чему научился** — желательно изменение в подходе, а не «стал внимательнее».

Пример формулировки:
> «Я раскатил миграцию, которая добавляла индекс на большую таблицу без `CONCURRENTLY` в Postgres. Она взяла блокировку и положила запись в прод на 4 минуты в пиковое время. Я сразу откатил, написал в инцидент-канал, что причина во мне, и взял координацию постмортема. Корневая причина была не только в моей невнимательности — у нас не было ревью миграций и не было линтера на опасные DDL. Я добавил в CI проверку (squawk) и чек-лист ревью для миграций. С тех пор таких инцидентов не было. Главный вывод: если ошибка возможна, виноват не человек, а процесс, который её допускает.»

### Истории про конфликт
Подробно в `conflicts.md`. Здесь главное: показывай, что конфликт ты решал **через интересы и данные**, а не через «продавил» или «уступил, чтобы не ссориться». Финал — disagree and commit или найденный третий вариант.

## Антипаттерны
- **«Мы» вместо «я».** Невозможно оценить твой вклад. Чётко: «команда сделала X, моя часть — Y».
- **Гипотетика.** «Я бы поступил так...» — это не поведенческий ответ. Нужен реальный случай. Если случая нет — честно скажи и приведи ближайший аналог.
- **Идеальные истории без трудностей.** «Всё прошло гладко» = не было сложности = не senior-масштаб.
- **Факап, где виноваты все, кроме тебя.** Перекладывание вины — мгновенный red flag.
- **Нет цифр.** «Стало лучше» без метрик. Если точных цифр нет — дай порядок («примерно вдвое», «с минут до секунд»).
- **Растекание по Situation.** 5 минут контекста, 30 секунд действия.
- **Заученность.** Слишком гладкий, отрепетированный монолог без живых деталей вызывает недоверие. Знай канву, но говори естественно.
- **Технический шум без сути.** Перечисление технологий вместо объяснения решений и trade-off'ов.

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

**В:** Расскажи о самой технически сложной задаче, которую ты решал.
**О:** Выбери задачу с реальной неоднозначностью (не «сложную» в смысле объёма). Структура: в чём была сложность (распределённость, неочевидный баг, конфликт требований), какие варианты рассматривал и почему отбросил, что выбрал, как валидировал, результат в цифрах. Senior-сигнал — рассказ про trade-off'ы и про то, как ты управлял неопределённостью, а не только финальное решение.

**В:** Расскажи о своём самом крупном профессиональном провале.
**О:** Бери настоящий факап с последствиями. Признай вину прямо, покажи немедленную митигацию и системное исправление (постмортем, процесс), закончи конкретным выводом. Избегай «фейк-факапов» вроде «я слишком много работал».

**В:** Опиши ситуацию, когда тебе пришлось принять решение с неполной информацией.
**О:** Покажи, как ты ограничивал риск при неопределённости: выделил, что известно/неизвестно, какие допущения сделал явными, как сделал решение обратимым (feature flag, canary), как договорился пересмотреть при новых данных. Это прямой сигнал на «dealing with ambiguity».

**В:** Был ли случай, когда ты пошёл против мнения большинства / своего руководителя?
**О:** Покажи, что отстаивал позицию данными и интересами дела, эскалировал корректно, и — ключевое — что было дальше: либо тебя услышали, либо ты сделал disagree and commit. Финал не должен быть «я был прав, а все дураки».

**В:** Расскажи, как ты получал жёсткую обратную связь. Что сделал?
**О:** Сигнал — self-awareness. Опиши конкретный фидбэк (не размытый), первую эмоциональную реакцию честно, и как ты её переработал в действие. Покажи измеримое изменение поведения. Избегай «я не согласился, фидбэк был неправильный».

**В:** Приведи пример, когда ты вышел за рамки своей роли.
**О:** Ownership-вопрос. Покажи, что увидел проблему вне своей зоны (флейки в CI, отсутствие алертов, выгорающий коллега) и взял её, не спрашивая разрешения, потому что это влияло на результат. Подчеркни, что согласовал, где надо, чтобы не выглядеть «героем-одиночкой».

**В:** Расскажи о задаче, которой ты гордишься больше всего.
**О:** Не самая большая, а самая показательная по влиянию. Свяжи технику с бизнес/командным эффектом. Дай понять, почему гордишься именно ей — это раскрывает твои ценности (качество, влияние, рост команды).

## На что копают на senior+
- **Где границы твоего вклада.** Будут уточнять: «А что конкретно делал *ты*?», «Кто принял финальное решение?» — проверяют, не присваиваешь ли чужое.
- **Глубина trade-off'ов.** «Почему не выбрал альтернативу X? А какой минус у твоего решения?» Senior всегда видит обратную сторону своего выбора.
- **Масштаб и долгосрочность.** «Как это решение жило через год? Не пришлось ли переделывать?» Проверяют, мыслишь ли ты за горизонт спринта.
- **Влияние на людей и процессы**, а не только на код. История, где ты изменил подход команды, ценится выше, чем где ты написал классный алгоритм.
- **Честность рефлексии.** На факапе будут давить: «А что бы ты сделал иначе сейчас?» Заготовленный «идеальный» вывод хуже, чем живой и самокритичный.
- **Консистентность.** Сопоставляют твои истории между собой и с резюме. Противоречия (то «я лид», то «я только кодил») рушат доверие.