Imagine hiring someone who has already solved your biggest problem. They built the team, improved the numbers and earned the promotion. You have called a former colleague, who would happily work with them again. For once, the hiring decision feels easy.

Then they arrive. The plan requires a data team you don't have, a brand customers already trust and permission to hire six people. Their previous success was real. You bought it without understanding what made it possible.

This is the difficulty with hiring for a startup: you want evidence that someone can do the work, but the best evidence usually comes from somewhere else. A track record tells you what happened under a particular set of conditions. You still need to find out how the person thinks when those conditions disappear.

That tension runs through the hiring playbook published by QuantumLight, the venture firm founded by Revolut co-founder Nik Storonsky. Its [case for potential over experience](https://quantumlightcapital.com/playbooks/hiring/scale-up-ready-profiles) comes from the difficulty of hiring experienced executives into a rapidly changing company. Its [interview process](https://quantumlightcapital.com/playbooks/hiring/three-interviews-for-success) examines problem solving and past achievement separately. That separation is useful: a good career story should not answer a question about how someone will handle work they have never done.

## Put the unfamiliar work in the room

First-principles thinking is easy to claim. In an interview, it should mean something observable: working out what is true about a problem, which assumptions need checking and what to do next. You need to watch the candidate make those judgments.

QuantumLight uses an onboarding problem as one example in its problem-solving interview. Build a case like that around work the role will actually involve. Suppose customers are abandoning signup before completing identity checks. Ask the candidate how they would investigate and improve the process.

The opening answer matters less than the questions that follow. Where do customers leave? Does it vary by device or customer group? How long does a check take? Is the delay caused by missing documents, a technical failure or a queue? A candidate who asks for those facts gives you something to evaluate before recommending a redesign or more staff.

Now change a condition. In this illustrative case, tell them that a new compliance requirement will put 30% of applicants through a manual document check, and hiring is frozen. Their first plan may no longer work. Give them time to reconsider it.

Watch which parts they keep and which they abandon. Someone who proposed removing friction now has to distinguish avoidable friction from a required check. Someone who wanted more reviewers has to consider routing, queue priorities or clearer document instructions. Ask what they would test first and what result would make them change course again.

This changing constraint is a case design we recommend, rather than an established test with demonstrated predictive validity. Use the same starting facts, data and change for every candidate for the role. Tell them beforehand that the case will evolve and explain what you will assess. Surprise is not the skill you are hiring for.

Write down observations against five criteria: how they break down the problem, which data they request, how much prompting they need, how they adapt and how they weigh the proposed solution's trade-offs. Our guide to [structured interview scorecards](/blog/structured-interview-scorecards-predictive-validity) covers how to turn those observations into consistent ratings. A note such as “rechecked queue capacity after the new requirement” will help the hiring discussion more than “very strategic.”

## Find out what made the past result possible

After seeing the candidate reason through unfamiliar work, return to the achievements that got them into the room. The case gives you a fresh basis for listening. You can now ask whether their account of past work shows the same care with assumptions, evidence and trade-offs.

Consider a fictional sales candidate who finished second among 14 account executives. That sounds like a useful comparison. It becomes more useful when you learn that all 14 worked in the same segment under the same quota model, during the same year. It becomes less straightforward when the candidate mentions an inherited territory and a sales engineer who joined every important call.

Those details do not erase the achievement. They tell you what to investigate. Which deals did the candidate originate? What did they do when a sale stalled? How much of the result came from renewals? Would the approach work with your pricing, your product and your level of support?

The same questions apply to engineering and operations. A migration completed on time may reflect excellent judgment, a generous staffing budget or both. Ask the candidate to reconstruct the decisions they owned, the help they had and the conditions they would need to repeat the result. You can do this without asking for a former employer's confidential dashboards, customer records or code.

There is research behind taking context seriously. [Groysberg, Lee and Nanda's study of star securities analysts](https://doi.org/10.1287/mnsc.1070.0809) found that performance declined after employer moves, especially when analysts moved alone or to firms with weaker capabilities. Analysts who moved with their teams, or to stronger firms, did not show the same significant decline. The study concerns analysts, so it cannot tell you how a particular startup hire will perform. It does give you a reason to ask what support helped produce the result.

Take that question into references. With the candidate's consent, speak to someone who saw the work and ask about their contribution, the comparison group and the support around them. “Would you hire them again?” opens a conversation. “What would they need here to repeat that result?” gets closer to the decision you face. A referee's account adds evidence; it does not settle the question for you.

## Look past the speed of the career

Once you start asking what produced an achievement, promotion speed becomes harder to read. A fast rise may reflect unusual ability. It also reflects who received opportunities, whose work was visible and how a manager judged potential.

In [research on management-track employees at a large retail chain](https://www.aeaweb.org/articles?id=10.1257/aer.20220831), Benson, Li and Shue found that women received lower potential ratings despite higher performance ratings, and subsequently outperformed male colleagues. That finding comes from one employer, but it exposes a problem with treating someone else's promotion decisions as your own assessment of talent.

Ask what responsibilities grew, what the candidate learned and what they accomplished with the opportunities available. A person who improved a difficult system without a new title may have stronger evidence than someone promoted twice during a hiring boom.

Assess the work without using age, university prestige or an uninterrupted career as shortcuts. A career break does not tell you how well someone performed while working. For an early-career candidate, examine a relevant project and give the case more weight. For an experienced candidate whose work has no meaningful peer ranking, reconstruct the work itself. Inventing a percentile would only make the comparison look more precise than it is.

## Keep the two judgments separate

By now you should have two accounts of the candidate: how they approached your case, and what you could establish about their past work. Keep them separate long enough to see where they disagree.

An impressive track record with weak case reasoning leaves a question about adaptability. Strong case reasoning with little comparable experience leaves a question about delivery. Each calls for a different follow-up. Combining them immediately into “strong candidate” loses the distinction you spent the interviews trying to uncover.

Have interviewers submit their observations and ratings before reading colleagues' reviews or discussing the candidate. In the [hiring debrief](/blog/interview-debrief-decision-meeting-groupthink), start with disagreements and missing evidence. If a result remains unverified, record that uncertainty. Do not quietly score it as either a success or a failure.

The person making the decision should explain why the evidence is enough for this role. They may reasonably accept a delivery risk because the candidate has shown how they learn, or reject a celebrated candidate because the job requires support the company cannot provide. A written reason makes that judgment available to the people who will onboard and manage the hire.

## Leave a record the team can use

In Kit, you can run the case and the achievement discussion as Live Interview stages, then collect each set of ratings in a separate Team Review stage. Scoring criteria belong on Team Review rather than Live Interview stages, and voting is blind by default. The [reviews and feedback guide](/docs/reviews-and-feedback) explains how the team records its assessment.

Use the [Reference Check stage](/docs/running-reference-checks) for the standard reference questions, with a separate conversation for the context you still need. Its peer-ranking prompt uses the referee's own comparison group and cannot be customized to match the group discussed in your interview. Your team still has to establish what the achievement means.

Return to the hire at the start. Before making the offer, you would want to know that their plan needs six people, and hear what they would do with two. That answer gives you something useful to decide on, discuss before they join and revisit when the work begins.