Ask HN: Does "task-derived JD and evidence-based candidate" make hiring better?

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.)