Job-matching & skill-gap engine, integrated with India's NCS

Framing note. This describes the engineering and the data constraints. It does not claim usage numbers or government endorsement. "Integrated with the NCS ecosystem" is accurate; anything stronger is not. Implementation details of government systems are deliberately left out. The longer engineering account is in The NCS matching engine, in depth.

The constraint#

Most job-matching engines assume a clean input: a structured résumé, a tagged skills list, a job description written to a taxonomy. A national career-services ecosystem does not look like that. Profiles are partial. Skills are free-text or missing. The same role is described five different ways across five sources. Any matching approach that needs tidy data fails silently on the majority of real profiles: it returns weak matches and no one can tell why.

The actual problem was not which model ranks jobs best. It was to produce useful matches and an honest skill-gap read from data that is sparse, inconsistent, and entered by people who are not thinking about machine readability.

What I built#

Two coupled layers: a matching engine for which opportunities are relevant to a person, and a skill-gap engine for why that person is not ready for them yet.

• Structured representation first. Candidate and role are both turned into structured objects (canonical skills, evidence strength, hard requirements) before retrieval runs. LLM-assisted extraction fills gaps where a profile has prose but no fields, and is allowed to return nothing rather than guess. Deterministic rules handle the high-frequency cases so cost and latency stay predictable.
• Hybrid matching. Semantic retrieval finds relevant roles. Explicit constraint checks (location, seniority, hard requirements) stop a strong semantic match from overriding a disqualifying requirement.
• Skill-gap layer. For a target role, the engine returns which requirements are met, which are partially met, which gaps matter most, and which repeat across several target roles. The output is "build these things next", not a score.

What broke#

• Resume parsing. Arbitrary PDFs from a dozen resume builders, some without text layers, skills buried in paragraphs. A parser that handles ten hand-picked resumes is a different system from one that handles thousands. If the candidate representation is wrong, everything downstream is confidently wrong.
• Skill vocabulary. "MERN", "full-stack JavaScript", "React plus Node" have to be seen as related without being collapsed into one thing.
• Cold start. For a profile with almost no signal, the honest output is to name the missing information and ask for it, not to manufacture precision.
• Non-determinism. The model is bounded to extraction, interpretation, and reasoning over retrieved evidence. Application logic stays deterministic so the same candidate does not get different guidance on different days.
• Evaluation. There is no clean ground truth for a correct recommendation, so quality is tracked through several signals (ranking quality, reviewer agreement, whether flagged gaps are real and evidence-backed, whether students act on them) rather than one accuracy number.

Outcome#

Integrated with the NCS ecosystem, which gives the engine national-level distribution. Separately, piloted across 2 universities with 1,500+ students, contributing to 50+ placements. That placement figure is a contribution, not an attribution: hiring depends on student preparation, university processes, recruiters, and timing.

What I'd redesign#

Build the evaluation set before building more intelligence, from deliberately ugly data. Treat the skill ontology as real infrastructure rather than a prompting side effect. Keep the LLM off the critical path: data, representation, retrieval, and deterministic logic first, model reasoning only where it is needed. Keep the intelligence layer decoupled from any single frontend or platform.