Библиотека Go для собеса | вопросы с собеседований

❓ Чем signal.NotifyContext отличается от signal.Notify

signal.Notify — низкоуровневый примитив. Он перенаправляет сигналы в предоставленный канал, и приложение само обязано читать из него в горутине, обрабатывать значения и принимать решения.
 
signal.NotifyContext — обёртка поверх того же механизма, но интегрированная с context.Context. Получение сигнала автоматически отменяет контекст, и приложение работает через стандартный ctx.Done() — без ручного управления каналом.
 
На практике это важно, потому что большинство современных Go-библиотек принимают контекст: http.Server.Shutdown(ctx), sql.DB, gRPC-клиенты и т.д. signal.NotifyContext позволяет напрямую связать сигнал ОС с этими вызовами без дополнительного кода.
 

// signal.Notify — ручное управление
ch := make(chan os.Signal, 1)
signal.Notify(ch, syscall.SIGINT)
go func() {
<-ch
// вручную инициировать завершение
}()
 
// signal.NotifyContext — контекст сам распространяет отмену
ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT)
defer stop()
server.Shutdown(ctx) // контекст отменится при SIGINT

🐸 Библиотека Go для собеса

❓ Что произойдёт, если не вызвать stop() после signal.NotifyContext
 
Внутри пакета signal ведётся реестр каналов, которым нужно доставлять сигналы. Пока stop не вызван, канал остаётся в этом реестре. Это означает две проблемы.
 
Первая — утечка ресурсов: внутренний канал не будет собран GC, даже если контекст уже отменён и никто его не использует.
 
Вторая — поведенческая: если программа перехватывает тот же сигнал в нескольких местах, лишние подписчики продолжат получать события, что может приводить к неожиданному поведению.
 
Правило простое: stop вызывается через defer сразу после создания контекста, независимо от того, был ли сигнал получен.
 

ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT)
defer stop() // освобождает ресурсы в любом случае

🐸 Библиотека Go для собеса

❓ Что делает signal.NotifyContext(ctx, signals...) и что возвращает

Функция принимает родительский контекст и список сигналов ОС, возвращает два значения: дочерний контекст и функцию stop.
 
Контекст отменяется автоматически, когда процесс получает один из перечисленных сигналов — например, syscall.SIGINT (Ctrl+C) или syscall.SIGTERM. После отмены ctx.Err() вернёт context.Canceled, а ctx.Done() будет закрыт.
 
Функция stop останавливает перенаправление сигналов и освобождает внутренние ресурсы пакета signal. Её нужно обязательно вызвать — как правило, через defer stop() сразу после создания контекста.
 

ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
defer stop()
 
<-ctx.Done()
fmt.Println("получен сигнал:", ctx.Err())

🐸 Библиотека Go для собеса

До 31 мая можно забрать любой курс Proglib Academy со скидкой 40%

Если давно хотели прокачаться в Python, ML, алгоритмах или AI-агентах, сейчас самое время выбрать программу и начать обучение по сниженной цене.

🎁 Разработка AI-агентов — от 49.000 ₽ (вместо 69.000 ₽)

Практический курс по разработке AI-агентов для автоматизации задач, работы и собственных проектов

🎁 Курс AgentOps — 129.000 ₽ (вместо 149.000 ₽)

Для разработчиков и LLM-инженеров, которые хотят внедрять AI-логику в бэкенд и сохранять стабильность сервиса.

🎁 Математика для разработки AI-моделей — 23.990 ₽ (вместо 31.990 ₽)

Практическая база по математике для анализа данных, ML и дальнейшего развития в AI.

🎁 Математика для Data Science — от 29.990 ₽ (вместо 39.990 ₽)

Курс для тех, кто хочет решать задачи, которые дают на собеседованиях на позицию дата-сайентиста в бигтехе.

🎁 ML для старта в Data Science — 28.990 ₽ (вместо 38.990 ₽)

Разберётесь в машинном обучении: от базовых понятий и линейных моделей до ансамблей, бустинга и рекомендательных систем.

🎁 Основы IT для непрограммистов — 16.990 ₽ (вместо 28.990 ₽)

Курс для IT-рекрутеров, маркетологов, проджектов, продактов и всех, кто работает с IT, но не пишет код.

🎁 Архитектуры и шаблоны проектирования — 27.990 ₽ (вместо 37.900 ₽)

Освоите основные паттерны проектирования и прокачаете навыки архитектора программного обеспечения.

🎁 Специалист по ИИ — 89.000 ₽ (вместо 113.900 ₽)

Курс для тех, кто хочет получить профессию в сфере ИИ, собрать портфолио из 5 проектов и научиться разрабатывать сложных AI-агентов.

🎁 Алгоритмы и структуры данных — 33.990 ₽ (вместо 57.990 ₽)

Подготовитесь к алгоритмическим собеседованиям, разберёте структуры данных и научитесь писать более эффективный код.

🎁 Программирование на языке Python — 27.990 ₽ (вместо 47.390 ₽)

Освоите Python на практике: без сухой теории, с пошаговой прокачкой навыков и итоговым проектом в портфолио.

🙌 Выбирайте курс по ссылке, оставляйте заявку, и менеджер поможет подобрать программу под ваши цели — https://clc.to/SALE40

❓ Как устроено внутреннее состояние sync.WaitGroup

sync.WaitGroup содержит три поля: noCopy, state atomic.Uint64 и sema uint32.

noCopy — маркер для go vet, запрещает копирование структуры после первого использования. В рантайме не занимает места.

state — ключевое поле. В одном 64-битном слове упакованы два счётчика: старшие 32 бита — counter, количество незавершённых горутин, младшие 32 бита — waiter, количество горутин, заблокированных в Wait. Упаковка в одно слово нужна, чтобы атомарно обновлять оба значения за одну операцию и исключить гонку между Add и Wait.

sema — системный семафор рантайма. Когда горутина вызывает Wait и counter > 0, она атомарно инкрементирует waiter и паркуется через runtime_Semacquire. Когда Add обнуляет counter, он делает runtime_Semrelease столько раз, сколько горутин ждёт.

Done() — это просто Add(-1). Если после Add(delta) значение counter уходит в минус, рантайм паникует с "sync: negative WaitGroup counter".

🐸 Библиотека Go для собеса

📌 Что такое микросервисы в айти

Микросервисы — это подход, при котором ваше приложение превращается в созвездие маленьких, независимых сервисов. Каждый живет своей жизнью, решает одну конкретную задачу и общается с «соседями» через API.

Где мы это видим на практике:

Онлайн-магазины: один сервис отвечает только за корзину, другой за оплату, третий «пинает» доставку. Если упала оплата, корзина всё еще работает.

Стриминги (Netflix/YouTube): каталог фильмов, система рекомендаций и сам плеер это разные микросервисы. Поэтому рекомендации могут «тупить», но фильм всё равно будет играть.

А что сейчас в вашем проекте?
❤️ — Уютный монолит (всё в одном месте, полёт нормальный)
🔥 — Микросервисный зоопарк

🔹 Практический интенсив «Архитектуры и шаблоны проектирования»
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib

🏃‍♀️ Азбука айтишника

#ликбез

❓ Стоит ли стремиться к 100% покрытия кода тестами

Нет. Высокий процент покрытия не гарантирует отсутствие багов. Тесты ради покрытия часто проверяют тривиальные вещи и усложняют поддержку. Важнее покрывать критическую бизнес-логику, граничные случаи и обработку ошибок.

🐸 Библиотека Go для собеса

❓ Как посмотреть покрытие кода тестами в Go
 
Запускаете тесты с флагом -cover для общей цифры. Для детального отчёта генерируете профиль и открываете его в браузере:

go test -coverprofile=coverage.out
go tool cover -html=coverage.out

🐸 Библиотека Go для собеса

❓ Что делает t.Helper() и когда его вызывать

t.Helper() помечает функцию как вспомогательную. При падении теста стек ошибки укажет не на строку внутри хелпера, а на строку вызова в тесте.

Когда вы выносите повторяющиеся проверки в отдельную функцию, Go по умолчанию при падении теста покажет в стеке строку внутри этой функции. Допустим, у вас есть хелпер assertEqual, который вызывается в двадцати тестах. Тест упал, вы смотрите в лог и видите helper.go:14. Это строка с t.Errorf внутри хелпера. Чтобы понять, какой именно тест сломался, придётся идти по стеку вызовов вручную.

Вызов в начале функции говорит Go, что эта функция вспомогательная, и при ошибке нужно показывать не её, а место вызова. Вместо helper.go:14 вы увидите user_test.go:42, то есть конкретную строку теста, где всё пошло не так:

// Без t.Helper() ошибка укажет на строку 3 этой функции
// С t.Helper() ошибка укажет на строку вызова assertEqual в тесте
func assertEqual(t *testing.T, got, want int) {
    t.Helper()
    if got != want {
        t.Errorf("got %d, want %d", got, want)
    }
}

 
Вызывать t.Helper() нужно в каждой функции, которая сама не является тестом, но содержит вызовы t.Errorf, t.Fatalf или других методов, фиксирующих ошибку. Если хелпер вызывает другой хелпер, пометить нужно оба.

Пропуск t.Helper() не сломает тесты, они будут работать корректно. Но при отладке падений в большом проекте с десятками хелперов отсутствие этой пометки превращает чтение логов в квест. Привычка ставить t.Helper() первой строкой в любой вспомогательной функции экономит время и нервы.

🐸 Библиотека Go для собеса

❓ В какой момент лучше сбрасывать состояние объекта в sync.Pool, при Get или при Put

Оба варианта рабочие, но важно выбрать один и придерживаться его.

Сброс при Get надёжнее, потому что гарантирует чистое состояние независимо от того, кто и как вернул объект в пул.

Сброс при Put экономит время на стороне потребителя, но требует дисциплины от всех, кто кладёт объекты обратно.

🐸 Библиотека Go для собеса

❓ Вы случайно закоммитили в репозиторий файл с секретами. Как это исправить

Простого удаления файла и нового коммита недостаточно, потому что секрет останется в истории.

Нужно переписать историю через git filter-branch или git filter-repo, удалив файл из всех коммитов. После этого обязательно отозвать скомпрометированные ключи, потому что они могли быть уже скачаны.

🐸 Библиотека Go для собеса

❓ Гарантирует ли sync.Pool, что объект останется в пуле между вызовами GC

Нет. Сборщик мусора может в любой момент очистить содержимое пула. sync.Pool не даёт гарантий на время жизни объектов. Поэтому его нельзя использовать как кэш или хранилище.

🐸 Библиотека Go для собеса

❓ Когда использовать функции вместо интерфейсов

Ключевой критерий это количество методов в поведении. Если нужно абстрагироваться над одним действием, берите функцию-тип. Если поведение требует нескольких связанных методов — интерфейс.

Интерфейс оправдан, когда поведение требует нескольких связанных методов или когда реализация несёт внутреннее состояние — соединение, кэш, буфер. Тогда контракт нужно зафиксировать явно, и интерфейс делает это лучше.

Показательный пример из стандартной библиотеки — net/http. Там оба подхода живут рядом:

• http.Handler — интерфейс с одним методом ServeHTTP
• http.HandlerFunc — функциональный тип, который реализует этот же интерфейс.

Это позволяет передавать как структуры со состоянием, так и простые функции, не заставляя автора каждый раз писать обёртку.

🐸 Библиотека Go для собеса

❓ Можно ли складывать два разных алиаса на один и тот же тип

Алиас в Go это другое имя для существующего типа. Когда пишут type Meters = float64, компилятор не создаёт новый тип: Meters и float64 взаимозаменяемы без явного приведения.

Компилятор видит оба алиаса как float64 и не различает их. Поэтому сложение, сравнение и передача в функцию работают без приведения типов. Если функция принимает Seconds, в неё без ошибки пройдёт переменная типа Meters.

🐸 Библиотека Go для собеса

❓ Что такое httputil.NewSingleHostReverseProxy и зачем он нужен

NewSingleHostReverseProxy создаёт обратный прокси, который перенаправляет входящие HTTP-запросы на один заданный сервер. Вы передаёте функции целевой URL, а она возвращает http.Handler, готовый к использованию.

Типичный сценарий это API-шлюз или балансировщик нагрузки перед сервисом. Вместо того чтобы писать логику проксирования вручную, можно получить готовый обработчик в несколько строк:

target, _ := url.Parse("http://backend-service:8080")
proxy := httputil.NewSingleHostReverseProxy(target)
http.ListenAndServe(":80", proxy)

🐸 Библиотека Go для собеса

❓ Что возвращает Buffer.Peek(n), если в буфере меньше n байт

Buffer.Peek возвращает срез доступных байт даже если их меньше n. Ошибки при этом нет. Поведение аналогично bufio.Reader.Peek, но там при нехватке байт возвращается io.ErrUnexpectedEOF — это распространённое заблуждение при переносе привычек из bufio.

🐸 Библиотека Go для собеса

❓ Можно ли отдавать «HTTP 200 OK», если на сервере что-то пошло не так

Код 200 говорит клиенту: «Всё прошло штатно, держи результат». Если вместо результата внутри тела прячется ошибка, то клиент вынужден парсить ответ, чтобы понять, что запрос на самом деле провалился. Это ломает саму идею HTTP-контракта.

Когда это всё-таки допустимо? При ошибках бизнес-логики. Например, валидация формы вернула список замечаний: сам запрос обработан корректно, просто данные не прошли проверку на уровне домена. Но даже тут стоит трижды подумать.

Для всего остального в HTTP уже есть подходящие коды — и они существуют не просто так:

🔹 400 Bad Request — клиент прислал невалидные данные
🔹 404 Not Found — ресурс не существует
🔹 500 Internal Server Error — сервер сломался и не смог обработать запрос
🔹 503 Service Unavailable — сервер на паузе: перегрузка, деплой, обслуживание

🐸 Библиотека Go для собеса

❓ Как сэкономить память при использовании подстроки от строки

В Go строки неизменяемы и внутри представлены заголовком с указателем на массив байтов и длиной. При создании среза строки, например, s[10:20] данные не копируются — новый заголовок просто указывает на ту же область памяти оригинала. Из-за этого, если маленькая подстрока живёт дольше родительской строки, весь исходный массив остаётся в памяти, так как сборщик мусора не может его освободить, даже если нужна только небольшая часть.

Чтобы экономить память, используйте strings.Clone(substr)или string([]byte(substr)) для создания независимой копии подстроки. Это создаёт новый массив только с нужными байтами, позволяя сборщику мусора освободить большой исходный массив.

Копируйте строки только если подстрока действительно живёт значительно дольше родителя — для кратковременной обработки, например, внутри обработчика запроса, срез без копирования эффективнее, так как выделение и копирование дороже, чем удержание лишней памяти.

🐸 Библиотека Go для собеса

❓ Когда использование OnceValue может быть неправильным решением

Когда результат зависит от контекста или должен меняться со временем, например, обновляемый конфиг.

OnceValue кэширует навсегда и для изменяемых данных нужен другой механизм: atomic, mutex, канал.

🐸 Библиотека Go для собеса

❓ Что изменилось в команде go fix в Go 1.26

go fix была полностью переписана с нуля. Вот ключевые изменения:

Старая реализация cmd/fix была удалена, а go fix перестроена по модели go vet — обе команды теперь работают поверх одного и того же фреймворка. Разница между ними в том, что go vet сообщает о диагностике, а go fix применяет предложенные исправления.

Команда Go разработала десятки анализаторов для выявления возможностей модернизации кода. Они предоставляют надёжный способ обновить кодовую базу до актуальных идиом и API стандартной библиотеки.

Все старые фиксеры из оригинальной go fix, которые к этому моменту были устаревшими, были полностью удалены.

🐸 Библиотека Go для собеса