takentui
Stage 09

Algorithms, portfolio and job search

ResultMentorHub is designed as a verifiable release, with the candidate confidently showing work and explaining solutions.Landmark3–4 weeks purposefully, algorithms gradually progress from the first month.
AI mentorGo through this stage with an agentOpen prompt

Copy the prompt to ChatGPT or coding agent. The agent will open this page, clarify your level and guide you through the stage without completing the project for you.

You are my personal Python backend tutor. Help me complete this roadmap stage independently.

Current stage: 09. Algorithms, portfolio and job search
Stage page: https://takentui.ru/en/roadmap/job-search/
Expected outcome: MentorHub is designed as a verifiable release, with the candidate confidently showing work and explaining solutions.
MentorHub increment, or its equivalent in my chosen domain: release and protection
Project deliverable: release `v1.0.0`, two verifiable pull requests, a review and a security entry.
Estimated time: 3–4 weeks purposefully, algorithms gradually progress from the first month.

First, establish the context:
1. Open the stage page and read it fully: topics, practice, project increment, completion criteria and materials.
2. If you cannot open it, ask me to paste the relevant section. Do not pretend you have read it.
3. Use the page's requirements. Do not invent missing requirements.
4. If you can access my repository, read the README, structure, code, tests and history first. Make no changes.
5. Otherwise, ask for a repository link or only the files and command output needed for the next step.

Tutoring rules:
- Establish my skill level, chosen domain and project state, then adapt the route. I may use MentorHub or an alternative domain allowed by the roadmap. Respect my chosen product.
- Give one small assignment at a time. Stop and wait for my attempt.
- Before each assignment, explain the problem, how the principle works, why it matters in backend development, how it relates to my project and how to check completion. Use small examples from another domain, without giving away the assignment's implementation.
- Do not write the finished implementation, project files or homework for me. Explain the theory in as much depth as needed.
- Increase help gradually: guiding question → research direction → small hint → pseudocode → minimal example in another domain. Move to the next level only when necessary.
- Review my attempt: explain what works, then errors, risks and one next step. Do not rewrite the entire solution.
- Ask me to explain code, decisions and mistakes in my own words. If I cannot explain a solution, I have not mastered the topic yet.
- Avoid technologies from later stages and unnecessary architectural complexity.
- Diagnose problems using tracebacks, logs, tests and documentation.
- Track progress against the page's criteria. Require a working, verified deliverable before completing the stage.
- At the end of each session, suggest a short LEARNING.md entry covering what I did, learned, got wrong and should do next. This is optional.

Workflow:
1. Ask 3–5 short questions about my experience, available time, chosen domain, project state and difficulties.
2. After my answers, present an adapted plan with small checkpoints.
3. Explain the what, how and why of the first checkpoint and give the first assignment.
4. Wait for my attempt, review it and repeat.
5. Finish with the page's checklist and ask me to defend my decisions.

In your first reply, confirm whether you could read the page, name the final deliverable in one sentence and ask the diagnostic questions. Wait for my answers before teaching the stage or providing a solution.

Algorithmic minimum

  • Big O of time and memory;
  • array/list, hash map/dict, set;
  • stack, queue/deque;
  • sorting and binary search;
  • two pointers, sliding window, frequency map;
  • recursion and tree at a basic level;
  • heap as a min/max selection tool;
  • 30–50 meaningfully analyzed easy problems are better than 200 copied solutions.

For each task, record:

  1. naive solution;
  2. complexity;
  3. improvement;
  4. edge cases;
  5. re-solution a few days later without prompting.

MentorHub 1.0 Increment - Release and Security

Project artifact: release v1.0.0, two verifiable pull requests, a review and a security entry.

  1. Feature on demand. Don’t read the finished decomposition and implement it with a separate pull request: “The goal has an optional deadline. You cannot create a date in the past. There is a filter in the list of targets overdue; An unfinished goal whose deadline has already passed is considered overdue.” For another domain, adapt the requirement while maintaining the complexity: a new optional date field, validation rule, migration and filter by calculated state. Independently formulate acceptance criteria, data schema, API contract and tests.
  2. Unknown bug. Give a copy of the repository to another developer or AI with the request: “Introduce one realistic functional defect into a separate branch, do not change the tests and do not reveal the location of the breakdown.” Get only the branch or patch, reproduce the defect with a red test and fix it with a separate pull request. If there is no assistant, swap repositories with another student.
  3. Review. Publish both pull requests and request review from the developer, learning community, or another student. Pass the criteria to the reviewer: correctness of business rules, migrations, permissions, errors, test boundaries and launch reproducibility. Reply to each comment: correct or explain the refusal in writing.
  4. Independent fallback. If an external reviewer has not been found within seven days, conduct a review with AI using the same checklist, manually check each comment and save a comment in PR: what is accepted, what is rejected and why. This is weaker than human review, but does not block independent passage.
  5. Release and protection. After the green CI, create a tag v1.0.0 and record a continuous ten-minute demo: user scenario, one test, migration, logs, CI, request scheme and three accepted compromises.

Two projects in the portfolio

Main: MentorHub API or its domain replacement is a production-like project from this roadmap.

Second, smaller: integration with external API, Telegram bot, open data scraper or background-processing service. It should show a different strength and not repeat the same CRUD.

README of the main project

  • what problem does the project solve;
  • key capabilities;
  • architectural diagram;
  • stack and reasons for choice;
  • quick start;
  • configuration;
  • migrations and tests;
  • examples of API requests;
  • known limitations;
  • 3–5 decisions and compromises;
  • development plans.

What to be able to explain in an interview

It will help you choose topics for repetition. interactive map of interview topics: frequency of inspections, competency filters and transitions to practice. These are statistics from a particular archive, not the likelihood of being asked in any interview.

  • mutability, scope, exceptions, iterator/generator;
  • function, class, composition and inheritance;
  • virtual environment and dependency management;
  • unit vs integration test, fixture, mock;
  • HTTP method/status/header/body;
  • authentication vs authorization;
  • SQL JOIN, index, transaction, isolation;
  • ORM, migration and N+1;
  • sync vs async;
  • Docker image/container/volume/network;
  • request path through native application;
  • one complex bug and a method for diagnosing it;
  • one architectural solution and a rejected alternative.

Checking readiness for responses

  • There are 2 public projects without secrets and random files.
  • The history of the repository shows the development of MentorHub from CLI to API, and not one final dump.
  • The main project is launched using the README in less than 15 minutes.
  • CI green.
  • There are business logic and API tests.
  • I can do a 10-minute demo.
  • There is a pull request, which was finalized after review according to the graduation checklist; human beings are a priority, AI is acceptable as a clearly marked fallback.
  • I can draw the architecture and request path.
  • I solve typical easy problems and explain the complexity.
  • The summary describes results and specific technologies, rather than a list of courses reviewed.
  • I began to respond to the feeling of “I know everything.”

Practice for this stage