`hiring-agent`: The resume screener that turns hiring into an evidence pipeline
From PDF parsing to GitHub enrichment to rubric-based scoring, this project shows how to build an AI evaluator that explains its own verdict.
Our goal with the hiring agent is to create a more efficient and equitable hiring process. By automating the screening phase, we allow our customers to focus on the top talent, rather than getting bogged down in volume.
- `hiring-agent` is interesting because it treats hiring as evidence assembly, not free-form inference.
- The repo’s real innovation is not the model call, but the system around it: schemas, rubrics, and traceable outputs.
- GitHub enrichment changes the input from self-reported claims to externally checkable behavior.
- The project occupies a middle ground between keyword filters and human interviews, with a different trust model for each.
Most hiring software starts with a résumé and ends with a score. hiring-agent starts with a résumé, pulls in GitHub evidence, and then forces the result through a rubric. That makes the system feel less like an AI assistant and more like a programmable case builder.
The interesting part is not that it uses an LLM. It is that the LLM is boxed in by structure at every stage. The repo keeps asking the same question: what would it take to make a hiring judgment explainable enough to survive contact with a skeptical recruiter?
The pitch: a hiring agent that has to show its work
The public pitch from HackerRank is straightforward: automate screening, reduce volume, and keep the process more equitable. But the open-source repo reveals something more specific. It is not trying to replace judgment. It is trying to constrain judgment until it becomes legible.
That is the bigger story. The system does not merely decide whether a candidate is “good.” It builds a record of claims, supporting signals, and rubric-based reasoning that a human can review afterward.
Why resumes are the wrong input
A résumé is an awful data structure. It compresses years of work into a layout contest, rewards formatting, and hides the difference between a real contribution and a buzzword parade. This repo answers that problem by breaking the document into structured fields before the model gets to judge anything.
class JSONResume(BaseModel):
basics: Basics
work: list[Work]
projects: list[Project]
skills: list[str]
education: list[Education]
resume = parse_pdf_to_markdown(path)
structured = llm_to_schema(resume, JSONResume)
That small shift matters. Once the input becomes structured, the rest of the pipeline can reason over fields instead of page geometry. The project is not asking an LLM to invent understanding from scratch. It is asking the model to normalize mess into a form that software can audit.
Inside the pipeline: PDF, GitHub, rubric
The repo’s architecture is a three-stage assembly line. First, PDF extraction turns a document into Markdown and then into schema-shaped resume data. Next, GitHub enrichment adds outside proof. Finally, the evaluator scores each category with evidence attached, not just a number.
| Stage | What it consumes | What it outputs | Why it matters |
|---|---|---|---|
| PDF extraction | A raw résumé PDF | Structured sections and fields | Removes layout noise before evaluation |
| GitHub enrichment | A candidate identity or handle | Selected repositories and profile signals | Adds external behavioral evidence |
| Rubric evaluation | Structured résumé plus GitHub data | Category scores with evidence strings | Makes the final judgment inspectable |
That sequencing is the whole game. If the system scored too early, it would inherit the résumé’s bias and noise. If it waited too long, it would become another opaque AI wrapper. The repo lands in the narrow middle where each stage has a job and a boundary.
The part that makes it trustworthy
This repo leans hard on Pydantic schemas, Jinja templates, and rubric-driven evaluation. That is not accidental plumbing. It is the difference between a prototype that impresses once and a system that can be inspected twice.
prompt = template.render(
candidate=candidate_json,
criteria=evaluation_criteria,
evidence=evidence_payload,
)
result = evaluator.score(prompt, format=EvaluationData.model_json_schema())
The prompt template becomes a contract. The schema becomes a gate. The evaluator becomes a place where scores are tied back to evidence strings, which means a recruiter can challenge a verdict instead of just accepting it.
We are leveraging LangChain to orchestrate the interactions between the LLM and the candidate. The primary challenge is fine-tuning the agent to evaluate code quality and problem-solving skills accurately without being overly rigid.
Why GitHub changes the game
GitHub shifts the system from self-description to observed behavior. A résumé says someone worked on distributed systems. A repository, commit history, and project selection can show whether they touched real code, shipped anything public, or maintained something nontrivial.
| Signal source | Strength | Weakness | What hiring-agent does with it |
|---|---|---|---|
| Résumé keywords | Easy to parse | Easy to game | Uses it only as an initial signal |
| GitHub activity | Harder to fake | Uneven and incomplete | Selects representative repos as evidence |
| Rubric scoring | Consistent evaluation | Can still encode bias | Attaches evidence strings to each score |
The repo also pays attention to rate limits and repo selection, which is a quiet sign of maturity. It is not just scraping profile metadata. It is trying to choose the most representative projects, then use them to ground the evaluator’s conclusions.
What this replaces, and what it does not
| Mode | Best at | Weak at | Trust model |
|---|---|---|---|
| Keyword ATS filtering | High-volume triage | Context and nuance | Pattern match |
| Human interview services | Judgment and follow-up | Cost and scale | Expert discretion |
| hiring-agent | Structured first-pass screening | Full human context | Evidence-backed rubric |
That comparison matters because the repo is not pretending to be the whole hiring process. It is a first-pass filter with a different center of gravity. The promise is not perfection. The promise is a more defensible early decision.
The limits
The system still depends on public signals, and public signals are incomplete. GitHub can overrepresent open-source hobbyists and underrepresent strong engineers whose work lives behind company walls. It can also reward activity over impact, which is not the same thing.
Privacy is the other edge. The local-LLM path helps, because resumes contain sensitive data and keeping them on-premise matters. But the broader question remains: just because a candidate leaves a public trail does not mean that trail should become an automated hiring verdict.
Why this repo matters
The deeper lesson is that the most important part of an AI product is often not the model. It is the scaffolding around the model: schemas, evidence handling, prompt structure, and the rules that keep the output honest enough to use.
hiring-agent makes that scaffolding visible. It shows a practical way to let an LLM help with judgment without letting it disappear into it. That is useful well beyond hiring.