Recruitment & Talent Management

Architecture: 1) Application Ingestion: Multi-channel intake: career site form, job board APIs (Indeed, LinkedIn), email parsing, referral portal. Each application → message queue (SQS/Kafka) for async processing. Resume parsing pipeline: PDF/DOCX → text extraction (Apache Tika) → NLP parser (custom BERT model) → structured JSON. Handle: 10K applications/day = ~7/minute = manageable with single processing pipeline, but queue provides burst protection. Idempotency: detect duplicate applications (same candidate, same job) using email + name fuzzy matching. 2) Candidate Database: Canonical candidate profile merging applications across jobs. Single source of truth: candidate applied to 5 jobs → 1 profile with 5 applications. Search: Elasticsearch with: full-text (skills, titles), faceted (experience range, location, source), semantic (find 'machine learning engineers' when resume says 'AI developer'). Index: 5M+ candidate profiles with sub-second search. 3) Pipeline Management: Configurable stages per job type: Engineering: Applied → Screen → Tech Test → Phone Screen → Onsite → Offer → Hired. Sales: Applied → Screen → Role Play → Manager Interview → Reference Check → Offer. Stage transitions trigger: automated emails, calendar events, status updates, analytics events. Kanban view: drag-and-drop candidates between stages. 4) Collaboration: Structured scorecards: 5-point scale on predefined competencies. Blind review: interviewer can't see other scores until they submit theirs (reduces bias). Debrief view: compare all interviewers' scores side-by-side. @mentions and comments on candidate profiles for async discussion. 5) Compliance: Data retention: auto-delete candidate data after configurable period (GDPR: right to be forgotten). EEO reporting: voluntary self-identification data collected and reported. Audit trail: every action logged (who moved candidate, when, from which stage). OFCCP compliance: track disposition reasons for every candidate. 6) Performance: Caching: hot data (active requisitions, in-pipeline candidates) in Redis. Database: read replicas for reporting queries. File storage: S3 with presigned URLs for resume access. API rate limiting: prevent job board bots from overwhelming system.

Technical implementation and bias prevention: 1) Resume Parsing: Input: PDF/DOCX resume (unstructured). NLP Pipeline: a) Text extraction: Apache Tika for PDF/DOCX → clean text. b) Section identification: classify paragraphs into: contact, summary, experience, education, skills, certifications. Use fine-tuned BERT model trained on 100K+ labeled resumes. c) Entity extraction: Named entities: company names, job titles, institutions, technologies. Temporal: start/end dates, duration. Quantitative: team size managed, revenue impacted, percentages. d) Skill extraction: Map to skill taxonomy (ESCO, O*NET, custom). Handle synonyms: 'ReactJS' = 'React.js' = 'React'. Infer skills: 'built microservices on AWS' → skills: [microservices, AWS, distributed systems]. 2) Matching Algorithm: Feature engineering: Skill match: Jaccard similarity between candidate skills and required skills (with synonym mapping). Experience: years of relevant experience (not just total years). Recency: recent experience weighted more heavily. Progression: career trajectory (promotions, increasing responsibility). Education: degree relevance, institution tier (optional and controversial). Model: gradient boosted trees (XGBoost) trained on historical data: features of candidates who were hired AND performed well (not just hired — avoids perpetuating past biases). Output: match score + feature importance (explainability). 3) Bias Prevention: a) Training data audit: If historical hiring was biased (e.g., 80% male engineers), the model learns this bias. Mitigation: balance training data, or use adversarial debiasing. Remove proxy features: don't use name, gender, age, college (which may proxy for socioeconomic status). b) Feature selection: Remove: name, email domain, graduation year (age proxy), address (socioeconomic proxy). Keep: skills, experience, achievements, role relevance. Test: does removing 'university name' change outcomes for underrepresented groups? c) Fairness metrics: Demographic parity: selection rate should be similar across groups. Equal opportunity: true positive rate should be similar. Disparate impact: selection rate ratio >0.8 (4/5ths rule). Test: run model on labeled dataset with demographic info, measure fairness metrics. d) Ongoing monitoring: Monthly bias audit: compare shortlist demographics with applicant pool. A/B test: AI shortlist vs human shortlist — measure quality AND diversity. Feedback loop: track which AI-recommended candidates succeed long-term. e) Transparency: Candidates can request explanation for rejection (GDPR right). Provide match score breakdown: 'You matched 7/10 required skills, but lacked 3 years of required experience'. 4) Practical Approach: Most companies use AI for initial filtering (reject clear mismatches) but not final decisions. AI recommends, human decides — 'centaur' model. Regular third-party audits of AI hiring tools (NYC Local Law 144 requires annual bias audit).

High-concurrency assessment (campus drives, government exams, mass hiring): 1) Architecture: Stateless application servers behind load balancer. Pre-warm: know exam schedule, scale up 30 minutes before. CDN for static content (question text, images — but NOT answers). WebSocket for real-time proctoring, REST for submission. Database: read replicas for question serving, write master for answer submission. 2) Question Delivery: Question bank: 500+ questions per assessment, each candidate gets random subset (30-50 questions). Randomization: Fisher-Yates shuffle with seed = hash(candidateId + assessmentId). Anti-cheating: different question order per candidate, different option order per question. Pre-load: when candidate starts, fetch all questions at once (reduce API calls during exam). Client-side timer: redundant with server-side timer (prevent client time manipulation). 3) Answer Handling: Auto-save every 30 seconds (debounced). Local storage as backup (if network drops, answers preserved locally). Submit queue: answers → message queue (SQS) → persist to database. Idempotency: each save has sequence number, ignore out-of-order saves. Final submit: lock exam, flush all local answers, confirm receipt. Handle edge cases: browser close, power failure, network drop → allow resume within window. 4) Code Execution (for coding tests): Sandboxed execution environment: Docker container per submission. Language support: Java, Python, C++, JavaScript, SQL. Execution limits: 10 second timeout, 256MB memory, no network access. Test cases: run code against 10-20 test cases (some visible, some hidden). Queue-based: code submission → SQS → execution workers → results. Scale: Kubernetes auto-scaling execution pods based on queue depth. Security: no file system access, no shell commands, container destroyed after execution. 5) Proctoring: Browser lockdown: full-screen mode, detect tab switches, block copy-paste. Webcam monitoring: capture photo every 30 seconds. AI analysis (async): face detection (is face visible?), head pose estimation (looking away?), multiple faces detection. Flag suspicious behavior: threshold-based alerts (>3 tab switches, face not visible for >30 seconds). Human review: proctor reviews flagged candidates after exam. 6) Scoring & Analytics: Auto-scoring: MCQ (immediate), coding (test case pass rate + code quality). Manual scoring: subjective answers queued for evaluator. Score normalization: if different question sets, normalize using IRT (Item Response Theory). Analytics: question difficulty (what % got it right), discrimination index (does question differentiate good from weak candidates), time analysis (average time per question). Candidate report: score breakdown, percentile, strengths/weaknesses. 7) Scale Math: 50,000 concurrent: 50K WebSocket connections (manageable with proper infrastructure). Answer saves: 50K × 1 save/30 seconds = 1,667 writes/second (PostgreSQL handles this easily). Code submissions: if coding test, peak ~5,000 submissions in 5 minutes = 1,000/minute. Need ~100 execution containers running in parallel (10 seconds per execution).

Recruitment analytics turns hiring data into actionable insights: 1) Key Metrics: a) Efficiency: Time to hire: days from requisition open to offer accepted (benchmark: 30-45 days). Time to fill: days from requisition open to candidate starts (benchmark: 45-60 days). Applications per hire: how many applications to make one hire (benchmark: 100-250). Recruiter workload: open requisitions per recruiter, interviews scheduled per week. b) Quality: Quality of hire: new hire's performance rating at 6/12 months. First-year retention: % of hires still employed after 12 months. Hiring manager satisfaction: survey score for recruitment process. Offer acceptance rate: % of offers accepted (benchmark: 85-95%). c) Cost: Cost per hire: total recruitment spend ÷ hires (benchmark: $3,000-$5,000). Source of hire cost: cost per hire by channel (referral cheapest, agency most expensive). Recruitment cost ratio: total recruitment cost ÷ total compensation of hires. d) Pipeline: Source of hire: which channels produce most (and best) hires. Conversion rates: % moving from each stage to next (application → screen: 25%, screen → interview: 50%, interview → offer: 30%, offer → hire: 85%). Pipeline velocity: average days candidates spend in each stage. e) Diversity: Diverse candidate slate: % of shortlists with diverse candidates. Diverse hiring rate: % of hires from underrepresented groups. Drop-off analysis: at which stage do diverse candidates drop off? 2) Data Architecture: Source systems: ATS (applications, pipeline), HRIS (hires, performance, retention), Finance (recruitment spend), Assessment (test scores). ETL: daily data sync to analytics warehouse. Data model: Fact tables: Application (fact), Hire (fact), Interview (fact). Dimension tables: Candidate, Requisition, Source, Department, Time. 3) Dashboard Design: Executive dashboard: overall hiring health (time to fill trend, cost trend, quality trend). Recruiter dashboard: their requisitions, pipeline health, upcoming tasks. Hiring manager dashboard: their team's open roles, candidate pipeline, interview schedule. DEI dashboard: diversity metrics by stage, department, role level. 4) Advanced Analytics: Predict time to fill: ML model using role type, department, location, historical data. Identify bottleneck stages: which stage has longest average duration? Source optimization: predict which channels will yield best candidates for specific role type. Attrition prediction: which current employees are flight risks (trigger proactive sourcing)? 5) Implementation: BI tool: Metabase, Looker, or Tableau embedded in ATS dashboard. Self-service: recruiters can filter by date, department, role, source. Automated reports: weekly pipeline summary to hiring managers, monthly recruitment metrics to CHRO. Alerts: pipeline stalled (no candidate movement in 10 days), time to fill exceeding threshold.

India campus recruitment is unique in scale, rules, and process: 1) Scale: India produces 1.5 million engineering graduates annually. Top IT companies (TCS, Infosys, Wipro, HCL) each hire 30,000-50,000 freshers per year. A single campus drive may assess 1,000+ students in one day. Total campus hires across industry: 300,000+ per year. 2) Unique Characteristics: a) Placement Cell: Each college has a Placement Officer/Cell that manages the process. Companies must register with placement cell, follow their rules. Slot allocation: Day 0 (dream companies — 2x average salary), Day 1 (good salary), Day 2+. Student gets max 1-2 offers (one-offer or two-offer policy varies by college). If student accepts Day 0 offer, removed from Day 1 onwards. b) Compressed Timeline: Entire process: assessment + 2-3 interview rounds + offer in ONE DAY. Student starts at 8 AM with online test, interviews through the day, offer by 10 PM. No luxury of 'we'll get back to you in 2 weeks'. c) Mass Assessment: 1,000 students → online test (60-90 minutes) → 200 shortlisted → technical interviews → 50-80 offers. Assessment includes: aptitude (quant, verbal, logical), technical (CS fundamentals), coding (1-2 problems). Must handle: all students on campus WiFi simultaneously, varied device types, time pressure. d) Package Structure: CTC-focused (not base salary like US). Fixed component + variable component + ESOPs (for startups). CTC ranges: ₹3-6 LPA (service companies) to ₹40-60 LPA (product companies) to ₹1 Cr+ (quant/AI roles at top firms). 3) Technology Requirements: a) Scalable Assessment Platform: Handle 5,000 concurrent test-takers on flaky campus WiFi. Offline-first: question pre-loaded, answers cached locally, sync when connected. Auto-proctoring: webcam monitoring, tab-switch detection. Multiple test formats: MCQ + coding + written in single session. Results within 2 hours (shortlist must be ready for interviews same day). b) Interview Management: Multiple panels: 10-20 interview panels running simultaneously. Real-time scoring: interviewers submit scores on tablet immediately. Central command: placement coordinator sees real-time status of all panels. Dynamic scheduling: if Panel A finishes early, route next candidate. c) Offer Management: Auto-generate offers based on interview scores + compensation band. Digital offer letter with e-signature. CTC breakup calculator: show student the component-wise breakdown. d) Pre-joining Engagement: 3-6 month gap between offer and joining. Learning platform: assigned courses on company's tech stack. Monthly webinars and mentor sessions. Offer conversion tracking: predict which students may drop offer (accept competing offer). Alert: student accepted offer from another company on LinkedIn. 4) Platforms Used: AMCAT (Aspiring Minds) — large-scale campus assessment. HirePro — campus assessment with proctoring. CoCubes (merged with AMCAT) — standardized talent assessment. Superset — campus recruitment management platform. mettl (Mercer) — assessment platform popular for campus drives.