CVScrap

The brief

Academic research project analysing CVs to take developer hiring out of the manual screening loop. Upload a document, get a normalised, queryable profile, and let a hiring team search, shortlist and compare candidates instead of skimming PDFs.

Problem

Screening is the slowest part of technical hiring, and most of that time goes to reading documents that say the same thing in different ways. A recruiter has to hold skills, years and projects in their head while comparing candidates, which means good people get filtered out for formatting reasons rather than ability.

My role

Four-person academic team. I owned the UI/UX and the web build: the upload and review flow, the search and shortlist screens, and the design system that kept the research prototype consistent enough to test with real users.

Process

• Interviewed how a shortlist actually gets built, then designed the flow around filtering rather than reading
• Defined the normalised profile schema first, because the interface is only as stable as the data under it
• Built the upload, review, search and shortlist screens as a reusable component set so the team could iterate on the parsing model without redesigning the UI each time
• Tested parsing against real CVs and logged the layouts that broke it
• Documented the edge cases as part of the research write-up instead of hiding them
• Kept the review screen honest about uncertainty, flagging low-confidence fields instead of presenting a guess as a fact

Result

A tested prototype plus a research write-up that documents the parsing model, the edge cases real CVs produced, and where the approach breaks down. No public demo exists because the work was academic, and a parsing accuracy figure I cannot re-run today is not worth quoting. The durable outcome is the schema-first method: define the data contract, then let the interface follow it. The edge cases were the interesting part: two columns for education, dates written as month names in four formats, and skill lists buried in prose. Every one of those became a rule in the parser rather than a special case in the UI, which is the discipline that kept the prototype testable. If the project continued, the honest next step would be a human review queue for low-confidence parses, because a wrong shortlist is worse than a slow one.

What it had to do

• Parses CV documents into a normalised, queryable schema
• Search and shortlist flow designed for hiring teams
• Research write-up on parsing accuracy and edge cases

Stack

• React
• Next.js
• TypeScript
• NLP
• Tailwind CSS

Team credits

• Pushkar JhaKnow Him
• Niranjan BhattaKnow Him
• Sachin SubediKnow Him
• Nabin Ghimire (me)