Reimagining the Candidate Report

What was already breaking before you started?

Not the data — there was plenty of it. What the old report never gave a recruiter was an answer to the one question they opened it for: should this person move forward?

HackerRank's flagship product, Screen, exists to help companies evaluate coding skill at volume — the kind of volume where a single role draws hundreds of applicants. Evaluation sits near the end of that journey: it's the moment the customer finally gets the thing they came for, a confident hiring call. Get it right and the whole product feels like it delivered. Get it wrong and everything upstream was wasted. That made the report quietly central to retention, not a side screen.

When I picked up Candidate Reports in 2020, the experience was a long, information-heavy page built around scores and question- level detail. It held a lot of data. That was never the problem.

The problem was meaning. Recruiters and hiring managers had to dig through the detail themselves to work out what the results were telling them — and whether a candidate was worth moving forward. There was no narrative around performance. No quick way to see a strength, spot a weakness, or compare two people with any confidence.

There were two reports: a summary meant for a fast read, and a detailed one for the full dig. This phase focused on the summary — the screen a recruiter opens first, and the one carrying the most weight on the decision. It answered questions nobody was asking, and stayed quiet on the one that mattered.

One report, three people it let down

This wasn't a readability tidy-up. Every extra minute of interpretation slowed hiring, made two reviewers less consistent, and risked passing on good people. So before designing anything, I went to find out what that one question actually was.

What did you actually own here?

One report, one recruiter's question — and one honest boundary. I drove this to handoff, not to launch.

I was the Lead Product Designer and sole design owner, driving the redesign end-to-end through 2020–2021 — discovery, information architecture, interaction design, wireframes, high-fidelity design, and prototyping. I'm deliberate about where that ownership stops: this phase ended at handoff. I never watched it ship, and I claim none of the outcomes of the version that launched publicly in 2023. What I can stand behind is the reframe, the architecture, and the thinking underneath both.

The work didn't run in a straight line, but the order held: understand before defining, define before drawing, draw before polishing.

Before drawing anything, I set out what success would have to look like — the targets every later decision got measured against

Those targets came out of a reframe I'll get to shortly. But first, the rules that reframe forced onto every screen. They're the lens to read the rest of this against.

What rules did every decision have to pass?

I didn’t write these down at the time. But the same handful of principles kept deciding the hard calls.

I didn't formalise these as a list at the time. They emerged from the reframe — once the report became a recommendation rather than a record, the same handful of rules kept deciding things for me, and every screen in this case study traces back to one of them.

The rules were clear. What I didn't have yet was the recruiter's own words about where the old report actually failed. So I went and listened.

How did you learn what both sides actually needed?

The first real work was listening. Not a formal study — the practical, in-the-room understanding a lead builds by talking to the people who live in the thing every day.

To understand what was really broken in the report, I gathered inputs from the people closest to the workflow — the recruiters and hiring managers using it daily, the internal teams who saw patterns across many accounts, and the existing report itself. Three sources, each answering a different question.

Recruiter & HM feedback

The heaviest input came from the recruiters and hiring managers actually opening these reports every day. I asked what they looked for first, what they scrolled past, and where the report left them stuck. Ask any of them, and the same theme came back again and again:

"I can see the score — but I still don't know what this candidate is actually good at, or whether I should move them to the next stage."

Under every complaint was the same unspoken question they were really asking the report: is this person worth my time? A few themes repeated:

Product & CS partners

The daily-user feedback told me what individual recruiters felt. What it couldn't tell me was which frustrations were universal and which were local to one account. Working sessions with PMs and customer-facing teams filled that gap — they carried patterns from across many accounts and could tell me when a complaint I'd heard once was really a complaint I was about to hear a hundred times.

Existing-report review

Alongside the conversations, I studied how the current report was actually used and misused — which widgets earned attention, which got scrolled past, and where the timeline and integrity signals were missed. The least glamorous input, and one of the most useful: it's the only place where the design's own failures leave a paper trail.

None of it went to waste. It's why Candidate Details — feedback, past attempts, identity metadata — ended up last in the final report: useful, but never where a decision gets made.

These were the qualitative findings I designed against in 2020–2021 — the problem, not the result. This phase predates launch, so the case study reports no adoption or outcome metrics; those belong to the version shipped after handoff.

What I heard across all these conversations kept pointing at one thing. The report was answering the wrong question.

So what was the big reframe?

A report isn't a record — it's a recommendation.

The core decision was a shift in what the report was for. It had been a record — a faithful account of everything the assessment captured. I decided it needed to become a decision-support experience: something that led a recruiter toward a judgment instead of leaving them to assemble one.

I explored different ways of reorganizing the report, but they all started with data rather than the recruiter's objective. The turning point came when I reframed the experience around the recruiter's first question: should this candidate move forward? Once I focused on that decision, the hierarchy became clear — the verdict became the entry point, while scores, competency breakdowns, and supporting insights became evidence that built confidence in it.

A report isn't a record of what happened. It's a recommendation about what to do next.

Let me state the problem plainly, because the reframe only matters against it:

Evaluators lacked a quick, confident way to understand candidate performance. Risking longer evaluation cycles and slower hiring. "Risking" is deliberate — this phase predated launch, so the impact is the problem I was designing against, not a measured outcome.

I framed the reframe as a single How Might We to keep a wide stakeholder set — product, CS, sales, engineering, data — honest about whose problem this actually was:

That reframe changed every downstream choice. Instead of one continuous wall of information, the experience would be organized into sections that each answered a real hiring question — surfacing the verdict first, then letting the recruiter drill into evidence only when they wanted it.

The same shift, in pixels. The verdict sits where the old report buried it deepest — right at the top, before a single question result.

A reframe is only real if you know who it's for. Two people kept showing up.

Who were you actually designing for?

Two people, in practice: the recruiter who needed speed, and the hiring manager who needed depth. The report served a wider set of stakeholders, but everything led back to these two.

Understanding who I was designing for wasn't just about building personas — it was about holding two conflicting sets of needs on the same screen and finding a way to serve both without asking either to do the other's work.

The two archetypes

The tension was real. Recruiters wanted speed. Hiring managers wanted depth. Every design decision had to hold both — without asking either to do the other's work. That constraint became a creative forcing function.

With a clear picture of who I was designing for, I could see where the report actually broke down for them. That meant tracing the full arc — from assessment to hire.

Where did the journey actually break down?

At the hinge point — the moment everything upstream either pays off or gets wasted. The report wasn't the whole story; it was one moment in a longer arc from assessment to hire.

Mapping that arc showed why the report carried so much weight: it's the hinge the entire decision turns on.

Seeing it laid out made the stakes plain: a slow or unclear report doesn't just cost a few minutes at step three — it stalls everything downstream and risks losing strong candidates between stages. To see exactly how it failed, I traced the path a recruiter actually walked to reach a decision.

Same destination, very different journey. The before path made the recruiter do the report's job: gather, infer, cross-check, and only then decide. The after path front-loads the verdict and lets everything else become optional depth — with integrity signals surfaced rather than hunted for.

The screen that hinge point produces. Activity and proctoring evidence a recruiter can pull without leaving the report — reachable exactly at the moment this journey stage puts the most weight on them.

Which meant the report couldn't just be reorganized. It had to be rebuilt around the questions a recruiter asks. So I structured it around them.

How did you get from sketch to screen?

Structure first, then grey, then polish. I built the information architecture around the questions a recruiter moves through — then proved it in greyboxes before a single pixel earned colour.

I built the IA around the questions a recruiter asks when they evaluate someone, ordered the way a real decision unfolds — from snapshot to scrutiny. Each section existed to answer exactly one of them.

Ordering these five was itself a prioritization call. Overall Summary, Skill Insights, and integrity signals were non-negotiable — a recruiter couldn't make a confident decision without them, so they earned the surface. Comparison views, benchmarks, and recommendations were real wants, but they were depth, not the verdict, so they stayed candidates for later rather than first-screen weight.

Grey before polish A structure on paper is a hypothesis; I had to draw it before I could test it. I started rough on purpose. The earliest explorations weren't about visual polish — they were about pinning down what earned a place at the top and how the integrity signals should be handled. A wireframe alongside a PRD does what a PRD alone can't: it gives product and engineering a shared thing to react to, and surfaces disagreement early, while it's still cheap to change.

At wireframe fidelity I was testing one thing above all: did the snapshot hold? Could a recruiter land on the report and reach a verdict before deciding whether to go deeper — without a single label or styled component to lean on? Greyboxes are honest that way. If the structure works in grey, it works.

Once the grey structure held, I could let it become something a person would actually want to read. Here's what shipped-ready looked like.

What did it actually look like?

Three views, one report, verdict always first. With the structure proven in grey, high fidelity was where the principle became a surface.

The verdict moved to the top and earned visual weight. Skill-level insights read at a glance instead of after a scroll. And the integrity signals got the treatment they needed: present, unmissable when they mattered, quiet when they didn't. I brought the report onto the latest design system — not as decoration, but because a cleaner, more consistent visual language did real work for legibility and made "verdict first, detail later" easier to read at a glance.

The work resolved into three views, each answering a different question without making the recruiter leave the report.

FYI: One honest boundary on the screens below. The structure, hierarchy, and decisions are mine from this phase — but the visuals reflect the design as it was later

refined, so what you're seeing is the direction I set, not a frozen 2020–2021 snapshot. The annotations are mine, added for this case study. I've kept the framing accurate rather than dress these up as untouched originals.

Performance — the verdict-first view

Verdict header Integrity flag Score distribution Question breakdown

Score, integrity activity, and question-level detail — but ordered so the verdict reads first and everything else is read through it.

Attempt Activity — footprints and proctoring

Time taken Proctoring evidence Activity timeline Plagiarism filter

The candidate's footprints through the test, in question order — plus proctoring evidence when it's enabled. Integrity kept next to the behaviour it explains.

Candidate Details — reference, last

Past attempts Feedback rating Identity metadata

The basic metadata — placed last on purpose, because it's reference, not the decision.

What I resolved before handoff

None of the core components were built as one-offs. They were designed as reusable patterns, meant to hold up for whatever report HackerRank built next.

A clean happy path is the easy part. The real test was everything that could go wrong inside a report. That's where most of the real judgment lived.

What about when the data isn't clean?

A report is only trustworthy if it holds up when the data is ugly. Most of the design judgment lived here — in the states a polished mockup never shows.

I designed the structure to stay legible and honest across the cases that actually break reports:

None of it came easily. The hardest calls weren't visual at all. They were about what not to show.

What was the hardest part?

Choosing what not to show upfront. My instinct as a designer was to preserve every useful piece of information — but surfacing everything equally just recreated the original problem in a new skin.

The trade-off was between completeness and clarity. I deliberately prioritized the hiring verdict and the strongest supporting evidence, while moving deeper detail into progressive disclosure. The goal was never to remove information; it was to reveal it at the moment it became useful. That tension ran through every review: some stakeholders wanted every metric on the surface, nothing hidden — others wanted the simplest possible read. Both were right about something, and a report that ignored either would fail.

One of the biggest challenges wasn't the interface at all — it was working within the structure of the available assessment data. While exploring richer hiring insights, I realized the report couldn't surface every level of detail I wanted without significantly increasing complexity and development effort. Rather than delay the redesign or overwhelm recruiters, I focused on improving the hierarchy of the data already available: surface the hiring decision immediately, let recruiters explore supporting evidence only when needed.

Integrity signals were their own tension. A plagiarism flag had to be loud enough that no recruiter could scroll past it — that signal should change a decision. But lean on it too hard and the report starts shouting suspicion at every candidate, which erodes trust in the flag itself. The job was to make integrity unmissable when it mattered and invisible when it didn't.

So I treated "verdict first, detail on demand" as the resolution rather than a slogan: the simple read lived at the top for the people who wanted speed, the full depth stayed one layer down for the people who wanted everything. Getting that balance right took real back-and-forth — holding the line against the pull to surface everything, without losing the depth the report genuinely needed.

Early on, I made a mistake worth naming: I spent too long figuring out how to organize the existing information, instead of questioning whether all of it needed equal prominence in the first place. That shifted once I reframed the problem around decision- making rather than information presentation — a reminder to challenge the problem statement before investing heavily in the solution.

A design is only as good as the question it's measured against. So before handoff, I was clear on what success would have to mean — and honest that I'd never watch it arrive.

What did this build in me?

I built something I never watched launch — and learned that the thinking, not the pixels, was the real deliverable.

This phase ended at handoff, so I'm not claiming numbers — I never watched it ship. But I designed against a clear definition of success, and naming it kept every decision pointed the same way. It resolved to a single north star — not a metric, but the thing any metric would have to serve:

Reduce the effort it takes a recruiter to reach a confident hiring decision.

If I'd carried this to launch, that's the line I'd have instrumented against — effort down, confidence up, integrity signals seen when they mattered. Not engagement for its own sake, and not speed at the cost of a wrong call. The point was never a faster click. It was a surer one.

What I actually handed off

As Lead Product Designer I drove this end-to-end through 2020–2021 — discovery, IA, interaction design, wireframes, high-fidelity design, and prototyping. The handoff was more than screens: I documented the information hierarchy, the interaction behaviour behind progressive disclosure, component states, and edge cases, so the intent behind the design stayed clear during implementation. And rather than present the redesign as a visual improvement, I framed every discussion around recruiter decision-making — which made it easier to align product and engineering around the hierarchy, even where opinions on surface details differed.

I built something I never watched launch.The thinking was the deliverable — and the thinking held.

I never saw it ship. The foundations established in this phase were later evolved by the team into the Candidate Reports experience that became publicly available in 2023. I'm deliberate about that boundary: this case study is about the design process and decisions of the 2020–2021 phase, and it doesn't claim the outcomes or enhancements introduced after handoff — those belong to the people who carried it forward.

What I Learned

I learned to design around a decision, not a data set: Before this project, I believed the quality of an enterprise product came from presenting complete and accurate information. This changed that. Users weren't opening the report to understand every metric — they were opening it to make a hiring decision. I now begin enterprise projects by identifying the primary decision a user needs to make, then structure the experience around supporting it.

I learned to hold two opposing needs on one screen: The recruiter wanted speed; the hiring manager wanted depth. I couldn't pick a favourite. Designing for both — verdict first, depth one layer down — without sacrificing either became the most useful muscle I built here.

I learned to challenge the problem before solving it: My early mistake — organizing the existing information instead of questioning its prominence — taught me to interrogate the problem statement first. The reframe from "present the data" to "support the decision" was worth more than any layout I drew.

I learned to own the thinking, even without the launch: I never saw this ship, and I don't claim its shipped outcomes. What I can stand behind is the reframe, the architecture, and the principle underneath both — and the discipline of drawing a clear, honest line around exactly that.

Completeness still matters, but only after clarity. A report should hand a recruiter a decision, not just a record — and that idea now starts every enterprise project I take on.

That's what it built in me. And it's what I bring to every problem now.