| Hello HN, I’m testing an idea: generate JDs from real engineering tasks, then evaluate candidates against those tasks using code evidence. Instead of writing “5+ years X, Y, Z”, input is actual work context: - GitHub/Jira issues
- linked PRs and code diffs
- review comments and discussion timeline
- change size, dependencies, and failure modes From this, the system generates a structured JD, for example: - Problem Scope: what must be solved
- Required Skills: APIs, infra, debugging depth, testing expectations
- Seniority Signals: architecture ownership vs isolated implementation
- Success Criteria: what “done well” looks like
- Interview Focus: where to probe risk areas Then candidate evaluation is also evidence-first: - Build candidate activity profile from commit/PR/review history
- Map past solved problems to the generated JD requirements
- Score by evidence quality, not keyword match
- Output traceable reasons like:
- “Handled similar WebSocket memory leak with root-cause writeup”
- “Strong delivery signal, but weak automated test coverage”
- “No evidence for distributed locking incidents” So the goal is not “resume parsing”, but: 1. JD grounded in actual tasks
2. Candidate fit grounded in actual shipped work I’m still validating this concept and would value critical feedback: - For hiring managers: would this be better than today’s JD + ATS flow?
- For engineers: what would make this feel fair vs reductive?
- Where does this break first (privacy, gaming, legal, false confidence)? (For private/company data, my assumption is sanitized extraction before analysis.) |