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 не «избегает конфликтов» — он переводит их из эмоциональной плоскости в плоскость данных, рисков и trade-off'ов.
- Технические споры решаются критериями, а не громкостью голоса: SLA, стоимость, сроки, поддерживаемость, обратимость решения.
- **Disagree and commit** — ключевой навык: ты можешь быть против, но после принятия решения исполняешь его как своё и не саботируешь.
- С легаси работаешь инкрементально и с измеримой ценностью, а не «давайте всё перепишем».
- Со стейкхолдерами говоришь на их языке (деньги, риски, сроки, клиент), а не на языке стектрейсов.
- Пушбэк на нереалистичные сроки — это не «нет», а «вот варианты scope/quality/time, выбирайте».

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

### Природа конфликта на senior-уровне
Интервьюер проверяет не «бесконфликтность» (это red flag — значит человек либо избегает ответственности, либо врёт), а **зрелость**: умеешь ли ты не доводить разногласие до личного, отделять позицию человека от проблемы, и доводить ситуацию до решения, с которым команда может жить.

Базовая модель ответа на любой конфликтный вопрос — **STAR + урок**:
- **Situation** — короткий контекст (1-2 предложения).
- **Task** — в чём была твоя зона ответственности.
- **Action** — что конкретно *ты* сделал (не «мы»).
- **Result** — измеримый итог.
- **Урок** — что бы сделал иначе / что вынес.

Важно: на senior+ интервьюер слушает прежде всего **Action** и проверяет, не свалил ли ты вину на других.

### Разногласия по техническим решениям
Принцип: **спор должен иметь критерий разрешения**. Если два инженера спорят «gRPC vs REST» без критериев — это religious war. Senior сразу спрашивает: «По какому признаку мы поймём, кто прав? Latency? Команда уже знает технологию? Стоимость поддержки?»

Алгоритм:
1. Зафиксировать, что цель у всех общая (надёжный сервис, а не «моя правота»).
2. Выписать варианты и trade-off'ы письменно (мини-RFC / Decision Doc / ADR).
3. Привести данные: бенчмарк, прототип, цифры из прода.
4. Если данные не решают — выбрать **обратимое** решение (two-way door) и заложить точку пересмотра.
5. Эскалировать к решающему лицу (tech lead / архитектор), если deadlock.

Пример формулировки:
> «Мы с коллегой разошлись: он за то, чтобы вынести логику в отдельный микросервис, я считал, что это преждевременно. Вместо спора я предложил критерии: текущая нагрузка, частота релизов этого модуля, размер команды. По цифрам выходило, что выделять рано — связность данных высокая, отдельный деплой даст больше боли, чем пользы. Я набросал короткий decision doc с обоими вариантами и метриками, мы прошлись по нему с тимлидом. Решили оставить монолит, но выделить чёткий пакет-границу, чтобы вынести потом дёшево. Через полгода границы как раз пригодились, когда нагрузка выросла.»

### Disagree and commit
Это не «прогнуться». Это: я честно высказал аргументы, решение приняли против меня, и теперь я **исполняю его добросовестно** и не хожу по углам с «я же говорил». Саботаж принятого решения — главный признак не-senior.

Где проходит красная линия: если решение этическое или критично по безопасности/данным — там не commit, а письменная фиксация несогласия и эскалация. Senior отличает «мне не нравится подход» (commit) от «это приведёт к утечке персональных данных» (escalate).

Пример формулировки:
> «Я был против выбранной очереди — считал, что для нашего профиля нагрузки Kafka избыточна. Но команда и тимлид взвесили и решили иначе, аргументы были разумные. Я записал свои опасения в ADR, чтобы при ретро было видно контекст, и дальше вкладывался в решение полностью — написал обвязку, документацию, обучил двоих. В итоге опасения частично подтвердились по стоимости эксплуатации, но мы это спокойно обсудили на ретро без "я же говорил".»

### Работа с легаси
Антипаттерн — «давайте всё перепишем». Senior знает, что Big Bang rewrite почти всегда проигрывает (теряется знание, зашитое в багфиксах, бизнес встаёт на полгода). Подход:
- **Понять, почему код такой** — обычно за «уродством» стоят реальные требования и хотфиксы.
- **Покрыть тестами / characterization tests** перед изменением.
- **Strangler Fig** — постепенно перенаправлять трафик на новый код, оставляя старый рабочим.
- **Привязать рефакторинг к бизнес-ценности** — рефакторить то, что часто меняется или часто ломается, а не то, что эстетически не нравится.
- Boy Scout Rule: оставляй модуль чуть чище, чем нашёл, в рамках текущей задачи.

Пример формулировки:
> «Достался сервис без тестов, который все боялись трогать. Я не стал предлагать переписать — вместо этого добавил characterization-тесты на ключевые сценарии, чтобы зафиксировать текущее поведение, потом по Strangler перенёс самый горящий кусок (расчёт цены, который чаще всего ломался) за новый интерфейс. Рефакторинг я обосновал не "код плохой", а тем, что этот модуль давал 40% инцидентов. После этого инциденты по нему упали, и команда перестала бояться релизов.»

### Общение со стейкхолдерами
Главное правило: **переводи технику в их валюту**. Продакт думает фичами и сроками, бизнес — деньгами и рисками, поддержка — количеством тикетов. «У нас техдолг» им не говорит ничего; «из-за этого участка кода каждый релиз занимает на 2 дня дольше и даёт N инцидентов» — говорит.

Приёмы:
- Начинай с вывода/рекомендации, потом обоснование (пирамида Минто).
- Давай варианты с trade-off'ами, а не один ультиматум.
- Не прячь плохие новости — приноси их рано и с планом.
- Управляй ожиданиями: лучше обещать консервативно и перевыполнить.

Пример формулировки:
> «Продакт хотел фичу к дате запуска маркетинга. Я не сказал просто "не успеем". Я показал: есть полный вариант на 3 недели и есть MVP на 1 неделю без редактирования и с ручной модерацией. Объяснил, что MVP покрывает 80% сценариев запуска, а остальное докатим следом. Он выбрал MVP, маркетинг не сдвинулся, и мы не выгорели.»

### Пушбэк на нереалистичные сроки
Senior никогда не говорит просто «нет» и не молча геройствует, выгорая. Он делает дедлайн **разговором о trade-off'ах** через треугольник scope / time / quality (resources обычно не масштабируется мгновенно — закон Брукса).

Алгоритм:
1. Уточнить, откуда дата и что за ней стоит (жёсткое внешнее обязательство или «хотелось бы»).
2. Дать честную оценку с разбивкой и допущениями.
3. Предложить варианты: урезать scope, сдвинуть дату, осознанно срезать quality (с явной фиксацией техдолга), фазировать поставку.
4. Подсветить риски молчаливого согласия (что сломается, какой долг накопится).
5. Зафиксировать решение письменно.

Пример формулировки:
> «Мне дали 2 недели на то, что честно тянет на 5. Я не стал кивать. Разбил задачу, показал, где основная неопределённость — интеграция со сторонним API без песочницы. Предложил три варианта: выкатить к дате только happy-path и без retry-логики, сдвинуть на неделю ради устойчивости, либо параллельно подключить второго человека на интеграцию. Менеджер выбрал фазирование. Главное — я зафиксировал, что happy-path-версия требует доработки в следующем спринте, чтобы это не забылось как "уже сделано".»

## Антипаттерны
- **«У меня не было конфликтов»** — звучит как избегание ответственности или неумение в рефлексию.
- **Обвинение других** — «команда тупила», «менеджер не понимал». Интервьюер сразу ставит минус.
- **Геройство в ущерб себе и команде** — молча согласиться на нереальный срок и выгореть.
- **Религиозные войны** без критериев — спор ради правоты, а не результата.
- **Big Bang rewrite** легаси без тестов и без бизнес-обоснования.
- **«Я же говорил»** после disagree and commit — саботаж принятого решения.
- **Техножаргон со стейкхолдерами** — «у нас гонка горутин», когда надо «сервис иногда отдаёт неверные данные под нагрузкой».
- **Конфликт переходит на личность** — «он всегда так делает» вместо «это решение даёт такие риски».
- **Эскалация как первый шаг** вместо попытки решить на своём уровне (или наоборот — эскалация слишком поздно, когда уже горит).

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

**В:** Расскажи о техническом разногласии с коллегой. Как разрешили?
**О:** STAR. Подчеркни: общая цель, перевод спора в критерии, данные/прототип, письменная фиксация, и итог — включая что отношения с коллегой не пострадали. Главное — покажи, что был готов оказаться неправым.

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

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

**В:** Продакт настаивает на сроке, который нереален. Твои действия?
**О:** Не «нет», а варианты через scope/time/quality. Честная оценка с допущениями, подсветка рисков молчаливого согласия, письменная фиксация выбранного варианта и накопленного долга.

**В:** Как объяснишь не-техническому стейкхолдеру, зачем нужен месяц на техдолг?
**О:** Переведи в их валюту: скорость релизов, число инцидентов, риск для конкретного клиента/выручки. Дай варианты (всё/частично/ничего) с последствиями каждого. Не моральное «надо», а цифры и риск.

**В:** Опиши конфликт, который ты разрешил *плохо*. Что бы сделал иначе?
**О:** Не уходи в «у меня всё всегда хорошо». Возьми реальный кейс, где, например, эскалировал слишком поздно или продавил своё решение силой авторитета. Покажи рефлексию и конкретное изменение в поведении.

**В:** Член твоей команды постоянно не согласен и тормозит решения. Как поступишь?
**О:** Сначала 1:1 — понять, это техническая позиция или что-то личное/процессное. Дать пространство высказаться, ввести критерии и таймбокс на решение, при deadlock — эскалация с зафиксированными вариантами. Цель — разблокировать команду, не «победить» человека.

**В:** Тебе дали задачу, которая, по-твоему, вообще не нужна бизнесу. Что делаешь?
**О:** Не молча делать и не молча отказываться. Уточнить цель и метрику успеха задачи у заказчика — часто всплывает контекст, которого не видел. Если после этого всё ещё считаешь её бесполезной — аргументировать с альтернативой, но быть готовым к disagree and commit.

## На что копают на senior+
- **«Я» vs «мы»**: senior берёт ответственность за конкретные действия, а не прячется за командой. Но и не приписывает себе всё.
- **Перевод на язык бизнеса**: умеешь ли ты говорить со стейкхолдерами не стектрейсами, а рисками/деньгами/сроками.
- **Обратимость решений**: понимаешь ли разницу между one-way и two-way door — для обратимых решений быстро коммититься, для необратимых требовать данных.
- **Управление вверх (managing up)**: пушбэк на сроки и на менеджмент — без агрессии, через варианты и фиксацию.
- **Эмоциональная зрелость**: отделяешь позицию от человека, не носишь обиды, чинишь отношения после конфликта.
- **Системность**: после конфликта меняешь *процесс* (ADR, критерии, ретро), чтобы такое не повторялось, а не только тушишь конкретный пожар.
- **Где красная линия**: понимаешь, когда disagree-and-commit неуместен (безопасность, данные, этика, legal) и надо эскалировать письменно.