职业与工作方法github.com
不搞白板面试的招聘公司列表
Hiring Without Whiteboards
2017 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是一个 GitHub 上的开源清单，收录那些招聘流程中不使用白板算法题的公司，并附上各家的实际面试方式说明。它反映了开发者社区对“现场白板写算法”这一面试惯例的广泛不满，多年来反复登上 HN 首页，成为讨论技术面试改革的常用参考资源。
为什么经久不衰：白板面试争议多年未解，这份持续维护的清单为求职者和招聘方都提供了可操作的替代方案参考，因此历久弥新。
HN 评论精选
分享了一套“候选人反面试+带回家任务+代码评审”的三步无白板招聘流程，效果很好
我们采用三步流程，不用白板：1. 第一轮让候选人面试我们，了解市场、开发流程和技术栈，如果对方准备充分、提问到位，就发给他们；2. 一个编程任务——从 5 个源自我们实际设计的问题中选一个，要求不超过 100 行代码、2 小时工作量，日历时间不限，多数候选人都有全职工作。之后候选人回来，在我们团队面前主持一次代码评审，我会事先强调：评审目的是了解他们如何思考和解决问题，而不是批评风格；3. 第三轮与其他职能的管理者面谈，考察沟通能力和对公司的兴趣，同时争取组织内部的认可。我们喜欢这种方式，因为候选人可以在更自然的环境中写代码，没人职业生涯是在白板上写代码度过的。
11thEarlOfMar查看英文原文
We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask for 100 lines of code and not more than 2 hours. They take as much calendar time in days as they need, most have full time jobs, and let us know when you're done. The candidate then comes back, typically in 2 to 7 days and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not to criticize their style and approach. 3. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It's a check point to look for concerning weaknesses, as well as get buy in from the broader organization. We like this approach because it allows the candidate to code in a much more natural environment. They can take the time they need and comfortably solve. No one spends their professional career coding on a white board. This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.
亲历带回家项目式面试体验极佳，呼吁有能力的公司改革流程
我曾在清单上的一家公司面试过，流程是带回家项目：给一个玩具应用选择并实现几个功能增强，后续面谈讨论我的思路、设计和技术权衡——都是专业软件工程师工作中真正要做的事。过程有挑战但公平，流程之合理给我留下了极好的印象。带回家项目也不是完美方案，主要问题是要求候选人有工作之外的空闲时间。但作为喜欢慢慢消化问题的开发者，我宁愿每次申请花几小时做项目，也不愿花无数时间准备紧张的白板谜题。如果你所在的公司还在用高压算法谜题折磨候选人，而你又有能力改变流程，请效仿这份清单上的公司。
mbil查看英文原文
This is a great list. Thanks for sharing it. I actually had the pleasure of interviewing at one of these companies before. They had a take-home project, which was to choose and implement and couple enhancements to a toy app. In the subsequent conversations, we discussed how I approached the problem, details of my design, technical tradeoffs, etc -- all the sorts of things you would expect a professional sw engineer to be able to do on the job. It was challenging but fair, and I was struck by how reasonable the process was. It left a wonderful impression on me. Take-home projects are not a perfect solution to the interview problem. A major issue is that they require candidates to have free time outside of work to complete them. Personally, though, I'd much rather spend a few hours per application working on projects than countless hours prepping for stressful whiteboarding puzzles. As a developer who prefers to digest problems slowly, I look forward to the demise of on-the-spot whiteboarding interviews. If you work at a company that subjects candidates to such high-stress algorithmic riddles, and you have the ability to make your process more sane, please consider following the lead of cos on this list.
指出白板面试文化的恶果：刷题比做好本职工作更能带来职业回报
这是又一场技术面试讨论，我想引用本月早些时候一个帖子里的子讨论：“说实话我有点不敢离开现在的 FAANG 职位，因为我很确定不刷更多 LeetCode、不经历更多轮面试，我进不去第二次。”——一位 Big N 的技术负责人回复：“最令人沮丧的是，我知道在面试中根本无法 leverage 我过去 7 年职业积累的任何东西。”还有人说：“既然如此，何必在工作中做超出最低要求的事？把时间精力投入刷题和练面试才是更好的投资。”即便我们在争论技术面试指标的有效性，也值得思考整个行业衡量工程师价值的指标——这种 FAANG 中的存在主义式恐惧与绝望，既发人深省又有点悲哀。
Apocryphon查看英文原文
This is yet another tech interview discussion, so I'd like to highlight a subthread from the one earlier this month: > I'm actually a little scared to leave my current FAANG gig for that exact reason tbh. I'm fairly certain I wouldn't make it back in the door without more leetcode grinding + repeated loops than I'm willing to do at this point in my career. >> I'm in a similar position - a tech lead role at a Big N - and have recently been doing some interviews for senior roles at FAANG. The most frustrating thing is knowing I can't really leverage anything I've learned over the past 7 years of my career in the interview, at least at the early stages. >>> I feel extremely little of what I'm doing in my real, actual, job, helps me in advancing in my career. Unless maybe if I choose to stay at my current company until retirement lol. Otherwise, why bother doing anything more than the bare minimum to get by at work? It would be a far better investment of time and effort to grind leetcode and practice for interviews, instead of going above and beyond to excel at my job. At least until I get into an "endgame company" where I feel it's worth staying long term. https://news.ycombinator.com/item?id=23848717 Even as we debate the validity of the metrics measured by technical interviews, it's also worth considering the metrics used to measure engineer worth in the industry at large. This existentialist "fear and loathing in FAANG" discussion was quite illuminating, and a little sad.
以亲历者身份描述白板面试如何让优秀开发者大脑冻结、无法发挥真实水平
想象一下：你去面试，走进一个房间，两个人递给你一张写有几道题的纸，让你在白板上写解法，他们一言不发，盯着笔记本电脑和白板，像等精灵从瓶子里冒出来。你的大脑僵住了，陷入死循环。一小时后时间到，你勉强完成了一部分。握手告别如同死亡之吻。走回去的路上，所有题目的答案如洪水般涌入脑海——可惜，又一场“搞砸了”的技术面试。这是我作为一个身经百战、12 岁起就因热爱编程、专业写代码 15 年以上的开发者的亲身经历。
kelvin0查看英文原文
Imagine this. You are interviewing for a job, you walk in a room with 2 people who hand you over a sheet with a few problems. They ask you to write the solutions on the whiteboard, while they wait for you to complete. Not a word is said, they are clicking at their laptops, and staring at the whiteboard, as waiting for the genie to pop out of a bottle. All the while your mind is frozen and stuck in a bad loop. This lasts an hour, you are barely able to complete parts of the problems and are frozen. Of course this affects your usually creative and sharp mind. The torture lasts an hour, time's up! You shake their hands, as a kiss of death, and head out. As you are walking back, all the answers to all the problems they wanted you to whiteboard, come rushing like a torrent in your mind. Too bad, another 'botched' technical interview. This is my experience as a battle tested developer who is shipped many products and has been programming for the love of computers since the age of 12 (professionally for more than 15 years). I am not going to be working at Google any time soon (not that a Google job really matters to me).
历次讨论
同类还值得读
用十年时间自学编程（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