Senior Python Developer Interview Questions and Scorecard
Six question sets for the owner or lead running the interview: core language depth, architecture and data, testing and production, a code review exercise that replaces the whiteboard, mentoring, and a scoring rubric with red flags. Download as DOCX.
The hardest part of hiring a senior Python developer is that the questions everyone asks online have public answers. A candidate who spent an evening reading can define a decorator, a generator, and the Global Interpreter Lock perfectly well, and you learn almost nothing from hearing it. The gap between a strong mid-level developer and a real senior one does not live in the definitions.
At FirstHR we build for small businesses that hire without an HR department, where the owner or a single lead runs the whole interview. These six sets are written for that reader. Every question comes with what a good answer sounds like, plus a code review exercise that works even if you do not write Python yourself, and a scorecard so the decision rests on written evidence.
One note before you start. Nothing here is written for the candidate. It is written for the person deciding what to ask, which is why each set explains the reason a question is worth asking and what separates a strong answer from a rehearsed one.
TL;DR
Interview a senior Python developer on five things: language depth judged by reasons rather than definitions, architecture and data judgment, testing and production discipline, code review quality, and mentoring. Ask why that matters once after every answer. Replace the whiteboard with a 20 minute code review of a file with planted problems. Federal wage data puts the software developer median at $135,980 and the 75th percentile at $171,980.
What a Senior Python Developer Owns
A senior Python developer owns outcomes rather than tickets: choosing a design, defending it, keeping it running in production, and raising the level of everyone who touches the code afterward. The Python itself is the smallest part. Judgment about systems, data, and people is what you are paying the premium for.
That definition matters because the title is used loosely. Some candidates have five years of writing features inside a design someone else chose. Others have owned a service end to end, including the night it broke. Both may call themselves senior, and only one of them will help a small team that has no safety net.
At a small company the scope is broader still. The same person often picks the framework, writes the tests, sets up deployment, reviews their own work, and explains tradeoffs to an owner who does not code. Our guide to technical recruitment covers the sourcing side; this page covers the interview itself.
Which Question Set to Use
Use the core language, architecture, and production sets for every senior candidate, then add the code review exercise and the mentoring set for anyone who will work without a peer reviewing their code. The scorecard is used with all of them.
Core Python Language
Depth, not trivia
Language questions with a second layer: mutable defaults, the GIL, generators, copies, and type hints, each judged on the reason rather than the definition. Start here.
Architecture, API, Data
Judgment about systems
Service design, framework choice, REST versus RPC, the N+1 query, zero-downtime migrations, queues, and secrets. The set a senior hire is really paid for.
Testing and Production
Your on-call weekends
Unit versus functional tests, what to mock, a slow request in production, tooling, incidents, logging, and dependency upgrades. Weight this heavily for a sole developer.
Code Review Exercise
Better than a whiteboard
A short file with planted problems, reviewed out loud in 20 minutes. Works even if you cannot write Python, and grades what the job actually involves.
Seniority and Mentoring
Scope, not years
Owned decisions, mentoring evidence, pushing back on requirements, technical debt calls, and explaining tradeoffs to a non-technical owner.
Scorecard and Red Flags
Rate, then decide
A six-area rubric, a mid-level versus senior comparison, and a red-flag checklist so you compare candidates on written evidence instead of impressions.
Ask Why That Matters, Once, After Every Answer
The single highest-value follow-up in a senior interview is one short question: why does that matter? A rehearsed candidate delivers the definition and stops. A senior one keeps going into the consequence, the time it cost a team, the tradeoff they accepted. You are not testing whether they know the answer, you are testing whether they have lived with it. Use it after every question in every set on this page, and write down what came out.
6 Question Sets to Download
Download all six as a single Word document, or copy the sets you need. Each one follows the same structure: when to use it, the questions with good-answer notes, what to listen for, and space for notes. The last file is the scorecard with a mid-level versus senior comparison and a red-flag checklist.
Download All 6 Senior Python Question Sets
Core language, architecture, testing and production, a code review exercise, seniority and mentoring, plus a scoring rubric with red flags. All in one DOCX.
Set 1: Core Python Language Questions
Language questions with a second layer built in: mutable defaults, the Global Interpreter Lock, generators, copies, and type hints, each judged on the reason rather than the definition. Start here with every candidate.
Core Python Language Questions
CORE PYTHON LANGUAGE INTERVIEW QUESTIONS (SENIOR)
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This set separates a senior Python developer from a competent mid-level one. The
questions are not trivia. Every one of them has a textbook answer a mid-level
candidate can recite, and a second layer, the reason it matters, that only
someone who has shipped and maintained Python in production tends to reach. Ask
6 to 8 of these. After each answer, ask "why does that matter?" once.
QUESTIONS
1. What is the difference between a list and a tuple, and when do you pick each?
(Good answer: mutability and hashability, tuples usable as dict keys and in
sets, and a real design choice they made because of it. A weak answer stops
at "tuples cannot be changed.")
2. Why is a mutable default argument, such as def f(items=[]), a trap?
(Good answer: the default is evaluated once when the function is defined, so
every call shares the same object. Uses None as the sentinel instead. A senior
candidate has usually debugged this in someone else's code.)
3. What does the Global Interpreter Lock mean for your code in practice?
(Good answer: one thread runs Python bytecode at a time, so threads help
I/O bound work while multiprocessing or async fits CPU bound work. Look for
the practical consequence, not a definition.)
4. Walk me through a decorator you wrote and why you wrote it.
(Good answer: a concrete case such as retry, timing, caching, or auth, plus
awareness of functools.wraps and what happens to the signature.)
5. When did you use a generator instead of building a list, and what did it buy?
(Good answer: memory and laziness on a real dataset or stream, with numbers.)
6. Shallow copy versus deep copy: when has the difference actually bitten you?
(Good answer: a nested structure mutated through a shared reference, and how
they found it.)
7. How do you use type hints, and what do they give you at runtime?
(Good answer: nothing at runtime by default, the value is static checking,
editor support, and documentation. Knows the checker they run in CI.)
8. What do you reach for in the standard library before adding a dependency?
(Good answer: names real modules and has an opinion on dependency weight,
supply chain risk, and long-term maintenance cost.)
WHAT TO LISTEN FOR
•Reasons and tradeoffs, not memorized definitions
•Specific stories from code they maintained, not tutorials they read
•Comfort saying "I do not know, here is how I would find out"
•An opinion about dependencies and long-term maintenance
NOTES
__
__
Set 2: Architecture, API, and Data Questions
Service design, framework choice, REST versus RPC, the N+1 query, zero-downtime migrations, background work, and secrets handling. This is the set a senior hire is really being paid for, so weight it accordingly.
Architecture, API, and Data Questions
ARCHITECTURE, API, AND DATA QUESTIONS (SENIOR PYTHON)
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
A senior developer is hired for judgment about systems, not for syntax. This set
tests whether the candidate can design something your team will still be able to
change in two years, and whether they know what breaks under real traffic and
real data. Use it for anyone who will own architecture decisions.
QUESTIONS
1. Walk me through the architecture of a Python service you designed. What would
you change if you started it again today?
(Good answer: a clear diagram in words, honest regrets, and the reasoning
behind the original choice. Regret with a reason is a strong senior signal.)
2. Which of Django, Flask, and FastAPI have you shipped, and how do you choose?
(Good answer: matches the framework to the problem, batteries included versus
minimal, sync versus async, and the team that has to maintain it.)
3. What are the core principles of a REST API, and how does that differ from RPC?
(Good answer: resources and uniform methods versus calling remote procedures,
plus a view on when RPC style is the better fit.)
4. Tell me about an ORM query that was slow in production. How did you find and
fix it?
(Good answer: the N+1 query pattern, found through query logging or an
application performance tool, fixed with eager loading or a rewritten query.)
5. How do you run a database migration on a live system with no downtime window?
(Good answer: additive changes first, backfill, deploy code, then remove the
old column. Knows that a long lock on a large table takes the service down.)
6. When do you move work to a background job or queue instead of the request?
(Good answer: anything slow, external, or retryable, with a view on idempotency
and what happens when the job fails halfway.)
7. How do you handle configuration and secrets across environments?
(Good answer: environment variables or a secret manager, never in the repo,
with a story about rotating a leaked credential.)
8. Where do you draw the line between a module, a package, and a separate service?
(Good answer: team boundaries and deployment cadence, plus healthy skepticism
about splitting a small system into services too early.)
WHAT TO LISTEN FOR
•Designs sized to the business, not to a resume
•Knows how systems fail, not only how they work
•Can defend a choice and also name its cost
•Talks about the people who maintain the code afterward
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Set 3: Testing, Debugging, and Production Questions
Unit versus functional tests, what to mock, a slow request in production, tooling, past incidents, logging, and dependency upgrades. If the hire will be your only Python developer, this set predicts your on-call weekends.
Testing, Debugging, and Production Questions
TESTING, DEBUGGING, AND PRODUCTION QUESTIONS (SENIOR PYTHON)
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
This is the set that predicts what your on-call weekends look like. A senior hire
is the person who keeps the service up, not only the person who adds features.
Ask these of every senior candidate, and weight them heavily if the hire will be
your only Python developer.
QUESTIONS
1. What makes a good unit test, and how is it different from a functional test?
(Good answer: fast, isolated, one behavior, fails for one reason, versus a
test that exercises the system end to end. Has a view on the right mix.)
2. How would you test code that calls a third-party API you do not control?
(Good answer: a boundary they own, fakes or recorded responses, plus a small
number of real contract tests. Does not mock everything blindly.)
3. What do you mock, and what do you leave real?
(Good answer: mocks at the edges, real code inside. Knows that over-mocked
tests pass while production breaks.)
4. A request is slow in production and fast locally. Walk me through your first
hour.
(Good answer: reproduce, look at metrics and traces, isolate the layer, check
the database and the network before rewriting Python. Method, not guesswork.)
5. What do you run for linting, formatting, type checking, and profiling?
(Good answer: names real tools and says which run in CI and which run locally.)
6. Tell me about a production incident you caused or fixed. What changed after?
(Good answer: owns it plainly, describes the fix, and names the guardrail added
afterward. Evasion here is a red flag at senior level.)
7. How do you handle logging and error tracking in a Python service?
(Good answer: structured logs, correlation identifiers, sensible levels, and an
error tracker. Knows not to log secrets or personal data.)
8. What is your approach to dependency upgrades and security patches?
(Good answer: a routine, pinned versions, automated alerts, and a story about a
breaking upgrade they handled.)
WHAT TO LISTEN FOR
•A repeatable debugging method rather than intuition
•Tests treated as a design tool, not a chore
•Ownership of past incidents without blame shifting
•Awareness that someone has to run this at 2am
NOTES
__
Set 4: Code Review Exercise
A short file with six to eight deliberate problems planted in it, reviewed out loud in 20 to 30 minutes. Includes the problem list, the run instructions, and a grading guide with senior, mid-level, and red-flag signals.
Code Review Exercise (Replaces the Whiteboard)
SENIOR PYTHON CODE REVIEW EXERCISE
Candidate: __
Company: __
Interviewer: __
Time: 20 to 30 minutes
WHY THIS EXERCISE
Reviewing code is closer to the actual job than solving a puzzle on a whiteboard,
and it works even when the interviewer cannot write Python. You hand the candidate
a short file, ask them to review it out loud, and grade how they think. Seniority
shows up in what they notice first and how they say it.
HOW TO RUN IT
1. Take a real file from your codebase, 40 to 80 lines, or write a small one.
2. Plant 6 to 8 problems from the list below. Keep a copy of the answer key.
3. Give the candidate the file 10 minutes before the call, or share it live.
4. Ask: "Review this as if a teammate opened the pull request. Talk me through it."
5. Do not correct them. Note what they find, in what order, and how they phrase it.
PROBLEMS TO PLANT
[ ] A mutable default argument, such as def add(item, target=[])
[ ] A bare except that swallows every error silently
[ ] A database query inside a loop (the N+1 pattern)
[ ] A hardcoded API key or password in the source
[ ] A function that does three unrelated things and needs splitting
[ ] An off-by-one error in a slice or a range
[ ] A variable or function name that hides what the code does
[ ] Missing or misleading error handling around an external call
[ ] A test that asserts nothing meaningful
HOW TO GRADE IT
Senior signals:
•Finds the security problem and the N+1 query, not only the style issues
•Prioritizes: says which problems block the merge and which are minor
•Explains the impact, for example "this leaks the key into version control"
•Asks about context before judging, for example "is this path hot?"
•Phrases comments the way a teammate would want to receive them
Mid-level signals:
•Finds the obvious style and naming issues, misses the silent failures
•Lists everything at equal weight with no priority
•Rewrites the code instead of explaining the problem
Red flags:
•Cannot find anything, or finds only formatting
•Condescending or dismissive about the code or its author
•Rewrites everything without asking why it was written that way
SCORE
Problems found: ______ of ______
Prioritization: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Communication: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Notes: __
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Seniority, Mentoring, and Collaboration Questions
Owned decisions, evidence of mentoring a named person, pushing back on a requirement, technical debt calls, and explaining a tradeoff to a non-technical owner. At a small company this set often decides the hire.
Seniority, Mentoring, and Collaboration Questions
SENIORITY, MENTORING, AND COLLABORATION QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
The word "senior" in a job title is about scope and judgment, not years. This set
is where you find out whether the candidate has actually owned decisions, raised
the people around them, and worked well with a business that is not technical.
At a small company this set often matters more than the language questions.
QUESTIONS
1. What is the biggest technical decision you owned end to end, and who
disagreed with you?
(Good answer: a real decision with a tradeoff, named opposition, and how it was
resolved. Candidates who have never faced disagreement have rarely led.)
2. Tell me about a developer you mentored. What did they get better at?
(Good answer: a specific person and a specific improvement. Vague pride in
"helping the team" is not evidence of mentoring.)
3. How do you write a code review comment that lands well?
(Good answer: separates blocking from optional, explains the why, asks
questions rather than issuing orders.)
4. Describe a time you pushed back on a product requirement. What happened?
(Good answer: raised the cost early, offered an alternative, and accepted the
decision once it was made.)
5. How do you decide when to pay down technical debt and when to ship?
(Good answer: ties the decision to business risk and frequency of change, not
to personal taste about clean code.)
6. You will be the only Python developer here for a while. How do you work?
(Good answer: writes for the next person, documents decisions, sets up CI and
tests early, and finds review outside the company if needed.)
7. How would you explain a technical tradeoff to an owner who does not code?
(Ask them to actually do it with a real example. This is a daily task at a
small company and it is easy to test on the spot.)
8. What would your first 90 days look like in a codebase you have never seen?
(Good answer: read and ship something small early, learn the deployment path,
ask why before changing things, and improve one painful area.)
WHAT TO LISTEN FOR
•Ownership of outcomes, not just of tickets
•Concrete evidence of raising other developers
•Plain language when talking to non-engineers
•Humility about code they did not write
NOTES
__
Set 6: Scoring Rubric, Seniority Guide, and Red Flags
A six-area rubric scored 1 to 5 with evidence lines, a side-by-side mid-level versus senior comparison, and a red-flag checklist, so candidates are compared on what they said rather than on who interviewed best.
Scoring Rubric, Seniority Guide, and Red Flags
SENIOR PYTHON DEVELOPER SCORECARD
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO SCORE
Score each area from 1 to 5 right after the interview, while it is fresh. Anchor
every score to something the candidate actually said or did. If more than one
person interviews, each scores independently before anyone talks, so the loudest
opinion does not set the tone. Use the same rubric for every candidate.
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
SCORING AREAS
Python language depth: reasons and tradeoffs, not definitions
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Architecture and data: designs sized to the business, knows how systems fail
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Testing and production: a method for debugging, ownership of incidents
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Code review quality: finds real problems, prioritizes, communicates well
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Mentoring and communication: raises others, explains tradeoffs plainly
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Ownership and judgment: owned decisions end to end, honest about regrets
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
MID-LEVEL VERSUS SENIOR SIGNALS
Area Mid-level Senior
Language Correct definitions Reasons, costs, and stories
Design Implements a given design Chooses and defends a design
Debugging Guesses and tries things Follows a repeatable method
Code review Style and naming Security, data, and priority
Scope Owns a task Owns an outcome
Team Answers questions Raises the people around them
Estimates Optimistic Bounded, with the risks named
RED FLAGS (WEIGH CAREFULLY)
[ ] Cannot give a specific example from code they maintained
[ ] Blames every past problem on management, the team, or the legacy code
[ ] Never says "I do not know" in a long technical interview
[ ] Dismissive about tests, documentation, or code review
[ ] Wants to rewrite everything before understanding why it exists
[ ] Cannot explain a technical tradeoff without jargon
[ ] Vague about what they personally built versus what the team built
You do not need to grade the code, you need to tell a specific, reasoned answer from a rehearsed one. That is a skill you already have from every other kind of interview, and the notes in each set give you the shape of a strong answer so you can listen for it without reading Python.
The pattern is consistent across all six sets. Strong answers name a real system, describe how the candidate found the problem, and say what the fix cost. Weak answers stay at the level of the textbook and never mention a consequence. Three examples make the difference concrete.
Why is a mutable default argument a trap in Python?
Strong answer: The default value is created once, when the function is defined, so every call shares the same object and state leaks between calls. A strong answer uses None as the sentinel and creates the list inside the function, then usually adds a story about debugging this in code someone else wrote.
Weak answer: A weak answer repeats that lists are mutable and tuples are not, without explaining when the default is evaluated or what actually goes wrong.
An ORM query is slow in production. How did you find and fix one?
Strong answer: Names the N+1 pattern: one query to fetch a list, then one more per row inside the loop. A strong answer says how they saw it, query logging or a performance tool, and how they fixed it, eager loading or a single rewritten query, with a before and after number.
Weak answer: A weak answer says the database was slow and they added an index, with no method for finding the cause and no measurement afterward.
A request is slow in production and fast on your laptop. First hour?
Strong answer: Describes a method: reproduce, check metrics and traces, isolate the layer, look at data volume, the database, and the network before touching Python. A strong answer is calm and ordered, and mentions what they would not do, such as optimizing code before measuring it.
Weak answer: A weak answer jumps straight to a guess, usually rewriting a loop or adding caching, without any step that would confirm the guess is right.
Two habits do most of the work here. Ask why that matters after every answer, and ask for the number: how slow, how many rows, how long the fix took. A candidate who has lived the story produces the detail without effort, and one who has not gets vague at exactly that point.
What Separates Senior from Mid-Level
Seniority is scope and judgment, not years. A mid-level developer implements a design well; a senior developer chooses the design, defends it, and names its cost out loud. Interview for that difference directly rather than assuming a longer resume delivers it.
Depth signals
Explains why a rule exists, not just the rule
Tells stories from code they maintained
Says what a choice costs as well as what it buys
Production signals
A repeatable debugging method under pressure
Owns a past incident without blame shifting
Thinks about the person on call at 2am
Leverage signals
Specific evidence of mentoring a named person
Code review comments that land well
Explains tradeoffs to a non-technical owner
Red flags
Never says I do not know in a long interview
Wants to rewrite before understanding
Vague about what they personally built
Signal
Mid-Level
Senior
Explains why a language rule exists, not just the rule
Chooses and defends an architecture, naming its cost
Follows a repeatable debugging method under pressure
Writes correct, working code from a given design
Finds security and data problems in a code review
Has specific evidence of raising other developers
One warning about years. A candidate with a decade inside a large platform team may have never chosen a database, run a migration alone, or explained a tradeoff to an owner. A candidate with five years at two small companies often has done all three. Interview the scope, not the calendar.
The Code Review Exercise
Replace the whiteboard with a code review. Hand the candidate a 40 to 80 line Python file with six to eight problems planted in it, ask them to review it as if a teammate opened the pull request, and grade what they find first, how they prioritize, and how they phrase it.
Pick a real file
Take 40 to 80 lines from your own codebase, or write a small one. Real code beats a puzzle because it carries the context a senior candidate will ask about.
Plant six to eight problems
A mutable default, a bare except, a query inside a loop, a hardcoded key, an off-by-one, a function doing three jobs. Keep the answer key.
Ask them to review it out loud
The prompt is simple: review this as if a teammate opened the pull request. Do not correct them. Note the order in which they find things.
Grade what they notice first
Seniors surface the security problem and the query in the loop, rank what blocks the merge, and phrase comments a teammate would want to receive.
The exercise works for a non-technical interviewer because seniority shows up in ordering and tone, not in syntax. A senior candidate opens with the hardcoded credential and the database query inside the loop, then says which problems block the merge. A mid-level one starts with naming and formatting and treats everything as equally important.
It also respects the candidate. Senior engineers who hold several offers will decline a four-hour unpaid take-home project and rightly so, but almost all of them will happily spend 25 minutes reading code with you. That is a real advantage when you are competing for people, as our guide to finding developers for a small company covers in more detail.
Skip the Timed Algorithm Puzzle
Copying a large technology company screen, with a whiteboard and a timed puzzle, tests something your job does not require. It measures interview practice rather than the ability to maintain a production system, and it filters out exactly the experienced candidates a small team needs, since people who have shipped for fifteen years are the least likely to have spent last month drilling puzzles. Use the code review exercise and the production questions instead, and reserve any written exercise for a paid, short, realistic task.
Scoring the Interview
Score every candidate on the same rubric immediately after the interview, while the answers are fresh. Rate six areas from 1 to 5 and anchor each score to something the candidate actually said, so you compare evidence rather than whichever conversation felt best. The scorecard set above holds the full sheet.
Scoring area
What a 5 looks like
Python language depth
Gives reasons and costs, with stories from code they maintained
Architecture and data
Designs sized to the business and knows how systems fail
Testing and production
A repeatable debugging method and ownership of past incidents
Code review quality
Finds security and data problems, then ranks what blocks the merge
Mentoring and communication
Names a person they raised and explains tradeoffs plainly
Ownership and judgment
Owned a decision end to end and is honest about the regret
If two or three people interview, each should score alone before the group talks. Otherwise the most technical voice anchors everyone else. The same questions and the same rubric for every candidate is the heart of a structured interview, and it feeds a clean decision through a shared evaluation form.
Keep the completed scorecards for every candidate together rather than scattered across three inboxes, so the comparison still holds up a month later when a second role opens. Applicant tracking is coming soon to FirstHR; until it ships, a shared folder and a consistent file name are enough for a small team.
Senior Python Developer Pay
There is no separate federal occupation for Python, so benchmark against software developers and adjust upward for seniority. Use the government figures as the floor of the conversation, then account for your market, whether the role is remote, and how much scope the person will carry alone.
Median $135,980, 75th Percentile $171,980 (BLS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers had a median annual wage of $135,980, about $65.38 an hour. The 25th percentile was $105,210, the 75th percentile $171,980, and the top 10 percent earned more than $214,670 (U.S. Bureau of Labor Statistics). Senior roles sit in the upper half of that range.
Classification matters as much as the number. Under the Fair Labor Standards Act, the computer employee exemption can cover a software engineer or similarly skilled worker paid on a salary basis at no less than $684 per week, or hourly at no less than $27.63. Duties and pay decide it, not the title, and some states apply a stricter test.
Write the classification, the pay, and the remote expectations into the offer. If you have not written the role out yet, the Python developer job description and the senior backend developer templates give you a starting point. This is general information, not legal advice.
Fair, Legal, and Structured Interviewing
A good technical interview is fair, legal, and structured, and the three reinforce each other. Asking every candidate the same job-related core questions keeps you compliant, reduces bias, and produces a better decision, which is the part most engineering interview lists leave out entirely.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing a hiring decision on protected characteristics, and questions that probe them create risk even when they are asked as small talk. Skip age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. In a senior developer interview the usual traps are casual: asking when someone graduated, how long they have been coding as a proxy for age, where they are originally from, or whether they can keep up with a young team. Ask about the work instead. This is general information, not legal advice.
Same core questions, every candidate
A structured interview, where every candidate answers the same core questions and is scored against the same rubric, predicts on-the-job performance better than a free-flowing technical chat, and it lowers the chance that a decision rests on rapport. Engineering interviews drift more than most, because a technical conversation follows whatever the candidate happens to be good at. Writing the questions in advance and keeping the same set across candidates is the fix, and it also gives you a defensible record of how you compared people.
Score independently, then discuss
When two or three people interview a senior developer, have each score the rubric alone before the group talks. Otherwise the most technical voice in the room anchors everyone, and a candidate who disagreed with that person about a framework quietly loses. Compare written evidence first, then discuss the gaps. Where scores diverge sharply, that disagreement is usually the most useful conversation of the whole process, because it surfaces what each interviewer actually values in the role.
Interview for your codebase, not a big tech screen
A senior Python developer at a company with a platform team and one at a company where they are the only engineer are different hires. Copying a large technology company screen, with algorithm puzzles under a timer, tests something your job does not require and pushes away strong candidates who maintain production systems for a living. Weight the code review exercise, the production questions, and the mentoring set, and be explicit about what the role must accomplish in its first 90 days.
Structure Beats a Free-Flowing Technical Chat
Federal hiring guidance describes the structured interview, where every candidate answers the same questions and is rated on the same scale, as one of the most reliable and legally defensible selection methods available (U.S. Office of Personnel Management). Asking the same job-related questions of everyone also keeps you within the EEOC rules against basing decisions on protected characteristics.
Technical interviews drift more than most, because a free conversation follows whatever the candidate is good at. Writing the questions in advance and holding the set steady is the fix. If you want the general version of this discipline, see our guides on running an interview and on questions employers cannot ask.
Interviewing Without an HR Department
A large company runs a senior developer through coordinated panels with a recruiter managing the scorecards and a platform team ready to catch mistakes. A small business has none of that, and the hire often becomes the entire engineering function. That reality should change how you run the interview.
You are hiring a senior Python developer and you do not write Python
Most owners making this hire cannot grade the code themselves, which is exactly why the interview has to be built differently. You do not need to judge whether an answer is technically perfect. You need to tell a specific, reasoned answer from a rehearsed one. Every question in these sets carries a note on what a good answer sounds like, and the code review exercise is designed so that the ordering of what a candidate notices tells you most of what you need, even if the code itself is opaque to you. Where you still feel unsure, pay a trusted senior engineer for two hours to sit in on one round.
This person may be your entire engineering function
At a larger company a senior developer sits inside a system of code review, on-call rotation, and platform tooling that catches mistakes. At a small business that system is the person you are hiring. That changes what you weight: testing and production discipline, willingness to document, and the ability to work without a peer reviewing every change matter more than raw algorithm speed. Ask the sole-developer question directly, and listen for someone who writes for the next person rather than someone who needs a team around them to be effective.
The offer and the first 90 days decide whether the hire works
Senior engineers are in demand, so a slow, vague process loses the candidate you wanted, and a strong hire who lands badly still leaves within a year. Once you decide, move: a clear written offer, the new hire paperwork, system and repository access ready on day one, and a first 90 days that gets them shipping something small in week one. FirstHR covers that people side for a small business: send the offer for e-signature, run the onboarding workflow and task checklist, and keep signed documents on the employee profile. To be clear on scope, FirstHR is an onboarding and HR platform, not a code hosting service or a technical assessment tool. Applicant tracking is coming soon to FirstHR.
Two practical rules follow from this. Weight testing, documentation, and production discipline above raw speed, because there is no team to catch what slips. And move fast once you decide, since the same candidate is usually talking to two other companies. More question sets for other roles sit in the hiring templates library, including a QA engineer set if you are building out the wider team.
From Interview to Onboarding
The interview is step one, and a strong hire who lands badly still leaves within a year. Move quickly from decision to a written offer letter, run a reference check that confirms what the candidate personally built, and have access ready before day one.
Send the offer fast
Confirm title, pay, remote expectations, and start date in writing, with e-signature. Senior engineers hold multiple offers, so a slow week costs you the hire.
Have access ready on day one
Repository, cloud, database, error tracking, and the deployment path. Nothing signals a serious employer faster than an engineer who can ship in week one.
Sign the security and IP paperwork
Confidentiality, intellectual property assignment, and the acceptable use policy, acknowledged before access is granted, not weeks later.
Structure the first 90 days
A small shipped change in week one, ownership of one area by month two, and a written check-in at 30, 60, and 90 days.
Developer onboarding has a few extra steps because of the access involved: repository, cloud, database, and deployment credentials, plus confidentiality and intellectual property paperwork signed before any of it is granted. Our guide to onboarding a developer walks through the sequence, and the standard new hire paperwork still applies on top of it.
FirstHR connects the offer, the e-signatures, the paperwork, and the access and policy checklist in one place, and keeps the signed documents on the employee profile, so a small business can run the whole hiring-to-onboarding path from one system. FirstHR is an onboarding and HR platform, not a code hosting service or a technical assessment tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
If you want the first 90 days written down rather than improvised, an onboarding template gives the new developer a structured ramp: something small shipped in week one, ownership of one area by month two, and a written check-in at 30, 60, and 90 days.
Key Takeaways
Interview a senior Python developer on judgment, not recall: language depth, architecture, production discipline, code review, and mentoring.
Ask why that matters once after every answer; the second layer is where a senior candidate separates from a rehearsed one.
Replace the whiteboard puzzle with a 20 to 30 minute code review of a file with six to eight planted problems.
Seniority is scope and judgment rather than years, so interview the decisions someone owned, not the length of the resume.
Score six areas from 1 to 5 with written evidence, independently, before anyone discusses the candidate.
Benchmark pay against the federal software developer figures: a $135,980 median and a $171,980 75th percentile in May 2025.
Move fast from decision to written offer, because senior engineers usually hold more than one.
Frequently Asked Questions
What questions should I ask a senior Python developer?
Ask questions that test judgment rather than recall, across five areas: core language depth, architecture and data, testing and production, code review, and mentoring. Strong openers include why a mutable default argument is a trap, what the Global Interpreter Lock means for their code in practice, how they found and fixed a slow ORM query, how they run a migration on a live system with no downtime window, and what their first hour looks like when a request is slow in production but fast locally. Add the seniority questions: the biggest technical decision they owned end to end, who disagreed, and a developer they mentored. After every answer, ask why that matters once. The second layer is where a senior candidate separates from a competent mid-level one, and it is the part a rehearsed answer rarely covers.
How do I interview a Python developer if I cannot code?
You do not need to grade the code, you need to tell a specific, reasoned answer from a rehearsed one. Each question in these sets carries a note on what a good answer sounds like, so you can listen for the shape rather than the syntax. The strongest tool is the code review exercise: hand the candidate a short file with a few deliberate problems planted in it, ask them to review it out loud, and note what they find first and how they say it. Seniority shows up in ordering and communication, both of which you can judge without reading Python yourself. Push every claim to a specific example, and ask them to explain one tradeoff in plain language. If you still feel unsure, pay a trusted senior engineer for two hours to sit in on one round.
What is the difference between a mid-level and a senior Python developer?
Scope and judgment, not years. A mid-level developer implements a design well and answers questions correctly; a senior developer chooses the design, defends it, and names what it costs. In practice the differences show up in specific places: a mid-level candidate recites the definition of a Python feature while a senior explains why the rule exists and tells a story about it going wrong; a mid-level candidate guesses during debugging while a senior follows a repeatable method; a mid-level code review finds naming and style while a senior finds the hardcoded key and the query inside the loop and says which one blocks the merge. Seniors also raise the people around them and give bounded estimates with the risks named. The scorecard on this page includes a side-by-side comparison of these signals.
Should I use a coding test or a take-home project?
For a senior hire, a code review exercise usually beats both. Algorithm puzzles under a timer test something the job does not require and push away strong candidates who maintain production systems for a living, while long unpaid take-home projects lose senior candidates who already hold other offers. The alternative is short and closer to the real work: give the candidate a 40 to 80 line file with six to eight deliberate problems planted in it, ask them to review it as if a teammate opened the pull request, and grade what they notice first, how they prioritize, and how they phrase the comments. It takes 20 to 30 minutes, works for an interviewer who does not write Python, and produces evidence you can score. If you do use a take-home, keep it under two hours and pay for it.
How much does a senior Python developer cost?
Python developers fall under the federal software developers occupation, which reported a median annual wage of $135,980 in May 2025 according to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey. Senior roles sit well above the median: the 75th percentile was $171,980 and the top 10 percent earned more than $214,670, while the 25th percentile was $105,210. There is no separate federal occupation for Python specifically, so treat software developers as the benchmark and adjust for your market, the seniority you are actually buying, and whether the role is remote or tied to a high-cost metro. Remember that a senior developer at a small company often carries architecture, testing, and deployment alone, which is a broader scope than the same title at a large employer.
Is a senior Python developer exempt from overtime?
Usually, but the title alone does not decide it. Under the Fair Labor Standards Act, the computer employee exemption can apply to a computer systems analyst, programmer, software engineer, or similarly skilled worker whose primary duty is systems analysis, design, development, or testing. The employee must be paid on a salary or fee basis at no less than the standard salary level of $684 per week, or at an hourly rate of at least $27.63. Job duties and actual compensation, not the job title, determine the outcome, and some states apply stricter tests than the federal one. Check the current federal fact sheet and your state rules before classifying the role, and reflect the classification in the offer letter. This is general information, not legal advice.
What are red flags in a senior Python developer interview?
The clearest red flag is an inability to give a specific example from code the candidate personally maintained, because senior claims should come with stories attached. Watch also for a candidate who blames every past problem on management, the team, or the legacy code, who never says they do not know across a long technical interview, who is dismissive about tests, documentation, or code review, or who wants to rewrite a system before understanding why it was built that way. In the code review exercise, finding only formatting issues while missing a hardcoded credential is a strong signal about level. Vagueness about what they personally built versus what their team built matters too, and it is the one a reference check will confirm or dismiss quickly.
How long should a senior Python developer interview process take?
Two to three rounds over one to two weeks is a reasonable target, and speed is a competitive advantage because senior engineers usually hold more than one offer. A practical shape is a 30 minute screen on scope and fit, a 60 minute technical round covering language depth and architecture, and a 45 minute round built around the code review exercise plus the mentoring questions. Score after each round while the answers are fresh rather than at the end. Long processes with five or six rounds mostly serve large companies with hiring committees, and at a small business they lose candidates rather than improving the decision. Decide what you must know, ask exactly that, and make the offer quickly once you know it.
