职业与工作方法danluu.com编辑精选
开发者招聘与柠檬市场
Developer hiring and the market for lemons
2016 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dan Luu 借用经济学中“柠檬市场”（信息不对称导致劣币驱逐良币）的概念分析开发者招聘市场：由于雇主难以识别优秀开发者，招聘流程反而系统性地筛掉好人、招进“柠檬”。文章回应并反驳了 Joel Spolsky 关于“优秀开发者流动性高、好公司不愁招人”的经典论断。
为什么经久不衰：它把信息经济学框架引入招聘讨论，解释了为何“招不到人”与“找不到工作”长期并存，其分析在 Leetcode 式面试盛行的今天依然切中要害。
HN 评论精选
优秀与公开知名度被混为一谈，大量优秀开发者因缺乏公开履历而被埋没。
“优秀开发者”似乎成了“有公开知名度开发者”的同义词，否则公司怎么“知道”谁优秀？我认识不少真正扎实、值得再次共事的开发者，他们从不写博客、不做演讲、也没有公开的 GitHub 仓库——按多数定义他们是优秀的，只是公司无从知晓。
mgkimsal查看英文原文
It seems that "great" developer is somewhat a synonym for "public" developer. I'm not sure how companies would just "know" someone is "great" otherwise. And yes, not all publicly known developers are necessarily great (or even good), but I'm not sure how one would recognize a 'great' developer without that person also having some degree of publicness to them. And yet, I've known more than a handful of developers who are really solid, great people to work with, and I'd like to work with again. None of them have ever blogged, podcasting, presented at conferences nor run a public repository on github. Yet by many definitions of 'great', they fit the bill, but not the sort of 'great' that would mean companies would just 'know' of their greatness, and go out of their way to hire/recruit them.
澄清 Spolsky 原意：顶尖开发者靠人脉流动，传统招聘渠道收到的简历天然偏向非顶尖人群。
作者在某种程度上和 Joel 说岔了。Joel 的重点不是优秀开发者不换工作，而是他们很少走传统投简历的流程——他们靠朋友和口碑“以啤酒的速度”流动。所以桌上的简历大多来自不得不主动投递的人，往往不代表最优秀的开发者。
sixhobbits查看英文原文
I think the author is talking past Joel to some extent. Joel's emphasis is not on good developers not changing jobs, but more about the fact that they very seldom go through a traditional application process of sending in a cv to a hiring manager. Instead, these people "travel as fast as beer" when they're looking for a new position - they mention it to a friend or colleague who has a beer with someone else who sends over a job offer. It can seem paradoxical that companies are saying that they can't find people to hire, and even with the tech boom there are developers who can't find jobs (at least ones that they are completely happy with), but this is because a huge percentage of CVs on desks are from people who have needed to take the time to send off job applications, and are often therefore representative of the not "great" developers.
“优秀开发者”无法量化定义，整个面试评估流程本质上是伪科学的巫毒招聘。
每当谈到“优秀开发者”，我都会挑战别人用量化术语精确定义它。如果说不清什么是“优秀开发者”，你怎么知道某人是？招聘是评估过程，但就像软件测试一样，无法量化需求就无法量化测试——于是面试成了“巫毒招聘”：看似科学，实则最终决定仍基于无法证明有意义的主观意见。
andrewstuart查看英文原文
When the topic of "great" developers comes up, I always challenge anyone to define precisely, in quantifiable terms, what a "great developer" is exactly. How do you know someone is a "great developer" if you can't, in tangible terms, say exactly what a "great developer" is? This is even more of an issue when recruiting because recruiting is an assessment process to determine if someone meets some requirement. But just like software testing, if you can't quantify the requirement, then you can't quantify a test to determine if someone meets that requirement, and therefore the interview/assessment process is simply voodoo recruiting. Voodoo recruiting is when you have the appearance of scientific process in recruiting. - a process, - a set of questions that appear good, - a coding test that seems technical enough that it must be telling you something meaningful about the candidate, - the opinions of many people on the candidate. But in fact all of this is voodoo because you still can't directly define the requirement and thus you never known if you ever found what you are looking for, which is not actually known. The final decision in recruiting a "great developer", as always, comes down to some subjective opinion based on a range of criteria that can't be proven to have had any meaning in the first place.
只考算法题的面试正是制造柠檬市场的典型做法。
想知道怎么招到柠檬吗？只问 Leetcode 式问题。不问任何与工作相关的东西——不问过往经验、架构、具体技术。你就会陷入文中描述的境地：错过好工程师，也判断不出招来的人能否胜任实际工作。
seattle_spring查看英文原文
Want to know a great strategy for hiring lemons? Ask only Leetcode-style questions. Don't ask anything relevant to the job. Don't ask about past experiences, architecture, tech-specific questions, or anything like that. Only. Ask. Leetcode. Questions. If it's not a stupid algorithm disguised as something cute like a dog jumping over a river, then don't ask it. You will be in the exact situation this article describes: Passing up on good engineers, and not being able to tell if the people you do hire can actually perform on the job.
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com