Как оцениваете свой уровень разработчика
Что проверяют
Насколько трезво вы себя видите и совпадает ли самооценка с грейдом вакансии. Интервьюеру важно не слово «middle», а то, на чём оно держится. Следом обычно спрашивают: «Что вам нужно, чтобы вырасти на следующий уровень?»
Как отвечать
Назовите уровень и сразу обоснуйте его критериями, а не стажем. Для DevOps-инженера рабочие критерии такие:
- зона ответственности: выполняете ли вы задачи по готовому плану или сами проектируете, например, CI/CD для нового сервиса и защищаете решение;
- глубина базы: Linux, сети, DNS, TLS. Именно на них спотыкаются в инцидентах, где инструменты не помогают;
- инструменты с масштабом: не «знаю Kubernetes», а «поддерживал три кластера, обновлял версии, писал Helm-чарты, настраивал автомасштабирование»;
- инфраструктура как код: Terraform или Ansible в реальной работе, ревью чужих изменений;
- инциденты: дежурства, разборы после сбоев и что изменилось в системе после них;
- влияние на других: онбординг новичков, документация, общие шаблоны пайплайнов.
Потом одна-две сильные стороны с примером и цифрой и один честный пробел с планом: «на Go пишу простые утилиты, сейчас разбираюсь, как устроены операторы Kubernetes». Цифры нужны ваши: время сборки, число сервисов, частота релизов.
Если вы переходите из системного администрирования или разработки, скажите это прямо и покажите, какие навыки переносятся. Это честнее, чем подтягивать опыт под грейд.
Где спотыкаются
Говорят «я где-то средний» без критериев. Такой ответ ничего не даёт интервьюеру, и уровень он определит сам, обычно ниже.
Перечисляют технологии вместо ответственности. Список из двадцати инструментов без масштаба и результатов звучит как пересказ резюме.
Завышают уровень под вакансию и сыплются на первом же вопросе по сетям или разбору инцидента. Честный middle, подтверждённый примерами, лучше, чем senior, который не вытягивает.