Problem Solving Score: What It Measures and How to Raise It

Problem Solving is the score most likely to surprise candidates who are used to being judged on outcomes. In most of our professional lives, results are what get noticed — the project shipped, the bug got fixed, the client stayed. But an interview transcript can't observe a result; it can only observe how you talk about getting there. That's exactly what this score is measuring, and it's why a great outcome, described thinly, can still score lower than a modest outcome described with real reasoning behind it.

What this score is actually checking

It tracks how you approach ambiguous situations and reason through challenges — your process, not your conclusion. The interview questions in this category are deliberately open-ended and often deliberately underspecified, because the gap you fill in with assumptions and reasoning is exactly what's being evaluated. A confident, correct-sounding answer with no visible reasoning behind it doesn't actually demonstrate problem-solving — it demonstrates that you can state a conclusion.

Where candidates lose points

• Jumping straight to a conclusion ("I just figured it out" or "it worked out fine") without narrating what happened between the problem and the solution.
• Describing the problem in detail but glossing over what you actually did about it — the analyst is left inferring your process rather than reading it.
• Reaching for a clean, hypothetical, textbook-style example instead of a real one with a real constraint — deadline pressure, limited information, conflicting priorities — because tidy examples tend to skip the messy reasoning that this score is built to reward.

How to raise it

• Narrate your thinking, not just your outcome. "Here's how I broke the problem down" carries more weight than "and it worked out fine" — even when the outcome is genuinely the more impressive part of the story.
• When a question is ambiguous — and many of them are on purpose — say what assumptions you're making and why before you answer. That's the exact muscle this score exists to test.
• Anchor your example to a real constraint. A story about solving a problem with a hard deadline, incomplete information, or competing priorities gives you far more reasoning to show than a clean, idealized scenario does.
• If your first approach didn't work, say so. Describing a wrong turn and how you corrected it demonstrates more problem-solving than a story where everything worked on the first try.

A quick before-and-after

Consider a question about handling incomplete information. A thin answer: "I made my best guess based on what I knew and moved forward, and it turned out okay." A strong answer: what specifically was missing, what you assumed and why that assumption was reasonable given what you did know, what you did to reduce the risk of being wrong (a quick check-in, a smaller first step, a fallback plan), and what you'd do differently if you hit the same gap again. The strong version isn't a longer story for its own sake — every added sentence is doing the specific job of showing reasoning the analyst can actually evaluate.

It's fine to describe a wrong turn

A pattern we see often: candidates instinctively edit out any part of the story where their first instinct was wrong, worried it makes them look less capable. It's the opposite. An answer that shows you noticed something wasn't working and adjusted demonstrates real-time reasoning — which is precisely what this score rewards. A story that goes smoothly from problem to solution with no friction in between often reads as under-detailed rather than impressive.

This score rewards your reasoning, not your results. A messy real example with visible thinking beats a clean, tidy one every time.

It's fine if your first instinct wasn't the final answer

One more thing worth saying directly: this score isn't checking whether you got it right on the first try. It's checking whether you can reason your way toward a good outcome, including when that means revising course partway through. If your actual process involved trying one approach, noticing it wasn't working, and switching to another, that full arc is more valuable to describe than a cleaned-up version where you present only the approach that ultimately worked, as if you'd known it all along.

When there wasn't a clean resolution

Not every real problem-solving story ends in a clear win, and candidates sometimes avoid these examples on the assumption they'll score worse than a tidy success story. Usually the opposite is true. A situation where you had to make a genuine tradeoff — accepting a smaller downside to avoid a bigger one, or making the least-bad call among a few imperfect options — often shows more real reasoning than a story where everything simply worked out. Naming the tradeoff explicitly, and why you accepted it, is itself strong evidence of judgment.

The good news is that this, like Communication, is a habit more than a fixed skill — most candidates already reason well under pressure in their actual work, they just don't narrate that reasoning out loud when asked to describe it afterward. Practicing that narration, out loud or in writing, before your next attempt is the single most direct way to move this number.