13 KiB
Базовые вопросы собеседования (не по стеку)
Опираются на ../RESUME.md и ../legend/LEGEND.md. Ответы — черновые, от первого лица; дорабатывать своими словами перед реальным собеседованием, чтобы не звучало заученно (см. ../AI_GUIDELINES.md).
Расскажите о себе
Начинал с тестирования встроенного ПО в ОКБ СУХОЙ — писал тестовые сценарии, автоматизировал проверки на Selenium, работал на стендах на CentOS. Через полтора года перешёл в АО ТНИИС на позицию инженера по сопровождению — там уже занимался мониторингом (Grafana, Prometheus, Mimir), автоматизацией через Ansible и поддержкой инфраструктуры на Astra Linux. Сопровождаю внутренний контур предприятия — Java-сервисы за балансировкой Nginx на парке VM; предприятие режимное, поэтому детали продукта не раскрываю, но со стороны мониторинга, автоматизации и инцидентов могу рассказать всё в деталях (подробный нарратив — ../legend/STORY.md). Сейчас ищу позицию инженера сопровождения или DevOps-инженера, где можно развивать именно эту сторону — автоматизацию и эксплуатацию.
Почему решили сменить место работы?
Иду не «от», а «к»: текущее предприятие режимное, и это по своей природе закрывает ряд направлений, которые интересно развивать дальше — нет облаков, нет Kubernetes в проде, нет удалённого/гибридного формата (доступ к контуру только из офиса). Хочется расти в сторону современной эксплуатации и DevOps — облачная и контейнерная оркестрация, более гибкий формат работы — а это ограничено спецификой текущего места, а не желанием или возможностями команды. Полный разбор — ../legend/STORY.md → «Причина ухода».
Как не надо: ругать текущего/бывшего работодателя, жаловаться на коллег или начальника — интервьюер запомнит не причину, а то, что вы негативно отзываетесь о людях за глаза.
Почему вам интересна именно эта вакансия?
[Заполнить под конкретную вакансию перед откликом — что конкретно в описании вакансии пересекается с реальным опытом: мониторинг, Ansible, Docker, Nginx.]
Расскажите о сложной задаче, которую вы решали
Пример на основе легенды (АО ТНИИС): настройка Ansible-ролей с интеграцией тестирования в CI через Molecule и TeamCity — сложность была в том, чтобы роли были одновременно и рабочими, и покрытыми тестами, не ломающими деплой. Разбирался с идемпотентностью ролей и с тем, чтобы тесты в CI реально ловили проблемы до продакшена, а не просто формально проходили. (Проработать детальнее после выполнения кейса ../stack/ansible/CASE.md — рассказывать нужно про то, что реально прогонялось руками.)
Как не надо: выбирать пример, где сложность была не в самой задаче, а в конфликте с человеком, или отвечать абстрактно («было много сложных задач») без конкретики: что именно было сложно, какие варианты рассматривались, почему выбран именно этот.
В чём ваши сильные стороны применительно к этой роли?
Опыт на стыке тестирования и эксплуатации — понимаю, как проверить, что решение реально работает, а не просто «задеплоено». Разбираюсь в мониторинге не только с точки зрения «настроить дашборд», но и с точки зрения «что эта метрика значит и когда она сигнализирует о проблеме».
В чём слабые стороны / что развиваете сейчас?
[Заполнить честно — например, ELK/CI-CD проработаны пока меньше, чем мониторинг и Ansible, сейчас в процессе закрытия этого пробела (см. чек-лист checklist.md).]
Как не надо: выдавать замаскированное достоинство за слабость («слишком перфекционист») — это штамп, который интервьюеры слышат постоянно и не воспринимают всерьёз. Лучше называть реальный, но не критичный для роли пробел и прямо говорить, что с ним делаете.
Как вы расставляете приоритеты при нескольких инцидентах одновременно?
Смотрю на импакт: что сейчас реально влияет на пользователей/сервисы, а не на то, что «громче» по ощущениям. Мониторинг (Grafana/Prometheus) — первый источник, чтобы понять масштаб проблемы, логи (ELK) — чтобы найти причину. Сначала стабилизация (например, откат/рестарт), потом уже разбор первопричины.
Готовы ли к удалённой работе, гибриду, командировкам?
Готов к удалённой работе и гибриду (см. ../RESUME.md), к командировкам не готов — это указано в резюме и остаётся так.
Расскажите о ситуации, когда вы допустили ошибку
[Заполнить конкретным честным примером, связанным с одним из проработанных кейсов — например, ошибка в конфиге, которую поймал Molecule/тест до продакшена, и что из этого вынес.]
Как не надо: отрицать, что ошибки вообще были, или перекладывать вину на других — это читается как неспособность к рефлексии. Ценится не факт ошибки, а то, что из неё было сделано (какой вывод, что изменилось в процессе после).
С какими облаками работал? Есть опыт с OpenStack?
Прямого рабочего опыта администрирования облачных платформ (AWS/GCP/Yandex Cloud/OpenStack) у меня нет — рабочий опыт (АО ТНИИС, ОКБ СУХОЙ) строился на собственной инфраструктуре компаний. При этом смежные концепции знакомы через pet-практику: домашний кластер Kubernetes (../stack/kubernetes/CASE.md) даёт понимание оркестрации и абстракций, на которых строятся облачные платформы (в том числе managed Kubernetes-сервисы в облаках). Если конкретно про OpenStack и Ceph — это отдельная область, с которой предметно не работал, и на собеседовании честно обозначил бы это, а не пытался бы изобразить опыт, которого нет.
Есть ли у вас вопросы к нам?
[Подготовить 2-3 вопроса под конкретную вакансию: про стек, про процесс on-call/дежурств, про то, как устроен CI/CD в компании.]
Вопросы про отдел и процессы
Опираются на ../legend/STORY.md и ../legend/DEPT_STACK.md — черновые ответы, доработать своими словами, состав команды и бытовые детали подтвердить/поправить перед реальным собеседованием.
Кто ставил задачи? Какой был тасктрекер?
Задачи ставил начальник отдела на дейлике, часть — приходила от смежных отделов через заявки. Тасктрекер — Jira, спринты в Agile-процессе отдела.
Сколько человек в команде и с кем вы работали?
Небольшой отдел сопровождения и мониторинга — начальник отдела и порядка нескольких инженеров сопровождения/мониторинга плюс Java-разработчики со стороны сопровождаемых сервисов. Плотно взаимодействовал с группой Linux-администраторов (обслуживают парк VM) и с отделом разработки по инцидентам. Подробнее — ../legend/STORY.md → «Состав отдела».
Где живёт ваша инфраструктура? Кто её обслуживает?
On-premise: парк VM под Astra Linux, без внешних облаков — режимный контур предприятия. Обслуживает группа Linux-администраторов, я — со стороны мониторинга и автоматизации конфигурирования (Ansible).
Как проходило внедрение изменений/релизов?
Конфиг или роль пишется и тестируется (Ansible + Molecule), пушится в Gitea, задача заводится в Jira с описанием, дальше раскатка через TeamCity — часто совместно с администраторами, если изменение затрагивает их зону ответственности.
Куда вы смотрите в Grafana? На какие дашборды?
Node Exporter (загрузка железа по VM), Nginx (статус балансировщика), Blackbox Exporter (сроки TLS-сертификатов), дашборды под конкретные сопровождаемые сервисы — рестарты, ошибки, задержка ответа.
В каком формате выгружали дашборды? Как было устроено версионирование?
JSON, версионировались в Gitea вместе с остальными конфигами отдела, раскатка — TeamCity. Подробнее — ../legend/STORY.md → «Версионирование дашбордов Grafana».