CandidateX

Hiring evidence is fragmented across resumes, repositories, deployments, schemas, coding profiles, and interviews. Collapsing those signals into an opaque score hides provenance, uncertainty, and contradictions.

Why it matters. Interviewers need to know what a candidate claims, what the supplied artifacts actually support, where evidence is missing, and which questions would reduce uncertainty before making a human hiring decision.

Workflow. A synthetic CV, job description, and selected public links are normalized into a manifest; evidence is acquired under safety constraints, analyzed into a provenance-backed graph, scored against role requirements, checked for contradictions, and converted into an interviewer dossier with prioritized probes.

Outcome. A reproducible research prototype that helps interviewers inspect technical evidence without making autonomous hire or reject decisions.

I designed and implemented the end-to-end CandidateX research and product prototype represented by the repository: candidate intake, evidence acquisition boundaries, static analyzers, Candidate Evidence Graph construction, scoring, diagnostics, interview probes, backend APIs, and recruiter-facing web workflow.

Constraints.

• The system is employer decision support only; it does not autonomously hire or reject candidates.
• The public demo must use synthetic candidate data; real candidate resumes are outside the demonstrated privacy boundary.
• Candidate repositories are inspected statically; untrusted candidate code is not executed.
• Missing evidence is represented as unknown coverage rather than an arbitrary zero capability score.

Primary technologies. Python · FastAPI · Next.js · PostgreSQL · Redis · Static analysis

• The backend is organized around FastAPI, SQLAlchemy, provenance-aware domain contracts, acquisition guards, analyzers, scoring, graph construction, and a staged analysis pipeline.
• Static analyzers cover multiple programming-language and infrastructure artifacts without running candidate repositories.
• The Next.js recruiter workspace surfaces candidate intake, directory views, dossiers, comparison workflows, evidence state, and export paths.
• Research tooling preserves the paper-reported benchmark separately from the repository supplementary implementation ablation so the two experimental designs cannot be accidentally conflated.

Hardest engineering problem. The central engineering problem is preserving provenance and uncertainty while still producing a result that is useful to an interviewer. CandidateX therefore separates observed capability from evidence coverage and keeps source lineage beside the resulting diagnostics.

The CandidateX repository documents a Next.js frontend, FastAPI backend, PostgreSQL/Redis infrastructure, static multi-language analysis, a Candidate Evidence Graph, role-capability scoring, and research experiment tooling. The public demo is restricted to synthetic candidate data and is not validated for employment decisions. The submitted paper reports a controlled synthetic benchmark of 28,800 candidate-role evaluations; the repository separately contains a 4,800-sample supplementary implementation ablation harness. Neither should be described as real-world hiring performance. A public CandidateX deployment is available at candidatex-smoky.vercel.app.

• The repository connects synthetic candidate artifacts and selected public technical evidence to an inspectable evidence graph and role-specific evaluation workflow.
• Scoring, coverage, contradiction diagnostics, and interview-probe generation are represented as distinct outputs instead of one opaque ranking.
• The submitted paper reports 28,800 synthetic candidate-role evaluations across six roles; the repository also contains a separate 4,800-sample supplementary implementation ablation harness.

Validate the scoring and probe-generation behavior with carefully designed human-reviewed studies rather than simulated cohorts alone, then publish calibration, fairness, and operational measurements.

• Evidence provenance is more useful than a confident-looking score with no traceable source.
• Coverage and uncertainty need their own first-class outputs in evaluation systems.
• Research provenance must distinguish paper-reported results from later implementation diagnostics.