职业与工作方法gwan.com
谷歌“工程总监”招聘测试
Google's “Director of Engineering” Hiring Test
2016 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
G-WAN 作者 Gilles 在博客中记录了他应聘 Google“工程总监”职位的电话面试经历：面试官照着一张标准答案表提问，问出 MAC 地址长度、TCP 三次握手的十六进制表示等细节问题，并因他的回答与“纸上的答案”不符而质疑他。文章引发对 Google 招聘流程机械化、非技术人员面试技术人员的广泛讨论。
为什么经久不衰：它多年反复登上首页，因为它触及每个工程师都经历过的痛点——被照本宣科的招聘流程误判，同时评论区里 Google 内部人士的回应让这场争论更有层次。
HN 评论精选
Google 内部人士指出这些问题根本不属于总监面试，更像普通 SRE 岗位，且单方记录未必可信。
顺便说一句：作为 Google 的工程总监，我也负责面试其他工程总监候选人，这些问题没有一条出现在工程总监的面试指南或评分表上。这些是很多公司标准的 SWE/SRE 问题（尤其是 SRE），我猜他实际上是被按普通 SWE/SRE 岗位评估的。也许他申请的是工程总监职位，但对方决定按不同的级别/岗位来面试他。另外，对这类面试“记录”我总是持保留态度——每个故事都有两面，尤其当一方把另一方描述得像个白痴时，其百分之百准确的可能性历来“不太高”。
DannyBee查看英文原文
FWIW: As a director of engineering for Google, who interviews other directors of engineering for Google, none of these are on or related to the "director of engineering" interview guidelines or sheets. These are bog standard SWE-SRE questions (particularly, SRE) at some companies, so my guess is he was really being evaluated for a normal SWE-SRE position. IE maybe he applied to a position labeled director of engineering, but they decided to interview him for a different level/job instead. But it's super-strange even then (i've literally reviewed thousands of hiring packets, phone screens, etc, and this is ... out there. I'm not as familiar with SRE hiring practices, admittedly, though i've reviewed enough SRE candidates to know what kind of questions they ask). As for the answers themselves, i always take "transcripts" of interviews (or anything else) with a grain of salt, as there are always two sides to every story. Particularly, when one side presents something that makes the other side look like a blithering idiot, the likelihood it's 100% accurate is, historically, "not great".
非技术人员照表面试技术人员，既荒谬又无法评估真实水平。
我很惊讶他连 MAC 地址多长、SYN/ACK 等 TCP 标志位都记得这么清楚。你只需要知道它们是干什么的，需要细节时搜一下就行。让非技术人员面试技术人员也很奇怪，会闹出快排那种愚蠢讨论。照着表念问题的人无法给出任何有层次的反馈——一个稍微懂点代码的初级工程师都能听出对方是不是在堆砌技术名词。想想如果让外行来招聘医生会怎样？你会因为一个读了十年医学院的人不知道“麻筋儿”是什么而拒绝他吗？
lordnacho查看英文原文
I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing. It's a bit strange to have someone non-technical interviewing a techie. You end up with stupid discussions like the one about Quicksort. If you point out qs is one of several things with the same big-O, you'll probably also get it "wrong". But the real problem is that a guy who is just reading off a sheet can't give any form of nuanced feedback. Was the guy blagging the sort algo question? Did he know if in detail? Does he know what the current state of research on that area is? There's no way to know that if your guy is just a recruiter, but I'm sure even a relatively junior coder would be able to tell if someone was just doing technical word salad. I wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face.
面试也是软技能考验：对着照本宣科的招聘官硬刚技术细节，赢了道理输了机会。
评论区很多“哈哈，蠢招聘官”的回应。但我要说，面对一个拿着答案纸的非技术人员做技术电话筛选，弄清楚对方想要的“正确答案”也是挑战的一部分。这可是工程总监面试——理解语境、与“真实的人”打交道、软技能本就是岗位职责的一部分。回答三次握手的十六进制表示？真的吗？你可能遇到了蠢招聘官，觉得自己很聪明，但在我看来，考虑到对方明显在照纸念答案的语境，你的回答方式相当愚蠢。我以前会说“哦，答案可能在你那张表上”，招聘官就会说“啊对，打勾”然后跳过几个我本可能答错的问题。如果你非要“刚到底”——恭喜，你赢了道德之战，祝下次求职好运。
philjr查看英文原文
Without actually hearing the transcript verbatim, it's hard to give much enlightened perspective here, but there's a lot of "hur hur, dumb recruiter" responses here. What I will say, in general, is that figuring out what the "right" answers are here for what is obviously a technical phone screen by a non-technical person with answers on a piece of paper is also part of the challenge. This is a Director of Engineering interview. Understanding context & navigating "real people", having soft skills etc. is meant to be part of the job description. Feels like this gentlemen couldn't turn the hardcore engineer off who's technically right about everything but yet never seems to get anyone to listen to him. Giving the hexadecimal representations of the 3-way handshake... really? You may have gotten a dumb recruiter and you may think you're smart, but from my perspective, you answered the questions in a pretty dumb way given the context of non-technical recruiter, very obviously reading answers from a sheet of paper. I've done two of these before and I've often said "Oh well, it might be down on your sheet at this thing" and the recruiter goes "Ah, yeh, that's it. Tick" and moved through 3-4 questions that in theory I might have gotten wrong. If you take the "be a dick" routine... Congrats. You won the moral war. Best of luck with your next job.
换个角度看：面试者可能高估了自己的资历，流程筛掉他正是其设计目的。
一位真正的 Google 工程总监指出这些是个人贡献者级别的 SWE/SRE 问题（我自己应届毕业时也被问过几乎一样的题）。仔细读会发现，他们可能并不是在面试他做工程总监——只是他觉得自己作为一家很小的软件公司“写代码的 CEO”够格担任工程总监。他大概是在被面试 SRE 团队主管之类的职位。而且，如果你假设面试者记错了问题，很多对话就说得通了。这样一来，筛掉一个自我评价过高、认定电话那头是蠢货的人，恰恰是这个流程该做的事。
geofft查看英文原文
This was posted previously, in October 2016: https://news.ycombinator.com/item?id=12701272 An actual Google director of engineering pointed out that these are individual-contributor SWE/SRE questions (and I can attest I got very similar questions as a new college grad). As I commented previously: "Reading more closely, it sounds like they are not interviewing him for a director of engineering position; it just sounds like he thinks his current role, CEO-who-writes-code of a very small software company (http://www.gwan.com/about), qualifies him for a director-of-engineering-level position. He's probably being interviewed for an SRE team lead or thereabouts." Also, a ton of this conversation makes a lot more sense if you make the assumption that the interviewee is misremembering the questions: https://news.ycombinator.com/item?id=12702726 (Which is a very gentle assumption, if the interviewee also mistakenly thought they were being interviewed to be a director of engineering.) In which case, screening out someone with an inflated sense of their own experience and overconfidence that the stupid person on the other end of the phone is stupid is exactly what this process is supposed to do.
历次讨论
同类还值得读
用十年时间自学编程（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