Discovery & Customer Craft

A customer engineer will hand you a problem statement. It is almost never the real problem. Your first job as a Forward Deployed Engineer is to find the bottleneck they can't see, then prove you found it before you propose a single line of work.

The stated ask is a symptom that already passed through a manager, a planning doc and someone's pet theory. "We want Cursor to auto-review PRs" might really mean review takes four days because two staff engineers are the only approvers and they're underwater. Auto-review the wrong way and you've added noise to a queue that was already the constraint.

Questions that surface the bottleneckdiscovery toolkit

Good discovery questions force concreteness. Vague answers hide the constraint, so you trade abstractions for numbers and last-week examples.

Map the inputs before you map the solution

Discovery isn't only about pain. You also have to know what you'll actually be allowed to touch, because that constrains every design you'll later propose.

Earning credibility fast

Senior engineers gate-keep their codebase. They've watched consultants parachute in with confident nonsense and they'll test you in the first ten minutes. You earn the right to ask hard questions by demonstrating you already understand their world.

• Read the repo before the call. Reference a real file or pattern - "I saw your migrations run through a custom script, not the framework's" - and they relax.
• Use their vocabulary, not vendor vocabulary. Say "flaky test quarantine," not "quality enablement."
• Admit the limits of an AI agent honestly and early. Over-promising on the first call is how you lose the room for the rest of the engagement.
• Show, don't claim. One small, correct edit live in their editor beats a deck about capability.

The decomposition round hands you a deliberately under-specified enterprise problem and grades how you scope it, not whether you solve it. There is a repeatable method and running it visibly is the whole point.

A representative prompt: "A customer has a 1M-line monolith on a deprecated framework and wants off it. Where do you start?" The candidate who starts describing a codemod has lost. The one who runs the five steps below, out loud, has won before they write any code.

1. 1Clarify the goal. Restate the problem in your words and confirm the real objective. Is the win getting off the deprecated framework or is it stopping the security CVEs that framework keeps generating? Those lead to different work.
2. 2Identify stakeholders and metrics. Name who owns the code, who approves the migration and who feels the pain. Pin a success metric you both agree on: "95% of files migrated with green CI and zero behavior regressions."
3. 3Map the inputs. What's the framework boundary, the test coverage, the CI setup, the code access? Coverage especially decides whether you can move fast or have to build a safety net first.
4. 4Decompose into subproblems. Break the monolith migration into independently shippable slices: detect usages, transform one module, verify, roll out. Each slice has its own risk and value.
5. 5Propose a walking-skeleton MVP, then iterate. Pick the thinnest slice that proves the whole pipeline works end-to-end, ship it, learn and expand. Make explicit that this is iteration one, not the finished system.

Sequence subproblems by risk and value

Not all subproblems deserve equal attention up front. Once you've decomposed, order the work so the scariest unknown gets tested first. If the riskiest piece is going to fail, you want to know in week one, not month three.

A walking skeleton is a version that touches every stage of the pipeline and does almost nothing well. It's ugly, it's narrow and it's live in days. That's the point.

Most engineers build depth-first: a beautiful transform engine, then weeks later the plumbing to actually run it. An FDE builds breadth-first. You wire input to output through every real step on a single trivial case, prove the path exists, then thicken each stage. A working sliver in three days creates a feedback loop that no design doc can.

Why days, not weeks

Speed isn't about looking productive. A thin slice running on the customer's own code does two things a polished v2 can't: it surfaces the wrong assumptions early and it earns the trust that buys you room for the hard parts.

1. 1Pick one real case. Not a toy - the simplest actual instance from their repo. One file, one PR, one incident.
2. 2Wire the whole path. Input, the model call, verification, output back where they'd consume it. Stub anything deep.
3. 3Run it in front of them. Live, on their code, in their editor or CI. Let them see it work and fail.
4. 4Thicken the riskiest stage next. Use what broke to decide where depth goes first.

Deferring to v2 without sounding like you're cutting corners

Saying "we'll handle that later" sounds like dodging. Tying every deferral to the agreed success metric makes it sound like judgment, because it is.

Tie the MVP to the metric and the first version is already measurable. If the agreed target was "95% of files migrated with green CI," then v1 reports its own number against that target on day one. A walking skeleton that can't tell you whether it's working isn't a skeleton - it's a guess.

The client-simulation round puts you across from a frustrated senior engineer - sometimes a real one, sometimes the interviewer playing one. The eval isn't whether you have the answer. It's whether they'd want you back in their codebase next quarter.

Cursor's culture is truth-seeking, which in a customer conversation means you name the real problem and the real risk, including bad news, without flinching. The skill is delivering hard truths in a way that preserves the relationship rather than detonating it.

Deliver bad news with a path forward

Never hand a customer a problem and stop. A problem with no options is an excuse. A problem with two options and a recommendation is leadership.

De-escalate with diagnosis, not defense

When a senior engineer is angry, the instinct is to defend the work. Resist it. Defensiveness confirms their fear that you don't get it. Diagnostic questions do the opposite: they show you're treating their frustration as data.

1. 1Acknowledge the cost to them, specifically. "You've lost two days to this and you're getting heat from your VP - that's on me to fix."
2. 2Ask, don't justify. "Walk me through exactly what broke and when - I want to see what you're seeing."
3. 3Take ownership in the first person. "I'll own getting this unblocked. Here's what I'm doing in the next 24 hours."
4. 4Close the loop. Come back with the fix and the metric, so the next conversation starts from trust.

Hold a technical boundary

Sometimes the customer wants something unsafe - auto-merge without review, an agent with write access to production, skipping the eval gate to hit a date. Saying yes to keep them happy is how you lose the account when it breaks. You hold the line and explain the why in their terms.

The goal of the whole conversation is one thing: a customer who adopts your workflow and trusts you with the next one. Winning the argument and losing the relationship is a loss.

The system-design round gives you an AI workflow and a hostile environment: SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool., data residency, legacy systems, an security team that says no by default. They grade your reasoning out loud, not a single correct diagram.

Take a concrete brief: "design automated PR review for a bank with 3,000 engineers, self-hosted everything, SOC 2, no source code may leave their VPC." The naive answer wires a model to a webhook. The strong answer treats trust boundaries, observability and rollback as load-bearing from the first sketch.

The constraint checklistraise these before they have to

Skeleton first, then harden

Even in system design, scope a walking skeleton before you describe the production system. It shows the same instinct from the build onsite and keeps the design honest about sequencing.

1. 1Skeleton. One repo, one team, model in-VPC, agent comments on a PR, human approves. End-to-end, flagged off for everyone else.
2. 2Instrument. Add tracing and the eval set against that one team's history before widening. Prove quality with numbers, not vibes.
3. 3Harden. SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool.-scoped identity, rate limits and retries with backpressure, per-failure fallbacks, cost budgets per call.
4. 4Roll out. Flag on team by team, watch the eval gate and the metrics, keep the one-switch rollback live the whole way.

Integrate with the legacy stack honestly

Enterprises don't run greenfield. There'll be a 12-year-old CI server, a custom code-review tool, secrets in a vault three teams don't fully understand. Pretending otherwise loses credibility instantly.