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/ > Модуль: Core Go · Уровень: Senior ## TL;DR Интерфейс в Go — это «толстый указатель» из двух слов: дескриптор типа и указатель на данные. Непустой интерфейс представлен структурой `iface` (с таблицей методов `itab`), пустой — `eface`. Главная ловушка senior-уровня: интерфейс с конкретным типом, но nil-значением внутри — НЕ равен nil. Удовлетворение интерфейса проверяется статически и структурно (duck typing). ## Теория ### Внутреннее устройство: eface и iface Любая переменная интерфейсного типа в рантайме — это структура из двух машинных слов (на amd64 — 16 байт). Пустой интерфейс `interface{}` / `any` представлен `eface`: ```go // runtime/runtime2.go type eface struct { _type *_type // дескриптор динамического типа data unsafe.Pointer // указатель на данные (или сами данные, если влезают в слово) } ``` Непустой интерфейс (с методами) — `iface`: ```go type iface struct { tab *itab // таблица: тип интерфейса + конкретный тип + методы data unsafe.Pointer } ``` ### itab — itable `itab` — это кэшируемая структура, связывающая конкретный тип с интерфейсом: ```go type itab struct { inter *interfacetype // тип интерфейса _type *_type // конкретный (динамический) тип hash uint32 // копия _type.hash для быстрых type switch _ [4]byte fun [1]uintptr // массив указателей на методы (переменной длины) } ``` - `fun[0] == 0` означает, что тип НЕ реализует интерфейс. - itab строятся лениво при первом присваивании конкретного типа в интерфейс и кэшируются в глобальной hash-таблице (`itabTable`). Поэтому повторные присваивания дешёвы. - `fun` содержит указатели на конкретные реализации методов в нужном порядке — вызов метода через интерфейс это разыменование `tab.fun[i]` + indirect call. Это мешает инлайнингу и предсказанию переходов. ### Хранение данных и escape Поле `data` — указатель. Если в интерфейс кладут значение, не помещающееся в указатель (или адресуемое), компилятор размещает его в куче (escape) и кладёт указатель. Даже маленькое значение `int` при упаковке в интерфейс уходит в кучу (есть оптимизация для маленьких целых через `staticuint64s` для значений 0–255). ```go var x interface{} = 42 // 42 копируется, обычно escape в heap ``` ### nil-интерфейс vs nil-значение (КЛЮЧЕВОЕ) Интерфейс равен nil ТОЛЬКО когда оба слова nil: и тип, и данные. ```go func doer() error { var p *MyError = nil return p // возвращаем nil-указатель, но в типизированном виде } err := doer() fmt.Println(err == nil) // false! tab != nil (тип *MyError), data == nil ``` Это классический баг. Объявив `var err error`, мы получаем `(nil, nil)`. Положив туда `(*MyError)(nil)`, мы получаем `(*MyError, nil)` — интерфейс не nil. ```go // АНТИПАТТЕРН func do() error { var err *MyError if somethingBad() { err = &MyError{} } return err // если err==nil, всё равно вернётся не-nil интерфейс } // ПРАВИЛЬНО: возвращать nil-литерал явно либо использовать error-переменную ``` ### Interface satisfaction (структурная типизация) Тип реализует интерфейс, если имеет все его методы — без явного объявления (`implements` не нужно). Проверка статическая, на этапе компиляции, кроме случаев присваивания через интерфейс/assertion (тогда в рантайме строится itab). Важно про набор методов (method set): - У типа `T` method set — методы с receiver `T`. - У типа `*T` method set — методы с receiver `T` И `*T`. Поэтому если метод объявлен на `*T`, то значение `T` не удовлетворяет интерфейсу (только `*T`): ```go type Stringer interface{ String() string } type Foo struct{} func (f *Foo) String() string { return "foo" } var s Stringer = Foo{} // ОШИБКА компиляции var s Stringer = &Foo{} // OK ``` ### Type assertion и type switch ```go v, ok := i.(T) // безопасная форма v := i.(T) // паникует, если тип не совпал ``` Под капотом: для конкретного типа сравнивается `eface._type` / `iface.tab._type`. Для интерфейсного целевого типа — строится/ищется itab. Form `, ok` не паникует. ```go switch v := i.(type) { case int: // v имеет тип int case string: // v имеет тип string case nil: // i == nil (eface пустой) default: } ``` Type switch использует `itab.hash` для быстрой первичной фильтрации. ### Пустой интерфейс и any `any` (Go 1.18+) — алиас для `interface{}`. Используется для гетерогенных данных, но теряет статическую типизацию. На senior-уровне предпочитают дженерики там, где раньше был `interface{}`. ### Accept interfaces, return structs Идиома: функции принимают интерфейсы (гибкость для вызывающего), но возвращают конкретные типы (вызывающий получает полный API, не теряет методы, проще тестировать). ```go func New() *Server { ... } // возвращаем конкретный тип func Process(r io.Reader) error // принимаем интерфейс ``` Исключение — фабрики с несколькими реализациями или когда возврат интерфейса намеренно скрывает реализацию. ## Подводные камни / gotchas - **Nil-интерфейс != typed nil.** См. выше — самый частый баг при возврате ошибок. - **Сравнение интерфейсов паникует**, если динамический тип не comparable (например, slice/map/func внутри). `i1 == i2` для двух интерфейсов со слайсами внутри → паника в рантайме. - **Method set и адресуемость.** `Foo{}.String()` работает (компилятор берёт адрес), но `Foo{}` нельзя положить в интерфейс, если метод на `*Foo` — значение в интерфейсе не адресуемо. - **Аллокации при упаковке.** Перевод значения в интерфейс часто вызывает escape в кучу — горячие пути с `interface{}` могут неожиданно аллоцировать. - **`fmt.Stringer` рекурсия.** Если `String()` вызывает `fmt.Sprintf("%v", t)` на том же типе — бесконечная рекурсия/переполнение стека. - **Изменение значения через интерфейс невозможно** — внутри копия (если value receiver). Нужен указатель. ## Вопросы на собеседовании **В:** Из чего состоит интерфейсное значение в рантайме? **О:** Из двух слов. Для непустого интерфейса — `iface{tab *itab, data unsafe.Pointer}`, где itab содержит тип интерфейса, конкретный тип, хэш и таблицу указателей на методы. Для пустого — `eface{_type *_type, data unsafe.Pointer}`. `data` — указатель на данные (значение копируется в кучу при упаковке). **В:** Почему `err != nil`, хотя я вернул nil-указатель? **О:** Интерфейс nil только когда оба слова nil. Возвращая типизированный nil-указатель `(*T)(nil)`, мы заполняем поле типа (tab/_type), поэтому интерфейс не nil, хотя data == nil. Сравнение `== nil` сравнивает оба слова. **В:** Что такое itab и когда он создаётся? **О:** itab связывает конкретный тип с интерфейсом и хранит таблицу методов. Создаётся лениво при первом присваивании конкретного типа в данный интерфейс, кэшируется в глобальной itabTable, поэтому повторные операции дешёвы. **В:** Может ли сравнение интерфейсов вызвать панику? **О:** Да. Если динамические типы совпадают, но не comparable (слайс, map, функция внутри структуры) — рантайм-паника при `==`. **В:** В чём разница method set для T и *T применительно к интерфейсам? **О:** Method set `*T` включает методы с обоими receiver, method set `T` — только value-receiver. Если метод на `*T`, то `T` не удовлетворяет интерфейсу — нужен указатель. **В:** Что значит «accept interfaces, return structs» и почему? **О:** Принимай интерфейсы для гибкости (вызывающий подставит любую реализацию, легче мокать), возвращай конкретные типы, чтобы не урезать API и не плодить лишние абстракции. Возврат интерфейса оправдан, когда нужно скрыть реализацию. **В:** Что происходит при `i.(T)` без `, ok` и с ним? **О:** Без `ok` — паника при несовпадении. С `ok` — возвращается zero value и false. Для конкретного T сравниваются дескрипторы типов, для интерфейсного — ищется/строится itab. **В:** Почему `interface{}` иногда вызывает аллокацию? **О:** Значение должно лежать по указателю в data. Если оно не адресуемо/не помещается оптимизированно, компилятор делает escape в кучу. Поэтому горячие пути на `any` стоит измерять. ## На что копают на senior+ - Точное знание layout: 2 слова, поля itab, ленивое построение и кэш. - Понимание escape-анализа при упаковке в интерфейс и влияния на GC/аллокации. - Объяснение, почему вызов через интерфейс мешает инлайнингу (devirtualization компилятором с Go 1.18+ для известных типов). - Follow-up: «Как компилятор девиртуализирует вызовы интерфейсов?», «Почему type switch быстрее цепочки assertion?» (используется hash), «Как реализован `comparable` при сравнении интерфейсов и где паника?».