[1] Context & ownership
How the systems connected, and where my ownership began and ended.
Fig. 1 · Search & Match and BerriTutor (highlighted) are the two systems I worked on directly.Ownership
AreaDetailRole
JD-to-candidate matching & ranking Architecture + implementation Primary owner
Ranking evaluation Relevance evaluation Primary owner
Resume parsing / taxonomy Candidate intelligence Built / contributed
BerriTutor Core development Initiated + led
LLM evaluation infrastructure Testing / regression Proposed + implemented
Interview integrity MediaPipe-based signals Contributed Recruiting-platform integration Workflow integration Integrated
Cloud deployment Production services Built / deployed
Problems and objectives
NameNotesType
Candidate ranking Slow, costly and not relevant enough. I benchmarked 100 JDs against 1,000 resumes. Problem
LLM development Prompts tied to one model, results hard to compare, and a lot of manual review. Problem
Voice tutoring Personalized tutoring that remembers the student, over low-latency WebRTC. Objective Integrity automation Flag suspicious behavior and cut the human review load. Objective
[2] Search & ranking
Re-architecting JD-to-candidate search & ranking
A staged ranking system, not a single matching call: retrieval and learning-to-rank in production, from diagnosis to recruiter feedback.
NameNotesPhase
Prior path Latency / cost / scalability issuesHigh false-positive recommendations Before
100 × 1,000 Benchmarked 100 JD × 1,000 resumeExposed bottlenecks Investigation
Multi-stage ranking pipeline
One input feeds two retrieval paths, which fuse before the expensive stages.
Fig. 2 · Retrieve broadly, then spend expensive scoring on a reduced set.StepWhat it doesWhy it is here
01Job description Turns the job description into a query for both retrieval paths. One input feeds two complementary searches.
02BM25 Lexical retrieval over candidate text. Catches exact skills and terms. 04RRF Fuses the two ranked lists into one top-K. BM25 and dense scores are not directly comparable, so it fuses by rank. 05Qwen3 reranker Cross-encoder scoring of JD and candidate pairs. Accurate but costly, so it only runs on the fused top-K. 06Ranking features Assembles signals for the learned ranker. Bridges retrieval output and learning-to-rank input.
07LambdaMART Learning-to-rank model producing the final order. Trained on recruiter relevance judgments. Candidate intelligence
From raw resume to a canonical profile the ranker can use.
Fig. 3 · Resume parsing and taxonomy.[4] Testable, reliable & operable
Making AI systems testable, reliable & operable
What made it production-ready: evaluation, integrity automation, delivery and reliability.
LLM evaluation system
A regression loop that stays repeatable as prompts, models and behavior change.
Fig. 5 · Release the change, or inspect the trace.Production delivery
Dockerized services running on GCP.
Fig. 6 · From commit to GKE / Cloud Run.Interview integrity I added MediaPipe signals that help flag suspicious behavior in interviews. Repeatable evaluation Datasets, evaluators, comparable scores and trace inspection.
[5] Results & evidence
Results, engineering decisions & evidence
The claims, architecture choices and engineering lessons, in one place.
SystemResultFraming
Search / ranking 42% reduction in shortlisting time Internal measurement
Search / ranking 100 JD × 1,000 resume benchmark Investigation benchmark
Production 4+ services deployed Implementation
Production ≈99.8% production uptime Production reliability
Architecture decisions
Hybrid retrieval Combine keyword and dense retrieval so each covers what the other misses.
Multi-stage ranking Retrieve widely, then run the costly scoring on a smaller set.
Recruiter-labelled LTR Train on recruiter relevance judgments, not just fixed weights.
Model-independent evaluation Share datasets and evaluators so regression checks still work when the model or provider changes.
Engineering lessons
01Retrieval quality is architectural.
Keyword search, dense search, reranking, learning-to-rank and evaluation work as one system.
02Evaluation should survive model changes.
What matters is how the application behaves, not tests tied to one provider.
03Production AI is systems engineering.
Latency, cost, deployment, observability and human workflows matter as much as the model.
Evidence: public product evidence · internal measurement · high-level architecture · implementation.