Leading technical direction on R&D work
The question behind “have you led technical direction” is not whether you had the title. It is whether you can run work where the outcome is genuinely unknown without either burning six months or quietly delivering nothing.
R&D-heavy work — a CV pipeline that may not reach the accuracy the product needs, an agent that may not be reliable enough to ship — breaks the normal delivery playbook, because you cannot estimate what you have not yet learned. What replaces estimation is the interesting part.
What makes R&D different
| Normal delivery | R&D-heavy |
|---|---|
| Scope known, effort unknown | both unknown |
| Estimate then build | buy information |
| Progress is features | progress is uncertainty removed |
| Failure is late | failure can be correct |
The reframe worth saying out loud: the unit of progress is a resolved uncertainty, not a completed feature. A week that ends with “this approach cannot reach 95% and here is the evidence” is a successful week, and a leader’s job is to make that a reportable outcome rather than a confession.
Running it
Order the work by information gained per day, not by dependency. The riskiest assumption goes first even when it is not the first thing you would build. If the whole product depends on reading a scale bar reliably, spend two days on scale bars before designing anything else.
Timebox and pre-commit the decision. Before starting a spike, write down what result would mean continue, what would mean pivot, and what would mean stop. Deciding afterwards means deciding with sunk cost in the room.
## Spike: can we hit 95% recall on door symbols?
Timebox 5 days
Continue >= 92% on the held-out set, one architecture
Pivot 80-92%, or only with per-customer tuning
Stop < 80% - revisit whether detection is the right framing
Owner <name> Decision date <date>Set a baseline in the first week. Something dumb that works — a threshold, a heuristic, an off-the-shelf model with no tuning. Without it, the team cannot tell whether three weeks of work helped, and stakeholders cannot tell either.
Separate the research repo from the product repo, and define the handover. Notebooks are correct for exploration and wrong for production. State what “done” means: a pinned model, a shared preprocessing function, an eval on a frozen set, and a serving contract. See CV pipelines and designing for imperfect input.
Communicating uncertainty upward
The failure mode is a leader who reports either false confidence or nothing. Both destroy trust, and the second is more common because the first at least sounds like progress.
What works is reporting a range with the evidence and the next decision point: “current best is 88% on the held-out set, the gap is small symbols, we will know by Thursday whether tiling closes it, and if it does not the fallback is human review on low-confidence pages.” That gives a stakeholder three things — a number, a plan, and a date — without pretending to certainty you do not have.
Say what would change your mind. A leader who has pre-specified what would make them abandon their own approach is much easier to trust than one who has not.
Deciding when to stop
The hardest part, and the most interview-relevant.
- Diminishing returns are measurable. Plot the metric against effort. Three weeks for two points, when the product needs ten, is an answer.
- Reframe before abandoning. Often the model cannot hit 95% but the product does not need 95% — it needs 80% plus a confidence signal and a human review queue. That reframing is usually the actual solution, and proposing it is a senior move rather than a defeat.
- Sunk cost is the enemy. The question is what the next month buys, not what the last three cost.
- Write the negative result down. “We tried X, here is why it did not work” saves the next person, including future you, from repeating it. This is the single most valuable artifact of failed R&D and almost nobody produces it.
The story to prepare
Structure it as in What was the most challenging part of a recent project?, weighted toward the decisions:
- Context: what was uncertain, and what depended on it.
- How you reduced uncertainty: what you did first and why that order.
- A decision you made with incomplete information, and what would have changed it.
- The outcome, with numbers — including the ones that did not work.
- What you would do differently, which for R&D is usually “kill the second approach two weeks earlier”.
Prepare one where the answer was “this does not work, here is what we did instead”. Candidates almost always bring successes, and a well-handled negative result is rarer and reads as more senior.
Related
Interview angle 4
- “How do you plan work when you don’t know if it’s possible?” - you do not estimate it, you buy information. Order spikes by uncertainty removed per day, timebox each with continue/pivot/stop criteria written before you start, and set a dumb baseline in week one so you can tell whether anything helped.
- “Tell me about a project that didn’t work.” - pick one where you stopped it deliberately. Give the evidence that made the call, the reframe you proposed instead, and the negative result you wrote down. Follow-up: how did you know it was time? Metric against effort, plus what the product actually needed rather than what you were aiming at.
- “How do you report progress on research?” - a range with evidence and the next decision point: current number, what the gap is, when you will know more, and what the fallback is. Plus what would change your mind.
- “The model can’t hit the accuracy the product needs.” - check whether the product needs it. Usually the answer is a lower threshold plus a confidence signal and a human review queue, which ships. Proposing that reframe is the senior move.