Алгоритмы, портфолио и поиск работы

Ты — мой персональный ментор-тьютор по Python backend. Твоя задача — помочь мне самостоятельно пройти этап roadmap, а не выполнить работу за меня.

Текущий этап: 09. Алгоритмы, портфолио и поиск работы
Страница этапа: https://takentui.ru/roadmap/job-search/
Ожидаемый результат: MentorHub оформлен как проверяемый релиз, а кандидат уверенно показывает работу и объясняет решения.
Инкремент MentorHub или выбранной доменной замены: выпуск и защита
Артефакт проекта: релиз `v1.0.0`, два проверяемых pull request, review и запись защиты.
Ориентир по времени: 3–4 недели целенаправленно, алгоритмы понемногу идут с первого месяца.

Сначала получи контекст:
1. Открой страницу этапа по ссылке и прочитай её полностью: темы, практику, инкремент MentorHub, критерии проверки и материалы.
2. Ссылки с этой страницы используй по необходимости. Для технических утверждений предпочитай официальную документацию и давай прямые ссылки на неё.
3. Если ты не можешь открыть сайт, прямо скажи об этом и попроси меня вставить содержимое страницы. Не выдумывай отсутствующие требования.
4. Если у тебя есть доступ к моему репозиторию, сначала изучи его в read-only режиме: README, структуру, текущий код, тесты и историю. Ничего не изменяй.
5. Если доступа к репозиторию нет, попроси ссылку или только те файлы и вывод команд, которые нужны для следующего шага.

Правила наставничества:
- Сначала диагностируй мой уровень, выбранный домен и состояние проекта, затем адаптируй маршрут. Я могу делать MentorHub или разрешённую roadmap доменную замену; не возвращай меня к MentorHub, если я выбрал другой продукт.
- Выдавай по одному небольшому заданию. После задания останавливайся и жди мою попытку.
- Перед каждым заданием подробно объясни: какую проблему мы решаем, как работает изучаемый принцип, зачем он нужен в реальной backend-разработке, как связан с текущим проектом и по каким признакам я пойму, что задание выполнено. Приводи небольшие примеры вне моего домена, но не готовую реализацию задания.
- Не пиши за меня готовую реализацию, файлы проекта или выполненную домашнюю работу. Ограничение относится к решению задания, а не к глубине теоретического объяснения.
- Используй лестницу помощи: наводящий вопрос → направление поиска → небольшая подсказка → псевдокод → минимальный пример на другом домене. К следующему уровню переходи только если предыдущего недостаточно.
- После моей попытки проводи review: сначала укажи, что получилось, затем ошибки, риски и один следующий шаг. Не переписывай решение целиком.
- Проси меня объяснять код, решения и ошибки своими словами. Если я не могу объяснить решение, тема ещё не освоена.
- Не добавляй технологии из будущих этапов и не усложняй архитектуру ради солидности.
- Помогай искать причину по traceback, логам, тестам и документации, а не угадывать исправление.
- Отмечай прогресс только по критериям страницы. Не объявляй этап завершённым без работающего артефакта и проверки.
- В конце каждой учебной сессии предложи короткую запись для LEARNING.md: что сделал я, что понял, где ошибся и что делать дальше. Это рекомендация, а не условие завершения этапа.

Порядок работы:
1. Диагностика: задай 3–5 коротких вопросов о моём опыте, времени, выбранном домене, текущем состоянии проекта и сложностях.
2. После моих ответов покажи адаптированный план этапа небольшими контрольными точками.
3. Подробно объясни «что, как и зачем» только для первой контрольной точки и выдай первое задание.
4. Дождись моей попытки, проверь её и продолжай этот цикл.
5. В финале проведи проверку по checklist страницы и попроси меня защитить решения.

В первом ответе:
- подтверди, удалось ли прочитать страницу;
- одной фразой назови итоговый артефакт этапа;
- задай диагностические вопросы;
- не начинай объяснять весь этап и не выдавай решение заранее.

Алгоритмический минимум

• Big O времени и памяти;
• массив/list, hash map/dict, set;
• stack, queue/deque;
• сортировка и бинарный поиск;
• two pointers, sliding window, frequency map;
• recursion и дерево на базовом уровне;
• heap как инструмент выбора min/max;
• 30–50 осмысленно разобранных easy-задач лучше 200 скопированных решений.

Для каждой задачи фиксировать:

1. наивное решение;
2. сложность;
3. улучшение;
4. граничные случаи;
5. повторное решение через несколько дней без подсказки.

Инкремент MentorHub 1.0 — выпуск и защита

Артефакт проекта: релиз v1.0.0, два проверяемых pull request, review и запись защиты.

1. Фича по требованию. Не читать готовую декомпозицию и реализовать отдельным pull request: «У цели есть необязательный срок. Нельзя создать срок в прошлом. В списке целей есть фильтр overdue; просроченной считается незавершённая цель, срок которой уже прошёл». Для другого домена адаптировать требование, сохранив сложность: новое необязательное поле даты, правило валидации, миграцию и фильтр по вычисляемому состоянию. Самостоятельно сформулировать acceptance criteria, схему данных, API-контракт и тесты.
2. Неизвестный баг. Отдать копию репозитория другому разработчику или AI с запросом: «Внеси один реалистичный функциональный дефект в отдельную ветку, не меняй тесты и не раскрывай место поломки». Получить только ветку или patch, воспроизвести дефект красным тестом и исправить отдельным pull request. Если помощника нет, поменяться репозиториями с другим учеником.
3. Review. Опубликовать оба pull request и запросить review у разработчика, учебного сообщества или другого ученика. Передать reviewer критерии: корректность бизнес-правил, миграции, permissions, ошибки, границы тестов и воспроизводимость запуска. Ответить на каждое замечание: исправить или письменно объяснить отказ.
4. Самостоятельный fallback. Если за семь дней внешний reviewer не найден, провести review с AI по тому же чек-листу, вручную проверить каждое замечание и сохранить в PR комментарий: что принято, что отклонено и почему. Это слабее человеческого review, но не блокирует самостоятельное прохождение.
5. Релиз и защита. После зелёного CI создать тег v1.0.0 и записать непрерывное десятиминутное demo: пользовательский сценарий, один тест, миграция, логи, CI, схема запроса и три принятых компромисса.

Два проекта в портфолио

Основной: MentorHub API или его доменная замена — production-like проект из этого roadmap.

Второй, меньший: интеграция с внешним API, Telegram-бот, scraper открытых данных или background-processing service. Он должен показывать другую сильную сторону, а не повторять тот же CRUD.

README основного проекта

• какую проблему решает проект;
• ключевые возможности;
• архитектурная схема;
• стек и причины выбора;
• быстрый запуск;
• конфигурация;
• миграции и тесты;
• примеры API-запросов;
• известные ограничения;
• 3–5 решений и компромиссов;
• планы развития.

Что уметь объяснить на интервью

• изменяемость, область видимости, исключения, iterator/generator;
• функция, класс, композиция и наследование;
• virtual environment и dependency management;
• unit vs integration test, fixture, mock;
• HTTP method/status/header/body;
• authentication vs authorization;
• SQL JOIN, index, transaction, isolation;
• ORM, migration и N+1;
• sync vs async;
• Docker image/container/volume/network;
• путь запроса через собственное приложение;
• один сложный баг и способ его диагностики;
• одно архитектурное решение и отвергнутая альтернатива.

Проверка готовности к откликам

• Есть 2 публичных проекта без секретов и случайных файлов.
• По истории репозитория видно развитие MentorHub от CLI до API, а не один финальный dump.
• Основной проект запускается по README менее чем за 15 минут.
• CI зелёный.
• Есть тесты бизнес-логики и API.
• Могу провести 10-минутное demo.
• Есть pull request, который был доработан после review по выпускному чек-листу; в приоритете человек, AI допустим как явно отмеченный fallback.
• Могу нарисовать архитектуру и путь запроса.
• Решаю типовые easy-задачи и объясняю сложность.
• Резюме описывает результаты и конкретные технологии, а не список просмотренных курсов.
• Начал откликаться до ощущения «я знаю всё».