Матрица навыков Go developer

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

Не игнорирует ошибки, оборачивает их с контекстом, различает sentinel errors и кастомные типы.

Проектирует зависимости через интерфейсы, разделяет domain, transport и infrastructure слои.

Улучшает структуру кода, сохраняя поведение и обратную совместимость.

Предпочитает стандартную библиотеку перед внешними зависимостями там, где это разумно.

Определяет соглашения по package layout, стратегии ошибок, code review и общим утилитам.

Создаёт переиспользуемые компоненты, которые снижают когнитивную нагрузку и не создают лишней связности.

Выявляет архитектурные риски, potential data races и проблемы совместимости в PR.

Задаёт структуру репозитория так, чтобы команда двигалась единообразно и не принимала ad-hoc решений.

Разрешает разногласия в команде по техническим подходам, аргументируя через принципы, а не вкусовщину.

Создаёт среду, где ревью приносит ценность: учит, а не придирается, снижает риски, а не затягивает поставку.

Отслеживает накопление tech debt и включает его погашение в roadmap наравне с новыми фичами.

Формирует engineering handbook с обоснованными решениями, которые работают в разных контекстах.

Оценивает зависимости по критериям: стабильность, поддержка, безопасность, lock-in риски.

Планирует эволюцию стандартов с учётом роста команды, масштаба системы и бизнес-направления.

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

Выступает на конференциях, пишет статьи, участвует в open-source — формирует внешний авторитет.

Добавляет concurrency только там, где это оправдано, без data races и утечек.

Пробрасывает context через цепочку вызовов, корректно реагирует на отмену.

Проектирует пулы с ограниченным параллелизмом, контролирует backpressure и graceful shutdown.

Обрабатывает временные сбои без перегрузки downstream-сервисов.

Выявляет и устраняет утечки goroutine при ревью и профилировании.

Выбирает synchronization patterns исходя из throughput, latency и production failure modes.

Использует -race детектор, pprof и трейсинг для поиска concurrency-проблем.

Определяет, какой паттерн (pipeline, fan-out, semaphore, worker pool) использовать в каждом контексте.

Выбирает базовые worker, queue и cancellation patterns так, чтобы команда не создавала нестабильных решений.

Выявляет риски в критичных путях: deadlocks, starvation, thundering herd.

Убеждается, что CI включает race detector и что критичные concurrency-сценарии покрыты тестами.

Выбирает модели ограничения нагрузки на уровне нескольких сервисов и команд.

Определяет, как масштабировать параллельную обработку без деградации смежных систем.

Задаёт принципы graceful degradation и circuit breaking на уровне домена.

Проводит архитектурный анализ на предмет скрытых race conditions и deadlock-рисков в интеграциях.

Использует JOIN, WHERE, индексы и параметризованные запросы, избегает SQL-инъекций.

Создаёт up/down миграции, понимает порядок применения и обратимость изменений схемы.

Читает EXPLAIN, добавляет индексы, устраняет N+1, переписывает subquery в JOIN там, где нужно.

Нормализует данные разумно, учитывает nullable, constraints и сценарии удаления.

Выбирает правильный уровень изоляции, избегает deadlocks и long-running транзакций.

Определяет naming conventions, обязательные индексы, правила nullable и migration workflow.

Применяет zero-downtime паттерны: expand-contract, column backfill в несколько деплоев, lock-free alter.

Решает, когда нужен read replica, шардирование, кэш или event sourcing вместо classical CRUD.

Настраивает pgxpool/sqlx параметры, контролирует max connections, timeout и health check.

Проверяет, что миграции протестированы, обратимы и не вызовут деградации в production.

Координирует database changes между несколькими сервисами и командами.

Определяет, кто и как добавляет индексы, как проходит review схемы, кто отвечает за performance regression.

Запрещает или согласует DROP, NOT NULL без default, full-table lock изменения в peak hours.

Выбирает между SQL, NoSQL и смешанными хранилищами в зависимости от нагрузки, структуры и SLO.

Закладывает partitioning, sharding и geo-distribution на уровне платформы.

Определяет RPO/RTO, тестирует восстановление, формирует runbook для инцидентов с данными.

Прогнозирует рост объёмов, затраты на хранение и вовремя инициирует архитектурные изменения.

Обеспечивает выполнение GDPR, retention policy и audit trail на уровне нескольких систем.

Понимает at-least-once семантику, не теряет и не дублирует сообщения без причины.

Публикует события с нужной структурой, обрабатывает ошибки отправки.

Обрабатывает дубликаты через deduplication key или идемпотентные операции в БД.

Настраивает DLQ, алерты на lag и процедуру reprocess для сломанных сообщений.

Настраивает мониторинг отставания consumer, выявляет и устраняет причины накопления.

Выбирает паттерн outbox, saga или choreography в зависимости от требований к консистентности.

Определяет schema событий, versioning strategy и backward/forward compatibility.

Аргументирует выбор, понимая tradeoffs: latency, coupling, failure isolation, observability.

Определяет, какой брокер и паттерн использовать в каких сценариях, документирует решения.

Обеспечивает алерты на lag, DLQ рост и partition skew; налаживает runbook для on-call.

Координирует изменения в event schema между producer и consumer командами.

Ведёт реестр событий, согласует breaking changes и организует совместное тестирование контрактов.

Выбирает брокеры, паттерны доставки и retention policy для всего домена.

Задаёт, где хранить event log, как строить проекции и как обеспечить replay.

Определяет уровень exactly-once или idempotency для критичных бизнес-операций.

Анализирует cascade failure, ordering проблемы и distributed transaction риски.

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

Запускает зависимости (БД, очереди, сервисы) локально, понимает volumes и сетевой namespace.

Правильно упорядочивает инструкции для кэширования слоёв, использует .dockerignore.

Реализует /healthz endpoint, обрабатывает SIGTERM и ждёт завершения активных запросов.

Читает логи, проверяет ресурсы, исследует файловую систему, работает с exec в prod-подобной среде.

Определяет базовые образы, linting правила и review checklist для контейнерных артефактов.

Обеспечивает, чтобы локальный Compose и production среда отличались минимально.

Запускает trivy/grype, отслеживает CVE в базовых образах, задаёт non-root user.

Выбирает и поддерживает golden images, управляет их обновлением и уведомлением команды.

Определяет политику запуска: non-root, read-only filesystem, resource limits, seccomp.

Обеспечивает регулярное обновление базовых образов и Go-зависимостей с проверкой на уязвимости.

Добавляет автоматический image scan в pipeline, настраивает severity threshold и уведомления.

Выбирает runtime (Docker, containerd), orchestration и image registry стратегию.

Стандартизирует approved base images, enforcement механизм и process их обновления.

Стандартизирует log format, metrics exposition, tracing injection на уровне платформы.

Формирует RFC и ADR для платформенных решений, получает buy-in от tech leads команд.

Разбирается в шагах CI: lint, test, build, deploy — знает, что каждый делает и где искать причину сбоя.

Умеет найти причину нестабильного теста: race condition, зависимость от порядка, внешний сервис.

Конфигурирует lint, test, build и deploy шаги с нужными environment variables и secrets.

Параллелизует шаги, кэширует зависимости и модули, сокращает холодный старт.

Разворачивает изменения постепенно, умеет откатить без downtime.

Выбирает rolling, canary или blue/green исходя из SLO, объёма трафика и критичности.

Определяет обязательные шаги: lint, security scan, test coverage, smoke test после деплоя.

Документирует и тестирует процедуру отката, убеждается, что команда может откатить под давлением.

Блокирует деплой при деградации coverage, появлении CVE выше порога или падении smoke тестов.

Определяет, что нужно для production-ready: checklist, approvals, observability requirements.

Балансирует скорость поставки и контроль риска: кто аппрувит, при каких условиях автоматически.

Проверяет, что сервис имеет healthcheck, метрики, алерты, runbook и документацию до деплоя.

Координирует release windows, feature flags и зависимости при совместных поставках.

Выбирает модель деплоя и инструменты CI/CD на уровне нескольких команд.

Задаёт принципы feature flags, traffic splitting и automated rollback на уровне платформы.

Определяет допустимое время сборки, процент flaky тестов и MTTR для CI-инфраструктуры.

Задаёт правила для hot fix, emergency deploy и change freeze — с балансом скорости и безопасности.

Измеряет DORA-метрики, находит ограничения и инициирует улучшения на уровне платформы.

Покрывает happy path и основные error branches, не тестирует детали реализации.

Структурирует тест-кейсы через subtests, избегает дублирования и делает тесты читаемыми.

Использует testcontainers или embedded БД — проверяет реальное поведение, а не моки.

Выбирает между interface mock и HTTP stub в зависимости от уровня теста.

Измеряет производительность функций, отслеживает регрессии через benchcmp.

Задаёт баланс между unit, integration и e2e тестами с учётом скорости и уверенности.

Использует Pact или schema-based approach для проверки совместимости между сервисами.

Отличает полезное coverage от бессмысленного, фокусируется на критичных сценариях.

Закладывает dependency injection и явные границы в дизайн, чтобы тестирование не требовало героизма.

Определяет, без чего PR не принимается: минимум coverage, обязательные сценарии, performance tests.

Следит за тем, чтобы после каждого инцидента добавлялся тест, предотвращающий повтор.

Ревьюит и удаляет тесты, которые только замедляют CI, но не повышают уверенность.

Ведёт список известных пробелов в покрытии и включает их устранение в roadmap.

Задаёт, как совокупность тестов разных уровней обеспечивает уверенность в поставке.

Определяет требования к load testing, chaos engineering и failure injection для критичных систем.

Внедряет systematic failure experiments для выявления слабых мест до production инцидентов.

Задаёт технические условия запуска новых сервисов с высоким SLO: тесты, нагрузка, DR.

Логирует достаточно, чтобы понять runtime behavior, без чувствительных данных и лишнего шума.

Читает существующие grafana-дашборды, понимает базовые RED-метрики своего сервиса.

Читает distributed traces, correlates logs и изолирует bottleneck или regression.

Создаёт алерты на error rate, latency p95 и saturation с правильными thresholds и runbook.

Отличает p50 от p99, понимает tail latency и влияние GC pauses на графики.

Выбирает значимые индикаторы качества, согласует цели с продуктом и устанавливает error budget.

Определяет стандарты именования, labeling и cardinality ограничения для Prometheus.

Инструментирует сервисы с правильным span context, baggage и sampling strategy.

Пишет blameless постмортем, выявляет системные причины и формирует action items.

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

Регулярно ревьюит алерты: убирает лишние, улучшает thresholds, добавляет runbook.

Гарантирует, что у каждого сервиса есть runbook, алерты с описанием и escalation path.

Нормализует blameless review, следит за выполнением action items и делится знаниями с командой.

Выстраивает единый подход к SLO, error budget и incident management для всего домена.

Формирует dependency SLA между командами, связывает бюджеты с приоритетами поставки.

Определяет платформенные инструменты сбора, хранения и визуализации observability данных.

Создаёт систему, при которой production-сигналы регулярно влияют на приоритеты команд.

Задаёт severity levels, escalation matrix, communication protocol и learning system для инцидентов.

Разбивает задачу на понятные шаги, уточняет неясное до начала работы.

Не застревает молча дольше дня — сигнализирует о блокере и предлагает варианты.

Сам определяет подход, согласует его и доводит до production без потери промежуточных шагов.

Предлагает конкретный вариант с tradeoffs, а не задаёт открытый вопрос «как делать».

Держит задачи в актуальном состоянии, сам расставляет приоритеты в рамках sprint-цели.

Замечает проблемы в системе и предлагает решение, не дожидаясь, пока кто-то поставит задачу.

Ведёт несколько задач одновременно, не теряет контекст и не создаёт bottleneck для команды.

Двигается вперёд с неполной информацией, фиксирует допущения и готов пересмотреть решение.

Управляет техническим backlog, задаёт направление и держит скорость без ежедневного менеджмента.

Балансирует новые фичи, tech debt и reliability work с учётом бизнес-контекста.

Самостоятельно оценивает и митигирует технические риски, эскалирует только существенные.

Помогает команде двигаться, не беря на себя чужую работу целиком.

Сам определяет, какие проблемы важны, и инициирует работу без внешнего запроса.

Выявляет системные проблемы и организует работу нескольких команд для их решения.

Удерживает в фокусе долгосрочные риски: vendor lock-in, architectural debt, skill gap.

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

Видит и управляет технической стратегией на 12–24 месяца вперёд.

Описывает, что изменено, зачем и как проверить — ревьюер не должен реконструировать контекст.

Следует принятому формату, описывает суть изменения, а не процесс работы.

Объясняет, почему выбрано именно это решение, какие альтернативы рассматривались.

Добавляет комментарий не «что», а «почему» — там, где логика неочевидна.

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

Описывает проблему, предложение, альтернативы и риски так, чтобы получить качественный feedback.

Записывает значимые архитектурные решения с контекстом, чтобы будущие инженеры понимали «почему».

Выбирает правильный формат: RFC, design doc, spike summary — в зависимости от сложности и аудитории.

Создаёт шаблоны и чеклисты, объясняет команде ценность хороших артефактов.

Возвращает на доработку PR и задачи без контекста, формирует ожидания на примерах.

Переводит технические решения в бизнес-язык: риски, сроки, влияние.

Поощряет async-first подход, документирование решений и прозрачность процессов в команде.

Определяет, когда нужен RFC, как он проходит ревью и как решения фиксируются и доступны.

Адаптирует технический документ для инженеров, менеджмента и внешних партнёров.

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

Пишет principles, manifesto и best practices, которые становятся ориентиром для команд.

Обновляет инструкции по запуску, env-переменным и зависимостям при каждом изменении.

Описывает назначение env-переменных, допустимые значения и поведение по умолчанию.

Описывает как запустить, остановить, откатить и продиагностировать сервис в production.

Поддерживает OpenAPI spec или аналог в синхронизации с кодом при каждом изменении контракта.

Описывает типовые операции: миграции, плановые рестарты, ротацию секретов.

Синхронизирует диаграммы и описания с реальным состоянием системы, не допускает устаревания.

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

Организует документацию так, чтобы нужное было легко найти и находилось в актуальном состоянии.

Определяет структуру, обязательные разделы и процесс обновления для разных типов документов.

Проверяет, что у каждого production сервиса есть runbook, alert descriptions и escalation path.

Выбирает инструменты и процессы для накопления и передачи знаний внутри команды.

Обеспечивает соответствие документации внешним требованиям: security review, vendor audit.

Задаёт, как знания накапливаются, структурируются и передаются между командами.

Обеспечивает, чтобы cross-team архитектурные решения были зафиксированы и доступны.

Формирует стандарты runbook, постмортема и incident report на уровне нескольких команд.

Делится опытом команды через блог, конференции и open-source — создаёт внешний технический авторитет.

Сообщает, что сделано, что осталось и есть ли блокеры — без необходимости уточнять.

Уточняет требования до начала работы, а не переделывает после завершения.

Адаптирует уровень детализации к аудитории, не уходит в детали реализации там, где нужен результат.

Даёт конкретный, действенный feedback — указывает на проблему и предлагает путь решения.

Говорит о проблемах прямо и без агрессии, принимает критику без защитной реакции.

Структурирует обсуждение, удерживает фокус и помогает группе прийти к конкретному выводу.

Регулярно синхронизируется, держит партнёров в курсе, не создаёт неожиданностей.

Находит компромисс или аргументированно убеждает, не втягивая менеджмент без необходимости.

Выступает от имени команды на кросс-командных встречах, транслирует приоритеты и ограничения.

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

Заблаговременно сигнализирует о рисках, изменении сроков и влиянии технических решений.

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

Создаёт среду, где люди не боятся высказывать идеи, признавать ошибки и задавать вопросы.

Представляет технические позиции на уровне директоров, партнёров и внешних аудиторий.

Создаёт форумы для обмена знаниями и решения общих проблем между командами.

Убеждает ключевых stakeholders в необходимости изменений, формирует коалицию поддержки.

Даёт ясные ориентиры команде и партнёрам, когда стратегия ещё формируется.

Выступает на конференциях, ведёт технический блог — формирует reputation компании в инженерном сообществе.