职业与工作方法quuxplusone.github.io
我遇到过的最好的工程面试题
The best engineering interview question I've ever gotten
2022 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者分享了他认为最好的工程面试题：给候选人一个不熟悉的真实代码库（memcached），让其在限定时间内阅读源码并实现一个新功能（如乘法命令），考察快速理解陌生代码的能力。出题者（数据库公司）认为这种能力在实际工作中至关重要。
为什么经久不衰：它展示了一种比刷题更贴近真实工作的面试思路——读陌生代码库并动手改代码，对设计技术面试仍有参考价值。
HN 评论精选
出题者解释题目来源：考察快速理解陌生代码库的能力，与实际工作高度一致
出题者本人：我在公司工作几个月后想出这道题，因为“快速钻进陌生代码并搞明白”对我们非常重要。数据库代码库庞大复杂，入职第一年做的几乎每个新功能都像这道题。多年评估中我们了解了它的各种偏差（误报和漏报），甚至有人沮丧到把笔记本摔在地上。欢迎提问！
ankrgyl查看英文原文
Author of the interview question here. I came up with the idea after working at the company for a couple months and realizing that the skill of "diving into an unfamiliar area of the code and quickly figuring it out" was very important for us. Database codebases are large and complex -- so much so that almost every new feature you work on for the first year or so feels a lot like doing the question. Over the years of evaluating with it, we learned a lot about its quirks (both false positives and false negatives). At one point, someone got so frustrated that they threw their laptop on the floor. Happy to answer any questions about it!
批评3小时高压面试不合理，正常工作不需要这种压力测试
大家先冷静一下，别急着夸这道题。让候选人在面试中煎熬3小时没什么好的，如果真有人气得摔笔记本，那就更糟了。是的，筛掉脾气差的人也许有道理，但我不明白为什么一份正常的案头工作需要证明自己能在这种压力下不崩溃——我们是在写代码，不是在拆定时炸弹。
mihaitodor查看英文原文
To everyone praising how good this challenge is, calm down. There's nothing great about making somebody sweat for 3 hours during an interview. It's even worse if "someone got so frustrated that they threw their laptop on the floor" like the top comment claims. Yes, it would be great to avoid hiring people who have a bad temper and tend to throw tantrums when nervous, but, then again, it's beyond me why anyone would need to prove they can cope with such pressure without breaking down. We're talking about a desk job here, which requires writing good quality code according to some requirements during normal working hours, not disarming a bomb with a timer attached to it.
指出乘法与加法混合会破坏交换性，候选人若能想到这点是加分项
这是道好题。补充一个值得关注的回答：添加乘法命令会引入客户端未曾预料的失败模式。加法和乘法各自单独可交换、可逆，但混用时顺序会影响结果。如果客户端需要回滚一系列操作，加入乘法后就必须显式保证顺序。候选人若能主动讨论这一点，是经验的良好信号。
davidst查看英文原文
This is a great interview question I don't want to be 'that guy' by picking at what may be a detail but there is another response to look for from a candidate. We should think very carefully about adding a multiplication command because it introduces a failure mode that may be unanticipated by the client. Code that previously worked could begin to fail after this command goes into use. Specifically, if the client needs to revert a series of operations on integers, and if the operations are transitive, there is no need for a mechanism to ensure they occur in any particular order (the usual caveat about working within the limits of precision applies.) This holds true for addition and for multiplication, in isolation, but is not true if they are combined. Change the order and the end result will change. Adding multiplication puts a burden on the client to understand this risk and be explicit in the ordering. Some people may argue that the client should already understand it and they have a point. We can't defend against every possible misunderstanding. I think there is a good discussion to be had on this question and if the candidate were to go there, it would be a favorable sign of experience on their part.
为仔细读代码的候选人辩护，认为时限偏紧但题目本身公平
为什么“反复阅读实现、确认没有魔法、搞清锁的实现和模块化程度”的类型1程序员被看扁了？这明明是好事。另外这题有点像找模式，竞赛编程背景的人可能真需要3小时。有合适的IDE和grep工具的话这是道公平的题，但时限确实夸张。不过如果面试的是做数据库产品的公司，你确实该懂基本操作是怎么实现的。Redis 源码读起来也很有趣。
abhishekjha查看英文原文
Why is the type1 programmer being looked down upon? I mean I am sure that I want to make sure how the lock implementation is. I also want to know if it is modular enough to be called somewhere or is it baked in the add step. I sure do want to multiple times read the add implementation and make sure there isn't a magic somewhere. And finally this problem looks a lot like can you see a pattern!! I mean sure but a lot of people who might go to interview with standards of competitive programming might take the whole 3 hours because there's a lot to rule out. I guess this is a fair question with a proper IDE and grep tools. The timing does look outrageous but if you are interviewing at a company which builds databases as a product, you better know how basic operations are provided. Redis source code is fun to read as well.
历次讨论
同类还值得读
用十年时间自学编程（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