The Curiosity Case Interview
Use a real historical company problem as the case, then test soft skills the candidate doesn't know you're testing
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 92%
Once a candidate clears a technical screen, Lachs runs a business case drawn from a real problem in the company's history — but the case's literal answer is not what is being graded. Planted flaws test curiosity, an inevitable wrong assumption tests how the candidate reacts to being corrected, and a forced call under incomplete information tests whether they can hold a point of view. Technical skills are table stakes; the soft signals are the hire decision.
Origin
Jessica Lachs's hiring process for DoorDash analytics and data science, built to select for curiosity — the one trait she believes cannot be taught.
Core principles
- 01Technical skill is a non-starter, not a differentiator — screen for it, then move on
- 02You cannot teach curiosity, so you must select for it
- 03The best signal comes from questions that assess something other than what they appear to ask
- 04Real historical company problems make better cases than abstract consulting puzzles
- 05How someone responds to being told they're wrong is one of the most important signals available
- 06In real life you must decide without full information — test for that
How to run it
- 1
Screen technical skills first and separately
Run a coding exercise and technical screen early. Treat this as a gate, not a ranking: everyone on the team must clear the bar, but clearing it earns nobody the job.
Pro tip Because hard skills are far easier to test than soft skills, spend your remaining interview budget entirely on the soft ones.
- 2
Build the case from a real company problem
Use an actual problem from the company's history rather than a generic consulting case. Real problems create genuine ambiguity and let the interviewer, who knows the business deeply, evaluate the candidate's structured problem-solving honestly.
Pro tip The interviewer's superior context is a feature — it guarantees the candidate will make at least one wrong assumption.
- 3
Plant something that isn't quite right
Seed the case with an anomaly. Watch whether the candidate notices it unprompted. If they don't, point it out and observe where they take it — do they pull the thread or accept the answer and stop?
Pro tip Pair this with a request for past examples; genuinely curious people volunteer stories that start with 'I noticed this thing and so we decided to investigate'.
Watch out Testing for curiosity is genuinely hard. Do not mistake enthusiasm or verbosity for it.
- 4
Tell them they're wrong and watch
When the candidate makes a wrong assumption, correct them. Grade how they respond: can they absorb new information, pivot, and rebuild their reasoning — or do they get defensive or collapse?
Watch out This only works if the wrong assumption is genuine, not a trap you manufactured to humiliate them.
- 5
Force a call under uncertainty
When a candidate says they could see it going either way, push them: if you had to make a call right now, what would it be? A data person who cannot form a point of view without perfect information cannot do the job.
Pro tip This mirrors the mandate: the team's value is having a point of view on what to do, not just explaining what happened.
In the wild
DoorDash's shortened business case presents a real historical problem. Most candidates make a wrong assumption because the interviewer knows the business better. The interview is really scoring three things the candidate isn't told about: whether they spotted the planted anomaly, how they handled being corrected, and whether they could commit to a decision when pushed.
→ A hiring rubric that selects for curiosity, ambiguity tolerance, and decisiveness — the traits Lachs identifies in her top performers — rather than only for SQL and statistics.
Lachs, self-taught in SQL and Python with an art background and a finance career, hires PhDs in statistics and ML specialists whose technical skills exceed her own, while keeping them anchored on business impact.
→ A team that mixes deep technical skill with pragmatism, described as 'a job I'd never be hired for' by the person who built it.
Common mistakes
Ranking candidates on technical score
Technical ability is table stakes. Once the bar is cleared, further technical differentiation adds little; the differences that predict impact are curiosity, response to correction, and decisiveness.
Using abstract consulting cases
Generic puzzles have clean answers and no genuine ambiguity, so they can't produce the wrong-assumption moment or the anomaly-spotting moment that carry the real signal.
Accepting 'it could go either way'
Letting candidates avoid a call hides the exact skill the role requires — forming a point of view with imperfect information.
Is it for you?
Best for
Data, analytics, and product hiring managers designing an interview loop where soft skills, not technical ability, are the binding constraint on team impact
Not ideal for
Roles where execution against well-specified requirements is the job and exploratory curiosity is not required, or teams with no historical problems rich enough to build a case from
From the transcript
“I think the first thing is just curiosity you you can't teach curiosity”
“have something that is not quite right within the case that you're presenting and see if people notice first and foremost”
“shortened version of a business case so real world problem solving typically it's something actually from door Dash history like a real problem that we…”
“seeing how people react to being told they're wrong”
“I always push people to say if you had to make a call right now what would it be”
From the episode
Building a world-class data org
Jessica Lachs (VP of Analytics and Data Science at DoorDash)