Technical Tests at Cyberr: from claimed skills to proven ones 

In cybersecurity hiring, everyone says they’re good. I designed the feature that lets candidates prove it, and gives clients a way to act on that proof. The hard part wasn’t the screens. It was making a test feel safe enough for candidates to take, and credible enough for clients to trust.

Context 

Cyberr is a hiring platform and professional network built only for cybersecurity. It had already solved two layers of trust: identities were verified, and certifications were validated via Credly. Clients could search talent, use AI matching, build shortlists and hire directly.

But a verified identity and a valid certificate still say nothing about whether a person can find and exploit a misconfigured service under time pressure. That was the layer missing. Clients kept running their own technical screening outside the platform, and every good candidate looked the same on paper as an average one.

A partnership with Airbus gave us realistic, hands-on missions in a real attack environment. My job was to turn that into a product people on both sides would actually use.

The Tension 

A test sits between two people who want opposite things from it.

If we lean too far toward the client, candidates don’t start. If we lean too far toward the candidate, the result becomes marketing, and clients stop trusting it. A test nobody takes and a result nobody trusts fail in the same way: the feature dies.

The first spec leaned toward strictness: one attempt per test, results synced to the profile, no detailed feedback. It was clean from an engineering point of view, but it assumed candidates would accept high stakes with no control. I wasn’t sure they would, so before designing anything I wanted to hear from both sides.

What the market taught us 

The skills gap in security is about quality, not just headcount: in 2024 ISC2 estimated a shortfall of about 4.8M professionals, and 90% of respondents reported skills gaps on their teams (ISC2). Employers need a better signal, and several products already try to give one.

Looking at them, I saw two camps. Training platforms like Hack The Box, TryHackMe and Root-Me PRO are great at motivation, with ranks, leagues and streaks. But their scores mostly measure how active you are, and hiring is a side feature. Assessment tools like HackerRank and TestGorilla live inside the hiring process, but their results belong to one employer. Candidates take a new test for every application, and the tests lean toward knowledge checks rather than hands-on work.

That gave me three principles to design by:

1. 01Borrow the motivation, not the noise. Gamification should pull candidates in, but the result must reflect skill, not grinding.
2. 02The result belongs to the candidate. It should be portable across employers, and the candidate decides when it’s shown.
3. 03Tests live where hiring happens. For clients, a test is useful only inside the project they are hiring for, next to the people they are considering.

Listening to both sides 

I ran discovery interviews with 6 candidates (half junior and mid-level, half senior) and 5 clients (recruiters, hiring managers and a technical lead). I split candidates by seniority on purpose: I expected juniors and seniors to feel very differently about being tested, and they did. Later, two rounds of moderated usability tests on Figma prototypes, with 5 participants per group each round, checked whether the design actually solved what we heard.

How the sessions were set up

Every usability task had a success criterion and an ease rating (SEQ, 1 to 7); candidate sessions ended with a SUS questionnaire. Issues were rated by severity and compared between rounds. One interview question did most of the work with clients: “A candidate scored 70% on a practical pentest. What does that tell you?” Almost nobody could answer without asking what exactly the person got wrong.

Research scripts: recruiting criteria, all four scripts and usability tasks.

What survived the synthesis

After each round I clustered notes on an affinity map and kept only patterns that came up with at least three people. Here is what survived, and what it changed.

The insight that reframed the project came from a senior pentester. Asked how he would feel about a public score, he said he’d simply never take the test. That one answer turned the first spec’s strict model upside down: if the most experienced people opt out, the leaderboard fills with beginners, and clients learn to ignore it.

Five decisions that shaped the product 

01Private by default, shared by intent

The central question was who sees a result, and when. We considered three models:

• Public by default, as in the first spec. This gives maximum transparency, but research told us senior candidates would simply not start.
• Auto-hide weak results below a threshold. This feels safe, but clients would see only good scores and stop trusting all of them.
• Private by default, with explicit sharing. This is what we chose.

The final model has two contexts. A test a candidate takes on their own stays private until they press Publish on my profile. A test a client sends is shared with that client by design, because the candidate accepts it as part of an application. Candidates get control where it matters for reputation; clients get unfiltered results where it matters for hiring. Retake test lowers the stakes even further: a first attempt is practice, not a verdict.

02Designing the in-between

The tests run in the Airbus environment, not in Cyberr. That gap is where trust leaks: users finish, close the tab, and don’t know if anything happened. An email alone felt too passive, and a status buried in the test card was too easy to miss.

I made the waiting state a first-class part of the page. Pending tests sit at the top of the hub: each card shows the test, the role and company it came from, the time left with a progress bar, and one action, Go to test. Results sync back automatically, so the block quietly turns into a result. Honestly, this was the least glamorous screen in the project, and probably the one that did the most for completion.

03Effort you can see before you commit

Candidates postponed tests when they couldn’t estimate the effort, so every card answers three questions at a glance: how hard (a level scale), how long (time) and what you get (points). A details panel before Start mission explains the environment and the topics covered. The pattern repeats on the client side: a client sees the same details, plus a Questions tab, before sending a test to anyone.

04From a number to a decision

For clients, the score itself was never the product; the decision was. We explored a ranked list of candidates by score and profile cards with a score badge. Both reduced people to one number, which is exactly what clients said they didn’t trust.

The final Test results view is a matrix: candidates in columns with their overall score, questions in rows with a clear pass or fail mark for each. A recruiter instantly sees that two candidates with similar totals failed completely different topics. Each test has its own tab, and Book a meeting sits right in the header, so the comparison ends with an action, not a spreadsheet.

Getting there had to be just as direct. Send test lives in the project’s shortlist and opens a three-step flow: select candidates, pick a test, send. A Tech Tests Left counter and an inline Buy more tests panel mean running out of tests never breaks the flow.

05Motivation without noise

We wanted juniors to have a reason to come back, without turning the leaderboard into a points race. Leagues are based on points from validated tests, not on weekly activity. The user’s own row is always pinned at the bottom of the table, even far down the list, and a progress card turns a distant rank into a concrete next goal: how many points to the next league.

What usability testing changed 

The first round of usability tests didn’t challenge the big decisions, but it exposed the gaps between them. Most issues were about clarity at moments of uncertainty, the same theme as the research.

In round 2, every candidate found their pending test and understood their result’s visibility without help. Clients completed the send-a-test flow without help, and most went straight to the per-question view when asked who did best.

The outcome 

Technical Tests shipped to production. Exact numbers are under NDA, but the shape of the result is clear:

What we measure

I worked with the PM to define success as a funnel, not a single number, so the team can see where trust breaks:

What I learned