职业与工作方法news.ncsu.edu
研究：科技公司面试考的是焦虑，不是软件技能
Tech sector job interviews assess anxiety, not software skills: study
2020 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是北卡罗来纳州立大学（NC State）2020 年发布的一项研究报道：研究者让参与者在有面试官站在身后、要求边解题边口述思路的情境下做题，并与独自安静解题的对照组比较，发现被观察的压力会显著影响表现——也就是说，技术面试常常测出的是应聘者的焦虑程度，而不是真实的编程能力。
为什么经久不衰：它用实验证据说破了程序员们长期吐槽却难以证实的体验：白板面试在考心理素质，因此每逢求职季都值得重读。
HN 评论精选
研究设计有混淆变量——口述本身增加了认知负担，未必只是焦虑在起作用。
原论文在这里。研究把参与者分成两组：一组独自安静解题，另一组被要求边解题边向站在身后的面试官口述思路。这项研究的缺陷在于两组做的其实不是同一件事——解题和口述解题过程并不等同。作者把差异归因于焦虑，而不是第二组多出来的口述负担。参与者自己也说困难来自要边写边说、边想边说；此外相当多的人（包括安静组）在30分钟限时的第10分钟就放弃，这也是研究设计上的问题。
PragmaticPulp查看英文原文
Link to actual study: http://chrisparnin.me/pdf/stress_FSE_20.pdf The study participants were split into two groups. One group solved the problem alone, in silence. The other group was instructed to narrate their thought process out loud to an interviewer who stood over their shoulder (literally, see the photo on page 3) while they solved it. The flaw in this study is that the two groups weren't really assigned the same task. Solving a problem isn't the same as verbally narrating your solution to a problem. The authors attributed the differences not to the extra work narration work assigned to the second group, but to anxiety levels. The participants even explained that their difficulty came from having to talk while solving: > Participants also had difficulty with performing tasks that involved multiple simultaneous actions. Participants felt stressed by having to “talk while trying to write” (P44), “talking while writing” (P25), and “think and talk and do code at the same time” (P39). P41 found it difficult to “constantly speak during solving” and “lost breath at a few places during the task”. There are other concerns with the study format such as many of a significant number of participants simply giving up well before the clock ran out, in both the private and public interview groups. They were given 30 minutes to solve 3 problems, but some of the participants (including in the private group) were giving up around the 10 minute mark without solving anything at all. This suggests a very high variance of the underlying abilities of their candidates, which necessitates a much larger sample size to draw conclusions.
面试官亲身经历“翻车”后才明白：糟糕的面试表现并不等于能力差。
我在第一家 FAANG 公司做过两三百场面试，常惊讶于简历上有多年微软或 Facebook 经验的候选人竟然“不会编程”，还暗自想“难怪干三年就走了”。后来我去另一家公司面试，自己彻底搞砸了，才恍然大悟：那些人当然都是合格的程序员，只是那天状态糟糕、多半是紧张，但他们本来大多会是很好的同事。我当初得多傲慢，才会认为不能在45分钟白板高压下快速漂亮地解出算法谜题的人不配和我共事。
CobrastanJorji查看英文原文
I conducted a couple hundred interviews for my first FAANG employer, and I was constantly amazed at the percentage of candidates with years of Microsoft or Facebook experience on the resumes who apparently did not know how to program. I always thought, 'huh, guess I know why they quit after 3 years, amazing that they all lasted this long." Then I interviewed for another company and utterly bombed. It became suddenly clear to me that I had been an idiot. Of course nearly all of those candidates were perfectly good programmers. They had had shit interviewing days, probably mostly due to nerves, but they probably would have mostly been perfectly good employees. How frickin' arrogant I had been for concluding that people who couldn't solve incredibly high stakes algorithm riddles on a whiteboard in 45 minutes with enough speed and flair were somehow not qualified to be my coworkers.
候选人的表现高度受时段、饥饿、状态等偶然因素影响。
人确实会失常，好人也会。这很遗憾，但是系统的一部分。有次面试一个候选人，我的题目故意设计得很简单，可他几乎什么都做不出来，连暴力解法都不行，连平均数和中位数都分不清，我在反馈里唯一能写的优点就是“似乎懂一点基本语法”。后来看到其他面试官都说这是他们多年见过最出色的候选人，我才学到一课——我这场被排在午饭前，比平时晚；在别人开始午休后开始面试，简直是自找的。他最后还是被录用了，委员会显然认为“饿了就不会思考”不算什么大缺陷。
lrem查看英文原文
People bomb, including good people. That is sadly part of the system. Once I had this candidate. Damn, I know my questions are deceptively simple on purpose, but he literally couldn't do anything. Not even a trivial brute force. Not even any related simple knowledge questions. Couldn't tell an average from a median. The only good thing I could write in the feedback was "seems to know some basic syntax". It was quite a learning moment to read that everyone else was praising how this was the most brilliant candidate they've seen in years. Well, mine was the interview just before lunch, in a schedule that was atypically later than usual. I guess starting an interview after most people start their lunch break was asking for it. He also got hired - apparently the committee agreed that "can't think when hungry" is not really that important a flaw.
面试考的是求职意愿和投入度，而不是工作能力。
在我看来很明显：这类面试就是在评估你有多想进这家公司——你愿不愿意花几个月刷题、做模拟面试、看书备考，只为争取一个机会，尽管这些内容对日常工作大概毫无用处。仅此而已。如果工作需要，我过去实现复杂算法毫无问题，如今连它们的名字都说不上来；而要把它们背到能独立默写的程度，需要多得多的投入，明知大多最后留不住。竞技体育和升学考试也是同一套系统：它们主要衡量你多想进这个圈子，而不是你进去后表现如何。如果入职前测试和入职后表现完美相关，就不会有绩效改进计划和按绩效裁员了。
chpmrc查看英文原文
It seems pretty obvious to me that this kind of interviews are simply there to assess how much you want to work for a certain company. As in: would you be willing to study for months, go through mock interviews, read books, test your skills etc. to have a shot at working for us? Even though the majority of that stuff will likely have zero impact on your day to day work? That's all there is, really. I've had no problems in the past implementing complex algorithms, if I needed it to get the job done. Today I'd barely be able to tell you their names. But to get to the point of knowing most of them by heart and being able to implement them with no help whatsoever, would take a lot more work and dedication, knowing that you'll probably end up not retaining most of it anyway. The same system is used in competitive sports and academic tests. They mostly measure how much you really want to be part of that league/team/school, rather than whether you'll do well or not. If there was a perfect correlation between pre and post entrance test performance there wouldn't be PIPs, performance based layoffs etc.
历次讨论
同类还值得读
用十年时间自学编程（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