2 min lesson
Why this isn't generic SaaS support
Use "At a typical SaaS company, a support rep is graded on tickets closed and CSAT" to say what a strong answer must include.
Step 1 of 2
At a typical SaaS company, a support rep is graded on tickets closed and CSAT. Here you're graded on whether an issue was actually root-caused and whether the parser or macro you wrote made the next ten tickets faster to handle. One TSE who ships a good log parser quietly raises the throughput of the entire queue.
You also sit between two worlds. To the user you are Anysphere - the person who makes the bug make sense and gives them a path forward. To Engineering you are the translator who turns an angry, vague report into a clean reproduction they can act on. You both fix and carry signal, which is why the role rewards people who can write code and write clearly.
Cursor's own support team uses Cursor on roughly 75% of non-trivial support interactions. The other ~25% is niche stuff that still wants manual debugging outside the editor, or billing and account work that involves context they'd rather not hand an LLM. That's a concrete adoption benchmark: the tooling you build and the editor you support are the same tools you live in all day.
“For our team, they're using Cursor on roughly 75% of non-trivial support interactions today.”
When a screener asks “what do you think this job is?”, lead with the dual nature: first-line technical defense that also builds the automations support runs on. Then drop the line that you'd be judged on issues root-caused and impact created, not tickets closed. That framing instantly separates you from candidates who picture a deflection queue.