How to Get a Python Developer Job in 2026-27

The five jobs hiding behind "Python developer", and how to read a posting

Python is not a job market. It is the shared language of five separate job markets whose interviews have almost nothing in common. A candidate who prepares for one and interviews for another looks weak through no fault of their ability. Before you apply, decide which market the posting belongs to, and let the nouns in the requirements tell you rather than the title.

Backend and web Python. You own HTTP or RPC endpoints, a relational schema, background jobs and the service's production behaviour. The giveaway nouns are Django, Django REST Framework, FastAPI, Flask, Litestar, Celery, Postgres, Redis, pytest, Docker. The interview is API design, schema and SQL, a coding round that is usually "implement this endpoint correctly", and a system design round. This is the largest of the five by volume.

Data engineering Python. You own ingestion and transformation: the pipeline, its schedule, its idempotency, its cost. The giveaway nouns are Airflow, Dagster, Prefect, dbt, PySpark, Snowflake, BigQuery, Databricks, Parquet, Kafka, Polars, DuckDB. The interview is SQL heavy (expect window functions), plus pipeline design, incremental and backfill logic, and data modelling. Python here is glue around a warehouse, and strong SQL matters more than clever Python.

Machine learning and AI engineering Python. You own model code or the system serving a model. The giveaway nouns are PyTorch, scikit-learn, transformers, Hugging Face, vLLM, MLflow, Weights and Biases, feature store, embeddings, pgvector, RAG, evals. The interview adds a modelling or retrieval round and almost always still includes a normal software engineering round, because most of this job is software. A research scientist posting is a different job again and usually asks for a PhD and publications; an ML engineer posting generally does not.

Scientific, quantitative and research Python. You own numerical correctness and speed. The giveaway nouns are NumPy, SciPy, pandas, Numba, Cython, JAX, simulation, time series, Monte Carlo, C++ interop, and domain words like genomics, seismic, actuarial, derivatives, lattice. The interview tests maths, numerical judgment, profiling and sometimes the domain. Quantitative developer roles in finance pay at the very top and screen hardest on algorithms and performance.

Platform, SRE and automation Python. You own internal tooling: CLIs, deploy scripts, cloud automation, observability glue. The giveaway nouns are boto3, Terraform, Ansible, Kubernetes, GitHub Actions, Prometheus, bash, Linux. The loop is often a DevOps or SRE loop in which Python happens to be the implementation language, so expect Linux debugging, networking basics and a troubleshooting scenario rather than a design round.

Two signals worth checking in any Python posting regardless of track. First, the Python version and the framework generation: a posting naming Python 3.8, Django 2.x or Airflow 1 is telling you about a long-lived codebase and a migration you will be doing. That is not automatically bad, and legacy modernisation work is plentiful and well paid, but you should price it. Second, whether the posting lists a second language. Python plus Go or Python plus TypeScript usually means the Python is the service and the other language sits adjacent to it. Python plus C++ in a scientific posting means you will be reading C++ whether or not the posting admits it.

• Requirements list a web framework and a database and no warehouse: backend track, prepare API and schema design.
• Requirements list an orchestrator (Airflow, Dagster, Prefect) and a warehouse: data engineering track, prepare SQL hard.
• Requirements list a model library plus Docker and a cloud: ML engineering track, software round included.
• Requirements say "research", list publications or a PhD, and name a maths area: research track, different job, different preparation.
• Requirements list NumPy, profiling and a compiled language: scientific or quantitative track, prepare numerical performance.
• Requirements list boto3, Terraform and Linux: platform track, prepare debugging and cloud rather than design.
• Posting says "Python/Django developer, must be comfortable with everything from CSS to Kubernetes": a small company where you will do all five. Fine, but ask who else is on the team.

What code and deployment evidence each track expects

Every Python posting asks for "strong Python" and no interviewer can assess that phrase. What they actually do is look for one artefact that proves you have shipped something other people depended on. The artefact differs by track, and the most common portfolio failure is bringing a notebook to a backend interview or a toy CRUD app to a data interview.

A universal baseline applies to all five. Whatever you show must be runnable by a stranger: a pyproject.toml with a lock file, a README whose quickstart actually works, tests that run with one command, type hints on the public surface, ruff and mypy configured, secrets read from the environment rather than committed, and continuous integration that is green. A reviewer gives your repository minutes, not hours. If the install and test commands in your own README fail, that is the whole review. Three small repositories like this beat fifteen half-finished ones, and a repository with recent commits beats one that stopped two years ago.

Deployment evidence is the part most candidates skip and the part that separates them. "Deployed" does not require a cloud bill. A docker compose up that brings the whole thing up with a seeded database counts. A single container on a small host with a real URL counts. A GitHub Actions workflow that builds the image, runs the tests and pushes somewhere counts. What does not count is a README sentence saying it could be deployed.

Backend track. Show a service with a real data model: migrations (Django migrations or Alembic), an OpenAPI schema, authentication that is not a hardcoded token, pagination, input validation with Pydantic or a serializer, and background work in Celery or an equivalent. Then show how it behaves badly: what happens on a duplicate POST, on a timeout talking to a third party, on database connection exhaustion. If you can name your p95 latency and your request rate, you are already ahead of most applicants.

Data engineering track. Show a pipeline that can be rerun safely. The interviewer is looking for idempotency, so make it visible: a job keyed by logical date, a merge or upsert rather than a blind insert, a backfill command, and a data quality check that fails the run (pandera, Great Expectations, dbt tests, or plain assertions with a clear message). Attach numbers: rows per run, runtime, warehouse cost, and what you did when the source schema changed under you.

Machine learning and AI track. Show reproducibility and honest measurement. A training or fine-tuning script with pinned versions and a fixed seed, a held-out evaluation with a metric, and a stated baseline (the dumb model you beat, which is often a majority-class classifier or a keyword search). For LLM work, the serving path and the eval harness matter more than the model: a FastAPI endpoint that streams, a prompt and retrieval setup under version control, and a scored eval set of 50 to 200 real examples with results from more than one configuration. Say what it gets wrong. A candidate who names their failure cases reads as competent, not weak.

Scientific and quantitative track. Here a notebook is a legitimate result artefact, but the code under it should be an installable package with tests, otherwise the reviewer assumes nothing is reusable. Show a correctness check against an analytic result or a reference implementation, and show a performance story with the method named: vectorised a loop, moved a hot function to Numba, chunked an array that did not fit in memory, with before and after timings on stated hardware.

Platform and automation track. Show the script turned into a tool: packaged as a CLI with subcommands, a dry-run flag, idempotent operations, structured logging, correct exit codes, and tests that fake the cloud API rather than calling it. Then show it running against something real on a schedule. The hiring question behind this track is always whether this person's automation will wake someone at 3am, so visible safety rails are the point.

• Non-negotiable for every track: pinned dependencies, a working quickstart, tests that pass, no committed secrets.
• Backend evidence: migrations, OpenAPI, auth, a failure story, and latency or throughput numbers.
• Data evidence: an idempotent rerun, a backfill, a quality check that fails loudly, rows and runtime.
• ML evidence: a baseline, a held-out metric, pinned versions and a seed, named failure cases.
• LLM evidence: an eval set with scores for more than one configuration, and the serving path.
• Scientific evidence: a correctness check plus before and after timings with the technique named.
• Platform evidence: a packaged CLI with dry-run, idempotency and tests that do not hit the real account.

How you actually become a Python developer, and the honest state of entry level

There is no gate to pass. That is genuinely good news and also why the market is crowded: Python is the most common first language and the most commonly taught, so the bottom of the funnel is enormous. Everything about getting hired is about distinguishing yourself from the many people who have completed the same tutorial.

Four routes work. A computer science or quantitative degree, which mostly helps at entry level in large graduate pipelines and for some visa pathways, and matters much less after about three years. A lateral move, which is the highest-yield route and underused: analysts, QA testers, sysadmins, actuaries, biologists, support engineers and finance staff who already write Python at work can convert that into a developer title, usually inside the same employer, by taking over something production-shaped. Self-taught with shipped work, which is entirely viable and is judged purely on the artefacts described above. And bootcamps, which for Python specifically are the weakest of the four in 2026: the generic full-stack graduate profile is heavily saturated and employers discount it, so if you take that route, expect to do the portfolio and networking work on top rather than instead.

Be clear-eyed about junior hiring. Entry level Python is harder than it was in 2021. Two forces pushed the same way: hiring slowed from the 2021 peak, and the easiest Python work (small scripts, scaffolding, CRUD endpoints, one-off data cleaning) is exactly what coding assistants do well, so some of the tasks that used to be given to a junior to learn on are no longer given to anyone. That is a real change and anyone telling you otherwise is selling something. It is not the whole picture, because demand for Python rose at the same time, driven by AI and data work. The result is a barbell: more mid and senior Python roles, especially AI-adjacent ones, and fewer undifferentiated junior ones.

What this means tactically. Do not compete at the saturated front door. Three doors are less crowded. First, adjacent entry: get hired as a data analyst, QA automation engineer, support engineer, implementation consultant or operations analyst where Python is used, then move internally in 12 to 18 months with an internal referral. Second, the unglamorous employer: insurers, hospital systems, universities, national labs, state and local government, utilities, manufacturers, logistics firms and defence contractors run enormous amounts of Python and receive a fraction of the applications a startup does. Pay is lower, learning is often excellent, and the experience counts. Third, open source: a handful of merged pull requests on a library the team actually uses is the strongest cold-outreach asset a junior can hold, and it is one of the few things that gets a reply.

A note on location, because it changes your odds more than most candidates expect. Fully remote Python roles draw the largest applicant pools of anything in this field, so they are the hardest place to be the obvious choice. If you are early in your career and a hybrid or onsite role in a city you can reach is acceptable, your conversion rate from application to screen will be materially better there, and the second job is much easier to make remote than the first.

On internships and new-grad pipelines: they are still the cleanest route into large employers, they open roughly 9 to 12 months before the start date, and they close early. If you are a student, that calendar matters more than your project list.

A note on what to learn first, because this is where months get wasted. Learn the standard library properly (collections, itertools, pathlib, dataclasses, logging, argparse, concurrent.futures, contextlib), learn pytest, learn SQL to the level of joins, aggregation and window functions, learn git beyond commit and push, learn enough Linux and Docker to debug a container, and learn the one framework your target track uses. That is a shorter list than most roadmaps and it is sufficient. Breadth across nine frameworks reads as unemployable; depth in one reads as hireable.

Finally, write for the market you want. If you want backend, your public work should look like services. If you want data engineering, it should look like pipelines. A portfolio that reads as undecided is the slowest possible path, because every reviewer is trying to place you on their track and cannot.

The loop, stage by stage, and what each round is really grading

Who screens you depends on employer size, and it changes what your application should optimise for. At a company of under about 50 people, the hiring manager or the lead engineer reads your resume personally and your repository matters enormously. At a mid-size company, a recruiter filters on titles and tools and an engineer reads your code. At a large employer, an applicant tracking system plus a recruiter screens first, an online assessment gates the loop, and your resume has to be plain, title-matched and keyword-honest to survive the first two steps at all.

Stage one, the recruiter screen, 20 to 30 minutes. They are confirming facts, not judging engineering: which Python version and frameworks, whether you have shipped to production, cloud exposure, work authorisation, notice period, location and salary expectation. Have a 30-second answer naming your track and your strongest project, and have a number ready for the pay question, informed by the sources in the key facts rather than by guesswork.

Stage two, the technical screen. One of three shapes. A timed online assessment of 60 to 90 minutes, usually two or three problems on a platform such as CodeSignal, HackerRank or Codility, common at large employers and still mostly data structures and strings, so practise typing Python fast under a clock. A take-home repository, common at mid-size companies, nominally 3 to 6 hours. Or a 60-minute live session with an engineer, which is increasingly "here is a small repository, add this feature" rather than a blank editor. For a take-home, cap your time, commit in small logical steps so your process is visible, write a README stating your assumptions and what you deliberately left out, and include tests. An untested take-home is the most common rejection reason at this stage. Ask what the AI policy is before you start, and follow whatever they say in writing.

Stage three, the Python depth round. This is the round people do not prepare for and it is where Python-specific rejections happen. It is partly code reading ("what does this print and why") and partly mechanics: generators, decorators, context managers, mutable default arguments, how asyncio differs from threads, how you would profile this, how your dependencies are pinned. It is grading whether you understand the language you claim or whether you have been pattern-matching it for three years.

Stage four, the applied coding round. Implement something real in 45 to 60 minutes with an interviewer watching: an endpoint, a parser, a rate limiter, a retry wrapper, a transformation over messy records. Graded on whether you ask about edge cases before coding, whether you handle errors, whether you write a test, and whether you talk while you work. Correctness plus clear reasoning beats a clever one-liner every time. A newer variant is a review or debugging round: you are handed a diff, often one written by a coding assistant, and asked what is wrong with it. Treat that as a first-class round and prepare for it.

Stage five, the design round, which is what actually sets your level and your offer band. Backend gets system design. Data engineering gets pipeline and data modelling design. ML gets "how would you build and evaluate this model or this retrieval system". Scientific gets numerical method and performance design. In all four, state the volumes out loud and do the arithmetic, name the tradeoff you are choosing, and say explicitly what you are not building yet and what signal would change your mind.

Stage six, the hiring manager conversation. Ownership, conflict, how you handled an incident, how you work with people who are not engineers, and why this job. Then references and offer. If a clearance is involved, add months. If the team is small, the whole loop can take a week.

One more thing worth doing deliberately: diagnose which stage is failing instead of applying harder. The stage where you stall tells you precisely what to fix, and the fixes are different enough that guessing wastes months.

• Recruiter screen grades: facts, communication, and whether your salary number is inside their band.
• Online assessment grades: speed and correctness on data structures. Pure filter, no credit for elegance.
• Take-home grades: tests, README, commit hygiene, and whether you handled the ugly input.
• Language depth round grades: do you actually know Python, including its sharp edges.
• Applied coding round grades: clarifying questions, error handling, a test, and thinking out loud.
• Review or debugging round grades: whether you catch defects in code you did not write, including generated code.
• Design round grades: level. Numbers, named tradeoffs, and knowing what to leave out.
• Hiring manager round grades: ownership and whether you are pleasant to be on call with.
• Diagnostic: dozens of applications and no screens means the resume, the title line or the track is wrong, not your code.
• Diagnostic: screens but no technical pass means drilling timed Python and SQL, not more projects.
• Diagnostic: onsites but no offers means the design round and your level story, so rehearse volumes and tradeoffs out loud.
• Diagnostic: offers below your target means the track and the sector you are applying to, not your negotiation script.

The Python depth round and the data round: what they test, and how to drill it

The depth round draws from a surprisingly stable pool. Here is the pool, with the thing the interviewer is listening for, because knowing the answer matters less than knowing why they asked.

Language mechanics. Mutable default arguments (def f(x=[]) shares one list across every call; the fix is a None default and a fresh list inside) tests whether you have been bitten in production. Late binding in closures created in a loop tests the same thing. The is operator versus equality, shallow versus deep copy, and why dict preserves insertion order (guaranteed from Python 3.7) are quick calibration questions. Generators versus lists tests whether you think about memory: a generator over a 40GB file is the correct answer, and being able to say that yield holds one item at a time while a list comprehension materialises everything is the full answer. Decorators with functools.wraps, context managers via the enter and exit protocol or contextlib.contextmanager, and slots for many small objects are the usual intermediate set. Expect one question comparing a dataclass, a NamedTuple, a TypedDict and a Pydantic model, and have a reason for each: dataclass for internal structures, TypedDict for dict shapes you do not control, Pydantic when data arrives from outside and must be validated and coerced.

Typing. New Python code is expected to be annotated. Know Optional versus a plain default, Protocol for structural typing instead of inheriting from a base class you do not control, generics (the class Box[T] syntax from 3.12 as well as the older TypeVar form), and what mypy or pyright in strict mode actually buys you. A good answer to "are type hints worth it" is specific: they make refactoring across a large codebase survivable and they catch None leaks, and they do nothing at runtime unless you validate.

Concurrency, which is the single most misunderstood area. Be able to say cleanly: threads for IO-bound work, processes for CPU-bound work, asyncio for large numbers of concurrent IO waits. The GIL historically meant one thread executes Python bytecode at a time, which is why CPU-bound threading does not scale. The free-threaded build arrived as an experiment in 3.13 and became officially supported, though still not the default interpreter, in 3.14, so describe it as a direction rather than something you can rely on at work today, and check its current status before asserting anything about it in an interview. The practical trap they are really testing: calling a blocking function (requests.get, a synchronous database driver, time.sleep, a heavy CPU loop) inside an async def stalls the entire event loop, and the fix is asyncio.to_thread, a real async client such as httpx or asyncpg, or moving the work to a queue.

Performance and memory. Know how to find a hotspot rather than guess at it: cProfile or py-spy for CPU, tracemalloc or memray for memory, timeit for microbenchmarks. Know the ladder of fixes in order: do less work, use the right data structure, vectorise with NumPy, cache, move the hot path to Numba, Cython or Rust, then parallelise. Saying "I would profile first" is table stakes; naming the tool and describing what its output looks like is the signal.

Packaging and environments, asked more in 2026 than it used to be because dependency pain is universal. Know pyproject.toml, the difference between a declared dependency range and a lock file, why pip freeze output is not a lock file (no hashes, no resolution for platforms other than the one you ran it on), editable installs for local development, wheels versus source distributions, and why a package that installs on your Mac fails in an Alpine container: Alpine is musl rather than glibc, so a manylinux wheel does not apply, and unless the project publishes a musllinux wheel pip falls back to compiling from source in an image with no toolchain. The usual fix is a slim Debian base image. Know uv, which resolves and installs dramatically faster than pip, and know Poetry, because you will meet both.

Testing. pytest specifics: fixtures and scope, parametrize, monkeypatch, tmp_path, conftest.py, and pytest.raises. The judgment question is what to fake: fake the network and the clock, use a real database (a container, or a transaction rolled back per test) rather than mocking the ORM, and never assert on the implementation. If you can describe one test that caught a real bug, say it. Interviewers remember that answer.

The data round, which applies to the data engineering and AI tracks and increasingly to backend. Expect SQL first and treat it as the main event: joins including the semantics of a left join against a table with duplicate keys, aggregation, window functions (ROW_NUMBER, LAG, running totals), date bucketing, and reading a query plan to see whether an index was used. Then dataframes. The pandas questions that actually get asked: why iterrows is the wrong tool and what to do instead, the difference between merge, join and concat, how NaN propagates and how dtypes bite (an integer column quietly becoming a float because of one missing value), groupby with multiple aggregations, and the copy-versus-view trap behind chained assignment, which copy-on-write removes and which pandas has been moving to as the default, so know which behaviour the codebase in front of you has. Then scale: what you do when the file does not fit in memory. The expected answers are chunking, pushing the work into SQL, reading Parquet column subsets with PyArrow, DuckDB over files, Polars with a lazy frame and predicate pushdown, or Spark when it is genuinely big. Being able to say when Spark is overkill is worth more than being able to use it.

How to drill all of this without wasting evenings: volume of tutorial watching does not move the needle, deliberately reproducing failures does.

• Write the sharp-edge examples yourself: mutable default, loop closure, blocking call in an async handler, integer column turned float. Break it, then fix it.
• Load a public dataset of 10 to 50 million rows into local Postgres and DuckDB, then write 20 SQL queries including window functions and read every query plan.
• Take one 200-line script you wrote and convert it properly: package it, add type hints, add pytest tests, add ruff and mypy in CI, pin it with a lock file, containerise it.
• Profile something real. Find a slow function, profile it, make it several times faster, and write down what the profiler said before and after.
• Practise reading code aloud. Get a 40-line Python function with three defects planted in it and find them in five minutes.
• Do timed coding in Python specifically, not in pseudocode. Fluency with collections, itertools, slicing and comprehensions saves minutes in an online assessment.
• Rehearse one failure story per track out loud until it is 90 seconds long and has a number in it.

The Python resume: what gets read, what gets skipped, and where the numbers come from

A Python resume is read in two passes. A recruiter or a filter scans for the title, the stack and the seniority in seconds, not minutes. An engineer then reads the top two bullets of your most recent role and, if those land, clicks your repository. Everything else on the page is decoration, so load the top.

Match the title to the posting. If the posting says "Python Engineer" and you call yourself "Full Stack Developer", you are relying on a stranger to make the leap for you. Put a plain title line at the top matching the track you are applying to, and keep a separate version of the resume per track. Two versions, honest in both, is normal practice and converts far better than one generic one.

Write the stack line precisely and honestly. "Python 3.12, Django 5.2 LTS, DRF, Celery, Postgres, Redis, Docker, AWS (ECS, S3, RDS), pytest, GitHub Actions" tells a reviewer exactly where you fit. A 40-item dump of every library you have imported once tells them you are padding, and it invites the interviewer to ask about the weakest item on the list. Everything on that line is fair game, so cut anything you cannot discuss for two minutes.

Bullets need a unit. The difference between a bullet that works and one that does not is a number with a dimension attached. Numbers a Python developer can legitimately produce: requests per second and p95 or p99 latency; rows processed per run and runtime; warehouse or cloud cost before and after; data volume in GB or TB; a reduced error rate or a specific incident class eliminated; queue backlog cleared; a model metric against a stated baseline; test coverage, but only if it accompanied something real; number of services, DAGs or users. If you genuinely do not have numbers from work, describe the shape rather than inventing a figure: "cut a nightly job from several hours to under 30 minutes by replacing a row-wise loop with a vectorised merge" is credible and checkable in conversation. Never invent a percentage. Interviewers probe the numbers, and a fabricated one collapses in the one room that matters.

What gets ignored or actively hurts. "Passionate about clean code." An objective statement. A skills section with proficiency bars. Tutorial projects with recognisable names (a to-do app, a weather CLI, the Titanic dataset, a clone of a well-known site) listed as portfolio work, because every reviewer has seen hundreds of them. Certifications stacked above experience. A GitHub profile that is 30 forks and no commits, which is worse than no link at all. Two columns, graphics and an embedded photo, which break text extraction in some applicant tracking systems, so keep the PDF single column with a real text layer and the links as plain visible URLs.

If you are changing tracks or coming from an adjacent job, say so in one line at the top and then make the evidence match: "Data analyst moving to data engineering: rebuilt our weekly reporting as an Airflow DAG with dbt models and tests, now the team's source of truth." That reads as a developer. "Proficient in Python, SQL and Excel" reads as an analyst, which is the job you are leaving.

On AI tool usage on a resume: do not list a chat assistant or an autocomplete tool as a skill, because it reads as filler. If AI work is relevant, name the engineering of it instead: the eval harness, the serving path, the retrieval design, the cost control. That is a skill. Prompting a chatbot is not a differentiator in 2026.

• Top of page: title matching the posting, one precise stack line, then your strongest two bullets with numbers.
• One resume per track. Backend and data engineering are different documents even with identical underlying experience.
• Every bullet: what you built, the constraint, the outcome with a unit. Cut bullets that describe responsibilities.
• Link two or three repositories that run cleanly, not a profile page full of forks.
• Cut tutorial projects by name. Replace one with a smaller project built on data you had to clean yourself.
• Single column PDF, real text layer, visible URLs. No bars, no photo, no tables around contact details.
• Everything on the stack line is interview material. If you cannot talk about it for two minutes, delete it.

Interview questions you should expect, and what each one is grading

These are the questions that recur across Python loops in 2026-27. Prepare the answer and the reason it was asked; the second part is what distinguishes a prepared candidate from a rehearsed one.

Practise them out loud. Python interviews are heavily verbal: much of the score comes from narration while you type, and silence reads as being stuck even when you are not.

• "What does this print?" over a snippet with a mutable default argument or a loop closure. Grading: production scars, not cleverness.
• "Generator or list here, and why?" Grading: whether you think about memory before it becomes an incident.
• "This endpoint is declared async and the service got slower under load. Why?" Grading: whether you understand the event loop. The answer is a blocking call inside it.
• "Threads, processes or asyncio for this workload?" Grading: whether your GIL knowledge is accurate and current rather than a slogan.
• "How do you pin dependencies, and what happens when a transitive dependency breaks the build?" Grading: whether you have run a real deployment.
• "Walk me through how you would find why this job takes four hours." Grading: whether you profile or guess. Name the tool.
• "Write a function that retries a flaky HTTP call." Grading: timeouts, bounded attempts, exponential backoff with jitter, which exceptions you retry, and idempotency. Most candidates forget the timeout.
• "Here is a messy CSV of 20 million rows. Compute X." Grading: chunking, or pushing it into SQL or DuckDB, rather than loading it all, plus how you handle bad rows.
• "Write the SQL for the latest record per customer." Grading: window functions. Asked in nearly every data-track loop.
• "How do you test code that calls a third-party API?" Grading: what you fake versus what you keep real, and whether you test behaviour rather than implementation.
• "Review this diff." Often a generated patch. Grading: whether you name defect classes (missing timeout, unbounded query, swallowed exception, race on a read-modify-write, unvalidated input, secret in a log line) instead of commenting on style.
• "Design the system or pipeline behind this feature." Grading: your level. Volumes out loud, a named tradeoff, and what you are deliberately not building.
• "Tell me about something you shipped that broke." Grading: ownership and honesty. Have one with a cause, a fix and a prevention step.
• "Why Python for this, and when would you not use it?" Grading: engineering judgment. Good answers include CPU-bound hot paths, hard real-time constraints, and shipping to an environment where a Python runtime is a liability.

Where the jobs are, how to reach a human, and what to say about pay

Python hiring is not concentrated in tech companies, and candidates who only apply to tech companies are fishing in the most crowded water. Large Python employers include banks and insurers (risk, pricing, reporting), biotech and pharma (pipelines, lab automation, bioinformatics), hospital systems and health tech, energy and utilities, aerospace and defence contractors, national laboratories and universities, logistics and manufacturing, government at every level, scientific instrument makers, and the agencies and consultancies that build for all of the above. Defence and government work that requires a security clearance is a durable moat: fewer applicants and a slower process. Note how it works, though, because candidates get this wrong: an employer sponsors the clearance process for someone they are hiring, and most US clearances require US citizenship, so it is not a route around work authorisation.

Routes that produce replies. Apply directly on company career pages rather than through aggregator reposts, because the aggregator version is often stale. Use the Python Job Board on python.org, which is small, moderated and far less crowded than the general boards. Read the monthly Hacker News "Who is hiring" thread and reply to the posts an engineer clearly wrote. Go to a local PyData, Django or Python user group meetup, and a regional PyCon if one is reachable; the proportion of attendees who are hiring is high and the conversation starts from code rather than from a resume. For quantitative and ML roles, specialist recruiters are genuinely useful and will talk to you.

The highest-yield cold approach for a Python candidate is code. Find a library the team uses, fix a real issue in it, get it merged, then write two sentences to the engineering manager: what you fixed, what you noticed about their stack, what you would want to work on. That gets a reply at a rate nothing else matches. Second best is a small, specific piece of work: reproduce a bug in their public API, or write a short note on something concrete you would improve in their open source repository. Do not send a generic "I am passionate about Python" message to 200 companies.

Referrals still dominate. One warm introduction is worth dozens of cold applications, and the referral does not need to come from a friend: a former colleague, someone from a meetup, or a maintainer you have worked with in public all count.

On pay, the discipline is the same as everywhere else in this guide: name the source, not a number you cannot support. Look up the BLS Occupational Employment and Wage Statistics for your metropolitan area under the occupation code matching your track, then read the posted ranges in states that require them, then triangulate against levels.fyi if you are targeting large public tech employers, remembering that it is self-reported and weighted toward the highest payers. Pay in Python roles varies more by sector and track than by Python skill itself: quantitative finance, AI infrastructure and senior backend at large tech employers sit at the top, while scientific, academic, non-profit and most public sector Python sit at the bottom, sometimes by a factor of two for technically similar work. Contract and consultancy day rates follow a different curve again and usually require you to carry your own insurance and downtime.

When the recruiter asks your expectation on the first call, give a range whose bottom you would actually accept, say it is based on the posted ranges for the role and location, and ask what band they have approved for the level. If they will not name a band and the posting does not have one, that is information too. Negotiate on the written offer with a specific competing data point rather than a feeling, and ask about the parts of the package that are easy to forget: on-call expectations and compensation, equipment and compute budget, conference and training budget, remote and time zone expectations, and whether the role is funded as permanent headcount or against a single project.

• Apply on company career pages. Treat aggregator listings as leads to verify, not as applications.
• Underfished employers: insurers, hospital systems, universities, labs, utilities, logistics, government and defence.
• Highest-yield cold outreach for a Python candidate: a merged pull request on a library they depend on.
• Pay sources, in order: BLS OES for your metro and occupation code, posted ranges in pay-transparency states, then levels.fyi for large public tech, caveated as self-reported.
• Ask the band on the first call, negotiate on the written offer, and ask about on-call before you sign.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Python developer
• Python engineer
• Python software engineer
• Backend engineer Python
• Python 3.12
• Python 3.13
• Python 3.14
• Type hints
• mypy
• pyright
• ruff
• Black
• uv
• Poetry
• pip
• pyproject.toml
• Virtual environments
• venv
• Lockfile
• Wheels
• Packaging
• Django
• Django REST Framework
• FastAPI
• Flask
• Litestar
• Pydantic
• Pydantic v2
• ASGI
• WSGI
• uvicorn
• gunicorn
• REST API
• OpenAPI
• GraphQL
• gRPC
• Celery
• RQ
• Redis
• RabbitMQ
• Kafka
• asyncio
• async await
• httpx
• aiohttp
• asyncpg
• Threading
• Multiprocessing
• concurrent.futures
• GIL
• Free-threaded Python
• Generators
• Iterators
• Decorators
• Context managers
• Dataclasses
• TypedDict
• Protocol
• itertools
• functools
• pathlib
• logging
• argparse
• Click
• Typer
• pytest
• Fixtures
• Parametrized tests
• monkeypatch
• Hypothesis
• tox
• nox
• Coverage
• Test-driven development
• SQL
• PostgreSQL
• MySQL
• SQLite
• SQLAlchemy
• Alembic
• Django ORM
• Database migrations
• Window functions
• Query optimization
• EXPLAIN ANALYZE
• Index design
• Transactions
• N+1 query
• pandas
• NumPy
• Polars
• DuckDB
• PyArrow
• Parquet
• SciPy
• Numba
• Cython
• Vectorization
• Jupyter
• Apache Airflow
• Dagster
• Prefect
• dbt
• PySpark
• Apache Spark
• Snowflake
• BigQuery
• Databricks
• ETL
• ELT
• Data pipelines
• Idempotency
• Backfill
• Data quality
• pandera
• Great Expectations
• scikit-learn
• PyTorch
• Hugging Face transformers
• MLflow
• Feature engineering
• Model evaluation
• LLM
• RAG
• Retrieval augmented generation
• Embeddings
• pgvector
• Vector database
• vLLM
• LangChain
• Structured outputs
• Evaluation harness
• Model Context Protocol
• AI code review
• Docker
• Docker Compose
• Kubernetes
• AWS
• boto3
• Lambda
• ECS
• S3
• GCP
• Azure
• Terraform
• CI/CD
• GitHub Actions
• Git
• Linux
• Bash
• Observability
• Prometheus
• Grafana
• OpenTelemetry
• Sentry
• cProfile
• py-spy
• tracemalloc
• Memory profiling
• Performance optimization
• Caching
• Rate limiting
• Retry with backoff
• Code review
• System design
• Agile
• Scrum
• On-call

Mistakes that cost people this job

Questions people ask