Building Developer Skill Certification

What was already breaking before you started?

Everyone online had learned to read a badge. For developers, it was saying the wrong thing.

2018. Somewhere on LinkedIn, a badge is lighting up on a stranger’s profile — a course finished, a workshop attended. Udemy and Coursera have already built businesses on that same small thrill: finish the thing, wear the proof. A badge has quietly become a language everyone online has learned to speak, and to read as this person can be trusted to do the thing.

Except for developers, it was saying the wrong thing. Most of what passed for a credential proved someone had watched a course — not that they could sit down and write code that actually worked. The one signal recruiters needed most was the one signal nobody was verifying.

I kept coming back to a number I couldn’t ignore: 28 million developers were already on HackerRank, proving real skill every single day, on problems that mattered. The evidence already existed. It just wasn’t being turned into anything a recruiter could trust at a glance. The missing piece wasn’t capability — it was certification, one step away from a platform that could legitimately issue it.

Not another badge — the one credential a developer could genuinely earn, and a recruiter could genuinely believe.

That was the system I set out to build, end-to-end, from the first pitch to the day it shipped.

What was hiring actually getting wrong?

Picture two résumés side by side. One belongs to a self-taught engineer who has spent three years quietly shipping real things nobody assigned him. The other belongs to a computer-science graduate from a name everyone recognizes. On paper, they read almost identically — and paper always tips toward the name you already trust. That was hiring in 2018: résumés, GPAs, school names, blunt proxies standing in for the one question anyone actually cared about. Can this person do the work?

The self-taught engineer rarely got to answer that question; his best work simply wasn’t legible to someone skimming for familiar names. The recruiter on the other side wasn’t off the hook either — every skill claimed on a résumé still had to be re-proven from zero, through take-homes and interviews that ate hours and still left a nagging doubt at the end of them.

Two sides, stuck on the same broken signal. One couldn’t prove skill; the other couldn’t trust the claim. The gap between them was where good matches quietly died.

The gap was obvious once I saw it. What wasn’t obvious was who had to be convinced first. That’s where the real work started — with the brief nobody wrote.

What did you actually own here?

No brief landed on my desk. I had to write it myself — and then earn the right to build it.

I owned this end-to-end as the sole designer — opportunity and problem definition, requirements and stakeholder alignment, information architecture, interaction and visual design, high-fidelity prototypes, developer handoff, and launch support. One credential, one designer, one continuous vision — in close step with product and engineering the whole way.

Ownership meant inheriting the real constraints too. The certification couldn’t become its own destination; it had to slot inside the practice platform developers already lived in. It had to hold up at a scale most products never see. And it had to earn a recruiter’s trust from zero — a credential nobody had heard of yet, asking real companies to weight it in real hiring decisions.

Before a single screen was designed, I aligned with product on what success actually had to look like.

The fidelity progression, honestly. No formal wireframe stage survived — validation looped straight back into design, and decisions moved into production once they held up against real candidate and recruiter reactions.

Before a single screen was designed, I aligned with product stakeholders on what success actually looked like.

The hardest constraint in the room was never technical. It was that trust can’t ship in a release — it accrues slowly, one fair interaction at a time. That single realization turned the brief inside out: not “design a test flow,” but “design the conditions under which trust could actually form” — which is why this product grew up in phases across 2018–2020 instead of landing as one finished thing.

Speed mattered. But never at the cost of fairness. Every decision came back to one question — does this make a developer more likely to be seen for who they really are, or a recruiter more likely to trust what they’re looking at?

Who else shaped this

I led the design, but I never built this alone in a room. The most important decisions came out of close work with engineering, product, and the wider team — out of that friction, not in spite of it.

Engineering shaped the wait state. I originally wanted an instant result the moment a candidate submitted. Engineering pushed back hard: scoring real code fairly and consistently just takes time, and there was no faking that. Instead of fighting the constraint, I designed around it — an explicit “evaluating, up to 30 minutes” state with an emailed result. What started as a limitation became one of the most honest, trust-building moments in the whole flow.

Product kept the scope two-sided. Every time a decision threatened to tilt toward one side, product and I pulled it back. The credential had to serve both the developer earning it and the recruiter reading it, or it wasn’t worth shipping. That shared line is why the design never optimized one side at the other’s expense.

The wider team grounded it in reality. People across the organization who actually understood employers, candidates, and how the platform got used in practice kept pulling the design back down to earth, away from the idealized flow I might have drawn on my own.

Validation was constant. One-on-ones, design critiques, team walkthroughs — presenting the thinking, taking the hits, adjusting, and coming back again. That rhythm, repeated for two years, is what let the product mature instead of stall.

The trade-offs I owned. Collaboration surfaced hard choices, and each resolved the same way — toward protecting trust, even at the cost of speed or simplicity.

Owning it end to end meant one thing before anything else: I had to decide what ‘good’ even looked like. So I set the rules first.

What rules did every screen have to pass?

I didn’t frame these as principles at the time. But looking back at the decisions I made, the same handful of rules kept deciding things for me — and they’re the criteria the rest of this case study should be read against.

Earning had to be real, never bought. The badge could only come from genuine assessment — never attendance, never a payment, never a checkbox. The moment a credential can be acquired instead of earned, it stops being a signal. Every screen in the earning flow was built to protect that: real code, scored fairly, or nothing at all.

A recruiter had to read it in a glance. The whole point was to replace the résumé as the thing a recruiter squints at and second- guesses. So the credential had to be legible instantly — no re-testing, no decoding, no “what does this actually prove.” If a recruiter couldn’t act on it in seconds, it hadn’t done its job.

Design the earning and the believing as one system. A badge only earns its keep if the earning and the trusting are designed together, as a single problem — not a test flow on one side and a display on the other. I framed it internally not as a feature but as a trust system, because the candidate’s experience and the recruiter’s confidence were the same design decision seen from two ends.

Protect the candidate’s dignity by default. A credential that can embarrass you is one you won’t attempt. Failed attempts stayed fully private; the badge could only ever add to a developer’s standing, never expose them. Recognition and confidence were features, not by-products.

Live where developers already are. The certification couldn’t become its own destination competing for attention. It had to thread into the practice platform developers already used and trusted, so earning it felt like a natural extension of what they were doing — not a detour to a place they’d never heard of.

And underneath all of them, one question: does this decision make a HackerRank badge more worth earning, or more worth trusting? Every trade-off in the sections that follow resolved by asking it.

The rules were clear. What I didn’t have yet was proof of what people actually needed. So I stopped theorizing and went to listen.

How did you learn what both sides actually needed?

The first real work was listening — a structured research push before any solutioning.

Before I sketched a single screen, I went and sat across from the people who’d actually have to live with this thing — developers hunting for their next role, recruiters trying to decide who to trust. I wanted every decision that came later to trace back to something one of them had actually told me, not something I’d assumed on their behalf. Three methods, each answering a different question.

Recruiter interviews

I ran 45-minute semi-structured interviews with 12 enterprise recruiters from companies already using HackerRank — teams running high-volume technical hiring, who knew exactly where the existing process cost them time. I asked how they screened today, what a résumé failed to tell them, and what they were doing manually that a trusted credential could replace.

Candidate interviews

I ran 60-minute semi-structured interviews with 15 developers and early-career candidates who’d been on the job market recently. I wanted the part recruiters couldn’t tell me — what it feels like to have real skill and no way to prove it, how they decide what’s worth putting on a résumé, and where the fear of being judged quietly stops them from trying.

One-on-one, I asked job seekers what they wished a recruiter could see, and asked recruiters what they wished they could trust. What came back was the same broken system, described from two completely different vantage points — one side couldn’t prove skill, the other couldn’t trust the claim.

The directional signal.

Every conversation kept pointing the same way. Both sides wanted the exact same undelivered thing: a credential that was credible, standardized, and visible enough to actually matter.

What the competition was missing

I went and looked at how everyone else was issuing credentials, half-expecting to find this problem already solved somewhere. Instead I found the same gap everywhere I looked: nobody offered a standardized, role-relevant, genuinely-assessed technical credential.

One insight outweighed the rest: candidates feared the downside of a credential as much as they wanted the upside. A visible failed attempt felt riskier than no attempt at all — and that fear was suppressing participation.

That single finding drove the most important decision in the build, which returns later as the “zero risk” principle.

What I heard didn’t just confirm the problem — it moved it. The real reframe was waiting in the transcripts.

So what was the big reframe?

The conversations settled the problem. Then they quietly rewrote it.

The hardest architectural call turned out to be the most important one: certification couldn’t become its own destination. It had to live inside the practice platform developers already used every day, so earning a credential felt like the next natural step — never a trip to some other product.

So I threaded the structure straight through the existing surface instead of building beside it. A skill a developer practiced and the certification for that skill became two states of the same object, not two separate places to visit.

Three principles organized the content. Status is always visible — every skill shows whether it’s not started, in progress, or certified, wherever it appears. The badge lives next to the skill it certifies, never in a separate trophy case. And the credential points forward — a pass connects directly to relevant jobs, closing the loop from skill to opportunity.

Once I knew certification had to live inside the daily flow, the next question was sharper: who exactly was I building it for? Two people, pulling in opposite directions.

Who were you actually designing for?

Two people kept surfacing in every transcript. I never went looking for them by name — but I designed for both from then on.

Two people kept showing up in every interview transcript, even though I never went looking for them by name. I kept both of them in front of me for the rest of the project — they wanted opposite things from the exact same object, and the product would only work if it satisfied both at once.

Arjun’s fear and Maya’s doubt were the same problem from two sides. A badge Arjun was afraid to attempt would never reach Maya. A badge Maya didn’t trust would never be worth Arjun’s attempt.

Representative personas synthesized from the research. Names are illustrative.

Knowing who I was designing for, I could finally trace what they’d move through — and where their trust would break. So I mapped the whole journey.

Where did the journey actually break down?

Before I drew a single screen, I walked the candidate’s entire arc — hunting for the exact moment trust would be won or lost.

I walked the candidate’s entire journey end to end, trying to feel exactly where trust would be won or lost along the way — then turned that map into the concrete paths a candidate could actually take, success and failure both.

The shape of it surprised me. The emotional low point doesn’t sit at the start or the end — it sits in the middle, in the exact moment a candidate has to decide whether the risk is even worth taking.

The journey’s emotional valley is in the middle — Consider and Wait. Most of the design effort went there, not into the celebratory ends.

From that map, I drew out the actual flow — decision point made explicit, so the failure case got designed on purpose instead of left to chance.

First-time pass: Dashboard → verification landing → review profile → take test → evaluating → pass → certificate, applications highlighted to recruiters. The credential becomes a recruiter-facing signal at the final step.

Attempt and fail: Same path to the decision point, then: result kept private, no company sees it, targeted practice recommended, retake unlocked after a set wait. The candidate leaves safe, not exposed — which is what makes a second attempt thinkable.

Return and re-certify: A returning candidate re-enters from the dashboard, where status (not started / in progress / certified) is always visible, and can pursue additional skills from the same surface.

Designing the fail branch with the same care as the pass branch is the whole argument of this case study in one diagram.

The map showed me where the risk lived. Now it was time to draw the thing that would carry people past it. Pen first, Figma later.

How did you go from whiteboard to screen?

There was no formal wireframe stage, and I never once missed it. The thinking happened at a whiteboard, in pen.

There was no formal wireframe stage, and I never once missed it. The real thinking happened standing at a whiteboard, in rough sketches, in working sessions with product and engineering where I worked a screen into shape against their input before anyone opened a design file. Once the bones were agreed, I went straight to high-fidelity and iterated from there.

Only two ideas survived those early sessions, but they carried the whole product. Certification had to live inside the dashboard a developer already used, never on a separate microsite. And the failure state deserved as much design attention as the success state, because that was where participation would actually be won or lost. Every screen I drew after this traces back to those two early calls.

Once the bones held up under pressure, the sketches were ready to become real. This is what shipped.

What did you actually ship?

The sketches became screens. The screens became a credential people could actually earn. This is what I designed.

Once the thinking held up, I moved into high-fidelity and started drawing the real, shipped experience. I kept the visual language deliberately restrained — HackerRank’s green for action and success, a clean type hierarchy, generous space — so the credential always read as official and trustworthy, never playful.

What follows are the screens that carry the two-sided trust story. I’ve called out the decision behind each one directly, rather than leaving you to guess at it.

Certification lives where developers already are

The candidate’s home base. Every skill they practice shows its certification status right alongside it, so earning a credential never means leaving the place they already work.

The promise, stated plainly — including the risk

The entry point to a certification. Before any commitment, it explains the value, the steps, and — crucially — the safety net, giving a hesitant candidate everything they need to decide to begin.

A low-commitment first step

The first step of the flow. Rather than dropping the candidate straight into a timed test, it opens on a familiar profile to review and confirm.

The wait state, handled honestly

The moment after submission, while scoring happens behind the scenes. Instead of a silent spinner, the screen sets a clear expectation and frees the candidate to step away.

Success closes the loop to opportunity

The success state. The credential is confirmed, and in the same view the candidate is connected to the opportunities it unlocks.

The failure state protects the candidate

The most carefully designed screen in the system. It delivers a hard outcome while protecting the candidate’s dignity and keeping the door open to try again.

The credential, made shareable

The earned credential itself — verifiable, official, and built to be shared wherever recruiters will see it.

One decision recurs across every screen: design the moments of fear — the start, the wait, the failure — as carefully as the moments of triumph. That’s what earns a credential the right to be trusted.

The product was real and in people’s hands. The harder question was whether it changed anything. So here’s what it moved.

What did this actually change?

This never shipped as one launch moment. It grew up in phases — and its purpose was never a number on a dashboard.

This never shipped as one big launch moment. It grew up in phases across 2018–2020, and its purpose was never a single number on a dashboard — it was closing the trust gap on both sides of the hire, one fair interaction at a time.

Publicly Verified

What Changed for Both Sides

A two-sided credential usually earns trust on one side at the other’s expense. The design goal was to move both — and the outcomes below are stated as design results I can defend, not metrics I can no longer verify.

What changed for HackerRank

A credential at the center of the ecosystem: The certification gave HackerRank a trust primitive that the rest of the platform — practice, assessments, interviews — could build around, rather than a standalone feature off to the side.

Skills-based hiring, made concrete: It moved “skills over pedigree” from a positioning line into something a developer could actually earn and a recruiter could actually act on.

A credential that outlasted the project: The clearest measure of success isn’t a launch-week metric — it’s that certification became a durable, still-growing part of how HackerRank represents developer skill, years later.

A note on measurement: internal dashboards tracked adoption and engagement during the project, but those records are no longer accessible to me today. Rather than present numbers I can’t independently verify, I’ve let the one publicly verifiable figure stand on its own and stated every other outcome qualitatively. The product was built to increase certification completion, strengthen developer credibility, and expand HackerRank’s skills-based hiring ecosystem — but I’ll only claim the number I can prove.

But impact is only the honest half of the story. The harder half is what didn’t resolve cleanly.

What was the hardest part?

Not everything about this landed cleanly, and I’d rather tell you where than pretend otherwise.

Not everything about this resolved cleanly, and I’d rather tell you where than pretend otherwise. A few of these were genuinely hard, and naming them honestly is part of what the work actually was.

Earning trust from a standing start: A brand-new credential walks in with no reputation at all. Some companies were slow to weight it in hiring decisions, and no amount of good design could rush that — trust in a signal only builds as the signal proves itself reliable, again and again, over time.

Scaling as participation grew: Every new wave of developers attempting certification put more strain on the assessment and evaluation infrastructure behind it. Keeping the experience consistent while that grew underneath it was a constant pressure I lived with, never a problem I got to close out.

The gap between certified and hired: A credential could open a door, but it couldn’t walk a candidate through it. Some certified developers never fully leveraged the badge they’d earned, and getting certification data to flow cleanly into employers’ existing hiring systems took longer than the product side wanted to admit.

Breadth came later: In the early days, the certification only covered a handful of skills, and its appeal was naturally limited until the catalog caught up. This was a system that had to grow into its own promise; it never had the luxury of launching fully formed.

None of this undercuts the core of what shipped: a credential a developer could genuinely earn, and a recruiter could genuinely begin to trust. But the honest version of this story includes the parts that didn’t come easy — and that’s the version actually worth learning from.

Naming the hard parts honestly leads to the last, most personal question. What did owning this actually build in me?

What did this teach you?

I went into this as a designer. I came out of it as something closer to an owner.

This was the first system I ever owned from a completely blank page — from spotting that certification was quietly becoming a trust currency, to arguing that bet in front of people who didn’t have to believe me, to shaping every single screen of how it finally worked. Nobody handed me a brief. I learned what product leadership actually feels like by finding out the hard way.

The deepest lesson was about trust as a design material, not a marketing line. You can’t ship trust in a release; you earn it, slowly, through a product that behaves fairly every single time — especially in the moments a user is afraid. Designing the failure state with as much care as the success state is the clearest thing I carried out of this project, and I’ve carried it into everything I’ve built since.

I also learned what it takes to hold a system together across interruption. This product grew up in phases over two years, through pauses and competing priorities that could easily have pulled it apart. Keeping one coherent vision intact through all of that — instead of watching it fragment into whatever was easiest that quarter — is a different muscle than shipping one clean sprint, and I’m glad I built it this early.

Most of all, this project told me how I actually want to work: grounded in real user fear and motivation, honest about what’s verified and what isn’t, and willing to choose the slower, more trustworthy path whenever trust is the actual point.

That’s what it built in me. And it’s what I bring to every blank page now.