Data scientist coding interview questions for employers: 40+ SQL, Python, and code-review questions with what a strong answer sounds like and a scorecard.
Six question sets for the employer side of the coding round: 40+ SQL, Python, code-review, leakage, and take-home debrief questions, each with the reason it is worth asking and what a strong answer sounds like, plus a weighted scorecard. Download as DOCX.
The first coding round I ever ran for a data role went badly, and it was my fault. I asked a puzzle question I had found online, the candidate solved it, and six weeks later it turned out the person could not write a query against our own tables without producing revenue numbers that were three times too high. The puzzle had tested something real. It just was not the thing the job needed.
At FirstHR, we build for small businesses that hire without an HR department and often without a data team either. This page is the coding round I wish I had run: six question sets covering SQL, Python, code review, leakage, and a capped take-home, each question paired with why it is worth asking and what a strong answer sounds like.
Every question here is written for the person deciding what to ask. If you are hiring for the role more broadly, the wider data scientist interview questions kit covers business framing, statistics, and communication. This one stays on the code.
TL;DR
A data scientist coding interview should test four things: SQL against an undocumented schema, Python on a messy file, a walkthrough of code they wrote, and validation habits that prevent leakage. Run 30 to 45 minutes live on a sample of your own data, cap any take-home at 3 hours, and score eight weighted areas from 1 to 5 with written evidence. Skip algorithm puzzles. Download 40+ questions and a scorecard as DOCX.
What the Coding Round Has to Test
A data scientist coding round should test whether someone can get a trustworthy number out of your data, not whether they can reverse a binary tree on a whiteboard. The four areas that predict on-the-job performance are SQL against undocumented tables, data wrangling in Python, the ability to explain their own code, and the validation habits that stop a wrong answer from reaching a decision.
That last one is the difference between this round and a general developer screen. A web application either works or it does not. An analysis can be completely broken and still return a number that looks reasonable, which means the coding habits you are testing for are mostly habits of self-doubt: checking the grain of a table, testing a join, counting the rows that got dropped.
What to test
Why it predicts performance
How to test it
SQL on undocumented tables
Most of the job below a certain company size
Live, 30 minutes, two of your own tables
Python on messy data
Cleaning is where the hours actually go
A file with mixed formats and duplicates
Explaining their own code
The result is worthless if nobody trusts it
Walkthrough of work they already wrote
Validation and leakage habits
A broken analysis still returns a number
Ask the order of operations before fitting
Reproducibility
Next month someone reruns it, often you
Ask them to make the notebook rerunnable
Notice what is missing. Nothing here asks for algorithm trivia, and nothing requires you to grade code style. Every item can be judged by an employer who does not write Python, because each one has a clear right instinct that a candidate either shows or does not.
Pick the Format Before the Questions
Choose the format first, because it determines which questions are even possible. A small business has four realistic options, and for a first data hire the live round on your own data is usually the strongest default, with a code walkthrough the best choice when nobody on your side reads Python.
Live coding, your data
Best default for a first data hire
Thirty minutes, screen shared, a sample of your own data. You see the thinking, not just the output, and nobody can outsource it. Costs you the time to prepare a safe sample once.
Code walkthrough
Best if you do not code
The candidate brings work they wrote and explains it while you ask why. Cheapest to run, hardest to fake under follow-up questions, and it works even when the interviewer cannot read the language.
Capped take-home
Best for depth on a real question
Three hours maximum, one real question from your business, always paired with a live debrief. Never send it without the debrief, and never send a task you would otherwise pay someone to do.
Algorithm puzzles
Usually the wrong choice
Whiteboard puzzles about trees and dynamic programming test preparation for a certain hiring process, not the work. A small business almost never needs them, and they screen out strong applied candidates.
Match the Format to Your Situation
No technical person on your side: run the code walkthrough set and let the candidate do the explaining. A technical founder or adviser available: run the live SQL and Python rounds on a sample of your own data. Hiring for a specific modeling project: add the take-home with a real question and a debrief. Whichever you pick, use the same format and the same time limit for every candidate in the search, or the comparison means nothing.
The Six Question Sets
The questions below are grouped into six sets, five of them rounds you can run and one a scorecard. Each set states when to use it, lists the questions with the reason each is worth asking, and describes what a strong answer sounds like so you can score without writing code yourself.
SQL Round
Grain, joins, and trust
Nine questions run live against two tables and no documentation. Watches whether the candidate checks the grain of a table before counting anything, which is where most wrong numbers start.
Python and pandas
A deliberately messy file
Nine questions on a file with mixed date formats, duplicates, and a number stored as text. The mess is the test; a clean file tells you nothing.
Code Walkthrough
They explain, you judge
Eight questions on code the candidate wrote, plus two planted bugs to find. The highest-signal round if you do not read Python yourself.
Modeling Code and Leakage
Where results go wrong
Eight questions on split order, baselines, time-based validation, and what to do when a first score looks too good. The habits that keep a result honest.
Take-Home Brief and Debrief
Three hours, capped
A brief you can copy, fairness rules, and eight live debrief questions that confirm the candidate wrote and understands what they sent.
Scorecard and Red Flags
Score, do not guess
Eight weighted scoring areas at 1 to 5, an evidence line per score, suggested starting weights, and red and green flag checklists.
40+ Questions and a Scorecard to Download
Download all six as one Word document, or copy individual sets. Every question carries a why-ask-it line and a strong-answer line. The scorecard adds weights, evidence lines, and red and green flag checklists. Fill in your own data and business question before you send anything to a candidate.
Download All 6 Coding Round Sets
SQL, Python, code walkthrough, modeling and leakage, a take-home brief with debrief, and a weighted scorecard. All in one DOCX.
Set 1: SQL Round
Nine questions run live against two tables and no documentation, covering grain, fan-out joins, window functions, NULL handling, and what to do when two sources disagree about the same month.
SQL Round Questions
DATA SCIENTIST CODING INTERVIEW: SQL ROUND
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Run this as a 30-minute live round against a small sample of your own data, or
against any two tables you can share safely. Ask the candidate to talk while
they type. You are not grading syntax. You are watching whether they check their
assumptions before they trust a number. Ask 5 or 6 of these, then score.
QUESTIONS TO ASK
1. Here are two tables and no documentation. Before you write anything, what do
you want to know about them?
Why ask it: the first minute of a real task at a company with no data team.
Strong answer: asks about grain (one row per what), row counts, key columns,
date ranges, and which system writes the data.
2. Write a query that counts customers who ordered more than once last quarter.
Why ask it: the most common real request, and it hides a grain trap.
Strong answer: checks whether the orders table is one row per order or per
line item before counting, and says so out loud.
3. Your join returned more rows than the left table had. What happened?
Why ask it: a fan-out is the single most common silent error in analysis SQL.
Strong answer: names a duplicate key on the right side, and describes how they
test for it before joining rather than after.
4. Rewrite that using a window function instead of a subquery.
Why ask it: separates people who write SQL daily from people who studied it.
Strong answer: reaches for a window function comfortably and can explain what
the partition and the order are doing.
5. This query is slow on 40 million rows. What do you try first?
Why ask it: tests practical judgment, not database internals.
Strong answer: looks at what is being scanned, filters earlier, questions
whether the full range is needed, and asks about indexes rather than guessing.
6. How do you handle a NULL in a column you are averaging?
Why ask it: a routine decision that quietly changes the answer.
Strong answer: asks why the value is missing before deciding, and knows the
difference between excluding a row and treating the value as zero.
7. Two tables disagree about revenue for the same month. Walk me through what
you do.
Why ask it: this happens in the first month at almost every small company.
Strong answer: reconciles a small sample by hand, finds the definition
difference, writes it down, and picks one source of truth.
8. Show me a query you are proud of from past work and explain it.
Why ask it: their own code is the fastest read on their real level.
Strong answer: explains the business question first, then the query, and can
say what they would change now.
9. How would you leave this query so the next person can reuse it?
Why ask it: at a small company the next person is often the same person later.
Strong answer: names comments, a saved file in version control, and a written
definition of the metric.
WHAT TO LISTEN FOR
•Checks the grain of a table before counting anything
•Tests for duplicate keys instead of trusting a join
•Says out loud what they are assuming
•Treats a disagreement between sources as work, not as a blocker
NOTES
__
__
Set 2: Python and pandas Round
Nine questions on a deliberately messy file: mixed date formats, duplicates, a number stored as text. Tests whether the candidate reads the data before transforming it and reports problems instead of quietly patching them.
Python and pandas Round Questions
DATA SCIENTIST CODING INTERVIEW: PYTHON AND PANDAS ROUND
Candidate: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Give the candidate a small, deliberately messy file: mixed date formats, a few
duplicate rows, some blanks, one column stored as text that should be a number.
Thirty minutes, their own editor, screen shared. The messy file is the test. A
clean file tells you nothing you cannot learn from a resume.
QUESTIONS TO ASK
1. Load this file and tell me the three things that are wrong with it.
Why ask it: real data work starts with reading the data, not modeling it.
Strong answer: inspects types, row counts, and distributions before touching
anything, and reports what they found instead of silently fixing it.
2. The date column has three different formats. How do you handle it?
Why ask it: the most common cleaning task in the job.
Strong answer: parses explicitly, checks how many rows failed to parse, and
does not let failures fall through as blanks.
3. There are duplicate rows. Are they errors?
Why ask it: tests whether they ask before deleting.
Strong answer: checks whether the duplicate is a true repeat or a legitimate
second event, and asks you rather than assuming.
4. Aggregate this by month and by segment, and show me the result.
Why ask it: the everyday shape of the work.
Strong answer: writes a readable groupby, sanity-checks the totals against the
raw file, and notices if a segment silently disappeared.
5. You are getting a warning about a copy versus a view. What is it telling you?
Why ask it: a small thing that reveals whether they use the library daily.
Strong answer: explains chained assignment plainly and shows the safe form
without needing to search for it.
6. This step takes eight minutes. How would you make it faster?
Why ask it: judgment about when speed matters at all.
Strong answer: asks how often it runs before optimizing, then vectorizes or
reduces the data rather than rewriting everything.
7. Turn this notebook into something I could run next month.
Why ask it: reproducibility is the difference between an analysis and a tool.
Strong answer: parameterizes inputs, removes the dead cells, pins the steps in
order, and mentions version control as normal practice.
8. How do you test analysis code when there is no obvious right answer?
Why ask it: most data scientists have never been asked this, and it separates.
Strong answer: checks row counts and totals at each step, tests edge cases on
a tiny sample, and compares against a known baseline.
9. Which libraries do you actually reach for, and for what?
Why ask it: names plus tasks beat a list of logos.
Strong answer: a short, honest list tied to real work, with an admission of
what they have not used.
WHAT TO LISTEN FOR
•Reads the data before transforming it
•Reports problems instead of quietly patching them
•Writes code a second person could run
•Optimizes only after asking how often it runs
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Eight questions on code the candidate wrote, plus two bugs you plant in a short script. The highest-signal round for a non-technical interviewer, because the candidate explains and you judge the explanation.
Code Walkthrough and Review Questions
DATA SCIENTIST CODING INTERVIEW: CODE WALKTHROUGH AND REVIEW
Candidate: __
Interviewer: __
Date: _
WHEN TO USE THIS SET
Ask the candidate to bring a notebook or a script they wrote and can share, or
review a short piece of code you supply with two bugs planted in it. This is the
highest-signal round for a non-technical interviewer, because the candidate does
the explaining and you judge the explanation. Budget 30 to 40 minutes.
QUESTIONS TO ASK
1. Walk me through this from the top. What was the question you were answering?
Why ask it: strong candidates start with the business question, not the code.
Strong answer: names the decision the work supported before describing a
single line of the script.
2. Why is this step here?
Why ask it: ask it about a cleaning step chosen at random.
Strong answer: gives a reason tied to the data, not a habit. If the answer is
that they always do it, ask what would happen if they skipped it.
3. What did you decide to drop, and what did dropping it cost you?
Why ask it: every cleaning decision throws something away.
Strong answer: knows exactly what was dropped, how many rows, and whether the
remaining sample is still representative.
4. Where would this break if the input changed?
Why ask it: tests whether they think past the run that produced the output.
Strong answer: points at hardcoded assumptions, column names, and date ranges
without being led there.
5. If you had two more days, what would you change first?
Why ask it: an honest self-critique is one of the best predictors here.
Strong answer: picks something specific and technical, not more data.
6. I planted two bugs in this script. Find them and tell me what they would do
to the result.
Why ask it: reading unfamiliar code is most of the real job at a small team.
Strong answer: works methodically through the logic, and explains the effect
on the output rather than only naming the line.
7. How would you tell someone their analysis has a bug in it?
Why ask it: on a two-person team, review is a relationship, not a process.
Strong answer: describes showing the evidence and the reproduction, and treats
it as normal rather than as a confrontation.
8. What would you want reviewed before an analysis of yours goes to me?
Why ask it: tests whether they have a real review habit or want one.
Strong answer: names the joins, the filters, and the metric definition as the
places errors hide.
WHAT TO LISTEN FOR
•Opens with the business question, not the tooling
•Can defend each cleaning decision on its merits
•Finds planted bugs by reasoning, not by scanning
•Treats review as normal and welcome
NOTES
__
Set 4: Modeling Code, Validation, and Leakage
Eight questions on the order of operations before fitting, baselines, time-based splits, metric choice tied to the cost of each error, and checking a model for bias before it touches people.
Modeling Code, Validation, and Leakage Questions
DATA SCIENTIST CODING INTERVIEW: MODELING CODE AND LEAKAGE
Candidate: __
Interviewer: __
Date: _
WHY THIS SET EXISTS
Most bad models are not bad math. They are code that let the answer leak into
the inputs, or a split that let the future leak into the past. These questions
test the coding habits that keep a result honest. They matter more at a small
company, where nobody else will catch the mistake before a decision is made.
QUESTIONS TO ASK
1. In code, what exactly do you do before you fit anything?
Why ask it: the order of operations is where leakage is created.
Strong answer: splits first, then fits any transformation on the training part
only, and applies it to the held-out part.
2. Your model scores 0.98 on the first try. What do you do?
Why ask it: the correct reflex is suspicion, and it is easy to fake badly.
Strong answer: assumes leakage, hunts for a column that encodes the outcome,
and checks the split before celebrating.
3. Show me how you would set up a split for data with a time dimension.
Why ask it: random splits on time series are a silent, common bug.
Strong answer: trains on earlier periods and tests on later ones, and explains
why shuffling would flatter the score.
4. What is the simplest baseline you would code first, and why?
Why ask it: a baseline is the cheapest way to know if the model earns its keep.
Strong answer: a rule or an average, written in a few lines, used as the bar
the model must beat before anyone talks about deploying it.
5. Which metric would you code for this problem, and what does it cost us when
the model is wrong?
Why ask it: metric choice is a business decision expressed in code.
Strong answer: ties the metric to the cost of each error type in your business,
rather than defaulting to accuracy.
6. How do you make a model result reproducible six months from now?
Why ask it: at a small company the person rerunning it is you.
Strong answer: seeds set, data version recorded, environment pinned, and the
steps in a script rather than in cell-execution order.
7. Walk me through how you would check a model for bias before we use it on
people.
Why ask it: any model touching hiring, pay, or customers carries legal weight.
Strong answer: measures outcomes across groups, treats a gap as a finding to
escalate, and knows this needs review rather than a quiet fix.
8. What would you monitor after we ship it, and how would you code that?
Why ask it: models decay, and nobody at a small company is watching by default.
Strong answer: a small, scheduled check on input distributions and on the
metric, with an alert that reaches a human.
WHAT TO LISTEN FOR
•Splits before fitting, every time, without prompting
•Treats a suspiciously good score as a bug report
•Codes a baseline before a model
•Thinks past the day the model is delivered
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
A three-hour brief you can copy and adapt, a set of fairness rules to keep constant across candidates, and eight live debrief questions that confirm the candidate wrote and understands what they sent.
Take-Home Brief and Debrief Questions
DATA SCIENTIST CODING TAKE-HOME: BRIEF AND DEBRIEF
Candidate: __
Interviewer: __
Date sent: _ Date returned: _
THE BRIEF (COPY THIS TO THE CANDIDATE)
Time limit: 3 hours. Please stop at 3 hours even if unfinished, and tell us what
you would have done next. We would rather see three honest hours than a polished
weekend.
Data: the attached file (or the sample we shared).
The question: [write one real question from your business here, for example:
which of our customers are most likely to stop buying in the next 90 days, and
what should we do about it]
What to send back:
•Your code, in whatever form you work in
•A short written answer to the question, under one page, for a non-technical
reader
•A note on what you assumed, what you could not check, and what you would do
with two more days
How we score it: correctness of the analysis, clarity of the written answer,
quality of the code, and honesty about limitations. We do not score visual
polish.
If you use AI coding tools, that is fine and expected. Please say where you used
them, and be ready to explain every line as your own.
DEBRIEF QUESTIONS (30 MINUTES, LIVE)
1. Walk me through your answer as if I had never seen the data.
Why ask it: the written answer is the deliverable; the code supports it.
Strong answer: leads with the finding and the recommendation, then the method.
2. Which assumption are you least comfortable with?
Why ask it: the strongest candidates volunteer their weakest link.
Strong answer: names a specific one and explains how they would test it.
3. Show me the part of the code you would rewrite first.
Why ask it: honest self-review, and it confirms they wrote it.
Strong answer: points somewhere specific and explains the tradeoff they made
under the time limit.
4. Change one requirement live: what if we only had half this data?
Why ask it: tests whether they understand their own approach.
Strong answer: adapts out loud, and knows which conclusions would no longer
hold.
5. Where did you use an AI tool, and what did you change about what it gave you?
Why ask it: tool use is fine; not understanding the output is not.
Strong answer: specific about where, and can explain and defend the logic
line by line.
6. What did you not have time to do?
Why ask it: separates people who ran out of time from people who ran out of
ideas.
Strong answer: a concrete list, in priority order.
7. What surprised you in the data?
Why ask it: only someone who really looked has an answer.
Strong answer: something specific and checkable, not a generality.
8. If we hired you Monday, what would you want in week one to do this for real?
Why ask it: turns the exercise into a plan.
Strong answer: access, a stakeholder, and one narrow question to answer first.
FAIRNESS RULES (KEEP THESE CONSTANT)
[ ] Same brief, same data, same time limit for every candidate
[ ] Same scorecard for every submission
[ ] Paid, or capped at 3 hours, or both
[ ] Never a real deliverable you would otherwise pay for
[ ] Offered an alternative format if a candidate requests an accommodation
NOTES
__
Set 6: Coding Round Scorecard and Red Flags
Eight weighted scoring areas at 1 to 5 with an evidence line each, suggested starting weights for a first data hire, and the red and green flags most question lists leave out.
Coding Round Scorecard and Red Flags
DATA SCIENTIST CODING ROUND SCORECARD AND RED FLAGS
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO SCORE
Score every area from 1 to 5 immediately after the round, before you discuss the
candidate with anyone. Write one line of evidence for each score, quoting what
the candidate actually did or said. If two people watched, each scores alone
first. Use the same weights for every candidate in the same search.
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
SQL fluency: writes working SQL against an undocumented schema
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Python and data wrangling: handles a messy file without hiding the mess
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Correctness habits: checks grain, joins, row counts, and totals unprompted
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Validation and leakage: splits before fitting, distrusts a great score
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Reproducibility: another person could rerun this next month
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Code readability: a second reader can follow it without a guide
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Explanation: narrates the work clearly to a non-technical listener
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Judgment under constraint: picks the simple path that answers the question
Weight: ____% Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Suggested starting weights for a first data hire at a small company:
You can evaluate a data scientist coding round without reading the code, by grading the narration instead of the syntax. Ask the candidate to talk while they work, then ask why about a step chosen at random. The quality of the answer to why is the signal, and it does not require you to know the language.
This works because the failures you most want to catch are failures of care, not of syntax. Someone who joins two tables without ever asking what one row represents is making a mistake you can hear. So is someone who deletes rows and cannot say how many. The signals below are the ones worth writing on your scorecard.
Before writing anything
Asks what the data means and where it comes from
Asks what decision the answer feeds
Checks how many rows and what one row represents
While writing
Narrates the assumption being made
Stops to sanity-check a number against the raw file
Says when something looks wrong instead of moving on
About rerunning it
Talks about version control as normal, not as a policy
Removes dead steps rather than leaving them in
Can say what happens if next month the file changes
When they are stuck
Says what they would look up rather than freezing
Narrows the problem instead of restarting
Asks a clarifying question instead of guessing
One more test costs nothing: hand the candidate a result that is subtly wrong and ask whether they believe it. A strong candidate goes looking for the reason. A weak one explains why the number makes sense. If you want a second opinion on the technical depth, a friendly contact or a fractional adviser can sit in on one round without joining your team.
The Four Bugs That Only Show Up in Data Work
Four specific bugs account for most wrong answers in analysis code, and all four are invisible in the output. They do not throw errors. They return a plausible number, which is what makes them dangerous and what makes them worth testing for directly in the interview.
The join that quietly multiplies your revenue
A duplicate key on one side of a join turns one order into three, and the total looks plausible enough that nobody questions it. Ask what the row count was before and after the join. A candidate who checks this without being told has been burned before, which is exactly what you want.
The transformation fitted on the whole dataset
If a candidate scales, imputes, or encodes before splitting the data, the test set has already seen the training set and every score afterward is optimistic. Ask them to narrate the order of operations. Split first is the answer, and it should come without prompting.
The random split on time-ordered data
Shuffling rows that have a date in them lets the model learn from the future to predict the past. The score is excellent and the model fails in production. Ask how they would split data with a time dimension and listen for training on earlier periods, testing on later ones.
The dropped rows nobody counted
Removing rows with missing values is often correct and often silently biases the sample. Ask how many rows were dropped and whether what remained still looked like the original. A candidate who knows the number has been paying attention.
Ask about all four. Each has an unambiguous right instinct, so the answers are easy to score even if you never write a line of code, and a candidate who shows the instinct on three out of four is in good shape.
When the Candidate Uses AI Coding Tools
Allow AI coding assistance and score understanding instead of authorship. Banning tools is unenforceable in a take-home and unrealistic in the job, so the practical policy is to state the rules in the brief and then design questions that only someone who understands the code can answer.
Round design
Survives AI assistance
Fails to survive it
Ask why a specific line is there
Ask what breaks if the input changes
Ask them to change a requirement live
A standalone puzzle with a known answer
An unwatched take-home with no debrief
The debrief is what makes a take-home hold up. Ask where they used a tool and what they changed about the output, and the candidates who understand their submission separate themselves within a couple of minutes. Put the policy in writing in the brief so nobody is guessing at your rules.
Scoring the Coding Round
Score eight areas from 1 to 5 immediately after the round, with one line of written evidence for each score. Set the weights before you meet the first candidate, not after you meet one you liked, because weights chosen afterward are just a way of justifying a decision you already made.
Scoring area
Suggested weight
What a 5 looks like
SQL fluency
20%
Works against an undocumented schema without hand-holding
Python and wrangling
20%
Handles a messy file and reports what was wrong with it
Correctness habits
15%
Checks grain, joins, and row counts unprompted
Validation and leakage
15%
Splits before fitting; distrusts a suspiciously good score
Reproducibility
10%
Another person could rerun the work next month
Explanation
10%
Narrates clearly to a non-technical listener
Code readability
5%
A second reader can follow it without a guide
Judgment under constraint
5%
Picks the simple path that answers the question
If two people watched the round, each scores alone before anyone speaks. That single rule does more for the quality of the decision than any question on this page, because it stops the most confident voice in the room from setting the anchor. Feed the scores into your interview feedback step and keep the completed cards with the rest of the interview evaluation paperwork.
Pay Context Before You Talk Numbers
Know the band before the conversation, because a coding round that goes well and a compensation conversation that goes badly is a wasted process. Federal wage data gives you the anchor, and the spread for this occupation is unusually wide.
Median About $120,230 a Year (BLS OEWS, May 2025)
Data scientists had a median annual wage of about $120,230, roughly $57.80 an hour, according to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025). The lowest 10 percent earned under about $67,240, the 25th percentile was near $85,660, the 75th near $158,880, and the top 10 percent above $199,130. The U.S. Bureau of Labor Statistics projects the occupation to grow much faster than average through 2034, with about 23,400 openings a year on average.
A small business hiring its first data person usually recruits in the lower and middle part of that band, and a part-time or fractional arrangement is a real option when the workload does not yet justify a full-time hire. Be explicit about scope in the data scientist job description before the coding round, because a mismatch on scope is what drives early turnover. If the role leans more toward production systems, the machine learning engineer posting is the closer fit.
Fair, Legal, and Structured Coding Rounds
A coding test is a selection procedure, which means the same rules that govern any employment test apply to it. Give every candidate the same task, the same data, and the same time limit, score against a written rubric, and keep the records. Structure is what makes the round both fairer and more predictive.
The EEOC treats tests and selection procedures as subject to the same anti-discrimination law as any other hiring step, and its guidance on employment tests and selection procedures is worth reading once before you design your first one. The federal Uniform Guidelines on Employee Selection Procedures set out the expectation that a test relates to the job, which is one more reason to build the round from your own data rather than from a puzzle list.
Practice
Why it matters
Same task, data, and time limit for everyone
A comparable result, and a defensible process
A written rubric fixed before the first candidate
Scores reflect the work, not the impression
Task built from real job duties
Job-relatedness is the core legal expectation
An alternative format on request
Reasonable accommodation for a disability
Records of tasks, scores, and decisions kept
You can show how the decision was made
Keep the interview conversation itself tied to the job as well, and stay away from the small-talk traps the EEOC lists as prohibited practices. The rest of the questions employers cannot ask apply to a technical round exactly as they do to any other, and running a structured interview is the simplest protection. This is general information, not legal advice.
Running a Coding Round Without HR
At a large company a coding round is designed by a hiring committee, delivered by a senior data scientist, and calibrated across dozens of candidates. At a small business the founder builds it, runs it, and scores it alone, often without being able to read the code. Three problems follow from that, and each has a practical fix.
Nobody on your side can read the code
At a company with a data team, a senior data scientist grades the coding round. At a small business the founder often runs it alone, and the honest fear is that a confident candidate will talk past them. The fix is to stop grading syntax and start grading narration. Ask the candidate to explain every step while they work, and judge whether the explanation holds together: does the order of operations make sense, do they check their own numbers, do they say what they assumed. A candidate who cannot explain their code to you cannot explain a result to you either, and that is the job.
Your data is nothing like the data they trained on
Candidates from large employers arrive expecting a documented warehouse, a platform team, and clean tables. Your data lives in a production database, a spreadsheet, and a payment processor, and none of them agree. Run the coding round on a sample of your own real data rather than a textbook dataset, because the mismatch is the single biggest fit risk. The candidate who asks good questions about your messy file and gets something working anyway is the one who will still be productive in month two, whatever their pedigree says.
One coding round is the whole technical process
You will not run five rounds with a panel, so the one round has to carry the weight. Make it count by using your own question, capping the time, and scoring on a weighted card rather than a feeling. Write the weights down before the first candidate, not after the one you liked. Once you choose someone, the work shifts to hiring them properly, and that is where FirstHR fits: the offer, e-signature, the new-hire paperwork, and a structured first ninety days in one place. Applicant tracking is coming soon to FirstHR.
The through-line is the same in all three: replace technical authority you do not have with structure you can control. A fixed format, a real data sample, written weights, and an evidence line per score turn one founder's interview into something closer to a panel's, and they cost nothing but the time to decide them in advance. This is where skills-based hiring genuinely pays off for a small team.
From Coding Round to Offer
Once the scorecards are in, the process shifts from evaluating to hiring: comparing written scores, sending an offer, and setting up a data hire whose access needs are heavier than most. A data scientist typically touches customer records in week one, so the confidentiality agreement and the access plan belong in the onboarding checklist, not in a later cleanup.
Compare the written scores
Put the weighted scorecards side by side before anyone says which candidate they liked, so the strongest talker does not outrank the strongest coder.
Send a clear offer
Scope, reporting line, the tools you do and do not have, and compensation, confirmed in writing and signed electronically.
Grant access on day one
Database credentials, the analytics tools, and a confidentiality agreement, because a data hire touches customer records from the first week.
Name the first question
One real business question, one stakeholder, and one deliverable in the first month, or a solo data hire spends a quarter looking for direction.
FirstHR connects the offer, the confidentiality agreement, e-signatures, the new-hire paperwork, and the first-week access checklist in one place, so a small business can move from a finished coding round to a productive first month without stitching four tools together. Applicant tracking is coming soon to FirstHR. For the rest of the interview beyond the code, the wider role kit and the other hiring templates cover the non-technical rounds. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Test SQL on undocumented tables, Python on a messy file, a walkthrough of their own code, and validation habits, not algorithm puzzles.
Run the round on a sample of your own real data, because the mismatch with a clean textbook dataset is the biggest fit risk.
Judge the narration rather than the syntax: ask why about a step at random and listen to whether the reasoning holds.
Ask about the four silent bugs: fan-out joins, fitting before splitting, random splits on time data, and uncounted dropped rows.
Allow AI coding tools, state it in the brief, and score understanding through a live debrief instead of authorship.
Cap take-homes at three hours, keep task, data, and time limit identical for every candidate, and score eight weighted areas with evidence.
Frequently Asked Questions
What coding questions should I ask a data scientist?
Ask questions that reproduce the work rather than test puzzle preparation. The four areas that matter are SQL against an undocumented schema, Python and data wrangling on a deliberately messy file, a walkthrough of code the candidate wrote, and modeling code where validation and leakage live. Strong openers include: here are two tables and no documentation, what do you want to know first; your join returned more rows than the left table had, what happened; load this file and tell me the three things wrong with it; and your model scored 0.98 on the first try, what do you do. Each of those has a clear right instinct, so you can score it even without writing code yourself. This page has six downloadable sets, each question paired with why it is worth asking and what a strong answer sounds like.
Should I use algorithm puzzles for a data scientist coding interview?
Usually not. Whiteboard puzzles about trees, graphs, and dynamic programming test preparation for a specific style of hiring process rather than the work a data scientist does at a small company. The daily job is SQL against messy tables, data cleaning, validation, and explaining a result to someone who will act on it. A candidate can be excellent at all of that and rusty at puzzles, and screening them out costs you a good hire. Run a live round on a sample of your own data instead, or review code the candidate already wrote. If you have a genuine algorithmic need, such as a latency-critical component, test it directly with a small realistic problem rather than a puzzle. Keep the format the same for every candidate so the comparison stays fair.
How long should a data scientist coding round be?
Plan 30 to 45 minutes for a live round and cap any take-home at three hours. A live SQL or Python round of half an hour is enough to see how a candidate approaches an unfamiliar table, whether they check their own numbers, and how they narrate their thinking. Longer rounds mostly test stamina. If you use a take-home, state the time cap in the brief, ask candidates to stop at the cap and describe what they would have done next, and always pair it with a live debrief of about 30 minutes. Unpaid multi-day assignments push out strong candidates who already have jobs, and they tell you less than a short live round does. Two rounds totalling under two hours of the candidate's time is a reasonable process for a small business.
How do I run a coding interview if I cannot code?
Grade the narration, not the syntax. Ask the candidate to explain each step out loud while they work, and judge whether the explanation is coherent: do they check what one row of a table represents before counting it, do they compare a result against the raw file, do they say what they assumed. Then ask why about a step chosen at random. A candidate who cannot explain a line of their own work to you cannot explain a finding to you either, which is the actual job. The code walkthrough set on this page is built for exactly this situation, because the candidate does the explaining and you evaluate the explanation. If you want a technical second opinion, a friendly contact or a fractional adviser can sit in on one round without joining your team.
What is data leakage and why should it be in a coding interview?
Data leakage is when information that would not be available at prediction time slips into the training data, producing a model that scores beautifully in testing and fails in use. In code it usually comes from one of two mistakes: fitting a transformation such as scaling or imputation on the full dataset before splitting it, or splitting time-ordered data randomly so the model learns from the future. It belongs in a coding interview because it is not a math question, it is a habit question, and habits show up in the order of operations. Ask what the candidate does in code before fitting anything, and ask what they do when a first score looks extremely good. The right reflex is suspicion. At a small company nobody else will catch this before a decision is made on it.
Is it fair to let candidates use AI coding tools in the interview?
Yes, and it is more realistic than banning them, as long as you keep the rules the same for everyone. Say clearly in the brief whether tools are allowed, then design the round so understanding is what gets scored. In a live round, ask the candidate to explain why a line is there and what would break if the input changed. In a take-home debrief, ask where they used a tool and what they changed about the output. A candidate who used assistance and can defend every decision is showing you the skill you are hiring for. A candidate who submitted code they cannot explain has failed the round regardless of how the code was produced. Write the policy into the brief so no candidate is guessing.
Should a data scientist coding take-home be paid?
Pay for it or cap it tightly, and ideally do both. A take-home that runs past a few hours is real work, and asking for unpaid real work narrows your candidate pool to people with spare time, which is not a quality filter. A practical standard for a small business is a three-hour cap with a clear instruction to stop at the cap, or a modest flat payment for the time. Two rules protect you either way: never assign a task that is a deliverable you would otherwise pay someone to produce, and give every candidate the same brief, the same data, and the same time limit. Offer an alternative format if a candidate requests an accommodation. Consistency here is both the fairer approach and the one that gives you a comparable set of results.
How much do data scientists cost to hire?
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), data scientists had a median annual wage of about 120,230 dollars, roughly 57.80 dollars an hour. The lowest 10 percent earned under about 67,240 dollars and the highest 10 percent more than about 199,130 dollars, with the 25th percentile near 85,660 dollars and the 75th near 158,880 dollars. That is an unusually wide band for one occupation, and it reflects seniority, industry, and location more than title. A small business hiring its first data person is generally recruiting in the lower and middle part of the range, and a part-time or fractional arrangement is a legitimate option when the workload does not yet justify a full-time hire. Benchmark against your local market before you name a number.
