When we set out to build Gradivate’s matching engine, we had a clear goal: produce shortlists that hiring managers actually trust. Not ranked lists based on keyword density. Not recommendations that require hours of manual verification. Shortlists where every candidate has been evaluated against the role requirements with enough rigour that a hiring team can move straight to interviews. This post explains how we got there — the dimensions we evaluate, the architectural decisions we made, and why we deliberately avoided certain approaches that are fashionable in the industry.

Four signal dimensions

Every candidate is evaluated across four core dimensions: experience, projects, academics, and skills. Each dimension contributes independently to the overall match score, and each uses different evaluation methods appropriate to the signal it provides.

Experience evaluation goes beyond job titles and durations. Our models assess the technical context of work described — what technologies were used, what problems were solved, and at what level of responsibility. A graduate who spent six months building a production API handles differently from one who completed a tutorial project, even if both list the same technologies on their CV. We parse the narrative of what was actually done, not just the labels attached to it.

Project evaluation is where graduate candidates often differentiate themselves most clearly. We analyse repositories, academic projects, hackathon entries, and portfolio work to understand what a candidate has actually built. The key insight is that project complexity and scope are stronger signals of capability than project count. One well-architected full-stack application tells us more than ten boilerplate tutorial projects.

Academic evaluation incorporates university, degree subject, grade, and graduation year — but contextually. A 2:1 in Computer Science from one institution represents different things than a 2:1 in the same subject from another, and our system accounts for these differences when matching against roles that specify academic criteria. This isn’t about ranking universities — it’s about understanding what a given academic record signals about a candidate’s preparation for a specific role.

Skills evaluation maps the technical competencies a candidate demonstrates — not just the ones they list. If a candidate describes building a Next.js application with server-side rendering and API routes, our semantic analysis infers proficiency in React, Node.js, JavaScript, and HTTP fundamentals, even if those aren’t explicitly mentioned. This implicit skill extraction dramatically improves match accuracy compared to keyword-based approaches.

Why we avoided black-box ML

There’s an obvious temptation in recruitment technology to throw a deep learning model at the problem and call it innovation. Feed in thousands of successful placements, let the model learn what ‘good’ looks like, and surface candidates that match the pattern. We deliberately chose not to do this, for reasons that are both principled and practical.

The principled reason is explainability. When a hiring manager asks ‘Why is this candidate ranked first?’, we need to provide a concrete answer — not a confidence score from a neural network. Our matching produces structured explanations: this candidate matches because they meet your university criteria, their project work demonstrates the required technical depth, and their skills profile aligns with your must-have requirements. Every ranking decision can be traced back to specific, interpretable signals.

The practical reason is bias. ML models trained on historical hiring data encode the biases of past decisions. If previous hires disproportionately came from certain universities or backgrounds, the model learns to favour those patterns — not because they predict performance, but because they predict past selection. In graduate recruitment, where the candidate pool should be evaluated on capability rather than pedigree, reproducing historical bias is the opposite of what we’re trying to achieve.

Where semantic understanding does help

This doesn’t mean we avoid AI entirely — far from it. Our semantic analysis layer uses language models to understand the meaning behind CV content, not just the words. When a candidate writes ‘Developed a RESTful microservices architecture handling 10,000 concurrent users,’ our system understands this implies experience with distributed systems, API design, load handling, and likely cloud infrastructure. A keyword matcher would only find the terms explicitly stated.

We also use semantic understanding to normalise how candidates describe similar experiences. Graduates write CVs inconsistently — some use technical jargon, others describe the same work in plain language. Our models map these varied descriptions to a common technical framework, ensuring that how someone writes about their experience doesn’t unfairly advantage or disadvantage them against candidates with identical capability but different writing styles.

The result is a matching engine that’s transparent, auditable, and resistant to the feedback loops that plague fully automated approaches. Every match can be explained. Every ranking can be interrogated. And critically, the criteria driving the match are the ones the hiring team defined — not patterns inherited from historical data that may not reflect what they’re actually looking for today.