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
- Senior лидирует **без формальной власти**: через техническую репутацию, ясность аргументации и помощь другим, а не через приказы.
- Менторство — это не «давать ответы», а **поднимать самостоятельность**: задавать вопросы, давать рамку, отпускать ответственность.
- Code review — главный масштабируемый инструмент влияния. Тон, фокус на важном и обучающие комментарии важнее, чем количество найденных проблем.
- Архитектурные решения senior принимает **с обоснованием и обратимостью**: ADR, прототип, понятный trade-off, путь отката.
- Техническое влияние измеряется не «я был прав», а «решение приняли и оно сработало», и тем, что **другие выросли** рядом с тобой.

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

### Лидерство без формальной власти
На senior у тебя обычно нет людей в подчинении, но есть ожидание, что ты двигаешь команду. Источники влияния:
- **Компетентность** — тебе доверяют, потому что твои прошлые решения сработали.
- **Ясность** — ты умеешь объяснить сложное просто и предложить конкретику, а не критику.
- **Надёжность** — ты доводишь до конца и не подводишь по обещаниям.
- **Щедрость** — ты помогаешь, делишься контекстом, не копишь знания.

Формулировка для интервью:
> «У меня не было прямых подчинённых, но я был техническим owner'ом платёжного домена. Влияние строил так: когда предлагал изменение, приходил не с "надо переписать", а с прототипом, бенчмарком и одностраничным ADR с альтернативами. Люди соглашались, потому что видели обоснование, а не моё мнение.»

### Менторство джунов и middle
Главная ловушка ментора — решать за человека, потому что так быстрее. Это даёт результат сегодня и отнимает рост завтра.

Рабочая модель — **постепенная передача ответственности**:
1. *Я делаю, ты смотришь* — показываешь подход на реальной задаче, проговаривая ход мысли.
2. *Мы делаем вместе* — паринг, человек ведёт, ты подстраховываешь.
3. *Ты делаешь, я ревьюю* — отдаёшь задачу целиком, остаёшься на подхвате.
4. *Ты делаешь сам* — выходишь из цикла.

Техники:
- **Сократический метод.** Вместо «здесь нужен mutex» — «что будет, если две горутины зайдут сюда одновременно?». Человек находит сам и запоминает.
- **Давать задачи на вырост.** Чуть сложнее текущего уровня, с подстраховкой. Зона комфорта роста не даёт.
- **Нормализовать незнание.** «Я тоже не помню сигнатуру, гуглю каждый раз» снимает страх спрашивать.
- **Обратная связь регулярно и конкретно.** Не «ты молодец», а «твой PR был хорошо разбит на коммиты, это сильно упростило ревью».

Формулировка:
> «Менторил джуна полгода. В начале он приходил с вопросом "как сделать X", я отвечал вопросом "а какие у тебя есть варианты и какой минус у каждого?". Сначала это его фрустрировало, но через пару месяцев он стал приходить уже с готовыми вариантами и обоснованием. Это и было целью — не чтобы он знал ответы, а чтобы умел их находить. К концу он вёл свою фичу от дизайна до прода самостоятельно.»

### Культура code review
Code review для senior — это не «гейткипинг», а:
- **Обучение** — комментарии учат всю команду, не только автора.
- **Распространение контекста** — ревью держит знание о коде неэксклюзивным.
- **Подъём планки качества** — через примеры, а не через регламенты.

Принципы здорового ревью:
- **Разделяй уровни замечаний.** Помечай: `blocking` (надо исправить), `suggestion` (на усмотрение), `nit` (мелочь, можно игнорить), `question` (хочу понять). Это снимает напряжение «всё подряд требуют».
- **Критикуй код, не человека.** «Этот цикл аллоцирует на каждой итерации» вместо «ты плохо написал».
- **Объясняй почему.** Не «вынеси в функцию», а «вынесем — переиспользуем в хендлере экспорта и упростим тест».
- **Хвали хорошее.** Положительный комментарий — тоже обучение и поддержка.
- **Не блокируй на вкусовщине.** Стиль решает линтер (gofumpt, golangci-lint), а не ревьюер. Это экономит конфликты.
- **Знай, когда отпустить.** Идеальный код, который не выходит в прод, хуже хорошего, который выходит. Не превращай ревью в бесконечный пинг-понг.

В Go-контексте полезные обучающие темы для ревью: обработка ошибок с `%w` и контекстом, отмена через `context`, утечки горутин, защита разделяемого состояния, корректность интерфейсов на границах пакетов, отсутствие лишних аллокаций в горячем пути.

### Техническое влияние и принятие архитектурных решений
Senior двигает решения процессом, который масштабируется и переживает спор:
- **RFC / ADR.** Документ: проблема, контекст, рассмотренные варианты, выбор, последствия, trade-off'ы. Письменный артефакт превращает спор мнений в обсуждение фактов и остаётся как память команды.
- **Прототип вместо спора.** Когда два решения «звучат правильно» — спайк за день закрывает вопрос данными.
- **Обратимость.** Предпочитай решения, которые можно откатить (feature flag, canary, постепенная миграция). «Решение в одну сторону» (one-way door) требует больше согласования, чем обратимое.
- **Привлекай людей рано.** Решение, в которое команда вложилась на этапе дизайна, не саботируется на этапе внедрения. Соавторство > навязывание.

Формулировка:
> «Мы спорили, брать ли gRPC или оставить REST для внутренних сервисов. Вместо недели дебатов я написал ADR с тремя осями сравнения — latency, удобство контрактов, стоимость миграции — и сделал спайк на одном сервисе. Цифры показали выигрыш по latency, но реальной болью оказалась не она, а отсутствие контрактов. Команда согласилась на gRPC именно из-за этого аргумента, который без прототипа мы бы не увидели.»

## Антипаттерны
- **Лидерство через авторитет.** «Делайте так, потому что я senior» убивает доверие и инициативу.
- **Менторство-диктат.** Решать за подопечного и переписывать его код молча — он не растёт и теряет мотивацию.
- **Ревью как самоутверждение.** Демонстрация ума, разнос на людях, блокировка на вкусовщине.
- **Bottleneck-герой.** Всё держится на тебе, ты ревьюишь всё, без тебя команда стоит. Это анти-масштаб и риск для проекта.
- **Knowledge hoarding.** Скрывать контекст, чтобы быть незаменимым. Senior, наоборот, делает себя заменимым в рутине.
- **Архитектура «в голове».** Решения без документа — спор пересобирается каждый раз, новые люди не понимают «почему так».
- **One-way doors без обсуждения.** Необратимое технологическое решение, принятое в одиночку.
- **Менторство только «приятным».** Избегать неудобной обратной связи — медвежья услуга для роста человека.

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

**В:** Расскажи, как ты менторил кого-то. Какой был результат?
**О:** Конкретный человек, начальная и конечная точка его роста, твои техники (сократический метод, передача ответственности), измеримый итог (стал вести фичи сам, прошёл на middle). Сигнал — ты растишь самостоятельность, а не зависимость от себя.

**В:** Как ты влияешь на технические решения, не имея формальной власти?
**О:** Через артефакты (ADR/RFC), прототипы и вовлечение людей рано. Приведи кейс, где решение приняли благодаря твоему обоснованию, а не должности. Подчеркни, что иногда твой вариант не побеждал — и это нормально.

**В:** Опиши твой подход к code review.
**О:** Разделение уровней замечаний, фокус на важном, обучающий тон, делегирование стиля линтеру, знание когда отпустить. Покажи, что видишь ревью как инструмент роста команды и распространения контекста, а не как контроль.

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

**В:** Как ты передаёшь знания в команде?
**О:** ADR, парное программирование, обучающие комментарии в ревью, внутренние доклады/доки, отказ от bus factor = 1. Сигнал — ты осознанно борешься с собственной незаменимостью.

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

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

## На что копают на senior+
- **Растишь ли людей реально.** «Где этот человек сейчас?» — проверяют долгосрочный эффект менторства, а не разовую помощь.
- **Не bottleneck ли ты.** «Что происходит с командой, когда тебя нет?» Здоровый ответ — «работает без меня, я убрал зависимость от себя».
- **Влияние vs упрямство.** Различают, умеешь ли ты убеждать данными и при этом отступать, или просто продавливаешь.
- **Качество архитектурных решений во времени.** «Какое твоё решение не пережило год и почему?» Проверяют рефлексию и масштаб мышления.
- **Тон и эмпатия в ревью.** На senior+ ищут того, кто поднимает планку без выгорания команды.
- **Баланс между качеством и поставкой.** Перфекционизм, мешающий релизам, — анти-сигнал. Ищут прагматика.
- **Способность делать необратимые решения осознанно.** Понимаешь ли разницу между one-way и two-way door и согласуешь ли первое.