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