The problem: a resume is only part of the evidence
Hiring evidence arrives in different forms. A resume describes experience, a transcript captures technical discussion, code shows what a candidate wrote during an interview, and quiz results provide another assessment input. Reviewing these in isolation makes it harder to judge how the evidence fits a specific job.
Candidate identity creates a second challenge. Different names can appear against the same resume or the same claimed projects. A workflow that evaluates one person at a time can miss those patterns across the candidate pool.
My role: connect the data to the recruiting decision
As AI Systems Architect and Data Automation Lead, I designed the data pipelines and AI evaluation workflows behind the recruitment intelligence work. The goal was to turn unstructured candidate material into structured information that recruiting and talent operations could use.
The earlier implementation used Python, BigQuery, OpenAI APIs, SQLite, and Google Sheets. The system later moved to PostgreSQL and expanded the evidence sources to include interview code, candidate information, and quiz results alongside resumes and transcripts.
Bring the evidence together before evaluating fit
BigQuery provides interview transcripts, resumes, candidate information, and candidate quiz results. Code samples written during interviews add another source of evidence. PostgreSQL became the database for the evolved system, replacing the earlier local SQLite storage.
These inputs serve different purposes. Interview answers and code contribute evidence of technical performance; resumes describe claimed experience and projects; quiz results add assessment context. The evaluation combines those inputs around the candidate and target job.
Evaluate against the tech stack and the JD
I used customized prompts for each tech stack so the assessment could reflect the technical requirements of the role. The system creates a candidate score for the match with a job description, rather than treating one generic assessment as applicable to every vacancy.
The earlier code illustrates the foundation: job-specific prompt templates, job descriptions, and output schemas combine with transcript, resume, and code inputs. The expanded PostgreSQL workflow carries that role-specific evaluation into a broader set of candidate evidence.
Check for potential fraud across candidates
The evolved system checks for duplicate resume data and project claims between multiple individuals. The relevant pattern is different names attached to the same resume or the same projects, which can otherwise escape a candidate-by-candidate review.
That check addresses a different problem from processing deduplication. Skipping a candidate who has already run through the pipeline prevents repeated work; comparing claimed experience across individuals surfaces potential fraud. A duplicate match is a signal for investigation, not proof of fraud.
Build a repeatable processing workflow
The available earlier source includes configurable job groups, parallel job processing, checks for already-processed candidates, stored model responses, and synchronization of results to Google Sheets. These mechanisms make the analysis a repeatable data workflow rather than a sequence of manual prompts.
The system evolved from a local analysis pipeline into a PostgreSQL-backed workflow with more evidence sources and cross-candidate checks. That evolution reflects the central engineering requirement: evaluate the evidence for a particular job while also comparing claims across the wider candidate pool.
The outcome: fit scoring and a second lens on candidate claims
The workflow brings multiple evidence sources into recruitment analysis and produces two distinct outputs: a candidate-to-JD match score and signals of duplicate resume or project claims across individuals. That gives recruiting teams a way to assess suitability and investigate inconsistencies in the same workflow.
The broader recruitment intelligence work covered 150k+ resumes and 10k+ interview transcripts, as reported in my portfolio. Those figures describe the overall body of work across recruitment analysis, rather than a benchmark of the PostgreSQL workflow.