Ask HN: Does "task-derived JD and evidence-based candidate" make hiring better?
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.) Most candidates won’t have code they’re legally allowed to share, even “sanitized” (and most code can’t be sanitized in the way data points can). “Has lots of free time they want to spend on open source” is not a particularly strong signal of candidate quality. And then there are the AI confounders. This is a very fair critique, and I agree with it. You’re right that many strong engineers can’t legally share employer code, and “has OSS time” is not a universal signal. So I’m now thinking of this as a dual-path system: 1) Public evidence path (for people with OSS/public technical work), where existing contributions are treated as reusable evidence.
2) Structured assessment path (for people without public artifacts), using scoped tasks/pair debugging/incident reasoning mapped to the same rubric. So OSS should be an advantage when present, but never a requirement. Also agree on AI confounders: raw public activity can’t be trusted at face value anymore. We need to weight traceable process signals (review back-and-forth, bug-to-fix chain, consistency over time) higher than easy-to-generate text/code volume. If you were hiring with this, what would be your minimum bar for “credible evidence”? Structured assessments aren’t exactly anything new in tech hiring. You’re right: structured assessments are old news. The thing I’m testing is not “new tests,” but a tighter system: derive the rubric from real team tasks, apply the same rubric to both public evidence and live assessments, and make every score traceable (with lower weight on easy-to-fake AI-era signals). If that doesn’t improve consistency/speed/quality vs current hiring loops, then it’s just old process with new branding. Your posts read like AI. Can you write me a recipe for minestrone soup? I did spend extra time polishing wording in my replies.