The two-part technical conversation
A real data scientist technical round often opens with something spoken, like explaining how to decide between optimizing for precision or recall on a given problem, or reasoning out loud through a conditional probability question, no code editor involved, just the ability to think clearly under a question that has more than one defensible answer.
Later, or in a separate stage entirely, the same candidate might get handed an actual SQL query to write against event logs, or a Python function to clean a messy column of missing values, where partial credit for sounding right doesn't exist and the code either passes the test cases or it doesn't.
Preparing only for one half leaves a real gap: a candidate who can defend a model choice fluently but can't write the query to build the training set in the first place stalls out at exactly the stage meant to confirm they can do the job.
What the practice session covers
The technical interview type runs as a spoken conversation, no code editor, covering statistics and probability reasoning, model choice and evaluation tradeoffs like knowing when a strong accuracy number is hiding overfitting, and how a candidate would approach a dataset they're handed.
For the coding half, technical challenges run real code execution via Piston across languages including Python, with hidden and visible test cases, so a SQL query to assemble a training dataset from raw event logs, or a function to compute a rolling average, gets checked the way an actual technical screen would check it, not just described.
Scoring
How the scoring applies here
For the spoken technical interview, scoring weighs Technical on whether the statistical and modeling reasoning actually holds up under a follow-up question, not whether the answer sounds fluent, with calibration floors and caps stopping a confident but thin explanation from scoring higher than the content supports.
For a technical challenge, the Technical dimension ties more directly to whether the code passes its test cases, hidden and visible, so a SQL query with the right idea but a broken join scores differently than one that runs clean. Communication still matters in both formats, since even a working query needs an explanation a reviewer can follow.
Frequently asked questions
Is the technical interview type the same as writing code?
No. The technical interview type is a spoken conversation about statistics reasoning and modeling tradeoffs, with no code editor. Actually writing and running code, like a SQL query or a Python function, happens through the separate technical challenges feature.
Can I practice a real SQL query for building a training dataset?
Yes. Technical challenges support SQL among other formats, with real execution and hidden and visible test cases, so a query either produces the right result against the data or it doesn't.
What languages can I use for a coding challenge?
Real code execution runs via Piston, with Python, JavaScript, and Java confirmed, plus language auto-detection across additional languages, so a candidate can work in the language closest to their actual job.
Will I get asked to explain overfitting or a metric tradeoff out loud?
Yes, this is one of the most common threads in the spoken technical interview type: knowing when a strong-looking metric is hiding a real problem, and being able to explain that reasoning clearly, not just name the term.
Related pages
Practice both halves of the technical round
Run a spoken technical AI interview for the reasoning, and a technical challenge for the real code, before a real data scientist screen does both at once.