---

**Резюме содержательно хорошее, но опыт выглядит сильнее, чем его подача.** Главные слабости: четыре страницы, много описаний действий вместо результатов и недостаточно доказательств уровня «ведущий разработчик». **Для ATS сам PDF выглядит нормально:** текст успешно извлёкся двумя разными парсерами, включая кириллицу, даты и навыки. Разбор по :codex-file-citation{path="/Users/a.povolockii/Downloads/Ушков Николай Васильевич.pdf" purpose="source"}.

Сильные стороны: реальные коммерческие проекты, понятные предметные области, PostgreSQL, интеграции, асинхронное взаимодействие, Temporal и идемпотентность. Переход с .NET на Go объяснён честно. В Hyundai уже есть полезный результат — автоматизация ручного сбора данных.

**Что стоит поправить в первую очередь:**

1. **Яснее показать общий опыт и стаж именно на Go.**  
   Общий backend-опыт — около пяти лет. Go указан только в текущей компании с ноября 2025 года, причём сначала там была работа на .NET. Точная продолжительность коммерческого Go-опыта непонятна. Для вакансий с требованием «3+ года Go» это может стать причиной отказа независимо от качества PDF.

   Укажи, с какого месяца работаешь на Go. В «Обо мне» замени «более 4 лет» на актуальное «5+ лет коммерческой backend-разработки».

2. **Превратить «ключевые достижения» в доказательства результата.**  
   Сейчас большинство пунктов — «разрабатывал», «реализовывал», «использовал». Они объясняют обязанности, но плохо показывают масштаб и ценность работы.

   Например, вместо длинного пункта про Temporal можно написать:

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

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

3. **Подкрепить должность «ведущий разработчик».**  
   По описанию виден backend-разработчик, но почти не виден масштаб ответственности ведущего. Неясно, какие решения принимал самостоятельно, за какие сервисы отвечал, проводил ли ревью, сопровождал ли релизы и production.

   Если это было, добавь 2–3 конкретных факта: архитектурное решение и его причины, ответственность за сервис от проектирования до эксплуатации, ревью или наставничество. Управление людьми необязательно — самостоятельная техническая ответственность тоже убедительна.

4. **Сократить до двух страниц как практическую цель.**  
   Четыре страницы для двух работодателей перегружают чтение. Особенно много повторов про REST API, PostgreSQL, миграции и бизнес-процессы.

   Я бы оставил:
   - текущую компанию: два Go-проекта с 3–4 сильными пунктами каждый; .NET-проект — компактно;
   - Hyundai: 5–6 пунктов суммарно;
   - один список стека на работодателя;
   - образование и языки — коротким блоком.

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

5. **Добавить доказательства инженерной глубины Go.**  
   Сейчас Go-опыт описан преимущественно через фреймворки и инфраструктуру. Не раскрыты тестирование Go-сервисов, работа с конкурентностью, отменой и таймаутами, диагностика производительности, обработка ошибок.

   Добавляй такие вещи только из реального опыта и через задачи. Например: какие интеграционные тесты написал или как устранил проблему с повторной обработкой сообщений. Перечень `goroutines, channels, context` сам по себе слабее конкретного примера.

6. **Привести навыки и оформление в порядок.**  
   `gRPC` есть в навыках, но применение нигде не показано. Kubernetes, Helm и observability перечислены в стеке, однако личный вклад неясен. Для каждого важного инструмента желательно понимать: настраивал сам, дорабатывал или использовал готовое окружение.

   Также стоит:
   - добавить C#/.NET в навыки как подтверждённый предыдущий опыт;
   - унифицировать `ClickHouse`, `Uber Fx`, названия технологий;
   - убрать дубли телефона и почты из «Обо мне»;
   - убрать медкнижку, самозанятость и время в пути из отдельной версии для отправки работодателю.

**По ATS: техническая читаемость хорошая, соответствие вакансии нужно оценивать отдельно.**

Я проверил все четыре страницы: PDF содержит настоящий текст, символы не разваливаются, разделы и навыки извлекаются. Разметка с датами слева не нарушила чтение в проверенных парсерах. Это положительный признак, **но не тест в конкретной ATS и не гарантия прохождения отбора**.

Для более предсказуемого распознавания отдельную версию лучше сделать с одной колонкой, обычными заголовками «Опыт работы», «Навыки», «Образование» и навыками в виде текста. Заголовок **«Go / Golang Backend Developer»** даст понятное название роли. Под конкретную вакансию используй её терминологию там, где она соответствует твоему опыту; добавлять отсутствующие технологии ради совпадений не стоит.

Блок «Обо мне» можно сократить до такого:

> Backend-разработчик с 5+ годами коммерческого опыта. В текущей компании разрабатываю сервисы на Go для платформы банковских гарантий и продуктового каталога кредитного конвейера. Основной стек: Go, PostgreSQL, Temporal, NATS JetStream. Опыт разработки REST API, внешних интеграций и отказоустойчивых бизнес-процессов. Ранее разрабатывал корпоративные backend-системы на C#/.NET.

**На Middle Go резюме выглядит убедительнее, чем на Senior/Lead Go.** Для Senior сильнее нужно раскрыть самостоятельность, сложные решения и эксплуатацию сервисов. Это оценка того, что доказывает документ, а не твоего реального уровня.

- Сократить резюме
- Адаптировать под вакансию
- Усилить достижения