职业与工作方法medium.com
招聘已崩坏：我在科技行业的面试经历
Hiring Is Broken – My interview experience in the tech industry
2016 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 Medium 文章记录作者在科技行业求职面试中的挫败经历，批评招聘流程——尤其是要求候选人在白板上凭记忆写广度优先搜索等算法题——脱离实际工作、不尊重候选人。评论区围绕“招聘到底坏不坏”展开：有人反驳说作者只是面试表现差，也有人分享长期求职的糟糕体验，并讨论公司选择权与基本礼貌、白板题能否衡量开发者能力。
为什么经久不衰：它集中呈现了技术招聘中长期存在的白板算法、面试体验与经验价值矛盾，多年后仍能在 Hacker News 引发共鸣和争论，今天读来既能照见招聘流程也能照见求职者心态。
HN 评论精选
反驳作者：招聘不是坏了，而是作者面试表现差；白板算法考的是推理能力，开源项目、连续提交和黑客松并非职业能力信号。
招聘没坏，老兄。只是你不擅长面试，而且你似乎连“你的名声和技能（如果存在的话）对市场未必有用”这个想法都抵触。这是你的问题。面试存在是因为雇主需要量化并判断你的能力；典型的计算机科学题是一种有缺陷但具体的判断方式。没有理性的面试官指望你当场在白板上完美默写广度优先搜索，但他们确实指望你能从问题陈述推理出近似解法——这本质上就是程序员做的事。你该有这种思考能力，也该愿意尝试。大喊“搞什么鬼？！”并声称因为自己不是应届生所以不会或不愿做，是借口和逃避。几个流行的开源项目未必说明你的程序员才华；960 天 GitHub 连续提交是琐事，不是有用信号，甚至可能标志你是倦怠目标。几次黑客松获胜和几百个 GitHub star 是一个成功爱好者的产物，不是职业能力的代理，也不是就业敲门砖。
sagichmal查看英文原文
Hiring isn't broken, dude. You just don't interview well, and you seem antagonistic even to the idea that your cachet and skills, insofar as they exist, aren't useful to the market. That's a problem -- for you. Interviews exist because employers need a way to quantify and qualify your ability. Typical computer science problems are a (flawed, but concrete) way of doing that. No reasonable interviewer expects you to recollect breadth-first search flawlessly, on demand, onto a whiteboard. But they do expect you to be able to reason from a problem statement to something approximating a solution. That's fundamentally what programmers do. You should have the chops to think in this way, and you should be eager to try. Emoting "what the fuck?!" and claiming you can't, or won't, because you're not a recent graduate is an excuse and a cop-out. A few popular open-source projects don't necessarily speak to your talent as a programmer. A 960 day GitHub streak is trivia, not a signal of anything useful. (If anything, it marks you as a target for burnout!) A few Hackathon wins and a couple hundred GH stars are the artifacts of a successful hobbyist, not a proxy for professional ability, or a gateway to employment.
分享自己求职一年、屡遭拒绝的经历，认同面试体验糟糕，但建议要么适应面试游戏并持续学习，要么依赖强大人脉。
我花了一年才找到新工作。onsite 被拒了八九次，之前还有几次拒信。OP 经历的一切我都经历过甚至更多。有次我被忘在面试房间，面试官去踢桌上足球然后回家了。我也曾所有轮次都拿到“正面反馈”，三天后却被拒。为了找工作，我在一条条充满气泡的废话河里游过，糟透了——但我从没觉得自己是个差工程师。你可以尽情恨这个游戏（我也真的恨），但你除了玩它或者拥有极强人脉之外别无选择。我甚至不想去那场最终给我工作的面试。之前电话筛据说只招一个完美匹配的人，大概不是我——我对视频播放器懂什么？而且那是那种前半场表现不好就会被踢走的面试。管他呢，我还是去了。运气好，我没被踢，而且表现很好。最后和 CTO 的电话面试里，我被问到如何找链表倒数第 N 个节点。我很长时间确实不擅长面试，一开始也不具备目标工作所需的全部知识。是持续学习和接受“面试就是这么一套狗屁”才让我找到新工作。
vdnkh查看英文原文
It took me a year to find a new job. I got rejected from on-sites 8 or 9 times, a few other rejections before that. I've been through everything the OP has and more. I was once forgotten in an interview room while my interviewer played foosball and then went home. I've managed to pass all rounds with "positive feedback" only to get rejected three days later. I've swam through rivers of aerated bullshit to find a new job and it sucked - but I never once believed that I was a bad engineer. Hate the game all you want (and I really do hate it), but you have no choice other than to play it or have an extremely strong network. I didn't even want to go to the interview which landed me my new job. In my previous phone screen they were looking to hire a single person.The perfect fit. Probably not me - what the hell do I know about video players? And it's one of those interviews where they'll boot you to the curb if you do poorly in the first half. Whatever, I'll go anyway. And as luck would have it, I didn't get booted. I did damn well. And in my final phone screen with the CTO, I got asked how to find the Nth last spot from the end of a linked list. I really wasn't good at interviewing for a long time. And from the outset, I didn't know everything I needed to get the job I wanted. It was consistent studying and a buy-in to the bullshit that interviewing is that landed me a new job.
区分公司的选择权与对候选人的基本尊重；质疑软件行业为何不像护理行业那样尊重经验，而把白板测试变成极客资历仪式。
有选择性是一回事，礼貌和尊重是另一回事。公司当然可以任意挑剔，如果那些测试真能招到他们想要的人，那也好。但礼貌和尊重要求你向候选人说清期望和要求，不浪费他们的时间，面试后告知结果以尊重其时间投入，甚至提前说明会考察哪些领域。否则就像之前评论说的，这真的只是彩票，看你是否恰好对面试官问的东西最近熟悉。还有另一面让我想问：公司为什么如此防御？我妻子是心脏重症监护病房的注册护士。如果她不懂自己在做什么，真会有人死——即使最差的软件开发者也很少造成这种后果。但她有学位和工作经验，面试时没人要求她站到白板前重新证明自己是护士。他们尊重她的经验，问题更多关于流程、工作习惯、性格等。在软件开发界，我们似乎完全不尊重经验，我想知道为什么？雇主是被坑太多次了吗？还是这更像一种极客资历的入会仪式？
markbnj查看英文原文
There's selectivity, and there's courtesy and respect. Companies are entitled to be as selective as they like, and if those are the kinds of tests that yield the people they want to hire then good for them. On the other hand courtesy and respect would demand that you're clear with the candidate about your expectations and requirements, that you don't waste their time, that you respect the investment of time by communicating after the interview to let them know how they did, and perhaps even that you let them know up front what areas you expect to cover. Otherwise, as was noted in an earlier comment, it really is just a lottery to see if you happen to be fresh on whatever thing they happen to ask you. There is another side to this which leads me to ask why companies feel they have to be so defensive? My wife is a registered nurse on a cardiac critical care ward. If she doesn't know what she's doing actual people can actually die, something that is a rare outcome for even the worst software developer. Nevertheless, she has a BS, and work experience, and when she interviews they don't require her to stand up at a whiteboard and prove she's a nurse all over again. They respect her experience, and the questions are more about process, work habits, personality, etc. In the software development world we appear to have zero respect for experience, and I wonder why that is? Have employers been burned so often? Or is this more of a geek cred gauntlet thing?
认为白板手写 BFS 是荒唐的极客身份仪式，但也坚持软件开发者应理解基本 CS 和图结构；前端工作同样需要这些概念。
我很矛盾。一方面，这篇文章描述的面试流程荒唐得可笑：站到白板前凭记忆实现广度优先搜索！就像有程序员坐在工位盯着编辑器时会这么干一样。我觉得对那个蠢问题回答“就是用队列的那个吧？”完全有效且完整。我也认为你有权要求面试官先在同一块白板上凭记忆实现 Kruskal 最小生成树，然后你再做 BFS——那是个极简单又重要的图论算法，同样没人背。这些面试是书呆子身份仪式。真正优秀的候选人知道并利用这一点；如果你认识这样的人，问问他们的故事，我听过一些很精彩的。但显然这不是选拔软件开发者的好方法。另一方面……“前端开发者”完全不需要会实现 BFS 这种想法让我很不安。如果你是软件开发者，你该理解基本计算机科学概念，应该能处理图。做 Web 工作时，你整天都在和图打交道，不管你意没意识到！我过去一个月做前端，做的底层性能分析比之前四年底层系统工作还多。
tptacek查看英文原文
I'm torn. On the one hand: the interview processes this post describes are hilariously broken. Stand up at a whiteboard and implement breadth-first search from memory! You know, like no programmer at their desk staring at their editor ever does. I think "that's the one where you use a queue, right?" is a fully valid and complete answer to that dumb question. I also think you're within your rights to demand that your interviewer implement Kruskal's minimum cost spanning tree from memory at the same whiteboard before you have to do BFS. That's an extremely simple and important graph theory algorithm that nobody memorizes either. These interviews are nerd status rituals. Really good candidates know this and game them. If you know anyone like this, ask them for stories. I've heard some great ones. But obviously, this isn't a good way to select software developers. On the other hand... The idea that "front-end developers" shouldn't need to be able to implement a BFS (at all) bothers me a lot. If you're a software developer, you should grok basic conceptual computer science. You should be able to work with a graph. If you're doing web work, you're working with graphs all day whether you grok that or not! I've been doing front-end work for the past month, and I've had to do more low-level profiling and performance work here than in the previous 4 years of low-level systems work.
历次讨论
同类还值得读
用十年时间自学编程（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