Debugging & Troubleshooting Method

The technical screen isn't grading whether you already know the bug. It's grading whether you have a method that finds any bug, including ones nobody at Cursor has seen yet.

Cursor ships an AI-native editor whose behavior drifts as models and the product change weekly. A memorized fix for last month's indexing quirk is worthless this month. What survives is a loop you can run on a problem you've never met - and a Technical Support Engineer who runs that loop visibly is the one who gets the offer.

Carry one loop into the room and use it for everything. Here it is end to end.

1. 1Clarify. Restate the issue in your own words and pin down what "working" would look like. Half of bad debugging is solving the wrong problem fast.
2. 2Reproduce. Get the failure to happen on demand. No reliable repro, no confident fix.
3. 3Isolate. Narrow the blast radiusHow much breaks if a change goes wrong; the scope of potential damage.. Change one variable at a time and binary-search the space.
4. 4Hypothesize. State a specific, falsifiable guess: "I think the index never finished, so retrieval returns nothing."
5. 5Test. Run the cheapest experiment that would prove the hypothesis wrong.
6. 6Root-cause. Name the underlying cause, not the symptom the user reported.
7. 7Resolve or escalate. Fix it, route it or hand Engineering a clean repro.
8. 8Document. Leave a KB entry or runbook so the next person skips the search.

Investigate in ask mode, not agent moderesearch without write access

Cursor's modes change which tools the AI can reach. Agent mode is the full suite - it writes code, edits files, moves them, runs the terminal. Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. strips all of that out and leaves you semantic search and codebase understanding. For support work you're mostly reading the product, not changing it, so ask mode is the efficient default. Pair it with a cost-effective model and you get the same answer without burning tokens or risking an edit you didn't want.

Reproduce before you theorizethe step everyone wants to skip

An issue you can't reproduce is an issue you can only guess about. The pull is always to jump straight to a fix because you recognize the words. Resist it. A solid repro turns a vague "agent gives bad answers" into "on this 4-file repo, with this prompt, the agent ignores the open file 4 times out of 5" - and that sentence is most of the diagnosis.

One variable at a timebinary-search the problem space

When several things could be wrong, cut the space in half rather than poking at it. Bisect across whatever axis is cheapest to flip.

Symptom is not root causethe distinction interviewers listen for

The user reports "autocomplete stopped working." That's the symptom. The root cause might be a corporate proxy returning 407 on the completions endpoint. Fix the proxy allowlist and the symptom evaporates; tell the user to restart Cursor and you've treated nothing. Always carry both in your head and say both out loud.

The fastest debuggers ask four sharp questions before they open a single log. The right facts can shrink "it's broken" down to a single suspect line.

On a real ticket you can't see the user's machine. In the interview you often get a terse prompt and an interviewer playing the user. Both reward the same instinct: pull the environment and the scope out first, because they cut the most branches.

Capture the environmentthe four facts that gate everything

Establish scope and timingone user or a fleet

• One user or many? A single user points at local config; a whole org points at policy, network or a server-side change.
• When did it start? A timestamp lets you correlate against a Cursor release, a model change or an internal incident.
• What changed right before? An update, a new extension, a fresh repo, a new VPN - recent changes are the prime suspects.

Get the exact error, not a paraphraseverbatim text is data

"It says something about a network error" and "Request failed: 429 Too Many Requests" lead to completely different fixes. Ask for a screenshot or copy-paste of the literal message and the exact steps that triggered it. A paraphrase has already thrown away the part you needed.

Tag every fact: confirmed, assumed, unknownand chase the unknowns that matter

Logs are where a vague complaint becomes a specific cause. The skill isn't reading every line - it's knowing where Cursor writes the signal and which line is the first one that's actually yours.

Cursor is a VS Code fork, so it inherits VS Code's diagnostic surfaces while adding its own. Know the three places it surfaces problems and how to reach them.

macOS:    ~/Library/Application Support/Cursor/logs/
Windows:  %APPDATA%\Cursor\logs\
Linux:    ~/.config/Cursor/logs/

Read a stack trace from both endsfind the first line that's yours

Read top-down to see the frame that actually threw and bottom-up to see what triggered the chain. The line that matters is usually the first one that isn't framework or node_modules code - that's where your system meets the failure.

1. 1Find the throwing frame. The top of the trace names the error and where it was raised.
2. 2Walk down to the first non-framework line. Skip node_modules and runtime internals until you hit Cursor or extension code.
3. 3Read the message literally. ENOTFOUND, EACCES and 429 each point at a different layer - DNS, permissions, rate limiting.
4. 4Tie it to a timestamp. Match the trace time against the user's report and any server-side signal.

Network and HAR capturesfor auth, model and connectivity failures

When the failure smells like the network - sign-in loops, model errors, dropped completions - capture the requests. The DevTools Network tab (or an exported HAR) shows the status codes that name the cause.

End with a one-line root causefor an audience that isn't an engineer

Raw logs don't close a ticket. Translation does. "Your VPN is blocking the model endpoint, so completions time out" is something a user and a manager can both act on. Compress the trace into one plain sentence that names the cause and the fix.

These four scenarios cover most of what walks into a Cursor support queue. Rehearse them out loud so the loop is muscle memory before the screen, not something you assemble live.

This is the concept layer, so slow down before the drill. Name the mechanism first, then tie it to the role's daily decisions: what changes, what can fail and what proof would make a teammate trust the answer.

Each card runs the same loop and ends the same way: immediate user guidance, the root cause and whether you'd escalate. That ending is the part interviewers wait for.

Walk one all the way through“agent gives bad answers”

1. 1Clarify. "Bad" how - wrong code, ignoring files or refusing? Pin the exact behavior.
2. 2Reproduce. Same repo, same prompt, repeated. Does it fail every time or intermittently?
3. 3Isolate. Check the indexing indicator. Swap the model. Strip the repo down to the relevant files.
4. 4Hypothesize. "Indexing never finished, so retrieval returns nothing and the agent answers blind."
5. 5Test. Reindex, confirm completion, rerun the same prompt.
6. 6Root-cause. Index stalled on a large or ignored directory - symptom was "dumb agent," cause was empty context.
7. 7Resolve or escalate. If reindexing fixes it, write a KB note. If indexing stalls reproducibly, escalate with the repo and logs.

Escalation is a judgment call the role tests directly. Escalate too early and you burn Engineering's time on something you hadn't isolated; too late and a fleet-wide outage festers in your queue.

There are three exits from a ticket. Knowing which one you're taking - and being able to defend it - is the whole skill.

Script the gap, but keep it smallthe "fix now" move that isn't a feature

Customers ask for things the dashboard doesn't surface - per-user clicks per day when only the combined total exists. That's a fix-now candidate, not an escalation. Check first whether an existing API already returns it. If not, write a small script (a third-party API in the mix is fine) to gather the data, one-off or recurring. A support engineer knows the platform well enough to scope this and babysit the agent through it.

What a good escalation containsthe anatomy Engineering will thank you for

• Minimal repro - the smallest steps or repo that trigger it reliably.
• Environment - OS, Cursor version, plan, network shape.
• Expected vs actual - what should happen and what does, stated plainly.
• Logs and captures - the relevant trace or HAR, not the whole dump.
• Impact and severity - who's affected, how many and whether they're blocked.

Triage severity by impact and breadthblocking vs cosmetic, one user vs a fleet

Don't escalate before you've isolatedthe line interviewers probe

"It's broken, please look" is not an escalation - it's handing your unfinished work to a busier team. Escalate when you have a reproducible bug with a root cause that lives beyond configuration and not a step sooner. The exception is breadth: a fleet-wide outage you can't immediately isolate still escalates on impact, with the honest note that root cause is still open.

Close the loopthe step that compounds

1. 1Confirm the fix with the user, in their environment, not just in yours.
2. 2Update the KB so the next instance is self-serve instead of a fresh investigation.
3. 3Feed the signal back. If it's a recurring pattern, that's roadmap input Product wants - surface it, don't just close the ticket.