A1aM0

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

Hello HN,

I'm exploring a concept to fix the disconnect between "Job Descriptions" and "Actual Work."

The Problem: Companies usually hire with a specific intent (e.g., "We need someone to fix our legacy payment sync issues"), but by the time this reaches the JD, it becomes a generic soup of keywords: "Must have 5+ years Java, Microservices..."

The Hypothesis: Hiring is about solving problems. So why don't we use the problem itself as the JD?

The Proposed Workflow:

Input = The Problem Context (Public or Private): Instead of writing a JD, the hiring manager selects a set of actual tasks/issues from their issue tracker (GitHub, Jira, etc.).

Example (Open Source): "Here is Issue #123 (Memory Leak). Find me someone who has solved similar complexity." Example (Enterprise): "Here is a resolved task regarding high-concurrency database locking. We need another person who can handle this level of work." Vision: This could be done via an API or MCP (Model Context Protocol) server that securely fetches the task context—code diffs, discussions, and complexity metrics. The Match: We compare this "Problem Vector" against a candidate's "Activity Vector" (derived from their git log or contribution history).

Result: "Candidate X is a 90% match because they recently refactored a similar async queue system in Rust, which aligns with the complexity of your input issue." The Privacy Challenge (The Elephant in the Room): For this to work in Enterprise (Private Repos), privacy is paramount.

I'm thinking about a localized extraction layer where the "Problem Context" is sanitized (removing PII/secrets) before it's ever sent to an LLM for analysis. The goal is to extract the pattern of the problem, not the proprietary code itself. My Question: I'm building a prototype for the public GitHub use case first. But for those of you hiring in enterprise: Would you trust a tool that parses your internal issue context (sanitized) to generate a precise candidate requirement profile?

I believe this "Task-based Hiring" is fairer than "Resume Parsing," but I'm curious where you think this model breaks down.