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 the exact data shape Cursor's screen would hand you: a raw interaction events table.
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 real stage - step through to see what it tests and how to prep.
The DS technical screen is data-shaped, not algorithmic. Assume one fat events table - one row per user↔AI interaction - with 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.