2 min lesson
Carry honest critiques and frame them as the work
Put yourself in this case. "You're asked what frustrates you about Cursor. Draft a 30-second answer that proves real usage and reasons like someone on the inference team." Give the clearest next step.
Step 1 of 2
Carry honest critiques and frame them as the work
- A latency complaint you can locate: which surface, roughly what budget it blew and why that's a routing or batching issue rather than "the model is slow."
- A reliability complaint: a time a provider hiccup leaked through as a visible stall and how health-based routing or hedging would have hidden it.
- A cost-aware observation: where you'd suspect the system over-spends, say by hedging everything instead of only tail-risk requests.
- A quality observation tied to model choice: a task where one model clearly fit better, which connects straight to routing policy.
Show that you've customized the tool. Mention your .cursor/rules and the model-selection preferences you've settled on, with reasons: a cheaper model for boilerplate, a stronger one for gnarly refactors. That's exactly the routing instinct the role exercises.
Turn every critique into a hypothesis you'd test, not a gripe. "Tab felt slow on big files" is a complaint. A candidate already reasoning like the team says: "Tab felt slow on big files. I'd guess context assembly or prefill cost scales with file size, so I'd want the p95 split by file size before blaming the provider."
If you haven't used it for real, start now. Two to four weeks of daily, genuine work is the minimum to have opinions that survive a follow-up question. Cramming a demo the night before produces exactly the generic praise that gets screened out.