问HN：我们能否用实际的Git问题来替代职位描述？
你好，HN，
我正在探索一个概念，以解决“职位描述”和“实际工作”之间的脱节问题。
问题：
公司通常以特定的意图进行招聘（例如，“我们需要一个人来解决我们的遗留支付同步问题”），但当这些信息传达到职位描述时，往往变成了一堆泛泛而谈的关键词：“必须拥有5年以上的Java、微服务经验……”
假设：
招聘是为了解决问题。那么，为什么不直接用问题本身作为职位描述呢？
提议的工作流程：
输入 = 问题背景（公开或私有）：
招聘经理不再编写职位描述，而是从他们的问题跟踪系统（如GitHub、Jira等）中选择一组实际任务/问题。
示例（开源）：“这是问题#123（内存泄漏）。帮我找一个解决过类似复杂问题的人。”
示例（企业）：“这是一个关于高并发数据库锁定的已解决任务。我们需要另一个能够处理这种工作水平的人。”
愿景：这可以通过API或MCP（模型上下文协议）服务器来实现，安全地获取任务背景——代码差异、讨论和复杂性指标。
匹配：
我们将这个“问题向量”与候选人的“活动向量”（从他们的git日志或贡献历史中得出）进行比较。
结果：“候选人X的匹配度为90%，因为他们最近在Rust中重构了一个类似的异步队列系统，这与您输入的问题的复杂性相符。”
隐私挑战（房间里的大象）：
为了在企业（私有仓库）中实现这一点，隐私至关重要。
我在考虑一个本地提取层，在将“问题背景”发送到大型语言模型进行分析之前，先对其进行清理（去除个人身份信息/机密信息）。目标是提取问题的模式，而不是专有代码本身。
我的问题：
我首先在公共GitHub用例上构建原型。
但对于那些在企业中招聘的人：您是否会信任一个解析您内部问题背景（经过清理）的工具，以生成精确的候选人要求档案？
我相信这种“基于任务的招聘”比“简历解析”更公平，但我很好奇您认为这个模型在哪些方面会出现问题。
查看原文
Hello HN,<p>I'm exploring a concept to fix the disconnect between "Job Descriptions" and "Actual Work."<p>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..."<p>The Hypothesis:
Hiring is about solving problems. So why don't we use the problem itself as the JD?<p>The Proposed Workflow:<p>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.).<p>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).<p>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.<p>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?<p>I believe this "Task-based Hiring" is fairer than "Resume Parsing," but I'm curious where you think this model breaks down.