A Resume Is Not a Competency: Why the Market Needs a Skills Graph and Explainable Match

The classic resume was conceived as a tool for honestly telling your story. Today it has turned into a genre of fiction: every second candidate writes it for a specific job posting, every third employer reads between the lines. Meanwhile the market keeps growing, roles keep fragmenting, and job titles multiply faster than they make it into dictionaries. At this point a fair question arises: can we really match people and jobs using a document that lost touch with reality long ago? Let's break down how this problem is solved through a skills graph and explainable match — using the 4ITX project as an example.

What's happening in the hiring market

Let's start with scale. Ten years ago, IT roles divided into a few dozen understandable positions: developer, analyst, tester, administrator. Today, within development alone, there are several dozen specializations, and once you add AI and cloud platforms, the count runs into the hundreds. On top of that come hybrid roles: MLOps engineer, AI architect, data product manager. Each new position appears faster than HR systems can describe it.

As a consequence, standard search mechanisms start to stall. A recruiter searches for a "Python developer," but what they need is someone with experience building RAG pipelines and integrating vector databases. Formally, that's the same Python developer. In reality, it's a different profession. And there are thousands of examples like this.

An employer describes a job in their own language. A candidate describes themselves in theirs. The HR system tries to match them by keywords and almost always misses. The result: good specialists pass by good teams simply because their resume didn't match the job posting's wording.

The problem of fragmented data

One of the key problems in modern HR search is fragmentation. Job postings live on one platform, resumes on another. Candidate profiles differ in format, structure, and completeness. The same person looks like three different specialists on three different platforms: somewhere they're a Senior, somewhere a Lead, somewhere just "an engineer with ML experience."

Employers describe the same role in different words: "Backend developer," "Python engineer," "Server-side services developer." Technically it may be one position, but search treats them as different. A candidate who fits the first wording perfectly may never appear in results for the second — simply because they didn't use the right words.

Add to this the incompatibility of formats. Some platforms require structured fields, others work with text. Some rate skills on a scale, others use tags. There's no single standard, and every new service adds its own contribution to the overall chaos.

Why the resume stopped working

The resume is a paper-era tool. It assumes a person writes about themselves once, an employer reads it once, and that's a sufficient basis for a decision. In reality, it's different.

The first reason is staticness. A resume is updated rarely, usually for a specific job posting. Skills, meanwhile, change constantly. A specialist who was actively working with RAG six months ago may have moved into agentic systems by now. The resume won't tell you that.

The second reason is subjectivity. The resume is written by the candidate, evaluating themselves. One person calls themselves Senior after three years of experience; another is embarrassed by the word Middle even after ten. There are no formal criteria, which means level-based matching loses its meaning.

The third reason is the absence of evidence. A resume asserts but doesn't confirm anything. "Experience with LLMs" can mean a year-long production project or one evening of experimenting with an API. An employer can't tell the difference before the interview, and sometimes not even after.

And the fourth — incompatibility with automation. A text resume is poorly suited to machine processing, because it's full of synonyms, turns of phrase, and unique wording. Classic parsing catches keywords but misses the meaning.

What a skills graph is

A skills graph is a structure that describes skills as a connected system rather than a list of words. Each skill has relationships with others, levels of proficiency, and contexts of application. The graph grows and changes with the market, because new technologies are added as they appear.

Such a structure solves several problems at once. First, it normalizes terminology. "RAG," "document search," "augmented generation" — all become one node in the graph with synonyms. Second, it shows the proximity of skills. Someone who worked with RAG will pick up agentic systems faster than a person with no LLM experience. Third, the graph reveals context: a skill is applied in specific scenarios rather than existing in a vacuum.

If the graph is built well, it turns the search for a specialist from guesswork into navigation. You see not a list of matches but a map: here the candidate is strong, here there's a gap, here they can grow quickly. That's a qualitatively different level of matching.

Why match must be explainable

Now the second part — explainability. Classic matching algorithms work as a black box: the system says "this candidate fits" but doesn't explain why. The recruiter either trusts it or checks manually. The first is risky, the second kills all the time savings.

Explainable match is an approach where every recommendation comes with a rationale. The system says not "the candidate fits" but "the candidate fits because they have experience building RAG pipelines, working with vector databases in production, and integrating LLMs into client-facing products — all of which correspond to the key requirements of the job."

Such an explanation solves several problems at once. The recruiter decides faster. The candidate understands why they were chosen and what to strengthen. The employer sees the logic of the match and can adjust requirements. The system becomes transparent and builds trust instead of skepticism.

How it works in 4ITX

In the 4ITX project, we started from a fundamentally different logic. Classic HR search works like this: first a job posting appears, then candidates are sought, then parameters are compared. In our architecture, both entities are formed at the onboarding stage — when the specialist or employer is only filling in their profile.

This is the key point. Data is collected not for a specific job posting but as a structured description of competencies and needs. The candidate describes specific skills with context of application. The employer formulates real tasks and the competencies needed to solve them.

Then the skills graph goes to work. Profiles are matched by skill structure, accounting for proximity, proficiency level, and context. The result is a set of explainable matches: why this candidate fits, where their strengths lie, where gaps may be. The recruiter sees the logic of the match and can adjust requirements; the candidate understands what to strengthen.

This scheme changes the very unit of search. A text document gives way to a structured competency profile that reads equally well for a human and a machine.

Author's column

Climax: where the market is heading

In the end, the hiring market is going through the same transformation as other fields where documents are giving way to data. Banks long ago moved from paper forms to transaction-based scoring. Medicine is moving from paper records to electronic histories with analytics. HR is following the same path, only slower — because matching people is harder than matching transactions.

The skills graph and explainable match are tools that let us move from keyword search to search by substance. In this picture, the resume takes the place of the paper form: it was useful, it belongs to history, but the future is built on structured data and transparent logic.

Everything is within our power. The market is already moving in this direction; the only question is who gets there first — employers who master the new approach, or candidates who first learn to describe their competencies structurally.

Glossary of terms

• Skills graph — a structure describing skills as a connected system with proficiency levels, contexts, and interrelationships.
• Explainable match — a matching approach where every recommendation is accompanied by a rationale.
• Onboarding — the stage of initial profile completion by a specialist or employer. In this article's context — the primary data collection stage.
• Data-matching — matching data by structure and meaning rather than textual coincidence.
• HR-Deep-Tech — the field at the intersection of HR and deep technologies: AI, knowledge graphs, data processing.
• Terminology normalization — bringing different wordings of the same concept into a single form.
• Resume parsing — automatic extraction of data from a text document.
• Competency profile — a structured description of a specialist's skills with context of application.
• Skill application context — the scenario in which a specialist actually used a skill: project, task, role.
• Vector database — a store of embeddings for semantic search.
• RAG (Retrieval-Augmented Generation) — an approach where the model answers based on retrieved external documents.
• LLM (Large Language Model) — a large language model, the foundation of generative AI systems.
• MLOps engineer — a specialist responsible for operating ML systems in production.
• AI architect — a specialist who designs the structure and behavior of AI systems.
• Hybrid role — a position at the intersection of several specializations.
• Scoring — a numerical assessment used for decision-making.
• Anachronism — an outdated phenomenon that persists in new conditions.
• Hiring funnel — the sequence of stages from job posting to candidate hire.
• Candidate experience — the sum of a candidate's impressions from interacting with an employer.
• Structured data — data organized according to a predefined schema.
• Semantic search — search by meaning rather than exact word matching.