Пост для тех, кто нанимает в команду.
Если попросить 10 компаний описать идеального DevOps-инженера, почти наверняка получится 10 разных вакансий. При этом все компании используют одно и то же название вакансии. Именно поэтому у работодателя и кандидата разные ожидания.
Вакансии часто продолжают описывать стек, который формировался несколько лет назад, в результате чего появляются требования, отражающие не текущие задачи бизнеса, а список вообще всех инструментов.
Для кандидатов это выглядит как попытка найти универсального специалиста, который одинаково хорошо знает все существующие инструменты.
Можно знать Terraform, Kubernetes, Prometheus, Grafana и десятки других решений, но если инженер не сталкивался с отказоустойчивостью, масштабированием, авариями или эксплуатацией высоконагруженных систем, этого опыта может оказаться недостаточно для конкретного проекта.
Инженеры обычно принимают решение о новом месте работы не только исходя из условий, большое значение имеет понимание самого проекта.
⚪️ Какая инфраструктура уже существует?
⚪️ Какие задачи предстоит решать?
⚪️ Насколько зрелые процессы в компании?
⚪️ Есть ли возможность влиять на архитектуру?
Именно поэтому техническое интервью становится не просто этапом оценки кандидата. Оно превращается в обсуждение того, насколько ожидания обеих сторон совпадают.
Успешный поиск DevOps-инженеров редко строится вокруг длинного списка технологий. Гораздо лучше работают другие подходы:
⚪️ Четкое описание текущей инфры и проекта
⚪️ Разделение обязательных и желательных требований
⚪️ Понимание реальных задач на повестке
⚪️ Готовность обсуждать развитие роли инженера
А если компания не может понятно объяснить, с чем предстоит работать, вероятность отказа заметно возрастает. Это звучит очевидно, но далеко не все действительно ставят себя на место соискателя.
@DevOpsKaz 😛