Ask HN: Could we replace Job Descriptions with actual Git Issues?
2 comments
This does unfortunately lead to a problem of people only getting hired for jobs exactly like what they've already done, so they no longer grow or gain experience.
Juniors would be completely screwed. But then, I guess they sort of already are.
Juniors would be completely screwed. But then, I guess they sort of already are.
You hit the nail on the head regarding Juniors—they are already in a tough spot, and I certainly don't want to build a tool that makes that worse.
However, my hypothesis is that matching on 'Problem Vectors' might actually help break the cycle of 'only getting hired for what you've already done.'
Transferable Complexity: A traditional recruiter sees 'Game Dev' and ignores them for a Fintech role. But a vector model might see that the candidate solved a 'distributed concurrency' problem in a game that is mathematically similar to the 'payment sync' issue in the JD. It matches on capability, not just domain keywords. Signal for Juniors: Currently, ATS filters reject Juniors based on '0 years experience.' If a Junior has tackled a complex logic problem in a hobby project or Hackathon, this system highlights that specific signal. It gives them a fighting chance based on code reality rather than resume keywords. That said, I agree this model naturally leans towards Senior/Specialist roles where specific technical gaps need immediate filling. It's not a silver bullet for 'hiring for potential,' but I hope it's a step up from the current keyword-soup approach.
However, my hypothesis is that matching on 'Problem Vectors' might actually help break the cycle of 'only getting hired for what you've already done.'
Transferable Complexity: A traditional recruiter sees 'Game Dev' and ignores them for a Fintech role. But a vector model might see that the candidate solved a 'distributed concurrency' problem in a game that is mathematically similar to the 'payment sync' issue in the JD. It matches on capability, not just domain keywords. Signal for Juniors: Currently, ATS filters reject Juniors based on '0 years experience.' If a Junior has tackled a complex logic problem in a hobby project or Hackathon, this system highlights that specific signal. It gives them a fighting chance based on code reality rather than resume keywords. That said, I agree this model naturally leans towards Senior/Specialist roles where specific technical gaps need immediate filling. It's not a silver bullet for 'hiring for potential,' but I hope it's a step up from the current keyword-soup approach.
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.