Python Backend Roadmap · v0.3

From scratch
up to first job

Put together a production-ready project, learn how to defend technical solutions and prepare for the first reasonable responses.

[Route map]

Progress by milestones

Each stage ends with a verifiable artifact. If the result is not reproduced according to the README and cannot be explained, the stage is not yet closed.

00

Start and tools

a MentorHub repository has been created, which is launched from the terminal and will become the basis for all subsequent stages.

1 week.Open →
01

Basic Python

works MentorHub CLI with goals, tasks, progress and storage in JSON; The student writes small programs independently.

6–8 weeks.Open →
02

Engineering Python

MentorHub CLI became a small, maintainable Python project with separate business logic and storage.

4–5 weeks.Open →
03

Testing

MentorHub rules and JSON storage are checked automatically, and the found bug is fixed by test.

2–3 weeks, then testing continues at all stages.Open →
04

HTTP and API

MentorHub had the first HTTP contract and a minimal JSON service on top of already written logic.

2 weeks.Open →
05

SQL and PostgreSQL

MentorHub stores users, goals, and tasks in PostgreSQL; The student understands the schema and SQL under the application.

4–5 weeks.Open →
06

Web framework

MentorHub has become a full-fledged REST API with PostgreSQL, authorization, rights and integration tests.

6–8 weeks.Open →
07

Production basics

MentorHub runs reproducibly in a clean environment, goes through CI and leaves diagnostic logs.

4–5 weeks.Open →
08

Async and background tasks

MentorHub has added one valid concurrency, cache, or background processing scenario.

3–4 weeks.Open →
09

Portfolio and jobs

MentorHub is designed as a verifiable release, with the candidate confidently showing work and explaining solutions.

3–4 weeks purposefully, algorithms gradually progress from the first month.Open →

[End-to-end project]

One repository grows with your skills

MentorHub doesn't show up ready in the middle of training. You create it in the first week and at each stage you add only what you already know how to explain.

Training domain

MentorHub

The user creates goals, breaks them into tasks and sees progress. Later, a mentor appears with limited access - this is how a simple CLI gradually provides material for the database, API, authorization and background tasks.

Route rule

At the start this is not an API

First one command and JSON. Then the structure and tests. Only after HTTP and SQL does the same project become a web service. No roles, Docker and PostgreSQL until the appropriate stage.

You can choose a different domain, but keep the users, two related entities, rights, and business rules.

  1. Stage 00empty but reproducible projectREADME and first launch version in the public repository.
  2. Stage 01useful CLICLI with goals, tasks, progress calculation and saving in JSON.
  3. Stage 02structure instead of one filePython package with models, business rules and replaceable storage.
  4. Stage 03testable behaviorunit and integration tests and one bug fix, started with a red test.
  5. Stage 04first HTTP boundarycontract and running `GET /health`, `GET /goals`, `POST /goals` on top of the JSON storage.
  6. Stage 05PostgreSQL instead of JSONPostgreSQL schema, SQL queries, import from JSON and legacy scripts with new storage.
  7. Stage 06main REST APIREST API with auth, CRUD, permissions, pagination and OpenAPI.
  8. Stage 07service suppliedDocker Compose, CI, migrations, structured logs and reproducible deploy.
  9. Stage 08one reasonable improvementOne tested background processing or caching scenario with described failure behavior.
  10. Stage 09release and protectionrelease `v1.0.0`, two verifiable pull requests, a review and a security entry.

Final result

What will be in release 1.0

This set does not need to be implemented in advance. It consists of ten increments above and remains in the history of one repository.

  • Registration and login
  • Roles student and mentor
  • CRUD goals and objectives
  • Access rights
  • PostgreSQL and migrations
  • Unit and integration tests
  • OpenAPI and errors
  • Docker Compose
  • CI and quality checks
  • Architectural README

[Game Rules]

The code is more important than the number of hours watched

½

minimum

Practice

At least half of the class time is spent writing, running, and correcting your code.

1

base material

Focus

First, one selected material and practice. Documentation is for finding answers, not a second parallel course.

0

offer guarantees

Honest goal

Roadmap prepares a project and a basis for a junior position, but does not simulate commercial production experience.