# First Backend Role Fit

Public HTML route: https://alexgerlitz.github.io/AlexGerlitz/first-backend-role.html

Use this page when the hiring question is practical: can I join a backend team, take a bounded
Python/backend or API verification task, work with review, and leave evidence instead of only a claim?

## 30-Second Fit

Best-fit first role titles:

- Junior Backend Developer
- Junior Python Developer
- Back End Developer
- Python Developer
- Internal Tools Developer
- Integration Developer
- QA/API Python
- Support Engineer with Python when the work is API, SQL, logs, and backend handoff
- Backend Engineer when the first month is a bounded workflow slice

Fastest review path:

1. [Backend Role Fit](./BACKEND_FIRST_SCREEN.md)
2. [Autoschool Intake/Admin work sample](./AUTOSCHOOL_INTAKE_ADMIN.md)
3. [Synthetic demo seed](./data/autoschool-intake-admin-demo.json)
4. [First 30 Days Delivery Plan](./FIRST_30_DAYS.md)
5. [Skill Evidence](./SKILL_EVIDENCE.md)
6. [Decision-Ready Contact](./DECISION_READY_CONTACT.md)
7. [PDF Resume](./output/pdf/alex-gerlitz-python-backend-automation-resume.pdf)

Best immediate team context:

- Russian-speaking product/backend or support team where the first result is a small reviewed backend/API ticket.
- English-first async team where the review path is issues, pull requests, tests, docs, and handoff notes.

## Why This Exists

Some pages show a broad backend workflow direction. This page answers the smaller first-role
question: what can a team safely give me first?

| First-role question | Practical answer |
| --- | --- |
| Can I start without owning the whole system alone? | Yes. Give me one endpoint, data model, admin queue step, integration mapping, test gap, or runbook gap. |
| Can I work inside review? | Yes. The best first slice has a clear issue, small diff, tests or smoke checks, docs, and a reviewer-visible handoff. |
| Can I enter through QA/API or support? | Yes, when the work verifies real API behavior, SQL/data state, logs, reproducible issue context, and backend handoff notes. |
| Can I handle backend state? | The Autoschool work sample shows request intake, validated payload, database-style record, admin queue row, status update, and audit context. |
| Can I protect business data? | Public evidence uses synthetic data only and keeps live admin names, contact details, IDs, URLs, logs, dumps, and credentials out of GitHub. |
| Can I grow toward larger backend ownership? | The route connects first tasks to FastAPI, PostgreSQL, OpenAPI, Docker, CI, integrations, admin workflows, and runbooks. |

## Best First Tasks To Give Me

- Add or fix a FastAPI endpoint with request validation and response shape.
- Add a PostgreSQL model field, status transition, migration note, and small test.
- Turn one Telegram/chat request into a normalized backend payload and admin queue row.
- Add an admin filter, status action, or operator handoff note.
- Map one CRM/API integration payload with validation and error handling.
- Add a pytest, REST/OpenAPI, SQL/data, or smoke check for one workflow.
- Investigate one support ticket through logs/data, write a reproducible issue note, and propose the smallest safe fix.
- Add a smoke check, CI check, log note, or runbook section for an existing workflow.
- Write the issue-to-result handoff: what changed, how to test it, and what remains risky.

## What I Should Not Be Evaluated On First

Do not evaluate me by asking me to own a large architecture alone on day one. A better first assignment is a
bounded backend task with a real workflow, explicit review, tests or smoke checks, and a clear
handoff note.

## Evidence Boundary

This first-role fit uses public-safe evidence only. It does not include live admin screenshots,
real learner names, contact details, Telegram IDs, chat IDs, private URLs, raw logs, credentials,
database dumps, or private repository code.