职业与工作方法seldo.com
技术面试糟透了（2014）
People suck at technical interviews (2014)
2014 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章探讨技术面试为何常常失效，指出面试难以准确判断候选人的实际工作能力，并引发关于fizzbuzz测试、作品集、基本编程题等评估方式的争论。作者认为技术面试往往浪费时间和误判人才，而评论者则从招聘经理、面试官和候选人的角度提供了不同视角。
为什么经久不衰：技术招聘中的评估难题长期存在，关于面试是否有效、如何改进的争论至今仍能引发共鸣。
HN 评论精选
程序员应像技术艺术家一样用作品集证明能力，而非依赖面试测试。
需要转变对程序员‘类别’的认识，编程既是技术也是艺术，是依靠技术技能的创造性工作。类比摄影等‘技术艺术’行业，公司应重视作品集而非用面试测试量化艺术技能。程序员应创建展示技术和艺术技能的作品集，公司应认真对待。
PuffinBlue查看英文原文
There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture, drafting, perhaps writing too. It seems at the moment that companies are approaching programmers as if they are purely technical like an actuary or bookkeeper and are seeking to quantify artistic skill through interview tests. This is rubbing off on some programmers who begin to think of themselves in these terms. I don't recall a single instance as a photographer where I had to quantify my technical skill, but there were hundreds of times I had to based on my artistic skill, proving I had already made a vast range of photographs with sufficient quality to 'prove' my ability and by extension proving my technical ability. Crucially, it was the fact I had a portfolio that allowed me to prove my ability, both artistically and technically. I see a similar need in programming. I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously. At the moment it seems that far to many programmers are attempting to get jobs without a 'portfolio' which is why, in an creative endeavour like programming, companies that hire are trying to quantify and determine a new hires ability with these seemingly bullshit tests. There's room for improvement in this argument and there are outliers, but I think the basic premise is sound.
fizzbuzz考的是基本编程能力而非模运算，能有效筛掉不会写循环的人。
老实说，我不确定作者面试过多少人。比如fizzbuzz测试并非考模运算，而是考能否轻松写for循环。fizzbuzz并不算法，几乎每天都要遍历集合。如果候选人花20分钟做fizzbuzz，那正好节省时间。我曾认为fizzbuzz是侮辱，但面试后发现很多人10分钟还出错，它是很好的预测器。
skrebbel查看英文原文
In all honesty, I'm not sure the author did a lot of interviewing. For example, > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There's a rightfully vivid debate going on about the virtue of asking algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd wager that virtually all programmers iterate a collection at least once daily. The followup sentence drives it home for me: > Yet people will spend twenty minutes on it in an interview, a huge waste of limited time. Well, if it takes an applicant twenty minutes to Fizzbuzz, you're done! Just saved everybody lots of time. I used to think Fizzbuzz was insulting and bullshit until I started interviewing. I haven't yet met a programmer who couldn't solve a Fizzbuzz-level question, but I've met many who took over 10 minutes and made little logical errors. It's a great predictor for "can this person actually program, well, at all?".
技术面试必要，因为简历造假普遍，简单编程题就能筛掉一半不合格者。
招聘经理视角：人人撒谎。作为候选人我讨厌技术面试，但作为决策者我离不开它们。我的技术面试很简单：基本SQL题加数据库设计QA，完全工作相关。我不在乎语法细节，但会在乎写出LISP和Java杂交代码、声称会SQL却写不出基本语法、简历有Oracle证书却答不出JOIN的人。平均完成时间2分钟，拒绝率至少50%。
hanginghyena查看英文原文
Hiring Manager Perspective: Everyone lies, sorry. As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them. My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax. I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume. The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff. That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate. I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars. And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
面试中的小问题无法反映真实工作能力，实际项目经验和长期表现才关键。
我正在经历许多技术面试并全部失败，我爱这篇文章。我的技术能力从作品可见，有20多年编程经验。但我面试很差。用一小时判断与我工作一年如何是荒谬的。他们给的小问题是最琐碎的部分，难的是组织、文档、系统稳定性、设计算法、决策、愿景等。内向、单调声音、面无表情对性格测试不利。
gavanwoolery查看英文原文
As someone who is going through many technical interviews right now, and failing all of them, I love this article. (It was actually brought to my attention last week.) My technical ability is readily apparent to those who have viewed my work, and by virtue of those who have praised it. I don't claim to be the best programmer in the world, just a competent one. I've also been programming for over 20 years, that might have something to do with it. However, I suck at interviews, in any way shape or form (personality tests, technical tests, you name it). Yet I've aced every job ever given to me, and people love to work with me (even in spite of my salty attitude). To think that you can determine what it is like to work with me over the span of a year within the span of an hour is completely and utterly ridiculous. As it turns out, the little sub-problems they give are the most trivial part of programming. The hard part, the part it takes many years to get any good at, is coherently organizing, documenting, and ensuring the stability of a larger system, particularly concurrently with other programmers. Or designing an algorithm that you can't just Google. Or making a really tough decision about what features to cut or what direction to pivot. Or organizing a vision of what will add the most value for the customer. Or...etc Being an introvert with a monotone voice, general lack of expression, and deadpan sarcastic humor does wonders for personality tests. Most people's default reaction to me (in interviews or otherwise) is that I am a total dick. Which I am, but the kind you don't mind hanging around. I don't do well with programming that has a one hour deadline. But give me a day and I can produce the typical output a programmer would within a day. If I spent all my time practicing for interviews, I'd probably be better at them (with stuff like Top Coder or Interview Cake or whatever). And I think giving these things a whirl is well worth it (not for the sake of winning in interviews). But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks (sorry, writing a red-black tree on a white board within an hour never happens to me in the real world).
历次讨论
同类还值得读
用十年时间自学编程（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