AI Resume Shortlisting Tool

An explainable resume-to-job-description matcher: TF-IDF + cosine similarity produces a weighted match score, and a skill-gap analysis tells the candidate exactly which skills are missing — served via Flask web UI, a CLI, and a Python API over one shared engine.

Built with Python, Flask, scikit-learn, spaCy, PyMuPDF, and 1 more.

A ~1,500-LOC Python tool that scores how well a resume fits a job description and, more importantly, explains the score. PyMuPDF extracts text from PDF resumes; regex parsers pull required vs preferred skills, experience level, education and certifications from the JD. The match engine (ResumeJobMatcher) combines scikit-learn TfidfVectorizer (unigram+bigram, 5000 features) + cosine similarity with a set-based skill overlap into a weighted composite score, then produces common/missing/extra skills, improvement suggestions, and a 4-panel matplotlib visualization embedded as base64. The same engine backs three interfaces — a Flask web app (single and batch upload), a CLI, and a direct Python API — and a batch mode ranks many resumes against one JD. The design bet was deliberate: classic, CPU-only, fully-explainable IR instead of heavyweight embeddings, so the tool runs anywhere and can always point at exactly which skills moved the score. It's honest about its seams — the matching is lexical not semantic, skill matching is exact-token, the experience component isn't yet wired into the score, and the only currently-live URL is a static landing page rather than the running app.

• Resume-vs-JD match score via scikit-learn TF-IDF (unigram+bigram) + cosine similarity
• Explainable skill-gap analysis: common, missing, and extra skills plus generated improvement suggestions
• PDF resume parsing with PyMuPDF, contact-info and section extraction via regex
• JD requirement parsing: required vs preferred skills, experience level, education, certifications
• Weighted composite scoring (text similarity + skill overlap + experience weighting) with an intuitive score curve
• 4-panel matplotlib/seaborn visualization (score gauge, skill distribution, top missing, top matched) embedded as base64
• Batch mode: rank multiple resumes against one JD by match score
• Three interfaces over one engine: Flask web UI (single + batch), CLI, and a Python API
• Bundled sample JDs, pinned requirements.txt, setup.py installer, installation tests, MIT license

Every project hits walls. Here's what nearly broke AI Resume Shortlisting Tool — and how it shipped anyway.

• Scoring that's explainable, not just a number: designing a weighted composite (text similarity + skill overlap + experience) so every point traces back to a visible reason, and adding a hand-tuned curve to make raw cosine scores feel intuitive to users.
• One engine, three front-ends: keeping a single ResumeJobMatcher class clean enough to drop unchanged into a Flask route, a CLI, and a batch ranking loop, with a uniform {success, error, data} contract so failures never crash the caller.
• Rendering rich visual output in a stateless web app: generating a 4-panel matplotlib/seaborn chart server-side and embedding it as a base64 PNG so results are self-contained with no image file handling.
• Extracting structure from messy free text: regex-driven section splitting on resumes and required-vs-preferred requirement parsing on JDs, which is inherently brittle across formats.
• The deploy reality gap: the Flask app needs a real Python host (PyMuPDF, sklearn, uploads), which GitHub Pages can't provide — so the 'live' story is still unfinished.

Every build leaves residue. The takeaways from AI Resume Shortlisting Tool that carry forward.

• Lexical matching (TF-IDF) is a legitimate, shippable baseline — but its ceiling is real: it can't see that two differently-worded skills mean the same thing, which is exactly where a sentence-embedding upgrade would earn its keep.
• Advertising a feature the code doesn't fully implement (the experience component defaulting to a constant) is the kind of thing that only shows up on a careful re-read — worth auditing the gap between the README and the actual execution path.
• Exact-token skill matching quietly loses real matches ('nodejs' vs 'node.js'); normalization matters as much as the matching algorithm.
• A 'Live Demo' badge has to point at something that actually runs — a static landing page under a demo label erodes trust faster than having no link.
• Separating parsing, scoring, and presentation early is what made three interfaces cheap to build; the architecture choice paid off more than any single algorithm choice.