Six question sets written for the employer side of the table: 40+ questions with the reason each one is worth asking and what a strong answer sounds like, plus a live work sample and an eight-area scorecard. Download as DOCX.
The first data scientist I ever helped a small company interview was, by every visible measure, the strongest candidate in the pipeline. Excellent background, fluent about methods, and completely unable to say what business decision any of his past work had changed. The company hired him. Nine months later they had a lot of notebooks and no answers, and both sides were unhappy.
That failure was not a technical screening problem. It was an interview that tested what the candidate knew instead of how they think, which is the default outcome when you copy a question list written for candidates preparing to answer rather than for employers deciding what to ask. Almost everything published under this keyword is candidate prep. This page is the other side of the table.
At FirstHR, we build for small businesses that hire without an HR department, where the owner runs the whole interview between everything else. Below are six question sets, more than 40 questions in all, each with the reason it is worth asking and what a strong answer sounds like, plus a live work sample and an eight-area scorecard. See the full hiring template library for the rest of the process.
TL;DR
Interview a data scientist on five things: business framing, statistics and experimentation, modeling judgment, hands-on work with messy data, and communication. Ask the same core questions of every candidate, run a 30-minute live work sample on one real question from your own business, and score eight areas from 1 to 5 with a line of evidence each. Download 40+ questions and the scorecard as DOCX.
What the Interview Has to Test
A data scientist interview has to test judgment, not recall. The knowledge that is easy to quiz is also easy to memorize, and it correlates weakly with whether someone will produce work your business acts on. What actually predicts performance is how the candidate defines a question, how honestly they validate, and whether anyone outside the role understands the result.
That gap matters more at a small company than a large one. A big employer can hire a brilliant specialist and let a manager supply the framing and an engineering team supply the data. You cannot. The person you hire has to bring their own question definition and find their own data, which is why the framing set below comes first rather than the statistics set.
Structure Is What Makes an Interview Predictive
Federal hiring guidance describes a structured interview as one where every candidate is asked the same job-related questions and rated on the same predetermined scale, and identifies that consistency as the reason structured interviews are more reliable and more legally defensible than unstructured ones (U.S. Office of Personnel Management). For a technical hire the discipline is harder, because a candidate mentions a project and forty minutes vanish into it.
The practical version of that advice: write the questions before the first interview, ask the same core set of everyone, and let your follow-ups vary rather than the questions themselves. A structured interview is not a script that removes conversation, it is a spine that keeps the conversations comparable.
Which Data Scientist Are You Hiring?
Decide which version of the role you are filling before you write the question set, because data scientist is three fairly different jobs sharing one title. Hiring a modeling specialist into a measurement job is the most common cause of an early resignation, and it is entirely avoidable at the interview stage.
The analytics-leaning data scientist
Most of the work is measurement: defining metrics, running experiments, answering why a number moved, and building the reporting the business runs on. Weight the business framing and statistics sets heavily, and treat modeling as secondary. This is the version of the role most small businesses actually need first, and hiring for deep machine learning instead is a common and expensive mismatch. If this is your role, say so in the posting, because candidates expecting to build models will leave within a year.
The machine-learning-leaning data scientist
The work centers on building and shipping models that make repeated decisions: scoring, forecasting, recommendation, risk. Weight modeling judgment and the production questions in the tooling set, and pay attention to whether the candidate has taken a model past a notebook into something that runs on a schedule and gets monitored. Ask specifically who maintained their models afterward, because at a small business the answer is going to be the person you are interviewing.
The first data hire, doing all of it
This is the most common small business version: one person who finds the data, cleans it, answers the questions, builds the reporting, and occasionally trains a model. Weight hands-on data skill and small-company fit near the top, and interview hard on the tooling set. The failure mode here is hiring an excellent specialist from a company with a platform team who has never had to source their own data. Be honest in the interview about what does not exist yet.
Whichever version you pick, say it plainly in the posting and again in the first screen. The matching data scientist job description gives you the language for that, and if the work turns out to be mostly pipelines rather than analysis, the data engineer questions are the better set to run.
The Six Question Sets
The questions are grouped into six sets: five competencies plus a scorecard. A strong candidate performs across all five, and the ones they are least rehearsed for are usually framing and messy data, which is exactly why those two carry the most information.
Business Framing
Do they define the question?
Whether the candidate turns a vague request into an answerable question before writing code. The set that separates someone who delivers decisions from someone who delivers notebooks.
Statistics and Experimentation
Can you trust the result?
Power, peeking at tests, uncertainty, and the gap between a metric moving and a metric mattering. Rigor is the part you cannot audit later.
Modeling Judgment
Judgment over algorithm trivia
Baselines, leakage, time-based splits, and metric choice tied to what each error costs. Written so a non-technical interviewer can still tell care from recitation.
SQL, Python, Messy Data
Can they work without a warehouse?
Undocumented schemas, sources that disagree, joins that fan out, and reproducible work. The biggest fit risk when hiring from a large company.
Communication and Work Sample
Will anyone act on it?
Explaining a result to a non-technical owner, plus a 30-minute live exercise on a real question from your own business.
Scorecard and Red Flags
Score, do not guess
Eight scoring areas at 1 to 5, an evidence line for every score, a weighting worksheet, and a red-flag checklist. The asset most question lists leave out.
Do Not Skip the Sets That Are Uncomfortable to Ask
Candidates rehearse modeling and statistics questions most, because that is what the candidate-prep material drills. The sets that separate a useful hire from an impressive one are business framing, where you learn whether they define a question before answering it, and messy data, where you learn whether they can work without a warehouse. Ask at least two questions from every set, then score each area separately so a brilliant answer in one does not paper over silence in another.
40+ Questions and a Scorecard to Download
Download all six as a single Word document, or copy individual sets. Every set opens with why it exists, then lists the questions with the reason each one is worth asking and what a strong answer sounds like, then what to listen for, then space for notes. The last file is the scorecard.
Download All 6 Question Sets and the Scorecard
Business framing, statistics, modeling, messy data, communication with a work sample, plus an eight-area scoring rubric. All in one DOCX.
Set 1: Business Framing and Problem Definition
Whether the candidate turns a vague request into an answerable question before writing any code. The set that separates someone who delivers decisions from someone who delivers notebooks, and the one most technical interviews skip entirely.
Business Framing and Problem Definition Questions
DATA SCIENTIST INTERVIEW: BUSINESS FRAMING AND PROBLEM DEFINITION
Candidate: __
Interviewer: __
Date: _
WHY THIS SET EXISTS
Most data science work fails before a single model is trained, because the
question was never defined well enough to answer. At a small business there is
no analytics manager to translate a vague request into a specification, so the
data scientist has to do it. This set is the one that separates someone who
delivers decisions from someone who delivers notebooks.
QUESTIONS TO ASK
1. A department head asks you to "figure out why churn is up." What do you do
in the first hour, before you touch any data?
Why ask it: tests whether the candidate defines the question or starts coding.
Strong answer: asks who acts on the result, what decision changes, how churn
is currently defined, and over what window. Names the ambiguity out loud.
2. Tell me about a time you talked a stakeholder out of the analysis they asked
for and into a better one.
Why ask it: a data scientist who only takes orders will burn months on work
nobody uses.
Strong answer: a specific person, the original ask, the reframe, and what
changed as a result. Respectful, not condescending.
3. How do you decide whether a question needs a model at all, versus a query,
a chart, or a conversation with three customers?
Why ask it: overbuilding is the most expensive habit a first data hire can have.
Strong answer: reaches for the cheapest thing that answers the question and
can name times a simple cut of the data was enough.
4. Walk me through a project where the result was that we should not do the
thing. How did you handle that?
Why ask it: negative results are common and telling people so is a skill.
Strong answer: describes delivering the finding clearly and early, not
burying it or padding it into a maybe.
5. How do you scope a project so it delivers something useful in two weeks
rather than three months?
Why ask it: small businesses cannot fund long silent research phases.
Strong answer: describes a rough first pass, a checkpoint, and a plan for
what gets cut if time runs out.
6. What is a success metric you have chosen yourself, and why that one?
Why ask it: metric choice is where business judgment shows.
Strong answer: ties the metric to a cost or a revenue consequence, and can
explain what the metric fails to capture.
7. Tell me about an analysis of yours that nobody ended up using. Why?
Why ask it: honest candidates all have one, and the diagnosis is revealing.
Strong answer: owns the cause, usually unclear framing or no stakeholder
buy-in, rather than blaming the business for not understanding.
8. Here is a real question our business has right now. How would you approach it?
Why ask it: nothing predicts fit better than the candidate reasoning about
your actual problem.
Strong answer: asks clarifying questions first, proposes a small first step,
and states what data they would need to see.
WHAT TO LISTEN FOR
•Asks who will act on the answer before proposing a method
•Reaches for the simplest thing that resolves the question
•Comfortable saying a question cannot be answered with the data available
•Talks about decisions and costs, not just accuracy
NOTES
__
__
Set 2: Statistics and Experimentation
Power, peeking at running tests, uncertainty, observational estimates, and the difference between a metric moving and a metric mattering. Rigor is the part of the work you cannot audit later without redoing all of it.
Statistics and Experimentation Questions
DATA SCIENTIST INTERVIEW: STATISTICS AND EXPERIMENTATION
Candidate: __
Interviewer: __
Date: _
WHY THIS SET EXISTS
Statistical rigor is the part of the job you cannot audit later without redoing
the work. If a candidate runs an underpowered test and calls a coin flip a win,
the business will act on it and never learn otherwise. Ask these even if you are
not a statistician: the notes below tell you what a sound answer sounds like.
QUESTIONS TO ASK
1. We ran a test, it was not significant, and the team wants to run it two more
weeks and check again. What do you say?
Why ask it: peeking at results until they turn significant is the most common
real-world statistics error in a small company.
Strong answer: explains that repeated looks inflate the false positive rate,
and proposes fixing the sample size or duration in advance.
2. How do you decide how long an experiment should run before you start it?
Why ask it: tests whether power and effect size are part of their planning.
Strong answer: works backward from the smallest effect worth acting on,
the baseline rate, and the traffic available. Says what they would do when
the required sample is out of reach.
3. Explain p-value to a non-technical owner in two sentences.
Why ask it: communication and understanding are the same test here.
Strong answer: plain language, no jargon, and does not claim it is the
probability that the hypothesis is true.
4. We have no way to run a controlled test on this. How would you estimate the
effect anyway?
Why ask it: most small business questions are observational.
Strong answer: names an approach such as before and after with a comparison
group, and is explicit about what could confound the estimate.
5. Our sample is small and the difference looks big. How much do you trust it?
Why ask it: small businesses live at small sample sizes.
Strong answer: talks about uncertainty intervals and variance rather than
giving a yes or no, and suggests what would raise confidence.
6. What is the difference between a metric moving and a metric mattering?
Why ask it: statistical significance and business significance are not
the same thing, and confusing them wastes money.
Strong answer: translates the effect into revenue, cost, or hours saved.
7. Tell me about a time your analysis was wrong. How did you find out?
Why ask it: everyone has been wrong; only good scientists have a detection
habit.
Strong answer: describes a specific error, how it surfaced, and what they
changed in their process afterward.
8. How do you handle a stakeholder who wants you to slice the data until the
result they want appears?
Why ask it: this pressure is real at every company and it is a character test.
Strong answer: describes pre-registering the cut, showing all the slices, or
simply declining, without turning it into a fight.
WHAT TO LISTEN FOR
•Talks in uncertainty rather than single numbers
•Plans sample size before running, not after
•Distinguishes statistical significance from business impact
•Explains concepts plainly without hiding behind terminology
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Baselines, leakage, time-based splits, class imbalance, and choosing a metric that matches what each kind of error costs you. Written so a non-technical interviewer can still tell careful reasoning from a rehearsed definition.
Modeling Judgment and Validation Questions
DATA SCIENTIST INTERVIEW: MODELING JUDGMENT AND VALIDATION
Candidate: __
Interviewer: __
Date: _
WHY THIS SET EXISTS
Algorithm trivia is easy to memorize and tells you almost nothing. What predicts
performance is judgment: choosing a baseline, validating honestly, catching
leakage, and knowing when a model is the wrong tool. These questions are written
so a non-technical interviewer can still tell a careful answer from a rehearsed
one, because the tells are about process rather than mathematics.
QUESTIONS TO ASK
1. Your model reports 97% accuracy on the first try. What do you check?
Why ask it: suspicion of a too-good result is the single best signal of a
careful practitioner.
Strong answer: immediately suspects leakage, a target variable hiding in a
feature, an imbalanced class, or a bad split. Does not celebrate.
2. What is data leakage, and how have you caught it in your own work?
Why ask it: leakage is the most common way a model looks great and fails live.
Strong answer: gives a concrete example, often a field populated after the
outcome, and describes how they now build splits to prevent it.
3. How do you split data when the observations are ordered in time?
Why ask it: random splits on time series quietly train on the future.
Strong answer: uses a time-based split, holds out the most recent period,
and explains why random shuffling is invalid here.
4. What baseline do you compare a new model against?
Why ask it: a model that cannot beat a simple rule is not worth maintaining.
Strong answer: names something specific, such as the current rule of thumb,
last period repeated, or predicting the majority class.
5. How do you choose an evaluation metric, and when is accuracy the wrong one?
Why ask it: metric choice should follow the cost of each kind of error.
Strong answer: ties precision and recall to what a false positive and a false
negative actually cost this business.
6. We ask you to predict something rare, say 1% of cases. What changes?
Why ask it: class imbalance breaks naive approaches.
Strong answer: discusses appropriate metrics, thresholds, and the fact that
a model predicting no every time already scores 99%.
7. How would you explain a model decision to a customer who is unhappy about it?
Why ask it: interpretability is a business requirement, not a preference.
Strong answer: favors an explainable approach when decisions affect people,
and can describe the drivers in plain language.
8. What would tell you a model in production has gone stale?
Why ask it: at a small company nobody else is watching it.
Strong answer: names monitoring of inputs and outcomes, a drift check, and
a retraining trigger, plus who gets told when it fires.
WHAT TO LISTEN FOR
•Distrusts results that look too good
•Always has a baseline before a model
•Validation design fits the data, especially with time
•Thinks about the cost of each type of error, not just the score
NOTES
__
Set 4: SQL, Python, and Messy Data
Undocumented schemas, three systems that disagree, joins that fan out, missing values, and reproducible work. The biggest fit risk when you are hiring someone whose entire experience is inside a company with a platform team.
SQL, Python, and Messy Data Questions
DATA SCIENTIST INTERVIEW: SQL, PYTHON, AND MESSY DATA
Candidate: __
Interviewer: __
Date: _
WHY THIS SET EXISTS
At a company without a data team, the data scientist is also the person who
finds the data, cleans it, and lives with the consequences. Candidates from
large companies often arrive expecting a curated warehouse and a platform team.
This set tests whether they can operate when neither exists, which is the single
biggest fit risk for a small business hiring its first data scientist.
QUESTIONS TO ASK
1. Our data lives in a production database, a spreadsheet, and a payment
processor, and none of them agree. Where do you start?
Why ask it: this is the actual first month of the job.
Strong answer: picks one source of truth per entity, reconciles a sample by
hand, documents the differences, and does not wait for a warehouse.
2. How comfortable are you writing SQL against a schema nobody documented?
Why ask it: undocumented schemas are the norm below a certain company size.
Strong answer: describes exploring tables, checking row counts and joins for
fan-out, and confirming assumptions with whoever built the system.
3. Walk me through a join that produced more rows than you expected. What
happened and how did you find it?
Why ask it: a specific, common bug that only hands-on people have hit.
Strong answer: explains the duplicate key, how they spotted the row count
change, and how they now check before trusting a join.
4. What does your Python work actually look like day to day?
Why ask it: separates people who ship analyses from people who ran tutorials.
Strong answer: names concrete libraries and tasks, describes how they
structure a project, and mentions version control as normal practice.
5. How do you handle missing values, and when is dropping rows the wrong call?
Why ask it: a routine decision with real consequences for bias.
Strong answer: asks why the values are missing before choosing a method, and
knows that dropping can skew the sample systematically.
6. How do you make an analysis reproducible so someone else can rerun it?
Why ask it: at a small company the someone else is often you, six months on.
Strong answer: version control, a script rather than manual steps, seeds set,
and a short written record of assumptions.
7. What is the largest dataset you have worked with, and what broke first?
Set 5: Communication, Stakeholders, and Work Sample
Explaining a result to a non-technical owner, delivering an answer a leader did not want, and communicating uncertainty without hiding behind it. Includes the full instructions for the 30-minute live exercise.
Communication, Stakeholders, and Work Sample
DATA SCIENTIST INTERVIEW: COMMUNICATION AND WORK SAMPLE
Candidate: __
Interviewer: __
Date: _
WHY THIS SET EXISTS
A correct analysis that nobody acts on has zero value. At a small business the
data scientist presents directly to the owner, so translation is half the job.
This set combines the communication questions with a live work sample, which
tells you more in thirty minutes than any take-home you will wait a week for.
COMMUNICATION QUESTIONS
1. Explain a project you are proud of to me as if I have no technical training.
Why ask it: the clearest single predictor of whether this hire will be used.
Strong answer: leads with the decision and the outcome, keeps method to a
sentence, and checks whether you are following.
2. Tell me about a time you had to give a leader an answer they did not want.
Why ask it: this will happen here, probably in month two.
Strong answer: direct, evidence-first, and not apologetic about the result.
3. How do you communicate uncertainty to someone who wants a single number?
Why ask it: false precision leads to bad decisions.
Strong answer: gives a range with a plain-language confidence statement, and
still gives a recommendation rather than hiding behind the uncertainty.
4. How do you know your analysis actually changed something?
Why ask it: outcome orientation versus output orientation.
Strong answer: points to a decision made, a process changed, or a number that
moved, not to the number of dashboards produced.
5. Someone challenges your result in a meeting and they are partly right.
What do you do?
Why ask it: ego management in public is a real job requirement.
Strong answer: acknowledges the valid part immediately, separates it from the
part that stands, and follows up with the check.
THE 30-MINUTE WORK SAMPLE (RUN THIS LIVE)
Prepare in advance:
•One real business question you currently have
•A small, anonymized extract of your own data (a few thousand rows is plenty)
•Nothing cleaned up. Leave the duplicates and the blank fields in.
Run it:
•Give the candidate the question and the data at the start of the session
•Let them talk through what they would check, in what order, and why
•Answer their clarifying questions the way a stakeholder would
•They do not need to finish. You are watching the reasoning, not the output
Score it on:
•Did they ask what decision this informs before starting?
•Did they notice the data problems you left in?
•Did they state assumptions out loud?
•Would you understand their explanation if you were not in this role?
•Did they say what they would do next and what they would not bother with?
Give every candidate the same question, the same data, and the same time.
Pay for a longer exercise if you extend it beyond an interview slot.
NOTES
__
Set 6: Scorecard and Red Flags
Eight scoring areas at 1 to 5 with an evidence line for every score, a weighting worksheet to fill in before you interview, and a red-flag checklist. The asset almost every question list leaves out.
Data Scientist Scorecard and Red Flags
DATA SCIENTIST INTERVIEW SCORECARD AND RED FLAGS
Candidate: __
Interviewer: __
Date: _
HOW TO SCORE
Score every area right after the interview, while it is fresh, and write one
line of evidence for each score: something the candidate actually said. If more
than one person interviews, everyone scores alone before the group talks, so the
first opinion voiced does not set the room. Use the same scorecard for every
candidate for this 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
Business framing: defines the question before choosing a method
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Statistical rigor: uncertainty, power, and honest experiment design
A 30-minute live exercise on your own data tells you more than a week-long take-home, and costs both sides far less. Give the candidate one real business question and a small anonymized extract of your data, then watch how they reason. You are scoring the approach, not the finished answer.
Leave the data messy on purpose. Duplicates, blank fields, and two columns that disagree are the point: a candidate who works through them out loud is showing you the first month of the job. One who does not notice them is showing you something too. Answer their clarifying questions the way a stakeholder would, not the way an examiner would.
Live 30-minute work sample
Week-long take-home
You watch the reasoning as it happens
You see an output and guess who produced it
Costs the candidate half an hour
Costs unpaid evenings and filters out strong candidates
Decision moves the same week
Adds a week or more to your process
Uses your real question and your real mess
Usually a generic dataset with no business context
Clarifying questions are part of the signal
No way to see what they asked or assumed
Run the same exercise for every candidate: same question, same data, same time. An exercise used to select between candidates is a selection procedure, and federal guidance on employment tests and selection procedures expects it to be job-related and applied consistently. If you extend an exercise beyond an interview slot, pay for the time.
What to Probe For and the Red Flags
The listed questions open the topic. The follow-ups are where you learn whether an answer is lived or recited, and the most useful follow-up is almost always some version of what happened next. A candidate with real experience has a specific outcome ready; a rehearsed one retreats into the general.
Framing signals
Asks what decision the answer informs
Reaches for the cheapest sufficient method
Can name work of theirs that went unused
Rigor signals
Talks in ranges rather than single numbers
Plans sample size before running a test
Distrusts a result that looks too good
Hands-on signals
Has debugged a join that fanned out
Comfortable with undocumented schemas
Reproducible work as a personal habit
Red flags
Every project was a clean success
Cannot explain a project without jargon
Expects a warehouse and a defined backlog
One red flag deserves its own note: a candidate whose every project was a clean success. Real data science produces plenty of analyses nobody used and models that never shipped. A candidate who can name one and diagnose why is more trustworthy than one with an unbroken record, and the diagnosis itself tells you how they think about their own work.
Pay Context Before You Ask About Expectations
Know the market before the compensation conversation, because data scientist pay has one of the widest ranges of any single occupation and a number quoted without context will either lose you the candidate or overpay by a wide margin. Use federal wage data as the anchor, then adjust for your market and the actual scope.
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 and the highest 10 percent more than about $199,130. The U.S. Bureau of Labor Statistics projects employment in the occupation to grow 34 percent from 2024 to 2034, with about 23,400 openings a year on average.
What you are buying
Analytics-leaning
Machine-learning-leaning
Defines metrics and answers business questions
Designs and reads experiments
Ships models that run on a schedule
Monitors and retrains what they shipped
Usually sits lower in the wage range
Two practical notes. A fractional or part-time arrangement is legitimate when the workload does not yet justify a full-time hire, and it is a common first step for a small business. And several states and cities now require a pay range in the job posting, so check your own rules before you publish rather than after.
Fair, Legal, and Structured Interviewing
Fair, legal, and structured are the same practice described three ways. Asking the same job-related questions of every candidate keeps you compliant, reduces bias, and produces better hires at once. The EEOC publishes a plain summary of the practices that are prohibited under federal law, and it is worth reading once before you interview.
Ask about the job, not the person
Federal anti discrimination law, enforced by the EEOC, prohibits basing a hiring decision on protected characteristics, and a question that probes one creates risk even when it is asked 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 studied, when they graduated, or where they are originally from. Graduation year is an age proxy, so leave it out. Keep every question tied to the work: framing, rigor, modeling, data handling, and communication. This is general information, not legal advice.
Same questions, same order, every candidate
A structured interview, where every candidate faces the same questions scored against the same rubric, predicts on the job performance far better than a conversation that wanders wherever rapport takes it. For a technical hire the temptation to improvise is strong, because a candidate mentions a project and forty minutes disappear into it. That produces a warm feeling and no comparable evidence. Write the question set before the first interview, ask the same core questions of everyone, and let the follow ups vary rather than the questions themselves. The downloadable sets here are ordered so you can run them straight down the page.
Score alone before anyone talks
When more than one person interviews, have each interviewer fill in the scorecard independently before the group discusses anything. Otherwise the first opinion voiced sets the room, and for technical hires that voice is usually whoever is most senior or most confident about the technology. Compare written evidence first, then argue about the gaps. A 1 to 5 rating per area, with one line of evidence attached to each score, turns a debate about who liked whom into a comparison of what candidates actually said. Write the weighting down before the first interview too.
Be careful with automated screening
If you use an automated tool to score resumes, rank candidates, or grade a technical exercise, you are still responsible for the outcome. Federal guidance treats a selection procedure as a selection procedure regardless of whether a person or software applied it, so a tool that filters out a protected group creates the same exposure a biased interviewer would. For a small business the practical advice is simple: keep a human reading the finalists, keep records of why each candidate advanced, and do not adopt a scoring tool you cannot explain. This is general information, not legal advice.
Technical interviews drift toward small talk about schools and graduation years more than most, and graduation year is an age proxy. Keep every question on the work. For the fuller list of what not to ask, see our guide to illegal interview questions. This is general information, not legal advice.
Interviewing a Data Scientist Without HR
At a large company this hire goes through a recruiter, a technical panel, and a scorecard system somebody else maintains. At a small business the owner does all of it, usually while evaluating skills they cannot personally grade. That combination is where the avoidable mistakes live, and each one has a specific fix.
You are hiring for skills you cannot personally grade
Most owners hiring their first data scientist cannot evaluate a validation strategy on their own, and the usual response is to outsource judgment to a credential or to whoever sounds most confident. Neither works. What you can evaluate is process: does the candidate ask what decision the answer informs, do they distrust a result that looks too good, can they explain a past project without jargon, do they name a baseline. Every question in these sets ships with a note on what a sound answer sounds like, written so you can score it without a statistics background. If you want a second opinion, borrow a technical friend for the work sample only and keep the rest of the interview yours.
The candidate pool is full of people who have never worked without a platform team
A data scientist from a large technology company usually arrives into a curated warehouse, a defined backlog, and an engineering team that owns the pipelines. At your company none of that exists, and the first six months are finding data, reconciling sources that disagree, and building the reporting from nothing. This is the most common reason a strong-looking hire fails at a small business, and it is entirely predictable from the interview if you ask about it. Use the messy data set, be honest about what you do not have, and treat enthusiasm about building it from scratch as a real signal rather than a nice-to-have.
One person is the whole function, so a bad hire is the whole function
When the data scientist is your only data hire, there is no team to absorb a mismatch and no senior colleague to review the work. That raises the value of structure enormously: the same questions for every candidate, a live work sample on your real data, and a written scorecard filled in before anyone talks. Once you choose someone, the work turns into hiring them well, and FirstHR handles that side: send the offer for e-signature, run the new hire paperwork and onboarding workflow, and keep the signed documents and interview records on the employee profile. To be clear on scope, FirstHR is an onboarding and HR platform, not a data or analytics tool, so pair it with those. Applicant tracking is coming soon to FirstHR.
You have one real advantage over the large employers competing for the same people: you can decide in a week when they take a month. Use it. Two or three rounds, a live work sample instead of a take-home, and a decision made from written scores rather than a fourth meeting. A clean interview feedback step keeps that speed from becoming carelessness.
From Interview to Offer
Once the scorecards are in, the work shifts from evaluating to hiring well. Run reference checks after the work sample rather than before, so you can ask about the specific concerns your scorecards raised, then put the offer in writing with an offer letter that states the scope and the reporting line.
Fix the question set first
Choose the sets that match the version of the role you are filling, write the weighting on the scorecard, and use the same core questions for every candidate.
Score with evidence, alone
Eight areas at 1 to 5, one line of evidence per score, filled in independently before anyone in the group says what they thought.
Put the offer in writing
Confirm the scope, the reporting line, the tools you do and do not have, and compensation in writing, signed electronically.
Plan the first 90 days
Name the first business question, the stakeholders, and the first deliverable, or a solo data hire spends a quarter looking for direction.
A solo data hire needs a first 90 days with a named business question and named stakeholders, or the mandate stays vague for a quarter and both sides get frustrated. Structure that with an onboarding template, and handle the new hire paperwork in the same pass.
FirstHR connects the offer, the e-signature, the paperwork, and the onboarding workflow in one place, and keeps the signed documents and interview records on the employee profile, so a small business can run hiring through to onboarding from one system. FirstHR is an onboarding and HR platform, not a data or analytics tool, so connect those separately. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Test judgment rather than recall: framing, honest validation, and whether anyone outside the role understands the result.
Decide first which version of the role you are hiring, because analytics-leaning and machine-learning-leaning are different jobs sharing one title.
Ask what the candidate does before touching data; reaching for a model before asking what decision it informs is the core red flag.
Run a 30-minute live work sample on one real question and a small extract of your own messy data, identical for every candidate.
Score eight areas from 1 to 5 with one line of evidence each, independently, before anyone in the group says what they thought.
Use BLS data as the anchor: the occupation reported a median of about $120,230 a year in the May 2025 survey.
Applicant tracking is coming soon to FirstHR, and the offer, paperwork, and onboarding already run in one place.
Frequently Asked Questions
What questions should I ask a data scientist in an interview?
Ask questions in five areas: business framing, statistics and experimentation, modeling judgment, hands-on data skill, and communication. Strong openers include what do you do in the first hour when a department head asks you to figure out why churn is up, how do you decide how long an experiment should run before you start it, your model reports 97 percent accuracy on the first try and what do you check, our data lives in three systems that disagree and where do you start, and explain a project you are proud of to someone with no technical training. Each of these has a right shape of answer rather than a right answer, which is what makes them useful to an employer who is not a statistician. The six downloadable sets on this page pair every question with the reason it is worth asking and a note on what a sound answer sounds like.
How do I evaluate a data scientist if I am not technical myself?
You evaluate the process rather than the mathematics. A careful data scientist asks what decision an answer will inform before choosing a method, distrusts a result that looks too good, names the baseline they compared a model against, talks in ranges rather than single numbers, and can explain a past project without jargon. A weaker candidate reaches for a model immediately, reports one clean success after another, and cannot say what they personally did versus what the team did. Every question set on this page includes what a sound answer sounds like, written for a non-technical interviewer. If you want a technical second opinion, borrow a friend or contractor for the work sample only and keep the rest of the interview yours, so the hiring judgment stays with the person who owns the business outcome.
What is the difference between a data scientist and a data analyst?
A data analyst answers questions about what happened and why, usually with SQL, spreadsheets, and reporting tools, and delivers the measurement a business runs on. A data scientist does that too but also works on what will happen and what to do about it: designing experiments, building predictive models, and applying statistical methods to questions the data does not answer directly. In practice the line is blurry and many small businesses posting a data scientist role actually need strong analytics with occasional modeling. Decide which version you need before you interview, because hiring a modeling specialist into a measurement job leads to a resignation inside a year. A data engineer is a third role, focused on building and maintaining the pipelines that both of the others depend on.
Should I give a data scientist a take-home assignment?
A live work sample is usually better than a take-home. A take-home asks for unpaid hours, filters out strong candidates who have other offers, delays your process by a week, and does not tell you who actually did the work. A 30 minute live exercise on a real question from your business, using a small anonymized extract of your own messy data, tells you more: how they scope the question, whether they notice the problems you left in the data, what assumptions they state out loud, and how they explain their thinking. Give every candidate the same question, the same data, and the same time. If you do extend an exercise beyond an interview slot, pay for the time. Treat the exercise as a selection procedure and apply it consistently to every candidate.
What are the biggest red flags in a data scientist interview?
The clearest red flags are jumping to a model before asking what decision it informs, celebrating a suspiciously high accuracy score without checking for leakage, being unable to name a baseline, describing every past project as a success with no failed or unused work, and being unable to explain a project without technical jargon. For a small business, add one more: expecting a clean data warehouse, a platform team, and a defined backlog. A candidate who has only worked inside that setup often struggles in a company where the first six months are finding data and reconciling sources that disagree. None of these is automatically disqualifying, but each one deserves a direct follow up rather than a benefit of the doubt, and each should be written into the scorecard as evidence rather than a feeling.
How much does a data scientist cost to hire?
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey published in 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 earned more than about 199,130 dollars, so the range is unusually wide for a single occupation. That spread reflects seniority, industry, and location more than title. A small business hiring its first data scientist is generally recruiting in the lower and middle part of that range, and a fractional or part-time arrangement is a legitimate option when the workload does not yet justify a full-time hire. Benchmark against your local market and be specific in the posting about scope, because a mismatch on that is what drives early turnover.
What questions are illegal to ask a data scientist candidate?
Avoid any question that probes a characteristic protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, or genetic information. In a technical interview these usually slip in as small talk rather than as deliberate questions, most often through where did you study, what year did you graduate, and where are you originally from. Graduation year is an age proxy, so leave it out. You may ask whether a candidate can perform the essential functions of the job and whether they are authorized to work in the United States. State and local rules may add restrictions, including on salary history in many jurisdictions, so check your own state before you interview. Asking the same job related questions of every candidate is the simplest safeguard. This is general information, not legal advice.
How many interview rounds should a data scientist hire take?
Two or three rounds is enough for most small businesses, and more than that costs you candidates. A practical sequence is a 30 minute screen covering scope, experience, and compensation expectations, then a 60 to 90 minute main interview drawing on the business framing, statistics, modeling, and messy data sets, then a final session built around the live work sample and a conversation with whoever the role will report to. Reference checks come after the work sample rather than before, so you ask about the specific concerns your scorecards surfaced. Large technology companies run four to six rounds over several weeks, which is exactly the process a small business should not copy, because your advantage in a competitive market is deciding faster than they can.
