1 min lesson
Timed SQL + stats screen
Use "You don't find out whether your SQL holds up under a clock by reading query patterns" to describe the practical rule.
Step 1 of 3
You don't find out whether your SQL holds up under a clock by reading query patterns. You find out by setting a 60-minute timer, opening a blank editor and talking through every metric definition as you type it. This section is that drill, built on a plausible raw interaction events table, a stand-in for what a data-shaped screen would use.
Learn more
Full explanation
The Mock Loop You're Rehearsing
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
Each capstone section is a timed mock of one stage. Stage order follows the interview-loop module; the DS-specific screen and take-home formats are inferred from peer loops, so believe your recruiter if it differs.
Plan for a data-shaped DS technical screen. Assume one fat events table, with one row per event within a user↔AI interaction, and columns you'll reference all hour: event_id, user_id, request_id, model, client_version, event_type, latency_ms, status, ts. Set the timer before you read the prompts.
- request_id
- Logical attempt id. One prompt can emit many event rows under the same request_id.
- event_type
- prompt | retrieval | tool_call | edit_apply | success | error | timeout.
- latency_ms
- End-to-end completion latency for the interaction; heavy right tail.
- status
- ok | error | timeout, raw, before you collapse retries.
- model / client_version
- Your two main segmentation keys; never report a global number without them.