职业与工作方法danluu.com
算法面试：理论与实践
Algorithms Interviews: Theory vs. Practice
2020 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇长文讨论大厂算法面试的理论与实践差距：算法题到底在筛选什么、与岗位实际需求是否匹配，以及招聘流程中的错配和组织激励问题。文中也涉及 Google 面试经历、Code Jam 题目和绩效/薪酬机制等例子。
为什么经久不衰：它不只争论该不该考算法，而是把面试放回招聘机制和组织激励里看，多年后仍能解释大厂面试为何难改。
HN 评论精选
Code Jam 小题可暴力解，几何题对通才岗不公平，要求大测试集解法不现实。
我朋友曾在 Google 电话面试里遇到一道 Google Code Jam 世界总决赛题。我怀疑全世界没几百人能答对，而且他们几乎都会意识到这题放在电话面试里很荒谬。我觉得 Dan 漏掉的背景是：Code Jam 题通常有 small/large 数据集；small 是 N=10，暴力可做，和常见面试暴力题差不多。对通才岗位来说，几何题更不公平（若岗位涉及图形学、CV、自动驾驶地图则另说）。要求解 large N=2500 当然离谱。
fyp查看英文原文
> a friend of mine once got a Google Code Jam World Finals question in a phone interview with Google (...) I doubt there were more than a few hundred people in the world who would've gotten the right answer to the question in a phone screen and almost all of them probably would've realized that it was an absurd phone screen question Link to the question: https://code.google.com/codejam/contest/2437491/dashboard#s=p2 The gist of it is: You are given 4*N points on a 2D plane. Can you draw two perpendicular lines to separate them into N points per quadrant? I think Dan's missing context is that google code jam questions always have a small and large dataset. In this case, small is N=10 which makes a lot of bruteforce solutions possible and not much different from any other bruteforce puzzles common in interviews. Being a geometry question is the more unfair part if this is a generalist role (but not unfair if your role involves graphics, computer vision, self driving car mapping, etc). Expecting a solution for the large (N=2500) is ridiculous of course. See analysis: https://code.google.com/codejam/contest/2437491/dashboard#s=a&a=2
算法面试实际筛的是智力和模式匹配，以及愿意为工作准备/忍受不感兴趣任务的意愿，不只是防止 O(n^2)。
问热门大厂为什么强制考算法时，最常听到的回答是“规模太大，不能承受有人写出 O(n^2) 把站点搞挂”。我觉得这么说的人没抓住重点。这类面试主要筛的是：1）混合了智力和模式匹配的问题解决能力；2）愿意为获得/保住这类工作去做未必有内在动力的事。要通过，通常需要智力、模式匹配能力，以及即使不真正在意也愿意花时间准备面试的动力。它不是完美过滤器，会有误报和大量漏报，但“够用”。FAANG 里每 10 到 100 个工程师大概只需要一个 Dan Luu 级别的人；多数人做的是模式匹配式工作，只要足够有动力就能长期做下去。
Ozzie_osman查看英文原文
> When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site down". I think people who say this just don't get what's really going on here. If you look at these types of interviews, a big part of what they select for is: 1) Some sort of problem-solving skill that's a mix of raw intelligence and/or ability to solve problems by pattern-matching to things you've seen before. 2) Ability/commitment to work on something that may not be that intrinsically motivating, in the context of getting/maintaining a certain type of job. These interviews select exactly for that. To pass, you usually have some mix of: - raw intelligence. - ability to pattern match to similar problems you've seen before. - ability and motivation to spend time preparing for these types of interviews, even if they're not really what you care about doing. That's really what they're trying to capture. It's not a perfect filter (you will still have some false positives and plenty, plenty of false negatives), but it works "well enough". You really only need one Dan Luu per like 10 or 100 engineers at a FAANG. Most people aren't going to be optimizing at the level he is, they're going to be doing work that's mostly a mix of problem-solving by pattern matching, and ideally, they're motivated enough to have that job for as long as possible.
绩效和薪酬机制可能反向激励：干到“够好”就停，零和加薪让高效团队吃亏，员工要认识并推销自己的价值。
评论引用了文中两段：公司可能给超大额例外奖金，但若工作所在公司不常这么做，员工拿到最高绩效后，公司就没法再表示重视额外贡献；从机制设计看，这等于让员工“干够就停”。另一段是：很多公司给经理的加薪预算主要按人头决定，再在团队内零和分配；如果团队几乎都是高效工程师，没人能在零和加薪中表现突出。团队因同事好而流动率低，公司却用薪酬这个最大杠杆促使人们离开高效团队、去更弱的团队。承认组织有榨取最大价值的激励后，员工应：1）知道自己产出的价值；2）会推销它。这在晋升季也常见：要求你在下一级别职责上做到 50% 以上才有资格晋升，但没说出口的是……
Infinitesimus查看英文原文
> Some companies will give very large out of band bonuses to people, but that work wasn't for a company that does a lot of that kind of thing, so there's nothing the company could do to indicate that it valued additional work once someone did "enough" work to get the best possible rating on a performance review. From a mechanism design point of view, the company was basically asking employees to stop working once they did "enough" work for the year. and > This also happened in another way. As is common at a lot of companies, managers were given a team-wide budget for raises that was mainly a function of headcount, that was then doled out to team members in a zero-sum way. Unfortunately for each team member (at least in terms of compensation), the team pretty much only had productive engineers, meaning that no one was going to do particularly well in the zero-sum raise game. The team had very low turnover because people like working with good co-workers, but the company was applying one the biggest levers it has, compensation, to try to get people to leave the team and join less effective teams are pretty important points to note. Accepting that organizations are incentivized to extract the maximum amount of value from you means you should be: 1. Aware of the value you produce 2. Know how to sell it This also comes up during promotion season in places that require that you perform at 50%+ of the next "level" to be eligible for a promotion. The unsaid part is that you will be under compensated for that 50% "next level" and when the promo comes, you'll be at the bottom of the comp band at the new level (no wonder people tend to quite shortly after a large promotion)
Google 内部像多家公司，招聘路由错配严重；内推命中率低，背景匹配和 recruiter 流程很关键。
有趣的是，我在 Google 的内推命中率约 1/10：不是 10%，而是我提交了约 10 人，只有 1 人拿到 offer。我认为所有人都合格、都该拿 offer。作为对比，我大概做过 100 场面试。而且我还会主动劝人别申请，所以样本只包括“明白后仍要内推”的人。Google 现在更像几十家独立公司：Search/Ads、YouTube、Cloud、Photos、Android、Maps 等，路由不同体验差异巨大。就像 Dan 被错误导向软件面试，我朋友背景是图形学博士、从没写过网络程序，却被扔进 SRE 招聘流程问大规模分布式系统。给 Google 员工的建议：找到朋友真正想要的内推岗位，和 hiring manager 确认它对应外部招聘页的哪个岗位（常常对不上），再告诉分配到的 recruiter 你是认真推荐。Recruiter 仍可能否决你。
boulos查看英文原文
So, amusingly, my referral hit rate at Google is like 1/10. Worse, I only refer people if they've told me that they're certain they wish to go through the terrible process. When I say 1/10, I don't mean 10%, I mean I have entered about 10, and only one got an offer. In my opinion, all were qualified and should have been given offers. For comparison, I've done roughly 100 interviews or something (though not nearly enough SWE interviews, because I'm in San Francisco). As an additional upwards bias, I actively discourage people from applying, so this is only the folks that said "I understand, refer me anyway". All that said, Google is really more like dozens of independent companies now. There's Search/Ads, YouTube, Cloud, Photos, Android, Maps/"Geo", and so on. Your mileage will vary pretty drastically depending on how you're routed. Just like Dan was misdirected towards a software interview, I've had friends tossed into the SRE hiring pipeline, asked how to operate large-scale distributed systems and so on, when their background is "Umm, I just did my PhD in CS in Graphics... I've never written a networked program in my life". To all the other Google employees: find the job posting internally that your friends would actually want, talk to the hiring manager to figure out what that maps to externally on the job postings page (it often doesn't), and then tell the assigned recruiter that you're serious about your recommendation. The recruiter may still override you in deference to their hiring targets / goals though (the one offer I've seen from my referral went this way despite my effort), so don't promise your friends that you can fix it for them. I'm not here to excuse these hiring practices. Instead, be honest with yourself about why you want to apply, and how much hassle you're willing to put up with. In my experience, all other companies will decide more quickly on your hiring result, role, level, compensation and so on. I believe that's because of the scale of the interviewing and hiring (>10k full-time employees per year for the last few years), except it's always been pretty bad at Google.
历次讨论
同类还值得读
用十年时间自学编程（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