Читают ли сопроводительное письмо DevOps-инженера?

Кто его читает

В большинстве технологических компаний заявка на позицию DevOps сначала проходит через ATS. Рекрутер или нанимающий менеджер просматривает резюме на предмет совпадения стека — Kubernetes, Terraform, AWS или GCP или Azure, используемый CI-инструмент, запускали ли вы что-то в продакшене, а не только в туториале. Если совпадения нет, сопроводительное письмо не открывается. Это не оценка вашего текста; так работает воронка, когда на позицию middle DevOps приходят заявки от людей, чей единственный опыт с инфраструктурой — университетский проект.

Письмо читают позже в процессе или в небольших компаниях, где нанимающий менеджер сам делает первичный отбор. В платформенной команде из шести человек в стартапе серии B часто ведущий инженер читает каждую заявку напрямую, потому что слоя рекрутеров ещё нет. В такой ситуации письмо читают внимательно, потому что человек, который его читает, будет получать алерты вместе с вами в 3 часа ночи и хочет понять, как вы пишете отчёт об инциденте, а не только знаете ли вы Helm.

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

Что оно должно делать, чего не может резюме

Ваше резюме перечисляет инструменты. Оно может содержать «Terraform, Ansible, ArgoCD, Prometheus, Grafana, GitLab CI» и пункт о миграции или сокращении времени деплоя. Чего оно не может хорошо показать — это почему вы приняли те решения, которые приняли, а именно это и волнует нанимающих менеджеров DevOps, потому что работа — это в основном оценочные суждения в условиях ограничений: переносить ли stateful-сервис в Kubernetes или оставить на управляемом инстансе, чинить ли нестабильный тест или изолировать его, будить ли кого-то в 2 ночи или подождать до утра.

Рабочее сопроводительное письмо для этой области отвечает на один или два вопроса, не больше:

Соответствует ли ваш опыт с инфраструктурой форме их окружения. Не просто названия инструментов, но масштаб и зрелость. «Работал с Kubernetes» значит разное в пятичеловеческом стартапе с одним EKS-кластером и в компании с сорока микросервисами и платформенной командой. Если в объявлении упомянуты multi-cluster, multi-region или конкретный режим соответствия (SOC 2, HIPAA, PCI-DSS), скажите прямо, работали ли вы в таком контексте и что это реально включало — логирование аудита, политику ротации секретов, согласование изменений, что там было. Расплывчатые заявления об «опыте с облачной инфраструктурой в масштабе» — это ровно то, что пишут все остальные кандидаты, и их пролистывают.

Можете ли вы взять на себя инцидент и рассказать о нём после. Это специфично для DevOps и SRE-смежных ролей так, как это не характерно для большинства инженерных позиций: в какой-то момент вы будете тем, кто объясняет комнате или документу постмортема, почему что-то упало и что изменилось в результате. Одно конкретное предложение об инциденте, который вы диагностировали, откате, который вы выполнили, или корневой причине, которую вы нашли, бьёт три предложения о том, что вы «увлечены надёжностью». Назовите режим отказа, если можете — плохой деплой, который пропустил health check, состояние Terraform, которое повредилось из-за блокировки, сертификат, который истёк, потому что обновление не было автоматизировано. Конкретика здесь читается как компетентность, потому что её очень сложно подделать.

Если в короткое письмо влезает только одна вещь, сделайте это историей инцидента или владения, а не списком инструментов — список инструментов уже есть в резюме.

Где письмо мало весит, а где нет

Будьте честны с собой в этом. Если роль в крупной организации со структурированным процессом — заявка, скрининг рекрутера, технический скрининг, интервью по системному дизайну, панель — письмо вряд ли будет решающим фактором. Оно может помочь пройти начальный фильтр, если явно написано кем-то, кто читал объявление, но домашнее задание или раунд системного дизайна у доски (спроектировать CI/CD-пайплайн для X, отладить сломанный Kubernetes-манифест, объяснить, как сократить MTTR для нестабильного сервиса) — это где принимается реальное решение. Никакое письмо не компенсирует неспособность объяснить, чем Terraform apply отличается от plan, или что происходит, когда readiness probe пода падает во время rolling update.

Где оно весит: небольшие команды, нанимающие первого или второго DevOps-инженера, роли, где явно упомянута кросс-функциональная коммуникация (потому что вы будете объяснять инфраструктурные решения разработчикам, которые не думают об этом ежедневно), и любая роль, где объявление само просит сопроводительное письмо и уточняет, что в нём должно быть. Если в объявлении написано «расскажите о продакшен-инциденте, с которым вы справились», эта инструкция не декоративная. Игнорировать её или отвечать общим энтузиазмом вместо этого — большая проблема, чем полностью пропустить письмо.

Есть также категория DevOps и платформенных ролей, где публичный GitHub, личный infrastructure-as-code репозиторий или пост в блоге о миграции делают больше работы, чем любое письмо. Если у вас есть такое, дайте ссылку в самом письме, а не прячьте её в резюме — нанимающий менеджер, который может увидеть ваши реальные Terraform-модули или Ansible-плейбуки, получает больше сигнала из десяти минут чтения кода, чем из десяти минут чтения текста о ваших навыках.

Как обращаться с неудобными моментами

Если вы переходите из sysadmin или NOC в DevOps-титул, или из разработки в инфраструктуру, скажите это прямо и объясните, что вы уже делали из пересекающегося — писали скрипты деплоя, управляли дежурствами, строили внутренний инструментарий — вместо того, чтобы резюме намекало на смену титула без причины. Нанимающие менеджеры в этой области видят много sysadmin'ов, меняющих бренд без опыта автоматизации и IaC, чтобы его подкрепить, и письмо, конкретное о том, что вы реально автоматизировали, против того, чем управляли вручную, читается более правдоподобно, чем то, что просто претендует на новый титул.

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

Что с этим делать

Откройте объявление снова и найдите конкретный стек и конкретную болевую точку, которую оно называет — миграцию, нагрузку дежурств, проблему надёжности, требование соответствия. Напишите один абзац, связывающий ваш реальный опыт с этой названной вещью, с достаточной детализацией, чтобы его нельзя было скопировать в заявку для другой компании. Напишите один абзац или даже два предложения, описывающих один инцидент или проект, где вы приняли оценочное решение и оно сработало, назвав режим отказа или метрику, которая изменилась. Вырежьте всё остальное. Вырежьте «увлечён культурой DevOps», вырежьте «процветаю в динамичных средах», вырежьте всё, что было бы одинаково верно, если подставить другой джоб-титул. Стремитесь к объёму менее 250 слов — нанимающий менеджер, читающий это между тикетами, не прочитает больше, и более длинное письмо не компенсирует слабое техническое совпадение. Если есть ссылка на ваш код инфраструктуры или релевантный постмортем, вставьте её.

jobmarket.pro читает объявление полностью и составляет сопроводительное письмо из вашей реальной истории проектов и инцидентов, а не из общих заявлений, что и есть конкретная проблема, которую описывает эта статья.