Golang вопросы собеседований

Morph - генератор мапперов для Go, который закрывает одну из самых скучных частей backend-разработки: перекладывание данных между похожими типами. Типичный кейс: у вас есть protobuf-модели, доменные структуры, DTO, database-типы и API-ответы. Поля почти одинаковые, но код всё равно приходится писать руками:

func MapFromRecipeToToRecipe(source *from.Recipe) to.Recipe {
    if source == nil {
        return to.Recipe{}
    }

    var target to.Recipe
    target.ID = to.RecipeID(source.RecipeId)
    target.Name = source.Name
    target.Servings = int(source.Servings)

    return target
}

На одном маппере это терпимо. На десятках типов начинается боль: забытые поля, кривые конверсии, ручная синхронизация после каждого изменения схемы. Morph генерирует такой код автоматически и умеет работать не только с простыми структурами. Что поддерживает: * structs и enums * basic types, pointers, slices, arrays, maps * nested structs * concrete generic containers * safe и настроенные type conversions * вложенные сгенерированные мапперы * пользовательские callables для сложной логики * discovery готовых mapping-функций из указанных пакетов * presets, чтобы не дублировать конфиг для типовых сценариев Самый полезный случай - protobuf → idiomatic Go model. protoc часто генерирует не тот код, который хочется таскать по доменному слою: другие имена, другие типы, timestamp-обёртки, enum-формат, optional-поля. Morph позволяет описать правила один раз и дальше генерировать нормальные мапперы. Запуск простой:

go install github.com/seeruk/morph/cmd/morph@latest
morph

Конфигурация живёт в morph.yaml, а сам инструмент можно использовать и как CLI, и как библиотеку внутри более сложных codegen-пайплайнов. Хороший вариант для Go-проектов, где ручной mapping уже стал отдельным источником багов и мусорного кода. GitHub: https://github.com/seeruk/morph #golang

🔍Тестовое собеседование с Go Senior из Uzum в этот четверг 11 июня(в четверг!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Go-разработчика. Как это будет: 📂 Маруф Караев, Senior из Uzum, ex-Яндекс, ex-EPAM будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Маруф будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Маруфу Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Go-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_go_bot Реклама. О рекламодателе.

👣 Go 1.26 делает `go fix` заметно полезнее: теперь это не просто инструмент для старых миграций, а нормальный способ постепенно приводить код к современным Go-идиомам. Код живёт годами, язык меняется, а старые паттерны остаются. В итоге в проекте рядом могут лежать strings.Index + slicing, ручной clamp через if, хелперы вроде newInt, старые циклы и куча мелочей, которые уже можно записать короче, безопаснее и понятнее. Что появилось: - go fix в Go 1.26 переписали и усилили анализаторами - он умеет модернизировать код под новые возможности языка и стандартной библиотеки - может заменять старые паттерны на min/max, strings.Cut, range по int и другие более чистые формы - для Go 1.26 появился new(expr), который убирает кучу вспомогательных функций для указателей на значения - часть таких подсказок уже попадает в gopls, то есть IDE может показывать их прямо во время работы Пример, где это особенно приятно: раньше для optional-поля часто писали newInt(10) или ptr.To(10). В Go 1.26 можно проще: Attempts: new(10) Мелочь, но таких мелочей в большом Go-проекте сотни. go fix теперь стоит запускать не один раз в жизни при миграции, а после обновления toolchain. Желательно из чистого git-состояния, чтобы ревью потом смотрело только автоматические изменения. Zзык остаётся консервативным, но экосистема постепенно учится сама вычищать старые шаблоны и подтягивать проекты к более читаемому стилю. #golang https://altafino.com/blog/using-go-1-25-and-go-1-26-to-write-cleaner-more-maintainable-go-3ETksqLv07ShL2dFmF6LVndO8Ps

✔️ Go-ошибки - это не просто `err != nil`, а история о том, что именно сломалось. В Go у ошибок по умолчанию нет stack trace, как в Java или других языках. Поэтому контекст нужно добавлять руками: ошибка пришла из базы, из репозитория, из сервиса, из handler - и каждый слой должен аккуратно объяснить, что происходило. Когда команда делает это хорошо, получается понятная цепочка: unable to get user: failed to query users table: connection refused Когда плохо - в логах остаётся просто connection refused, и потом никто не понимает, где именно это произошло. Проблема в том, что такой контекст надо постоянно поддерживать. Код меняется, старые сообщения устаревают, кто-то забывает завернуть ошибку, и история разваливается. Автор предлагает практичный компромисс: добавлять stack trace в момент, когда приложение создаёт ошибку или впервые получает её от сторонней библиотеки. Тогда у команды всегда есть базовая точка опоры, а ручной контекст можно добавлять там, где он действительно нужен. Хорошие ошибки в Go должны не просто сообщать, что всё упало. Они должны рассказывать, как именно оно к этому пришло. https://robinsiep.com/blog/posts/go-errors/ #golang

📌 HyperLogLog на Go простыми словами Redis может примерно считать уникальные значения, почти не храня сами значения. Идея такая: - берём строку - считаем от неё хеш - первые биты выбирают ячейку - остальные биты проверяем на количество нулей подряд - чем длиннее серия нулей, тем более редкое событие мы увидели - редкие события намекают, что элементов прошло много Минимальный пример на Go:

package main

import (
 "fmt"
 "hash/fnv"
 "math/bits"
)

const registersCount = 16

type HyperLogLog struct {
 registers [registersCount]uint8
}

func hash64(s string) uint64 {
 h := fnv.New64a()
 _, _ = h.Write([]byte(s))
 return h.Sum64()
}

func (hll *HyperLogLog) Add(value string) {
 hash := hash64(value)

 // первые 4 бита выбирают регистр: 2^4 = 16
 index := hash >> 60

 // остальные биты используем для поиска серии нулей
 rest := hash << 4

 // сколько нулей подряд в начале
 zeros := uint8(bits.LeadingZeros64(rest) + 1)

 if zeros > hll.registers[index] {
  hll.registers[index] = zeros
 }
}

func main() {
 hll := HyperLogLog{}

 values := []string{
  "user_1",
  "user_2",
  "user_3",
  "user_1",
  "user_2",
  "user_4",
  "user_5",
 }

 for _, v := range values {
  hll.Add(v)
 }

 fmt.Println(hll.registers)
}

Это не полноценный Redis HyperLogLog, а понятная учебная версия. Что тут важно: • дубликаты дают тот же хеш • один и тот же хеш попадает в тот же регистр • регистр хранит только максимум найденных нулей • сами user_1, user_2, user_3 не сохраняются • память остаётся почти постоянной В Redis всё серьёзнее: там 16 384 регистра, аккуратная математика для оценки cardinality и поправки на маленькие и большие значения.

O(1) не значит «быстро» Одна из самых частых ошибок в алгоритмах: считать, что O(1) всегда быстрее O(n). На практике это не так. O(1) означает только одно: время работы не растёт вместе с размером входных данных. Но сама операция может быть дорогой. Например, хеш-таблица формально даёт O(1) для поиска, но если данные не в кэше CPU, один cache miss может сделать её медленнее, чем простой линейный проход по маленькому массиву. Именно поэтому в Go, Python и даже C-библиотеках для маленьких map/таблиц иногда используют обычный linear search. Парадоксально, но: O(n) при n = 16 и тёплом кэше может быть быстрее, чем O(1) с холодным cache miss. Big O описывает асимптотический рост, а не реальную скорость на маленьких данных.

🚀 Golang Roadmap 2026 — продвинутый курс на русском 📌 О курсе Это бесплатный open-source roadmap на русском языке. Внутри — 19 модулей, каждый со своей теорией, практикой, бесплатными ресурсами и финальным проектом. Программа собрана так, чтобы провести вас от полного нуля до уровня Senior/Staff Go Engineer за 12–18 месяцев при темпе 10–15 часов в неделю. Главный принцип курса — практика > видосы. Каждую тему вы закрываете кодом: пишете, ломаете, чините, рефакторите. Любой модуль завершается мини-проектом, который можно положить в портфолио. 🎯 Кому подойдёт 🐹 Новичкам в Go — даже если до этого писали только на Python/JS/PHP 🛠 Backend-разработчикам с другого стека — хотите перейти на Go 📈 Junior Go-разработчикам — нужен путь до Middle/Senior 🚀 Middle-инженерам — закрыть пробелы в архитектуре, observability, distributed 🤖 Тем, кто хочет писать AI-инфраструктуру — модуль 18 специально про это https://github.com/Develp10/golangroadmap2026\

# MCP становится новым API-слоем для агентов Если продуктом можно управлять через UI, REST и Terraform, то у агента тоже должен быть нормальный официальный вход. Не парсинг страниц, не хаки, а tools со схемами, типами и понятными описаниями. Главная мысль статьи - MCP-интерфейс нужно проектировать не для человека, а для модели. Для агента описание tool и input schema - это почти как документация и типы для разработчика. Плохое название поля, мутный enum или устаревший комментарий сразу превращаются в ошибки вызова. Что делает Oblique: - берёт gRPC/Protobuf как источник правды - генерирует MCP tools - подтягивает комментарии из proto-файлов - помечает read-only и destructive tools - чистит ответы от лишних полей - прогоняет сценарии через evals Обычный API часто возвращает много служебного шума: timestamps, metadata, внутренние поля. Для агента это лишние токены и больше шанс ошибиться. Поэтому MCP-ответы делают компактнее и ближе к задаче. MCP - это отдельный слой продукта, где важны названия, схемы, права, компактность ответа и тесты на поведение агента. Если продукт должен нормально работать с Claude Code, Codex и другими агентными средами, MCP постепенно становится базовой инфраструктурой. https://oblique.security/blog/mcp/

Собираетесь к нам в Go? ➡ Рассказали, как мы построили наймовый процесс, чтобы сделать его честнее для всех. Другие инженерные инсайты от 2ГИС → в Telegram-канале RnD

🚀 Удобная сборка с rigx для C, C++, Go и других языков rigx — это экспериментальная система сборки, которая упрощает процесс создания и тестирования приложений на нескольких языках. Она использует декларативный подход с конфигурацией в rigx.toml, обеспечивая изоляцию и кэширование сборок для повышения надежности и скорости. 🚀 Основные моменты: - Поддержка множества языков: C, C++, Go, Rust, Zig, Nim, Python. - Сборки и тесты выполняются в песочнице, не загрязняя систему. - Легкая конфигурация с помощью простого TOML-файла. - Возможность параллельного выполнения тестов и интеграционных тестов. - Кэширование выходных данных для повышения производительности. 📌 GitHub: https://github.com/unofficialtools/rigx

📘 На Mentorix вышел курс — «Golang: микросервисная архитектура и проектирование API» Уже работаете с Go и хотите перейти на уровень системного проектирования? Этот курс — про то, как разрабатывать API, строить распределённые сервисы и поддерживать их стабильную работу в продакшене под нагрузкой. • Полный стек: HTTP/REST, gRPC, RabbitMQ и Kafka, PostgreSQL, Redis, Docker, Prometheus + Grafana • 200+ интерактивных заданий с автопроверкой — пишете код прямо в браузере, в любое удобное время • Финальный проект: рабочая микросервисная экосистема, которую кладёте в портфолио и показываете на собесе 🎓 Сертификат по завершении — добавьте его в резюме или профиль LinkedIn 🚀 Прокачайте Go и выйдите на уровень мидл/сеньор-разработчика микросервисов. Начните сегодня — следующая неделя будет уже с новыми навыками. 👉 Пройти курс на Mentorix

🔐 Стань этичным хакером - с нуля до Pro Хочешь зарабатывать на поиске уязвимостей, а не бояться их? Этот курс проведёт тебя от первой команды в терминале до реальных техник пентеста. Что внутри: → Разведка целей: nmap, curl, анализ заголовков → Криптография и разбор кода на практике → Эксплуатация уязвимостей и документирование находок → Только живые задачи — никакой воды Без скучной теории. Только то, за что платят в bug bounty и на собеседованиях в InfoSec. 📈 От «что такое порт» — до отчёта пентестера за несколько недель. 👉 Записывайся на Stepik и начни взламывать легально уже сегодня.

👣 Почта прямо в терминале: Go-разработчикам завезли Matcha Matcha - это мощный email-клиент для терминала, написанный на Go и Bubble Tea. Идея простая: не выходить из CLI даже ради почты. Можно читать письма, отправлять ответы, работать с несколькими аккаунтами и rich content прямо из терминального интерфейса. Что внутри: - TUI-интерфейс на Bubble Tea - поддержка нескольких аккаунтов - встроенная система плагинов - 35+ community plugins - marketplace прямо из терминала - CLI-команда для отправки писем - поддержка AI-agent сценариев - AI rewrite plugin для черновиков через OpenAI, Ollama, Gemini или Claude Отдельно интересно, что Matcha можно использовать не только как «почту для гиков», но и как инструмент для агентных workflow: агент может отправлять письма через matcha send без интерактивного интерфейса. Для тех, кто любит терминал, Go и красивые TUI-приложения - проект точно стоит посмотреть. https://github.com/floatpane/matcha #golang

Kubernetes сам по себе ничего не решает. Сила появляется, когда начинаешь правильно его комбинировать Именно связки инструментов превращают кластер в полноценную платформу База, без которой никуда K8s + Docker даёт стандарт оркестрации контейнеров K8s + Terraform автоматизирует поднятие инфраструктуры K8s + Helm убирает боль с деплоем и версиями K8s + ArgoCD закрывает GitOps и делает релизы предсказуемыми Наблюдаемость и безопасность K8s + Prometheus + Grafana дают полный контроль над метриками K8s + Vault решает проблему секретов без костылей K8s + Cilium добавляет нормальную сетевую безопасность и observability K8s + OPA позволяет внедрить policy as code и контролировать всё на уровне кластера Трафик и масштабирование K8s + NGINX Ingress или Envoy дают контроль над L7 трафиком K8s + Istio превращает всё это в полноценный service mesh K8s + KEDA добавляет event-driven scaling, без ручного тюнинга AI и платформенная инженерия K8s + Ollama + KServe позволяют гонять LLM-инференс в проде K8s + Kubeflow закрывает ML пайплайны K8s + Crossplane делает из Kubernetes основу для platform engineering По факту Kubernetes это не инструмент, а каркас И то, во что он превратится, полностью зависит от того, какие связки ты соберёшь

⚡️k6 вышла версия 2: нагрузочное тестирование без боли и шаманства Если сервис падает только после релиза, проблема не в проде. Проблема в том, что его нормально не давили до прода. Grafana k6 - open-source инструмент для нагрузочного тестирования, где сценарии пишутся как код на JavaScript, а движок внутри сделан на Go. То есть тест можно хранить в репозитории, гонять в CI и проверять не «на глаз», а по нормальным метрикам. Что умеет k6: - генерировать нагрузку даже с обычной машины - описывать тесты кодом и версионировать их - проверять HTTP, WebSockets, gRPC, Browser-сценарии и не только - задавать thresholds, например «99% запросов должны быть быстрее 3 секунд» - экспортировать метрики в Grafana и другие системы - расширяться через экосистему плагинов GitHub: https://github.com/grafana/k6

Как выйти в мидлы+ Golang на "стагнирующем" рынке — без года проб и отказов Камиль (IT Отец) — ex‑lead в бигтехе, senior с 13+ годами опыта в корпорате и ментор с 50+ трудоустроенными учениками — открыл доступ к Backend 250k+ Offer Kit — ультимативный гайд получения крупных офферов в 2026 году для джунов и тех, кто застрял на низких грейдах Пройдя его, ты: ▪️ Поймешь реальный контекст рынка, узнаешь с кем на самом деле предстоит конкурировать за оффер, ▪️ Заберешь ТОП-3 стратегии добычи оффера на "стагнирующем рынке", ▪️Через инструменты в ките проапгрейдишь свое резюме и самопрезентацию, чтобы не быть ред-флагом для hr'ов, ▪️Узнаешь, какие 4 столпа определяют Middle-разработчика: что учить и насколько глубоко, ▪️И в конце получишь 2 понятные стратегии выживания на испытательном сроке, чтобы ты закрепился на островке стабильной ЗП ⚡️ Также Камиль бонусом бесплатно отдает 2 роадмапа из своего платного сообщества (общий backend + golang), чтобы ты не тратил время на хаотичный поиск информации в интернете. Забирай и применяй все инструменты из backend offer kit: ➡️ @CodemaniaProBot erid 2W5zFGLoDaR

M:N concurrency - одна из причин, почему Go так хорошо чувствует себя на сетевых сервисах. Идея простая: у вас может быть миллион маленьких задач, но это не значит, что под каждую нужен отдельный поток операционной системы. Runtime берёт много лёгких goroutine и сам распределяет их по меньшему числу реальных OS threads. Получается схема M:N: много пользовательских задач на несколько системных потоков. Из-за этого goroutine можно создавать тысячами и десятками тысяч без такого же дикого расхода памяти, как у обычных threads. А scheduler сам решает, кто сейчас работает, кого поставить на паузу, кого перенести на другой поток и как не дать одной задаче заблокировать весь процесс. В статье хорошо объясняется, почему это сложнее, чем кажется. За красивым go func() скрываются work stealing, preemption, blocking syscalls, queues, stacks, parking и постоянная борьба за баланс между latency и throughput. Для разработчика это полезно не ради теории. Когда понимаешь M:N модель, становится проще объяснить, почему одна программа летает на тысячах соединений, а другая внезапно упирается в scheduler, locks или blocking I/O. Go выглядит простым снаружи. Но внутри его конкурентность - это очень плотный кусок runtime-инженерии. 0xkiire.com/mn-concurrency-model/

👣 Go-разработчиков много. Backend-инженеров на Go, которые умеют строить реальные сервисы, гораздо меньше. Этот курс не про «выучить синтаксис» и поставить галочку напротив goroutines. Он про другое: научиться писать backend на Go так, как его ждут в продакшене. Вы разберёте, как устроены сервисы, которые: - принимают тысячи запросов; - не разваливаются под нагрузкой; - работают с базами данных; - используют очереди и микросервисы; - обрабатывают конкурентность без хаоса; - логируются, тестируются и масштабируются; - выглядят как коммерческий backend, а не учебная поделка. После курса у вас будет не просто знание Go, а понятный инженерный навык: спроектировать, написать и довести до рабочего состояния быстрый backend-сервис. Это тот уровень, после которого в резюме можно писать не «знаю Go», а «умею делать production-ready сервисы на Go». Для кого курс: - для тех, кто уже устал от абстрактных туториалов; - для начинающих backend-разработчиков; - для Python, JavaScript, PHP или Java-разработчиков, которые хотят перейти в Go; - для тех, кто хочет брать коммерческие backend-задачи, а не просто смотреть видео. 48 часов скидка 50% на Stepik: https://stepik.org/a/274119/

Claude ускорил production-код в 2 500 раз incident.io показали редкий нормальный кейс использования ИИ в разработке: не «сделай мне стартап за вечер», а скучная, больная и дорогая оптимизация реального production-кода. У них был рендер on-call расписаний. На бумаге звучит просто: кто сегодня дежурит, кого пейджить, когда смена. В реальности там ад из рабочих часов, оверрайдов, разных ротаций, daylight saving time и старых исторических записей. Старый алгоритм часто просто шёл по времени шаг за шагом от стартовой даты. Иногда это означало сотни тысяч итераций, чтобы понять, кто сейчас on-call. Команда уже пыталась ускорить это вручную. Были flame graph, бинарный поиск, фиксы в горячих местах, удаление лишних UUID, кеширование timezone. Всё помогало, но не решало главную проблему: алгоритм всё ещё делал слишком много работы. Потом они дали Claude Opus 4.6 CPU-профили и попросили найти математически более умный способ не перебирать каждую неделю, день или час с начала расписания. Через 20 минут Claude собрал RenderV2. Новая версия не ползла по истории, а «перепрыгивала» сразу к нужной точке, восстанавливала правильного дежурного и считала только видимое окно. Плюс Claude сам добавил dry-run режим: старый и новый рендер работали параллельно, а все расхождения логировались. Самое интересное: в процессе раскатки Claude нашёл баг в старом рендере, связанный с переходом на летнее время. То есть ИИ не просто ускорил код, а помог поймать ошибку, которая годами сидела в логике дат. После недели без предупреждений incident.io полностью переключились на новый рендер. Итог: p99 ответа schedule API упал с 2 секунд до 200 мс, а сам render method на сложных расписаниях стал примерно в 2 500 раз быстрее. Вот это и есть настоящий AI-assisted coding. Не вайбкодинг, не магия и не «агент всё сделал сам». А инженер с профилями, тестами, feature flag, production-телеметрией и ИИ, который помогает найти ход, до которого команда долго не доходила руками. https://incident.io/blog/whos-on-call-how-claude-helped-us-calculate-this-2-500-x-faster