Критерии и ограничения для ИИ

Этот файл — компас для любой доработки репозитория. Перед тем как добавлять/менять кейсы, вопросы или легенду, свериться с этим документом.

Цель репозитория

Подготовка к собеседованиям на позиции «Инженер сопровождения», «DevOps-инженер» и «Системный администратор» (уровень middle) — три направления, три отдельных резюме с одними и теми же фактами, но разной расстановкой акцентов (см. legend/PROFILES.md). Кандидат: RESUME.md / RESUME_DEVOPS.md / RESUME_SYSADMIN.md — Картман Эрик, 4 года 5 месяцев опыта, основной стек — мониторинг (Grafana/Prometheus/Mimir), Ansible, Docker, Nginx, ELK, Linux/Bash, CI/CD, немного тестирования (Selenium) и вспомогательные языки (Python, SQL, C/C++). Дополнительно — самостоятельная pet-практика (Kubernetes, PostgreSQL, сети, Kafka, Vault), см. раздел ниже.

Подготовка опирается не только на резюме, но и на разбор реальных прошедших собеседований — interview/real-interviews.md и сырые заметки в interview/. Оценочные суждения из чужих заметок о конкретных людях/компаниях (личные впечатления автора заметок) не переносятся в кейсы или ответы — используется только фактическое содержание вопросов.

Ключевая рамка: кейсы должны быть реальными, а не выдуманными

Это центральное ограничение всего репозитория.

Знания по многим технологиям из резюме в основном теоретические. Задача не в том, чтобы написать красивую историю, а в том, чтобы кандидат реально выполнил мини-лабу (домашний стенд, чаще всего на Docker/Docker Compose), получил настоящий опыт — и уже про этот опыт мог уверенно рассказывать и отвечать на уточняющие вопросы.
Каждый CASE.md в stack/*/ должен содержать воспроизводимую инструкцию: команды, конфиги, docker-compose, ожидаемый результат. Не абстрактное описание «как обычно это делается», а то, что можно взять и повторить на своей машине.
Не сочинять конкретные вымышленные факты о работе в АО ТНИИС или ОКБ СУХОЙ (несуществующие цифры, инциденты, имена коллег, названия внутренних систем и т.п.). Разрешено обобщённо описывать типовые задачи роли («инженер сопровождения занимается тем-то») — это соответствует духу резюме, но детали должны опираться на то, что кандидат реально проделал в кейсе.
Технологии, отсутствующие в опыте работы, но указанные в навыках резюме (Python, SQL, C/C++), — вписываются в легенду как вспомогательные инструменты внутри реальных задач (скрипты автоматизации, запросы к БД мониторинга и т.п.), тоже подкреплённые кейсом.
Технологии, которых нет вообще ни в одном рабочем месте (Kubernetes, PostgreSQL как СУБД, сетевая база, Kafka, Vault) — согласованное расширение легенды по итогам разбора реальных собеседований (interview/real-interviews.md). Вписываются только как честный pet-проект/домашняя лаборатория (раздел «Домашняя лаборатория / pet-проект» в legend/LEGEND.md) — никогда не приписываются к опыту в АО ТНИИС или ОКБ СУХОЙ. На собеседовании позиционируются прямо: «в рабочем стеке этого не было, поднимал себе дома, чтобы разобраться».

Политика цифр нагрузки

Вопросы вида «с каким трафиком сталкивался» / «как справишься с масштабом X» закрываются через legend/CAPACITY.md и три чётко разделённых источника цифр, которые нельзя смешивать:

Публичные документированные пределы технологий (со ссылкой на характер источника).
Реальные замеры, полученные прогоном инструментов на собственных CASE.md-стендах.
Факты о реальном масштабе, заполняемые только пользователем лично.

Не сочинять «продовые» или «типичные для компании такого профиля» цифры нагрузки — ни как метрики с работы, ни как параметры pet-лабы, выдаваемые за нечто большее, чем они есть.

Согласованность

Все документы должны быть непротиворечивы друг другу:

Даты, названия компаний, стек — идентичны во всех трёх резюме (RESUME.md, RESUME_DEVOPS.md, RESUME_SYSADMIN.md). Между собой резюме различаются только желаемой должностью, порядком подачи пунктов и группировкой навыков — не фактами. См. legend/PROFILES.md.
Легенда (legend/LEGEND.md) — единый источник истины про то, «где и зачем» применялась технология. Кейсы и ответы на вопросы ссылаются на неё, а не противоречат.
Если кейс меняет понимание того, как технология использовалась — обновить LEGEND.md в этом же заходе.

Стиль

Все документы — на русском, в markdown.
Ответы на вопросы в QUESTIONS.md — от первого лица, разговорным языком, как кандидат реально бы ответил, с опорой на кейс. Не копировать формулировки из документации слово в слово.
Без канцелярита и не заученно — если ответ звучит как выученный наизусть параграф, это плохой ответ и его надо переписать.
Все даты в тексте записываются в формате dd-mm-yyyy (например, 18-07-2026), а не yyyy-mm-dd или другими способами.

Куда идти

Порядок проработки категорий следует частотности тем в реальных собеседованиях, зафиксированной в interview/real-interviews.md и разложенной по шагам в interview/study-plan.md — не порядку строк резюме.
Добавлять вопросы «от простого к сложному»: сначала база (что такое, зачем нужно), потом — сравнение с альтернативами, потом — как бы решал проблему X.
При появлении новых разборов реальных собеседований — обновлять матрицу тем в interview/real-interviews.md и маппить новые вопросы на существующие/новые категории, а не оставлять их непокрытыми.
Держать README.md как актуальную карту готовности (что проработано, что нет).

Куда не идти

Не придумывать метрики/цифры, которых нет в резюме и не проверены кейсом («настроил 200 дашбордов» и т.п.).
Не добавлять технологии, которых нет ни в резюме, ни в согласованном расширении легенды.
Не делать кейсы избыточно сложными для уровня middle — стенд должен быть реалистичным для домашней проработки, а не production-инсталляцией.
Не переписывать ни одно из трёх резюме (RESUME.md, RESUME_DEVOPS.md, RESUME_SYSADMIN.md) без явного запроса пользователя — правки резюме пользователь вносит/подтверждает сам.
Не закладывать в резюме или легенду техники обмана работодателя/площадки — например, дублирующие профили с намеренно искажёнными данными (изменённые ФИО/возраст/контакты) для обхода отказов. Это не входит в понятие «подготовка к собеседованию». См. разбор в RESUME_RULES.md → «Осознанно не применено».

Правила оформления резюме

Отдельный применённый чек-лист внешних best practices по резюме — в RESUME_RULES.md. Он же фиксирует, что было сознательно отброшено и почему.

11 KiB Raw Blame History Unescape Escape