Python Developer Interview Questions and Scorecard
Free Python developer interview questions for small businesses: 6 sets by level, a coding exercise, good-answer notes, and a scorecard. Download as DOCX.
Python Developer Interview Questions and Scorecard
Six question sets for the owner running the interview: a 30-minute phone screen, a capped coding exercise with debrief questions, framework and data blocks, testing habits, behavioral questions, and a scorecard with a junior to senior level guide. Download as DOCX.
The first developer I ever hired, I interviewed by asking questions I had found on a list and nodding at answers I could not evaluate. He was pleasant, confident, and wrong for the job, and I did not find out until the third month. The problem was not that I could not write Python. The problem was that I had no idea what I was listening for.
At FirstHR we build for owners and managers who make this hire themselves, without an HR department and often without an engineer in the building. These six question sets cover the Python hire end to end: a phone screen, a capped coding exercise with the debrief questions that produce the actual signal, framework and data blocks, testing habits, behavioral questions, and a scorecard. Every question carries the reason it is worth asking and a note on what a good answer sounds like.
TL;DR
Interview a Python developer on five things: language fundamentals, practical coding on a real task, stack fit for the framework or data tooling you run, testing and production habits, and communication. Replace the whiteboard puzzle with a two-hour capped exercise and score the debrief rather than the code. Federal data puts the software developer median at $135,980. Download six question sets and a scorecard as DOCX.
What to Assess in a Python Developer
Assess five things: language fundamentals, practical coding on a realistic task, fit with the stack you actually run, testing and production habits, and the ability to explain a tradeoff to someone who does not code. Trivia about obscure language features is not on that list, because it predicts interview preparation rather than job performance.
The weighting shifts with company size. At a large employer a mid-level developer sits inside a team that reviews their work and catches what slips. At a small business there is nobody behind them, which is why production discipline deserves more weight than raw coding speed. Ask about the habits that survive a busy month, not the ones that show up in a rehearsed answer.
Language fundamentals
Mutability, data structures, and errors
Knows the reason, not just the definition
Manages environments and pinned dependencies
Stack fit
The framework or data tooling you actually run
Designs an endpoint or a pipeline end to end
Treats user input as untrusted by default
Production habits
Tests the logic that carries risk
A repeatable debugging method
Version control a stranger could pick up
Working with you
Explains a tradeoff without jargon
Asks before building the wrong thing
Comfortable being the only developer
Which Bar You Are Actually Setting
Decide the level before the first call, because it changes the questions, the exercise, and the pay. The practical dividing line is supervision: a junior developer needs somebody to review the work before it ships, and a mid-level developer does not. That single distinction decides most small business hires.
Level
What they can do unsupervised
When it fits a small business
Junior
Writes correct code for a task already defined for them
Only when someone else can review the work
Mid-level
Turns a fuzzy requirement into a working, tested feature
The right bar for most first developer hires
Senior
Owns the architecture and the consequences of it
When the hire will set the standard for a team
Most small businesses hiring their only developer need mid-level, because there is nobody available to review a junior hire and no team for a senior to lead. If you are deliberately hiring above that line, the deeper set in our senior Python developer interview questions covers architecture, mentoring, and a code review exercise built for that level. This page stays on the junior to mid-level hire.
Which Question Set to Use
Pick the sets that match your process and your stack rather than asking all of them. A typical three-round process uses the phone screen first, the exercise and framework block second, and the testing and behavioral sets in the final conversation, with the scorecard filled in after each round.
Phone Screen and Fundamentals
First 30 minutes
Seven questions that decide whether the candidate earns a full technical interview: what they personally built, lists versus tuples, the mutable default trap, and how they manage environments.
Practical Coding Exercise
Two-hour cap, live debrief
A realistic task brief plus the six debrief questions that produce the actual signal, including the walkthrough that checks authorship of work done with an AI assistant.
Frameworks, APIs, and Data
Match your stack
Two blocks: web and API work (framework choice, endpoint design, the slow page, secrets, injection) and data and automation work (pipelines, large files, dirty data, scheduling).
Testing and Working Habits
Your weekends
What they test and what they skip, mocking judgment, version control day to day, the production bug they cannot reproduce, dependencies, and documentation.
Behavioral and Collaboration
Month nine, not week one
STAR-style questions on disagreement, a bug that reached users, a wrong requirement, explaining tradeoffs to a non-technical owner, and working as the only developer.
Scorecard and Level Guide
Rate, then decide
A six-area rubric, a junior versus mid-level versus senior guide so you know which bar you are setting, and a red-flag checklist. Use with any set above.
Match the Set to the Round
First 30-minute call: Phone Screen and Fundamentals. Second round: Practical Coding Exercise, sent as a brief, plus the Frameworks block that matches your stack. Final round: the exercise debrief, Testing and Working Habits, and Behavioral and Collaboration. After every round: the Scorecard and Level Guide. Skip the framework block that does not apply, because a data hire and a web hire share a language and almost nothing else.
6 Free Question Sets to Download
Download all six as a single Word document or copy the sets individually. Each follows the same structure: when to use it, the questions with a reason and a good-answer note for every one, what to listen for, and space for notes. Fill in the blanks and use them as they are.
Download All 6 Python Developer Question Sets
Phone screen, coding exercise, frameworks and data, testing habits, behavioral, and a scorecard with a level guide. All in one DOCX.
Set 1: Phone Screen and Python Fundamentals
The 30-minute first call, built to decide one thing: does this candidate earn a full technical interview? Seven questions covering what they personally built, two fundamentals checks, and how they manage environments.
Phone Screen and Python Fundamentals
PHONE SCREEN AND PYTHON FUNDAMENTALS
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the 30-minute first call. It exists to answer one question: is this
person worth an hour of your engineering time? Ask 6 of these, in order, and stop
early if the answers are vague. Every question below carries the reason it earns
a slot and what a good answer sounds like, so you can score it even if you do not
write Python yourself.
QUESTIONS
1. Walk me through something you built in Python end to end. What did it do,
and what part did you personally write?
Why: it separates people who shipped from people who watched. The personal
ownership follow-up is the whole point of the question.
Good answer: a specific system, a specific slice of it they owned, and the
reason a decision inside it went one way rather than another.
2. What is the difference between a list and a tuple, and when do you reach
for each?
Why: cheapest possible check that the basics are real, and the "when" half
filters out memorized definitions.
Good answer: a list is mutable, a tuple is not, so a tuple works as a fixed
record or a dictionary key. A weak answer stops at "one uses brackets".
3. What happens if you use a mutable object such as a list as a default
argument value?
Why: the classic Python trap. Getting it right predicts real time spent in
the language rather than in a course.
Good answer: the default is created once when the function is defined and
shared across every call, so it accumulates state. The fix is a None default
and creating the object inside the function.
4. How do you manage dependencies and environments on a project?
Why: a developer who cannot reproduce an environment will hand you code that
only runs on their laptop.
Good answer: a virtual environment per project, pinned versions in a
requirements or project file, and a reason for pinning rather than floating.
5. What does a typical day look like for you, and how do you decide what to
work on when nobody assigns it?
Why: a small company has no ticket queue and no manager on standby.
Good answer: they set their own order, ask when the requirement is unclear,
and communicate before disappearing for three days.
6. What is the last thing you had to learn to finish a task, and how did you
learn it?
Why: the stack will change. Learning speed matters more than the current
library list.
Good answer: a concrete example with the source they used and what they
changed as a result.
7. What are you looking for in the next role, and what would make you leave it
after six months?
Why: it surfaces the mismatch now instead of in month seven.
Good answer: specific and honest. Silence or a perfectly polished answer both
deserve a follow-up.
WHAT TO LISTEN FOR
•Concrete systems and personal ownership, not team accomplishments
•The reason behind an answer, not only the definition
•Comfort saying "I do not know, here is how I would find out"
•Questions back to you about the product and the codebase
NOTES AND SCREEN DECISION
__
__
Advance to the technical interview: [ ] Yes [ ] No [ ] Hold
Set 2: Practical Coding Exercise and Debrief
A fill-in brief for a capped, realistic task, plus the six debrief questions that carry the signal. The walkthrough question doubles as the only reliable check on work produced with an AI assistant.
Practical Coding Exercise and Debrief
PRACTICAL CODING EXERCISE AND DEBRIEF
Candidate: __
Company: __
Interviewer: __
WHY THIS REPLACES THE WHITEBOARD PUZZLE
Algorithm puzzles measure interview practice. A small, realistic task measures
the job. Give one exercise, cap it at two hours, and spend the interview on the
debrief rather than watching someone type. The debrief questions below are what
actually produce the signal, so never accept a submission without them.
THE BRIEF (FILL IN AND SEND)
Task: write a small Python script or endpoint that reads ______,
transforms it into ______, and handles the case where the input
is missing or malformed.
Time cap: 2 hours. Send back what you have at the cap, finished or not.
Allowed: any library, any documentation, any AI assistant, as long as you can
explain every line in the debrief.
Deliverable: the code, a short README on how to run it, and one paragraph on
what you would do differently with another day.
DEBRIEF QUESTIONS (30 MINUTES, LIVE)
1. Walk me through the code as if I had never seen it.
Why: authorship and clarity in one question. It is also the only reliable
check on work done with an AI assistant.
Good answer: a clean narrative from entry point to output, with the reason
for the structure. Hesitation over their own code is the red flag.
2. What did you leave out because of the time cap, and why that instead of
something else?
Why: prioritization under constraint is the daily job at a small company.
Good answer: a deliberate cut with a reason, for example tests over polish,
or error handling over a nicer interface.
3. Where would this break first if the input were a hundred times larger?
Why: separates code that runs from code that keeps running.
Good answer: names the specific line, usually loading everything into memory
or a call inside a loop, and offers a realistic fix.
4. How would you test this? Show me the first test you would write.
Why: a developer who tests only when asked will not test at all once busy.
Good answer: starts with the failure case, not the happy path, and knows
what is worth mocking and what is not.
5. Which part are you least confident about?
Why: honest self-assessment predicts how they will behave in production.
Good answer: a real, specific weak spot. "Nothing" is not a strength.
6. I am going to suggest a change you may disagree with. Tell me why my idea is
wrong, or why it is better.
Why: you will be the non-technical voice in the room for a while. You need
someone who pushes back with a reason rather than agreeing to everything.
Good answer: engages on the merits, changes position when the argument is
good, holds it when it is not.
SCORING THE EXERCISE
Readability: a stranger can follow it [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Two blocks so you ask only what applies. Web and API work covers framework choice, endpoint design, the slow page, secrets, and injection. Data and automation covers pipelines, oversized files, dirty input, and scheduled jobs.
Frameworks, APIs, and Data Questions
FRAMEWORKS, APIS, AND DATA QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
Use the block that matches what the hire will actually touch. Python covers web
back ends, data work, and automation, and those are three different hires. Ask
the block you need and skip the rest. Asking a data-pipeline candidate about
templating tells you nothing useful.
BLOCK A: WEB AND API WORK
1. Which Python web framework do you know best, and what does it give you that
a bare script does not?
Why: framework fluency is most of the ramp-up time on a web hire.
Good answer: names the framework and the tradeoff. A full-stack framework
brings an ORM, an admin, and conventions. A micro-framework brings freedom
and more assembly. An async, type-hint driven framework brings generated API
docs and speed on I/O-heavy work.
2. How do you design a REST endpoint? Walk me through one you built.
Why: API design is where a small team pays for shortcuts later.
Good answer: resource naming, status codes, validation at the boundary,
pagination, and a versioning plan.
3. A page that used to load instantly now takes eight seconds. Where do you
look first?
Why: this is the real bug you will actually hand them.
Good answer: measure before guessing, then check for a database query issued
once per row in a loop, the single most common cause in an ORM application.
4. How do you handle authentication and store secrets such as API keys?
Why: one hardcoded key in a repository is a very expensive interview miss.
Good answer: secrets in environment variables or a secret manager, never in
the repository, and hashed passwords using a library rather than a homemade
scheme.
5. How do you prevent SQL injection when a query needs user input?
Why: a non-negotiable for anyone touching a database.
Good answer: parameterized queries or the ORM query layer, never string
formatting of raw SQL.
BLOCK B: DATA AND AUTOMATION WORK
1. Walk me through a data pipeline you built. Where did the data come from and
where did it land?
Why: data candidates describe tools easily and systems rarely.
Good answer: source, transformation, destination, schedule, and what happens
when a run fails.
2. How do you handle a file that is too large to load into memory?
Why: the dividing line between a notebook user and someone who can run a job.
Good answer: stream it, read in chunks, or push the work into the database
rather than pulling everything into a data frame.
3. What do you do when the source data is dirty: missing fields, duplicates,
inconsistent dates?
Why: most real data work is this, not modelling.
Good answer: validate at ingestion, log what was rejected, and never silently
drop rows.
4. How do you schedule and monitor a recurring job, and how do you find out it
failed?
Why: an unmonitored job is a job you will hear about from a customer.
Good answer: a scheduler, alerting on failure, and logs someone can read.
5. How do you make an analysis reproducible six months later?
Why: a small business cannot afford a result nobody can regenerate.
Good answer: pinned dependencies, version-controlled code, parameters in a
config rather than edited by hand.
WHAT TO LISTEN FOR (BOTH BLOCKS)
•Measures before optimizing
•Treats input as untrusted by default
•Thinks about the failure path, not only the happy path
•Can explain a technical tradeoff to a non-technical owner
NOTES
__
Set 4: Testing, Version Control, and Working Habits
The set to weight most heavily when the hire will be your only developer: what they test and what they skip, mocking judgment, version control day to day, the unreproducible production bug, and documentation.
Testing, Version Control, and Working Habits
TESTING, VERSION CONTROL, AND WORKING HABITS
Candidate: __
Company: __
Interviewer: __
WHY THIS SET MATTERS MOST AT A SMALL COMPANY
With one or two developers there is no safety net. Nobody reviews the change
that goes out on a Friday, and nobody notices the missing test until a customer
does. Weight this set heavily whenever the hire will be your only developer, and
weight it above raw coding speed.
QUESTIONS
1. What do you test, and what do you deliberately not test?
Why: "everything" and "nothing" are both wrong answers, and the reasoning
behind the line is the signal.
Good answer: tests the logic that carries risk and the bugs already found,
skips trivial getters and third-party library internals.
2. Show me how you would write a test for a function that calls an external
API. What do you replace?
Why: mocking judgment is where test suites turn into decoration.
Good answer: replaces the network call at the boundary, keeps the logic under
test real, and does not mock so much that the test proves nothing.
3. How do you use version control day to day? Branch, commit, review.
Why: a solo developer with bad habits leaves you a repository nobody else can
pick up.
Good answer: small commits with readable messages, a branch per change, and
pull requests even when working alone.
4. Something is broken in production and you cannot reproduce it locally. Walk
me through the next hour.
Why: debugging under pressure is the job, and the method is teachable only if
they already have one.
Good answer: reproduce from logs, narrow with a bisect or added logging, fix
the cause rather than the symptom, then add the test that would have caught it.
5. How do you decide when to add a library and when to write the code yourself?
Why: dependency sprawl is a slow tax on a small codebase.
Good answer: weighs maintenance, security updates, and how much of the
library they would actually use.
6. How do you keep dependencies current and handle a security advisory?
Why: nobody else at your company will be watching for this.
Good answer: a routine rather than a panic, automated alerts, and upgrading
in small steps with tests to catch breakage.
7. How do you document your work so somebody else can pick it up?
Why: assume this person eventually leaves. What remains is what you bought.
Good answer: a README that gets someone running, comments explaining why
rather than what, and clear naming as the first line of documentation.
WHAT TO LISTEN FOR
•A repeatable method, not heroics
•Tests treated as part of the work, not a separate chore
•Comfort leaving a trail for someone who is not there yet
•Honest description of a bug they caused and how they fixed it
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
STAR-style questions on disagreement, a bug that reached users, a requirement that turned out to be wrong, explaining tradeoffs without jargon, and working as the only developer in the company.
Behavioral and Collaboration Questions
BEHAVIORAL AND COLLABORATION QUESTIONS
Candidate: __
Company: __
Interviewer: __
HOW TO USE THIS SET
Technical skill gets someone through week one. These questions decide whether
the hire still works in month nine, when the requirement changed twice and
nobody wrote it down. Ask for real past examples and use the STAR pattern:
Situation, Task, Action, Result. If the answer stays hypothetical, ask again for
a specific time it happened.
QUESTIONS
1. Tell me about a time you disagreed with how something was being built. What
did you do?
Why: you need someone who raises a problem before it ships, not after.
Good answer: raised it early, with a reason, then committed to the decision
either way. Neither silent compliance nor a standoff.
2. Tell me about a bug you shipped that reached users. What happened next?
Why: everyone ships bugs. Only some of them own it.
Good answer: says what broke, what they did about it, and what changed so it
would not happen again. Blaming a previous team is a warning sign.
3. Describe a requirement you were given that turned out to be wrong. How did
you find out?
Why: at a small company the requirement is often a sentence from the owner,
and it is often incomplete.
Good answer: asked questions early, built something small to check, came back
with the problem rather than building the wrong thing correctly.
4. How do you explain a technical tradeoff to somebody who does not code?
Why: that person is you. If they cannot do this, you cannot make decisions.
Good answer: gives a real example in plain language with the business cost
attached, not a lecture about the technology.
5. Tell me about the last time you were stuck for more than a day. What did you
do about it?
Why: it measures how long silence lasts before somebody asks for help.
Good answer: a time-box, then asked, with a clear description of what they
had already tried.
6. What is something you built that you would write differently now?
Why: it measures growth and honesty at the same time.
Good answer: a specific decision, the reason it looked right then, and what
they learned. Nothing at all is a poor sign.
7. You will often be the only developer here. How do you feel about that, and
how have you handled working without a team around you?
Why: some strong engineers are miserable alone. Better to find out now.
Good answer: realistic about the tradeoffs, has an outside network for
sounding out decisions, does not expect a senior to unblock them.
WHAT TO LISTEN FOR
•Real situations with real outcomes, not philosophy
•Ownership language: "I decided", "I got it wrong", "I fixed"
•Asks questions early rather than guessing quietly
•Explains technical decisions in the language of the business
NOTES
__
Set 6: Scoring Rubric, Level Guide, and Red Flags
A six-area rubric with space for written evidence, a junior to senior level guide so you know which bar you are setting, and a red-flag checklist. Use it with any set above and fill it in immediately after each round.
Scoring Rubric, Level Guide, and Red Flags
PYTHON DEVELOPER SCORING RUBRIC, LEVEL GUIDE, AND RED FLAGS
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO SCORE
Score every area right after the interview, while it is fresh, and anchor each
score to something the candidate actually said. If two people interview, each
scores alone before anyone talks, so the most technical voice in the room does
not set everybody else. Use the same rubric for every candidate for the role.
Rating scale:
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or a red flag
SCORING AREAS
Python fundamentals: data structures, mutability, errors, environments
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Practical coding: the exercise, readability, handling messy input
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Stack fit: the framework, database, or data tooling you actually run
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Testing and production habits: tests, version control, debugging method
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Communication: explains tradeoffs to a non-technical owner
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Autonomy: decides and moves without a manager assigning work
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Total: ______ / 30
LEVEL GUIDE: WHICH BAR YOU ARE ACTUALLY SETTING
JUNIOR
•Writes correct code for a well-specified task
•Needs the task defined for them and review before it ships
•Fundamentals present, production habits still forming
•Hire when someone else can review the work
MID-LEVEL
•Takes a fuzzy requirement and returns a working feature
•Tests and debugs without being told to
•Knows one framework or data stack well enough to be productive in week one
•The right bar for most small businesses hiring one developer
SENIOR
•Owns the architecture and the consequences of it
•Raises the requirement problem before building
•Mentors, reviews, and sets the standard for anyone who follows
•Interview with a deeper set built for that level
RED FLAGS (WEIGH CAREFULLY)
[ ] Cannot explain code they submitted as their own work
[ ] Describes only what the team did, never what they did
[ ] Dismisses testing, documentation, or code review as bureaucracy
[ ] No example of a mistake they made or a decision they got wrong
[ ] Blames every previous employer for every previous problem
[ ] Vague about which parts of a project they personally built
[ ] Cannot describe a tradeoff without technical jargon
You do not need to write Python to run this interview, because you are not grading syntax. You are checking whether the candidate can explain their own work, whether they measure before guessing, whether testing is a habit, and whether they own a mistake in specific terms. All four are visible to a non-technical interviewer.
The examples below show the pattern. In each case the strong answer is specific and explains the reason, and the weak answer is a definition with nothing behind it or a fix proposed before the cause is known. Once you have seen three of these side by side, the shape becomes easy to recognize in any question.
What happens if you use a list as a default argument value?
Why ask it: It is the cheapest honest test in Python. The behavior surprises almost everyone the first time, so a correct answer means real time spent in the language rather than in a tutorial.
Strong answer: The default object is created once, when the function is defined, and every call shares it, so state leaks between calls. The fix is a None default and building the object inside the function body. A strong candidate has been bitten by this and remembers where.
Weak answer: A weak answer guesses that a fresh list is created each call, or recites the rule without being able to say why it works that way.
A page that loaded instantly now takes eight seconds. Where do you look first?
Why ask it: This is the actual bug you will hand them. It also reveals whether they measure or guess, which is the single most useful habit in a one-developer team.
Strong answer: Measure before changing anything, then check whether the code issues one database query per row inside a loop. A strong answer names that pattern, explains how to confirm it from query logs, and describes fixing it by fetching the related rows in one query.
Weak answer: A weak answer jumps straight to adding a cache or a bigger server without finding the cause, or lists optimizations with no way to tell which one applies.
What do you test, and what do you deliberately not test?
Why ask it: Both extremes are wrong, so the question has no rehearsed answer. The reasoning behind where they draw the line tells you how the codebase will look in a year.
Strong answer: Tests the logic that carries real risk, plus a regression test for every bug already found, and skips trivial code and third-party internals. A strong answer starts a test with the failure case rather than the happy path.
Weak answer: A weak answer is either that everything must be tested, which never survives a deadline, or that tests slow things down, which is what you will inherit.
The most useful single technique is the walkthrough. Ask the candidate to narrate their submitted code as if you had never seen it, then ask why once after every answer. That second layer is where preparation runs out and real understanding starts, and it needs no technical knowledge from you at all.
The Coding Exercise, Done Properly
Give a short, real task and spend the live time on the debrief. A two-hour capped exercise drawn from your own backlog predicts the job far better than an algorithm puzzle, which mostly measures how recently the candidate practiced puzzles. The exercise is the filter, and the conversation about it is the interview.
Use a task from your own backlog
Read a file or an API, transform the result, handle the malformed case. A real task is fairer than a puzzle and tells you far more about the work you are actually buying.
Cap it at two hours and say so
State the cap in writing and ask for whatever exists when time runs out. An uncapped take-home quietly filters for whoever had a free weekend, not for skill.
Allow any tool, including AI assistants
Banning them is unenforceable and unrealistic. Allow everything, then require the candidate to explain every line in the debrief, which is where the difference shows.
Score the debrief, not the code
Thirty minutes of walkthrough, scaling, testing, and pushback questions produce more signal than the submission itself. Grade the conversation on the rubric.
Two Rules That Keep an Exercise Fair
Cap the time in writing and say you want whatever exists at the cap, finished or not. An uncapped take-home filters for whoever had a free weekend rather than for skill, and it costs you strong candidates who have jobs. Second, never send a brief that solves a live problem in your product. A task modelled on your work is fine; unpaid work that ships is not. If the exercise needs more than a couple of hours, pay for it.
Trying to ban AI assistants is unenforceable and increasingly beside the point, since the candidate will use them on the job. Allow every tool, then make the debrief mandatory. A developer who understands their submission can narrate it comfortably; one who cannot will stall on the second question, which is exactly the information you wanted. Our guide to hiring assessments covers how this fits a broader skills-based hiring process.
Scoring the Interview and Red Flags
Score six areas from 1 to 5 immediately after each round, while the answers are fresh, and anchor every score to something the candidate actually said. Written evidence is what makes the comparison hold up a week later, when three good conversations have blurred into one general impression.
Scoring area
What a 5 looks like
Python fundamentals
Explains the reason behind the rule, not just the rule
Practical coding
Readable code that handles the messy input case
Stack fit
Real experience in the framework or data tooling you run
Testing and production habits
Tests and debugs by method, without being told
Communication
Explains a tradeoff to a non-technical owner
Autonomy
Decides and moves without a manager assigning work
If two people interview, each should score alone before anyone talks. On a technical hire this matters more than usual: the most technical person in the room otherwise anchors the decision, and the owner defers even when their read on communication and autonomy is the more reliable one. The same questions and the same rubric for every candidate is the core of a structured interview, and it feeds a clean decision through a shared evaluation form.
Weigh the red flags deliberately rather than letting one strong answer erase them. The heaviest are an inability to explain submitted code, describing only what the team did and never what they did, and having no example of a decision they got wrong. Keep the completed scorecards for every candidate in one place rather than scattered across inboxes. Applicant tracking is coming soon to FirstHR, and until it ships a shared folder with a consistent file name is enough for a small team. Our list of general interview red flags covers the non-technical ones.
Python Developer Pay
There is no separate federal occupation for Python, so benchmark against software developers and adjust for level, location, and whether the role is remote. Use the government figures as the frame of the conversation, then set your own number based on the level you decided to hire.
Median $135,980, 25th Percentile $105,210 (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 lowest 10 percent earned $82,460 or less, the 25th percentile was $105,210, the 75th percentile was $171,980, and the top 10 percent earned more than $214,670 (U.S. Bureau of Labor Statistics).
In practice a junior hire sits near the bottom quarter of that range, a solid mid-level developer around the middle, and senior engineers in the upper half. Classification matters as much as the number: under the Fair Labor Standards Act, the computer employee exemption can cover a software engineer 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 level, the pay, and the classification into the offer rather than leaving them to a conversation. If the role is not written down yet, the Python developer job description templates give you a starting point, and the back end developer templates help if the scope is wider than Python alone. 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 developer question lists leave out entirely.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that touch them create risk even as small talk. Do not ask about age, race, religion, national origin, sex, pregnancy or family plans, disability, or genetic information. Technical interviews drift into this more often than people expect, usually through casual questions about where someone learned to code, when they graduated, or where they are originally from. Keep every question tied to building and maintaining software for your business. This is general information, not legal advice.
Hold the question set steady
A free-flowing technical conversation follows whatever the candidate happens to be good at, which is exactly why unstructured technical interviews compare badly. Write the questions in advance, ask the same core set of every candidate for the role, and score against the same rubric. This is fairer, it is easier to defend if a decision is ever questioned, and it produces a better hire. For a small business it is also faster, because the second interview does not have to be reinvented from scratch.
Keep the exercise proportionate
A take-home task is a legitimate assessment when it is short, job-related, and applied to every candidate at the same stage. It stops being that when it runs unpaid for a weekend, or when the task is a piece of work you were planning to ship. Cap the time, say the cap out loud, and never send a brief that solves a live problem in your product. If you extend the exercise beyond a couple of hours, pay for it.
Score independently, then discuss
When two people interview, each should complete the scorecard alone before the conversation starts. On a technical hire this matters more than usual, because the most technical person in the room will otherwise anchor the whole decision, and a non-technical owner will defer even when their read on communication and autonomy is the more reliable one. Compare written evidence first, then talk about the gaps.
Structure Beats a Free-Flowing Technical Chat
Federal hiring guidance describes the structured interview, in which 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 down in advance and holding the set steady is the entire fix. For 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 developer through coordinated panels with a recruiter managing 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 what you weight and how fast you move.
You are hiring a Python developer and you do not write Python
Most owners making this hire cannot grade the code, and the standard advice, get an engineer to run the technical round, assumes you have one. You can still run a rigorous interview, because you are not grading syntax. You are checking whether the person can explain their own work, whether they measure before guessing, whether they test without being told, and whether they own a mistake. Every question in these sets carries a note on what a good answer sounds like, which turns the judgment into pattern matching rather than expertise. If you want a second opinion on the code itself, a paid two-hour review by a contractor is cheaper than a bad hire by an enormous margin.
This person will probably be your entire engineering function
At a larger company a mid-level developer sits inside a team that reviews their work, runs the deployment pipeline, and catches what slips. At a small business there is nobody behind them, so the traits that matter shift. Weight testing, documentation, and debugging method above raw speed, and weight autonomy heavily, because nobody will be assigning them tasks. Ask directly how they have handled working without a team around them. A strong engineer who needs a senior nearby to function will struggle here, and it is far kinder to both of you to find that out in the interview than in month three.
Good developers are gone in a week, so a slow process costs you the hire
Three rounds is enough for most small businesses: a 30-minute screen, a two-hour capped exercise, and a one-hour debrief plus behavioral interview. Adding a fourth round rarely changes the decision and regularly loses the candidate, because they are usually talking to two other companies. Decide within 48 hours of the last conversation and send the offer in writing the same day. Once you choose someone, FirstHR handles the part after the decision: the offer and the confidentiality paperwork out for e-signature, the access checklist as a task workflow, and every signed document on the employee profile. Applicant tracking is coming soon to FirstHR, so for now run the pipeline in whatever you already use and keep the scorecards together.
Trait
Junior hire
Mid-level hire
Writes correct code for a defined task
Ships without someone reviewing the work
Turns a fuzzy requirement into a feature
Tests and debugs without being told
Safe as your only developer
Two rules follow. Weight testing, documentation, and debugging method above raw speed, because nothing else will catch what slips. And move fast once you decide, since the candidate is usually talking to two other companies. If sourcing is the harder problem for you, see our guides on finding developers and technical recruitment.
Roles outside engineering need the same discipline and a different question set. The wider hiring templates library covers the rest of the team, and the QA engineer questions are the natural next set once one developer is not enough.
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 within 48 hours
Confirm title, pay, classification, remote expectations, and start date in writing, with e-signature. A week of silence after a good final round loses candidates to faster employers.
Sign the IP and security paperwork first
Confidentiality, intellectual property assignment, and acceptable use, acknowledged before any credential is issued. For a developer this is the paperwork that actually matters.
Have access ready on day one
Repository, cloud console, database, error tracking, and a working local environment. A developer who can ship something small in week one stays engaged.
Write down 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 so expectations are never a guess.
Developer onboarding carries 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 every signed document on the employee profile, so a small business can run the whole path from decision to first day in 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.
Key Takeaways
Assess a Python developer on fundamentals, practical coding, stack fit, production habits, and communication, not on language trivia.
Decide junior, mid-level, or senior before the first call; the dividing line is whether anyone will review their work.
Replace the whiteboard puzzle with a two-hour capped task from your own backlog, and score the debrief rather than the code.
Allow AI assistants, then require a line-by-line walkthrough, which is the only reliable check on authorship.
Ask only the framework block that matches your stack, because a web hire and a data hire share a language and little else.
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 $105,210 25th percentile in May 2025.
Frequently Asked Questions
What questions should I ask a Python developer in an interview?
Ask across five areas: language fundamentals, practical coding, stack fit, production habits, and collaboration. Strong core questions include: walk me through something you built and what you personally wrote; what is the difference between a list and a tuple and when do you use each; what happens if you use a list as a default argument value; a page that loaded instantly now takes eight seconds, where do you look first; what do you test and what do you deliberately not test; and tell me about a bug you shipped that reached users. Add framework questions only for the stack you actually run, because web work and data work are different hires. Every question in the six downloadable sets on this page carries the reason it earns a slot and a note on what a good answer sounds like, so an owner who does not code can still score the answers.
How do I interview a Python developer if I do not code myself?
You are not grading syntax, so you do not need to write Python to run a rigorous interview. You are checking four things you can absolutely judge: whether the candidate can explain their own code to someone who has never seen it, whether they measure a problem before guessing at fixes, whether testing and documentation are habits rather than chores, and whether they own a past mistake in specific terms. Each question in these sets includes what a strong answer sounds like and what a weak one sounds like, which turns the evaluation into pattern matching. The most useful single technique is the walkthrough: ask them to narrate the code they submitted, line by line, as if you had never seen it. Hesitation over their own work is the clearest signal available to a non-technical interviewer. If you want a second read on code quality, pay a contractor for a two-hour review.
Should I give a Python take-home test or a live coding interview?
Give a short take-home task and spend the live time on the debrief. A capped exercise, two hours at most, using a real task from your backlog, tells you far more than an algorithm puzzle on a whiteboard, because it resembles the job you are hiring for. State the cap in writing and ask for whatever exists when time runs out, since an uncapped take-home quietly filters for whoever had a free weekend rather than for skill. Allow any tool, including AI assistants, because banning them is unenforceable, then require the candidate to explain every line during a thirty-minute debrief. That conversation, not the submission, is where the signal is. Keep the task job-related and never send a brief that solves a live problem in your own product, and if the exercise runs longer than a couple of hours, pay for it.
What is the difference between a junior and a mid-level Python developer?
A junior developer writes correct code for a task that has already been defined for them and needs review before the work ships. A mid-level developer takes a fuzzy requirement, asks the questions needed to sharpen it, and returns a working feature, with tests and debugging done without being told. The practical dividing line at a small business is supervision: a junior needs somebody to check the work, and a mid-level developer does not. That makes mid-level the right bar for most small companies hiring their only developer, because there is nobody available to review a junior hire. A senior developer owns the architecture and its consequences, raises requirement problems before building, and sets the standard for anyone who follows. Decide which level you are actually buying before the first interview, because it changes both the questions and the pay.
What Python framework questions should I ask?
Ask only about the stack the hire will actually touch, because Python covers web back ends, data work, and automation, and those are three different roles. For web and API work, ask which framework they know best and what it gives them that a bare script does not, how they design a REST endpoint, how they store secrets such as API keys, and how they prevent SQL injection when a query needs user input. A good answer on framework choice names a real tradeoff: a full-stack framework brings an ORM, an admin, and conventions, while a micro-framework brings freedom and more assembly. For data and automation work, ask about a pipeline they built end to end, how they handle a file too large to load into memory, and how they find out a scheduled job failed. Skip the block that does not apply.
How much does it cost to hire a Python developer?
There is no separate federal occupation for Python, so benchmark against software developers and adjust for level and location. 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 lowest 10 percent earned $82,460 or less, the 25th percentile was $105,210, the 75th percentile was $171,980, and the top 10 percent earned more than $214,670. In practice a junior hire sits near the bottom quarter of that range, a solid mid-level developer sits around the middle, and senior engineers sit in the upper half. Remote hiring widens the range in both directions. Classification also matters: under the Fair Labor Standards Act, the computer employee exemption can apply to a software engineer paid on a salary basis at no less than $684 per week, or hourly at no less than $27.63, with duties and pay deciding it rather than the job title. This is general information, not legal advice.
How many interview rounds should a Python developer hire take?
Three rounds is enough for most small businesses. Round one is a 30-minute phone screen that decides whether the candidate earns more of your time. Round two is a capped coding exercise, sent as a written brief with a two-hour limit. Round three is a one-hour conversation combining the exercise debrief with the behavioral and collaboration questions. Adding a fourth round rarely changes the decision and regularly loses the candidate, because good developers are usually in conversation with two other companies at the same time. Decide within 48 hours of the final interview and send the written offer the same day you decide. If two people are interviewing, have each score the rubric independently before discussing, so the more technical voice does not anchor the whole decision before the non-technical read on communication and autonomy is heard.
Are these Python developer interview questions legal to ask?
Yes. Questions about technical experience, the code someone wrote, how they test and debug, and how they work with others are job-related and permitted. The legal caution is general to all interviewing: avoid questions that touch characteristics protected under federal law, which the EEOC enforces, including age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Technical interviews drift into this more often than people expect, usually through casual questions about when someone graduated, where they learned to code, or where they are originally from. Asking the same job-related core questions of every candidate and scoring them on the same rubric is the simplest safeguard, because it shows the decision rested on consistent job-related criteria. Keep any take-home exercise short, job-related, and applied to every candidate at the same stage. This is general information, not legal advice.
