面小厂就比面大厂更容易吗？

在我做 career coaching 的过程中，我发现不少人觉得「如果进不了大厂的话，那就降低一点目标，总能进小厂吧」，然后他们发现小厂 offer 也拿不到，于是怀疑自己能力是不是如此之差。大家从升学考试的经验出发，「进不了这一档次的学校就尝试下一档次的学校吧」，把这种逻辑推广到「进不了大厂就尝试小厂吧」看起来很合理，但很不幸人才和公司的匹配并不适用这种模式。

---

我时常用这样一个比喻来描述大厂和小厂招聘的本质区别：

大厂招聘，就如同 Walmart（沃尔玛）去采购两吨苹果用来上架。作为一家超市，Walmart 肯定有一套经过长期优化的采购标准，一个苹果只要满足采购标准 Walmart 就愿意要。Walmart 不在乎这些满足标准的苹果之间有什么个体差异，因为绝大部分都会被顾客买走，一小部分会卖不掉然后烂掉，但这早已在营收当中考虑到，Walmart 并不会亏钱。

小厂招聘，就如同个人消费者去买两个苹果。无论你个人对挑选苹果有什么准则，你肯定会按照你的准则挑选两个最好的。每个人的挑选准则都不太一样，如果有足够多的消费者，绝大部分的苹果都会被买走。

应聘时你就如同是一个苹果。如果你想被 Walmart 采购，你就要满足 Walmart 的采购标准。但因为 Walmart 是一个非常成熟的超市，所以采购标准相对稳定和可预测，反而更容易有针对性地做优化。如果你想被个人消费者挑选，反而很难抓住具体的某一个消费者让他挑你。每一个个人消费者的挑选准则都不太一样，你猜不到当前在挑苹果的这一位消费者是怎么想的，如果他不挑你你也没有办法，再等下一位消费者吧。这个过程比较看缘分。

---

为什么大厂和小厂的招聘模式会截然不同？

小厂招聘往往是针对一个或几个很具体的职位做的。举个例子，公司创业一开始还没找到产品方向，想要招一两个什么都懂但不用太精通的全栈工程师，创始人想要尝试做什么产品，熬个夜第二天就把原型做出来了。尝试了多个产品方向后，公司终于找到了一个靠谱的方向，开始缓慢地有用户积累，顺便招个前端工程师来打磨用户体验。用户增长持续加速，当初熬夜写出来那个单体后端已经支撑不住了，于是要招个有 micro-service 经验的后端工程师来重新设计后端架构，把后端拆成多个服务，并且为将来 sharding 做准备。服务拆了之后，单体数据库通过 replica 还撑了一段时间，终于也要不行了，需要赶紧招一个精通数据库优化的程序员。小厂每时每刻面临的问题都不一样，用固定的标准招通才并不能有效解决问题。

大厂可以用固定的标准招通才，尤其是 Facebook 和 Google 这种全公司统一招聘的。虽然大厂内的每一个团队都好像小厂一样，拥有此时此刻特定的招聘需求，但因为团队数量足够多，所以在统计学上大厂可以无视这些差异按照一个标准来招人。由于大厂的招聘标准如此的稳定和可预测，针对大厂的招聘标准做准备反而更容易。你可以尝试搞清楚大厂的招聘标准，搞清楚后这套标准不会变来变去。一旦你满足了这套标准，你不需要太过关心个体差异。

如果你达不到大厂的标准，要参与小厂的招聘，那马上就会变成跟上述苹果比喻一样看缘分。你不知道具体哪个小厂正好需要你，你要明白到大部分的小厂当前的需求都跟你不匹配，从统计学的角度来说你必须通过大量的小厂去找一个匹配的。这时候你的体验会变得完全不一样，从只需要针对几个大厂做准备变成需要跟很多小厂打交道。

---

从升学考试经验推导而来的期望在这时候完全不成立。如果你高考差几分上不了北大清华，你很可能还是能去非常好的学校。但在找工作时，差一点进不了大厂并不意味着马上有小厂意识到你的价值把你招走，你需要在茫茫大海中搜索跟你匹配的小厂。这时候设置正确的期望很重要，大量小厂跟你擦肩而过，但这不代表你能力有问题，你需要坚持下去。

小厂的招聘流程并不像大厂那样标准化和可预测，那意味着他们扔掉你简历时并不一定是你简历有问题；他们面试时不像大厂一样按套路出题，他们会针对特定的招聘需求来出题，所以你答不上来不一定是你能力有问题；经验有限导致他们的面试并不一定能有效挑选人才，你觉得自己面得很好但他们不要你，同样不一定是你能力有问题。这个过程的负反馈可能比应聘大厂难受很多，你唯一能选择的就是坚持住继续尝试。

SystemsExpert 测评

SystemsExpert 是 AlgoExpert 新出的一系列针对系统设计面试的内容，包括系统设计常见概念的科普型视频，以及若干模拟面试题和答案。它的内容非常适合从来没有面过系统设计的人，用来了解系统设计是面什么的，以及需要用到哪些知识点。

我接触到不少学生，毕业时通过了算法面试、成为了软件工程师，工作一段时间后跳槽时发现需要面系统设计，但因为从来没接触过所以觉得心虚。其实大家工作一段时间后，都或多或少地在实践中接触到了系统设计，要么是看过已有系统被设计成什么样子，要么是自己设计如何把新功能添加到已有系统上。但是可能因为没有非常刻意地做设计、覆盘、沟通，所以知识不成体系。SystemsExpert 能够帮助大家解决这方面的问题，通过二十多个视频系统地讲述每一个常见的系统设计概念。可能你看完后会发现，很多概念是你已经在工作中用到了的，只是现在变成了一个很具体你能拿来跟面试官交流的东西。

现阶段 SystemExperts 包括以下这些概念的视频：

• 客户端-服务器端模型
• 网络协议
• 存储
• 延时和吞吐量
• 可用性
• 缓存
• 代理
• 负载均衡
• 散列化（Hashing）
• 关系型数据库
• 键值存储
• 特种存储（Specialized Storage Paradigms）
• 复制和分片（Replication And Sharding）
• 领导选举（Leader Election）
• P2P 网络
• 轮询和流式传输（Polling And Streaming）
• 配置
• 限速（Rate Limiting）
• 日志和监控
• 发布/订阅模式
• MapReduce
• 安全与 HTTPS
• API 设计

除此之外，SystemsExpert 还有一个视频提供系统设计面试的概述，简单介绍系统设计面试是考察什么的。每一个视频十分钟上下，不需要花很多时间看，内容很容易理解，但不会讲得很深入。

以上是 SystemsExpert 的优点，但它也不是没有缺点的。缺点是模拟题不可能好像 AlgoExpert 或 LeetCode 那样给你任何的反馈，唯一模拟了的地方是面试官回答你的 clarifying questions。除此之外，模拟题就提供一个白板，让你自己书写你要怎样回答这道题目。至于模拟题的答案，SystemExpert 跟 AlgoExpert 一样提供了高质量的官方答案，包括一个长视频讲解，和对应的图文解释。

如果此前没有系统设计的面试经验，或者觉得自己没有系统学习过，花 $79 买一年的 SystemExpert 是值得的。如果你决定要买了，可以考虑用我的折扣码。点击以下链接打开 AlgoExpert 的网站，然后选择购买 SystemExpert，或是 AlgoExpert + SystemExpert 的套餐，记得在付费前在「promo code」一栏输入「catchen」，然后就可以享受九折。请记得一定要输入「catchen」这个折扣码，单纯使用链接打开是不会自动打折的。

https://chen.cat/algoexpert-referral

P.S. 如果你不知道 AlgoExpert 是否值得一起买的话，可以去看我之前的《AlgoExpert 测评》。

CoderPro 测评

CoderPro 是 AlgoExpert 的竞争对手，既然我写了《AlgoExpert 测评》，那就让我再写一篇 CoderPro 的测评吧。先说结论：我不推荐大家独立去购买 CoderPro，因为其价格跟 AlgoExpert 差不多但功能远没有 AlgoExpert 那么多。如果你原本就购买了或打算购买 Tech Interview Pro，免费赠送的 CoderPro 倒可以看一看。

优点

• 视频容易消化。（每道题的视频控制在 15 分钟内且有些小幽默。）
• 只用 Python 来做讲解。

缺点

• 只有视频讲解，缺乏自己做题和测试的过程。
• 只用 Python 来做讲解。

因为我个人认为练习和反馈的过程十分重要，所以我不建议大家买来通过看视频来学习。如果你已经通过 LeetCode 进行练习，只是有时候有些题目解不出来，那往往你能在网上找到别人的答案，包括 YouTube 上的视频解答。

---

CoderPro 背后的八卦估计比产品本身更有趣。原本 Tech Lead 是 AlgoExpert 的一个 affiliate，通过自己的 66 万粉丝的 YouTube 频道推荐 AlgoExpert 并从中赚取售价的 50%。后来做 AlgoExpert 的把 affiliate 的费用从 50% 降低到了 40%，然后 Tech Lead 就不干了。

Tech Lead 做了 AlgoPro 这样一个竞品，也就是现在的 CoderPro。然后他注册了 AlgoExpert.com 并指向自己的 AlgoPro。（AlgoExpert 用的是 AlgoExpert.io。）这导致 AlgoExpert 的 Clement 在自己的 YouTube 频道跟 Tech Lead 怼了起来。

Tech Lead 回应说，这都是因为 Clement 贪心，把 affiliate 的费用从 50% 降低到了 40%。Clement 说 AlgoExpert 的题目数量增加后售价也涨了，新售价的 40% 并不比原售价的 50% 少。Tech Lead 悄悄把 AlgoExpert.com 指回去 AlgoExpert.io，但 Clement 仍然不满意，表示不欢迎一个别人的域名指向自己的产品。

现状就是，AlgoPro 不再叫 AlgoPro，改名为 CoderPro，不再跟 AlgoExpert 的名字有重合的部分，事情告一段落。作为吃瓜群众，想要去了解当时的八卦的话可以看那时候的视频。

既然我在这里提到了 Tech Interview Pro，接下来我也会写一写测评，想要关注的话欢迎通过邮件或 RSS/Atom 订阅我的博客。

AlgoExpert 测评

AlgoExpert 是一个我称之为「LeetCode 精选」的服务，因为 LeetCode 现在的题目实在是太多了，但解答、提示等内容的质量又参差不齐。AlgoExpert 解决了这些问题：首先，它提供不到 100 道算法题，覆盖不同难度和不同知识点；其次，每道题都有一系列循序渐进的提示，使得你可以从毫无头绪开始一步一步做到最优解；最后，每道题最后都有视频讲解，从最笨的解法开始一步一步讲解如何优化，最后达成最优解。

因为我不需要通过刷题来准备面试，所以我买了之后并没有真的去做题，只是打开题目想想自己会怎么做，然后看看提示验证一下自己的想法。我有测试过用它的界面来写代码，感觉还不错。以下是我试用后的评价：

优点

• 模拟面试过程中的提示，而且是每一道题都有提示，不像 LeetCode 那样有些题目没有提示。我觉得提示是模拟真实面试的总要环节，因为在真实的面试过程中你也可能会卡住，但一旦获得一个小提示后你就能解决剩余的部分。
• 内置编码环境，支持常见的语言（C#、C++、Go、Java、JavaScript、Python、Switch）。
• 内置测试环境，可以跑自己的测试数据，也可以查看官方的测试数据。
• 视频讲解多种解法并对比它们的时间、空间复杂度。

缺点

• 视频讲解比较慢。（不过内置视频播放器可以用 1.5x 或 2x 速度播放视频。）
• 支持的语言不如 LeetCode 多（缺了 C、Ruby、Scala、Kotlin、Rust、PHP）。

如果是为了找工作而刷题，我觉得 AlgoExpert 是一个比 LeetCode Premium 更好的选择。AlgoExpert 是 $85 一年，但 LeetCode Premium 需要 $159 一年。尽管 LeetCode Premium 提供的内容更多，但如果你不准备花时间做那么多题其实没用。而且我觉得通过 LeetCode 把各大公司常见面试题死记硬背一遍不是正确的做法，我更倾向于 AlgoExpert 这样子的，用少量题把不同的知识点覆盖到了，然后学会在面试时灵活变通更重要。

如果你想要买 AlgoExpert，你可以考虑用我的折扣码。点击以下链接打开 AlgoExpert，然后记得在付费前在「promo code」一栏输入「catchen」，然后就可以享受八五折。请记得一定要输入「catchen」这个折扣码，单纯使用链接打开是不会自动打折的。

https://chen.cat/algoexpert-referral

赴美工作常识（Part 4 - 面试）

最近跟同事讨论面试的事情比较多，所以就综合大家所说的列举几条面试建议吧。这些建议是针对中国候选人应聘美国职位而写的，但适用范围可能更广。假若你实际的实力是 X，面试官感知到你的实力是 Y，这些建议既不能让你实力暴增（X++），也不能让你展现超乎实际的实力（Y > X），只能帮助你避免由于沟通问题而造成的实力不被发现（Y < X）。

当做讨论而非考试

尽管面试有个「试」字，但在真正好的技术面试其实不是一问一答的考试，更多是如同同事之间的技术讨论一样，从比较糟糕的解决方案开始做优化，直到做到大家都可以接受的程度为之。这个观点在《理想的技术面试过程》中也提到过，在这里就说一下具体应该怎么做。

首先你要自信，不能觉得面试是公司对你的单向选择，其实是同时包括你对公司的双向选择。有些心理学上的技巧可以让你显得自信一点的，例如说在公司大堂等待的时候尝试深呼吸和伸展一下四肢。由于人的心理状态和身体语言是互相加强的，所以如果你使用自信的身体语言，你就会无意识地被「误导」以为自己确实自信，不过这正是你想要的效果。（如果你想更多的了解什么身体语言表示自信，可以去找本身体语言方面的书来看。）

然后你不要高估题目的难度。有些人可能被 Google 中国的某些面试官虐待过，觉得越是好的公司题目自然越难，但这其实是中国应试体系的思维方式而已，题目难度不是筛选出少数人的唯一手段。就好像同事问你问题一样，问及的事情有可能是你完全没做过的，你就凭借常识来提供一些基本的判断；也有可能是你深入研究过的领域，你可以说出很多细节和难以遇见的问题。面对后面一种情况，假设你说的都是对的，面试官会很开心；面对前面一种情况，面试官会让你说出更多细节，或者问你哪里还能继续优化，这时候你就知道你的答案和已知最优答案还有差距了。（有些 Google 面试官会在你给出该问题业界已知最优解后仍然问你能不能继续优化。）所以千万不要一开始就假设题目很难，觉得给出一个没有优化过的答案很丢脸。

英语说慢一点

很多时候人一紧张起来，说话就会越说越快，在有点口音的情况下只会让对方越来越难听懂。在对自己技术自信的基础上，同时也需要对自己的英语表达能力自信。其实语法或者词汇有点问题，说话有口音，这些影响都不大，只要对方能够听到关键词汇，意思还是能明白的。有时候可能双方都要多说几次「excuse me」和「what is it」才能问明白对方的意思，但只要最后问题能讨论清楚，那你至少还是让面试官了解到了你的真实实力。

代码要易读易改

这个问题来源自某人的一句评论：

有 ACM 背景的人往往在面试过程中都很不介意写全局变量，但我更期望这个问题的解决方案就是一个函数，所以实现细节都在内部解决。

其实「全局变量」不是重点，代码的易读性和可维护性才是重点，而这往往是 ACM 或个人项目所缺乏的训练，这种问题尤其容易出现在编码能力很强但很少跟人合作的人身上。

对于 ACM 而言，只要程序能运行代码怎么写都没所谓，反正代码的生命周期也就是几个小时，无论是否通过几个小时后你就不会再去阅读或者修改这段代码了。这种训练使得写 hacky 代码缺少惩罚。但在实际工作当中，任何 hacky 的代码都会引入新的 technical debt，最终肯定是你以及你的同事承担。你写下的第一个版本，可能要在代码库中停留几年才有人完全推倒重写，这几年内不停地有人在上面做修改，你需要保证在这个过程当中大家都还能明白这段代码是干什么的。

如果你把面试官看做同事，那么你写的代码自然是要经过他 code review 的。不要为了追求高性能而写出很难读的代码来，面试官读不懂就判断不了代码的正确性，性能再好也没有用。你宁可先写下来最清晰可读的版本，如果面试官说需要优化性能时再做优化。

其它参考资料

我暂时能想到的就这么多了。此外推荐 David Wei 的《面试硅谷创业公司：请把面试官当成你的同事》。

面试体验：Facebook 篇

Google、Microsoft 和 Yahoo 都是去年的事情了，接下来说说今年的吧。其实我在豌豆荚非常爽，跟身边的设计师和工程师合作都很愉快，所以唯一能够诱惑我去面试的就只有 Facebook 了。最初接受 Facebook 面试邀请的原因并不是追求它的 offer，而是我就想了解一下 Facebook 是怎么面试的，有什么是值得豌豆荚招聘借鉴的。

过去在百度做面试官，只是面试而已，公司招不招得到人我没什么感觉。我觉得公司招不到人就招不到人咯，我们没必要扩张得那么快啊，先专注于做好手头上的项目再说嘛。豌豆荚其实不是着急要招前端工程师，我们还是坚持只招一流人才，只不过长期发不出 offer 还是让人感觉招聘有问题——我们浪费了大量的资源在面试上，发不出 offer 意味着回报率低，因此我们总要想办法研究如何提高回报率。

回到正题上来，我选择参加 Facebook 的面试，就是想看看他们是如何选拔人才的，他们所使用的题目是如何设计考点的，是不是设计得比我们的要好。因此，在收到 Facebook HR 的邮件后，我回信说愿意聊一下，然后跟他约了一个时间进行电话沟通。因为 Facebook 总部在美国西岸，所以之后的电话沟通和电话面试都约在了早上 8:00。尽管这导致他们要晚一个小时下班（按朝九晚五算的话），不过 HR 也很通情达理地接受了。（我猜大多数工程师都不会采用朝九晚五的正常作息时间吧。）

HR 在电话里先简单介绍了一下 Facebook 现在的情况，然后说明这是 Menlo Park 总部的职位，让我确认如果顺利应聘的话我会愿意到美国去。接着 HR 问了我两个很基础的 CSS 问题：display block 和 inline 有什么区别？position 有哪些取值？我觉得 HR 能够问这样的问题对于工程师来说是很爽的事情，因为纯粹的小白就被过滤掉了，也不需要浪费工程师的时间来面试。（我在之前的文章中说到过，在中国大多数面试前端工程师职位的候选人无法回答这两个如此基础的问题，不知道在美国是否也如此。）随后 HR 问我还有没有什么不明白的，或者关于 Facebook 想要了解的，我说没有了。HR 的最后一个问题是「你为什么选择 Facebook？」我当时心里想的是，「是你主动联系我的，我没想过这个问题哦」。于是我跟他说，「我暂时没有答案。我现在在豌豆荚工作很开心，不过我也乐意多地了解 Facebook。」

电话沟通后，HR 给我发了两道 puzzle，选做其中一道就可以了。两道题目都是前端相关的，其中一道需要设计一个简单的算法，另一道则需要支持移动设备触击交互。这种解 puzzle 的面试方法我不是第一次遇到了，4 年前申请 Google 的 Web Developer 职位时也遇到过类似的 exercise，只不过题目只有一道，没有选择的余地而已。相比起 4 年前 Google 的 exercise 而言，这两道 puzzle 的考点更加 update。（4 年前的 exercise 还需要考你如何做圆角和背景渐变，现在都是用 CSS 3 搞掂的了。）

我花了一周的时间完成了一个 puzzle，搞掂了算法设计和界面实现，连 unit test 也都写了，然后提交给 HR。HR 在 review 的结果出来后，把我介绍给另一位 HR，说她会帮我安排接下来的面试。第一轮面试感觉有点像 Google 的，主要由 3 道题目构成。题目的考点设计得很好，基础知识能被覆盖到，常用技法也需要用到，但又绝对不需要某一方面很高深的知识。（设计得不好的题目往往是依赖于面试官很熟悉的一个难点，如果你不知道这个难点，或者你的理解跟面试官不一样，你就完蛋了。）

第一轮面试的最终通话时间为 90 分钟，我猜这意味着我做得不够好，因为如果以 Google 的标准来衡量的话，45 分钟解 3 道题才算及格。经过后面几轮面试我才发现，原来 Facebook 面试一般是要求 60 分钟解 2 道题。第一轮的面试官之所以给我加了 1 道题，估计是因为第 2 道题我做得不好，所以他相当于换了一道题给我做。面试结束，面试官又问了之前 HR 问过的问题，「你为什么选择 Facebook？」我还是那样子回答。

面试一个星期后，HR 邮件跟我说，我通过了上一轮面试，接着要安排下一轮面试。第二轮面试感觉跟第一轮差不多，包括长度和难度。只不过这次就是 60 分钟 2 道题，估计是因为我 2 道题都解出来了吧。面试结束时面试官又问那个问题了，我决定反过来问他是否喜欢 Facebook 的工作。他说 Facebook 的工作很好，周围的人都很聪明，能够从他们身上学到东西，同时公司提供一天三餐，福利好到觉得自己被宠坏了。我其实不是很在乎福利的部分（豌豆荚又不是没有一日三餐），我更在乎的是人是否聪明，合作的过程中他们是否总能教会你一些你过去不知道的事情（这是我现在在豌豆荚拥有但离开就可能失去的部分）。随后我跟他说，我在乎的是能否跟聪明人一起工作，听他这样说感觉 Facebook 不错。

又过了一个星期，HR 邮件跟我说，需要安排我到美国面试。我一开始对这件事也不特别在意，觉得那你就慢慢安排吧，有人报销机票让我到湾区旅行就是好事情。在随后的电话沟通里面 HR 跟我说，因为今年的 H–1B 签证配额已经花出去一半了，如果按照这个速度估算的话可能到 5 月底签证配额就会花完，所以希望我尽快到美国面试。（如果签证配额花完了，有没有 offer 都没意义了。明年 4 月才能申请明年的配额，申请成功也要等明年 10 月签证才生效，就算公司很想要你，也只能先安排你在海外办公室工作一年。）于是我就连忙办签证 5 月下旬飞往美国参加面试，因此也就有了我之前那篇《三藩市湾区一周游》。

4 轮面试安排在一天内完成，Facebook 委托旅行社安排好往返机票和两晚住宿，随后我就出发了。因为害怕迟到，又因为美国郊区的公交又是一小时一班的，所以面试当天我早早就起床了，结果发现酒店门口是长期有出租车的，打车到 Facebook 后等了一个多小时才到原本约定的面试时间。HR 在见到我后先把我带到 micro-kitchen 让我拿吃的喝的，并且问我那么早来是不是没有吃早餐。我说确实没有，然后她就让我拿一些食品做早餐。（其实我应该在酒店叫早餐的，因为 Facebook 允许每天报销最多 $75 的餐饮开支。）随后她把我带到用作面试的会议室，给时间我解决早餐，并且跟我简单说明了当天的安排：早上 2 轮面试，结束后她会来带我去 Facebook 餐厅吃饭，然后下午还有 2 轮面试。

总体上来说，4 轮面试的形式还是一样的，每轮都是 60 分钟解 2 道题目。所有题目都是前端相关的，HTML + CSS + JS 都会考到，不过不涉及 HTTP。最后一轮的面试官有点特别，他先问了一个很古怪的 CSS 问题，然后又跟我讨论了一个跟前端不相关的编程问题。之所以说他那个 CSS 问题古怪，是因为在现实中大家都不会那样写 CSS，但他写出来了问你会显示成怎样，不是非常熟悉 CSS 标准细节的人又很难完全答对（我也有答错了的地方）。至于第二道题，他说他是突发性想出来的，他自己也不知道最优解是什么，就是想跟我讨论一下能够如何优化，我就跟他讨论了几种可能的优化方式。所有他又说如果把常数 k 改为可以变成任意大的 n 怎么办？我就说 n 的问题能够分解为 n/2 的问题，因此能够通过二分法来优化。

通常情况下，如果由于面试而进入一家公司的话，HR 所做的只是把你从 A 地带到 B 地，保证你顺利完成面试。如果是朋友带你参观公司则会很不一样，他会带你去看有特色的东西，并且告诉你这个好玩那个有意思。Facebook 的 HR 给人的感觉更像是后者，她向我介绍 Facebook 墙上的涂鸦，带我去天桥上看 Hacker Square 全貌，并且告诉我每次 hackathon 开始时大家就会聚集到 Hacker Square 上来。除了 HR 以外，也有一些面试官会提及他们喜欢的 Facebook 特色。这让我觉得 Facebook 里面还是有不少员工挺喜欢这家公司的。

面试结束后，HR 跟我聊了一下，告诉我如果有 offer 的话接下来会需要什么。根据之前 Google 面试的经验，我猜 Facebook 会不会也要我提交一大堆的材料，HR 说只要提交申请签证所需的学位证就可以了。之后 HR 让前台帮我叫出租车，在等待的过程中前台还很好人地问我是否需要拿喝的，需要的话可以在大堂冰柜里面拿。

随后的周末是美国的亡兵纪念日，周六到周一连续放假三天，我则利用这个长周末去参加湾区的各种好友聚会。周一中午 HR 打电话来说要发 offer 了，待细节确定后下午再打电话给我告诉我具体的数字有多少。我当时就在想，难道 Facebook 的面试官和 HR 周末都工作？这个效率很高呀。只要面试官稍微拖一下，周五的面试就必须等到下周才能有结果。而且确定 offer 细节估计也要经过几个人审批吧，节假日发 offer 就意味着大家都要在节假日处理工作了。

总体上来说，Facebook 面试过程中对候选人的关怀做得很好，效率也不错。让我「大开眼界」的是面试题，原来真正好的面试题并不在于它有多难，而在于它有多简单，简单到熟悉这个领域的人一下子就明白到你在说什么以及想问什么。能够进入 Facebook 的人应该都觉得面试不难，至少跟中国的面试对比起来如此，那是因为 Facebook 把觉得面试有点难的人都过滤掉了，而中国那些很难的面试反而没什么区分度。

《面试体验》系列文章到此就结束了。接下来有时间的话或许我会写写跟应聘美国职位有关的事情，例如 H–1B 的周期和配额是怎么样的，选择什么时间面试对你比较有利，拿到 offer 之后该如何为新的生活做准备等等。我知道对于很多在中国读书或工作的人来说，直接应聘美国职位看起来门槛很高，那是因为你身边很少人这样做所以你不了解而已。只要你愿意花时间去了解清楚，你会发现这件事其实没有你想象中那么难。如果你对这个话题感兴趣的话，可以订阅我的博客，或者留言提问。

面试体验：Yahoo 篇

前面两篇文章提到了 Google 和 Microsoft 的面试体验，可惜都没有 offer，接下来说说有 offer 的。

考虑到我已经在 Google 和 Microsoft 的招聘流程当中了，于是我也让 Yahoo 的同学帮我内部推荐一下，试试 Yahoo 的面试如何。本来没想着很正经地面，不过最后拿到了 offer，所以才有了我之前那篇文章所说的「越是放松越能成功」。

Yahoo 一开始并没有什么 HR 沟通和预约，某一天我从百度下班回家正准备做饭就接到面试官电话。我开头以为他想要跟我约时间，结果他问我是否方便进行面试。我当时毫无准备不是很想面试，不过既然室友可以做饭那面试一下也没什么所谓。Yahoo 的面试不像 Google 那样有很明确的规范，所以每一轮的面试官喜欢怎么面试就怎么面试。第一轮的面试官问了很多很基础的问题，每一道题考一个基本的知识点，例如某个 CSS 属性的取值，或者是 HTTP 的状态码。这些问题基本上不需要任何的解题能力，知道就知道，不知道也没办法。前端的基础知识我都知道，所以这对我来说没什么难度，只是感觉自己被人当 wiki 来查而已。

Yahoo 的面试让我感到舒服的一个原因是，它有前端工程师职位，所以不需要强行用后端工程师的标准来衡量我。在通过第一轮电话面试后，HR 终于出现了，跟我约了一个下午的面试时间。我问她要具体的时间安排，跟 Google 和 Microsoft 不一样的是，她说没有具体的面试安排，预计我的面试需要占用整个下午，所以请我预留整个下午的时间。这是让我感觉安排不够严谨的地方，后来才知道因为有多个不同的团队想要面试我，所以从一开始就给我安排了更多轮的面试，让不同团队的人都有机会来面试我。

我在 Yahoo 办公室一个下午的面试见了 4 位工程师，其中包括 1 位经理。因为 Yahoo 的经理也跟大家一起写代码，所以我也把他算作工程师。每一位面试官面试的风格都不一样，不过都涉及写代码解题。最后经理进来的时候给我带来了一罐 Diet Coke，除了让我写代码外，他还让我打开现有 Yahoo 产品的页面查看源代码代码，然后问我有哪些地方做得不够好以及如何能够改进。

在面试的过程中，我很明确地向经理表示我希望能加入一个多元化的团队，跟来自不同国家不同背景的人合作，最好有机会到美国出差工作一段时间。经理表示，既然我想要跟美国团队合作，他可以额外安排美国的同事跟我面试一下。我的理解是，到这里我就相当于已经有了口头 offer，不过有机会跟美国同事聊一下那就聊一下咯。

因为对方在 Miami，中国的上班时间正好是他的下班时间，所以面试只能约在中国上班的前一个小时。我早上 8:50 到 Yahoo 办公室后，不仅仅 HR 还没到，连前台都还没上班。9:00 前台上班，过了一会儿 HR 才来把我带到视频会议室。在 IT 帮忙调试半个小时后，确认视频用不了，只好降级为电话会议。Miami 那边的同事很认真地把问题分作 HTML、CSS 和 JavaScript 三部分来问，半个小时自然聊不完，但他的下班时间到了，只好跟 HR 说明天继续。结果第二天还是同样时间去 Yahoo 办公室通过电话会议聊了一个小时。

由于 Yahoo 知道我在等 Google 的结果，所以 HR 在电话口述 offer 给我听后，告诉我 offer 的邮件先不会发出来，因为发出来我就必须在指定的天数内接受，否则系统就会自动取消 offer。我觉得这还是挺人性化的。Yahoo 的面试安排规范化程度看起来没有 Google 和 Microsoft 那么高，随意性比较大。当然，这样做的好处是灵活性也大一些，经理和 HR 可以按照自己的需要做一些特殊安排。

《面试体验》系列文章就只剩下 Facebook 那一篇了，我承诺我一定会把它完成，但可能要经过一段时间后我才会把它发表出来，所以建议大家订阅我的博客，或者是在 Twitter 上 follow @CatChen。此外，我的博客也接受捐赠，通过信用卡支付，金额随意（$1 起）。

最后是广告一则：如果有任何曾经参加过豌豆荚（豌豆实验室）面试的人愿意写类似的面试体验文章，欢迎联系我并把文章地址发给我，我愿意在我的博客上以链接的形式进行分享。

更新： 《Facebook 篇》已发布。

面试体验：Microsoft 篇

在上一篇《面试体验：Google 篇》中说到，我对猎头的标准回复是「有美国或者香港的职位吗？」在进入 Google 招聘流程后，Microsoft 有一位 HR 打电话来跟我说有一个北京的职位跟美国总部会有密切的合作，问我有没有兴趣。我当时想的是，如果加入美国公司的中国分公司，或许将来有机会 relocate 到美国去，至少会有去总部出差的机会吧，所以就决定去试试。

HR 在联系我之后，招聘经理 Alex 直接联系我跟我约了晚餐时间。晚餐其实不是什么面试，只是互相了解一下。Alex 原本在 Microsoft 总部工作，只是碰巧他来北京轮岗 3 个月，有候选人申请职位他自然也乐意见见面。至于这个跟美国密切合作的项目，总监和一半的成员在美国，中国这边已经有几个人但还要多招几个。

Alex 在晚餐中教会我一件最重要的事情是：什么叫做 「commodify 工程师」。所谓的「commodity」是指无差别的一般等价物，例如按桶算的原油就是这样子，无论中东产的还是中国产的都一样。在说原油价格一桶多少钱时，我们并不会关注到底是哪里产的，因为价格差不多，使用起来也没有区别。因此「comodify 工程师」就是把工程师当做一般等价物看，无视其人性和个性，把工程师看做无差别的人力资源单位，哪个项目缺多少人力资源单位，就为它补充多少人力资源单位。他帮助我意识到我不满的百度现状是什么，同时也支持我要换一家公司并找机会到美国工作的想法。

之后 Alex 帮我约了一轮电话面试，面试官是印度人。他问了我两道问题，一道比较简单写代码就能解决的，另一道则是分布式系统设计相关的，我全无经验只能说说我知道的概念。我感觉后面这一道题回答得不是很好，因为总是没办法说到点上，同时也不像算法题面试官给些提示就能向前推进。事后证明这一轮面试的反馈确实不是很好。

随后 Alex 又约了我到 Microsoft 办公室进行一天的面试。早上到了之后他先让我参加了当天的 daily scrum，让我知道他们是如何工作的。接着是跟美国的总监通过电话会议进行面试，没有讨论技术问题，更多的是互相了解对方的工作方式，看看双方是否合适。接下来是跟北京这边的经理面试，因为团队在北京没有专门的经理，所以人事方面的事情就交由北京的经理负责。看到经理 Norman 的姓后，我就知道他是说粤语的，同时因为他一开始就说自己普通话不是很好，所以我就提议说不如我们说粤语吧，于是我就在 Microsoft 一天面试当中用到了英语、粤语和国语。Norman 问了基础的算法题和逻辑题，也聊了一下分布式存储的设计，同样我对后者回答不上什么点来。感觉 Norman 的题目很重视逻辑思维，在我说某一道基础算法题不能用贪心算法后，他问我使用贪心算法的充要条件是什么，同时另外一道逻辑题考的也是是否清楚充要条件是什么。

在 Norman 面试之后，他叫上 Alex 跟我一起去午餐，然后下午我跟中国这边的团队成员聊聊天了解一下他们的工作内容就完事了。整个过程并不是很难，也不会像 Google 那样专门考算法。感觉 Microsoft 更重视逻辑多一些，同时跟美国团队进行面试也确实比跟中国团队进行的面试要让人更舒服一些。（Alex 和 Norman 分别是在 Microsoft 总部和湾区工作多年的人，所以面试风格应该都还是很美国的。）我下午离开的时候，口头 offer 算是出来了，HR 在电话中说很高兴招到了人，并让我提交当前的薪酬信息。

由于快到过年了，提交薪酬信息的事情我一拖就拖了两个星期，过年回来后才提交。事后 HR 跟我说，进行第一轮面试的印度人对我不熟悉后端这一点表示有顾虑，其它人尝试说服他但是没有成功，所以 offer 出不来了。于是这个到手的口头 offer 就飞走了。

事实上，我在 Microsoft 的面试经历到此只不过是进行了 1/3，不过后面的我就不想详细说了。在我过年回广州放假的时候，有一位 Microsoft 的 HR 打电话给我问我面试时间安排的事情，我说面试不是结束了吗，然后才发现这是另外一个团队的 HR，并且她不知道我之前的面试，于是我又面试了一个不同的团队。因为前面所说的口头 offer 最终发不出来，Norman 把我推荐了给另外一位经理，那位经理又约了我进行了几轮面试。

总的来说，我在 Microsoft 的面试经历就是不停地被加试。加试意味着还不能确定，但又还不想放弃。不确定的原因自然是我没有后端经验，不放弃的原因估计是算法题和逻辑题我回答得还可以。最终我在 Microsoft 的 3 个团队中面试了 15 位工程师和 2 位 HR，还是拿不到 offer。Microsoft 的面试过程尽管没有 Google 那么体贴，但是安排还是挺专业的。因为 Microsoft 是各个招聘经理自己去招人，不像 Google 那样公司统一招聘，所以推动招聘进度的更多是招聘经理而非 HR，候选人也能直接感受到招聘经理到底有多在乎自己。

在整个 Microsoft 面试过程中，我觉得最有收获的是认识了 Alex 并且跟他聊了一些事情。我说如果有机会的话我想要体验一下在美国工作生活是什么样子的，然后才能知道我想要到哪里去。他帮我分析说去美国有 3 种途径：读书然后在美国找工作、加入美国公司的中国分公司后再找机会 relocate、直接加入美国公司，其中第一种方法最容易，第三种方法最难。他的首选建议是第一种方法，不过因为我短期内没有去美国读书的计划，所以第二种方法也不错。我觉得作为 mentor 最重要的是他要真的在乎你的个人发展，同时能够利用他的经验帮助你，因此我觉得 Alex 会是个很好的 mentor。在我加入豌豆荚后，他还联系过我，说 Microsoft 总部他所在的团队有职位开放，问我是否感兴趣。因为我当时刚刚加入豌豆荚，所以就拒绝了。

如果你对《面试体验》系列文章感兴趣，欢迎订阅我的博客，或者是在 Twitter 上 follow @CatChen。我承诺我接下来一定会完成 Yahoo 和 Facebook 相关的两篇文章。此外，我的博客也接受捐赠，通过信用卡支付，金额随意（$1 起）。

最后是广告一则：如果有任何曾经参加过豌豆荚（豌豆实验室）面试的人愿意写类似的面试体验文章，欢迎联系我并把文章地址发给我，我愿意在我的博客上以链接的形式进行分享。

更新： 《Yahoo 篇》和《Facebook 篇》已发布。

面试体验：Google 篇

尝试在自己的博客上搜索点东西，结果发现 4 年多以前还在博客上写过一系列的 recruiting events，把大四时候参加过的各种笔试面试都记录下来了。我从去年准备离开百度开始，到现在总过面试过 4 家公司：Google、Microsoft、Yahoo、Facebook，原本去年也想把面试经验写一写的，结果一拖就拖到现在。我不想写面试经验，因为我个人不喜欢漏题和背题的做法。我自己作为面试官，知道要设计出来一道好用的题目有多难，所以我希望面试者都是如实表现自己解题能力的。我更喜欢写面试体验，就是在整个面试过程中一家公司给人的印象是怎样的，HR 和面试官是否专业，能否让人信服这是一家值得长期工作的公司。

我想写的第一家公司是 Google，因为它是我在想要离开百度时第一家联系到我的公司。2010 年 12 月底的某一天早上，我突然感觉到我应该离开百度，因为如果这个时候已经没有勇气离开这家公司了，很可能就不会再想要离开了。当天中午在百度大厦西餐厅吃午饭，接到一个 Google 上海 HR 的电话，问我有没有兴趣去面试，我想既然你打电话来的时机那么好，我就答应你去面试吧。（在那一天之前，我对猎头的标准回复是「有美国或者香港的职位吗？」）她问我将来希望在北京还是上海工作，当时我对北京的厌恶程度还没有现在那么高，同时觉得搬家到上海又比较麻烦，于是就说在北京，接着我就变成跟北京 HR 沟通了。

Google 的 HR 会负责做两件简单得不需要面试官做的事情，这能够很好的提高招聘流程的效率。第一件是确认你能够适应工作环境中的英语，为此 HR 要我用英语跟她对话两三分钟，主要就是让我说说工作经验和其中的亮点。习惯在私企工作的人不要以为外企对英语的要求很高，其实大多数长期在中国工作的人说话或者发邮件都会很 Chinglish 啦，所以关键是要敢于用英语进行沟通。

然后 HR 发了一个 Codility 的地址给我，让我有空抽时间去做题。一个小时 3 道难度相当于 OI 基础题的题目，平均 20 分钟一道。最简单的题目一看就知道是 O(n) 能解决的，最复杂的题目看上去是 O(n^2) 但想一下就能优化为 O(n log n)。对于有算法训练背景的人来说，这样的题目会让人感觉到很有把握。对于没有经受过算法训练的人来说，掉进陷阱里是很容易的。很可能没有把 O(n^2) 优化为 O(n log n)，结果超时；可能没仔细看题目说明的数值取值范围，某些变量选错了数值类型，结果溢出。考虑到 Google 重视算法的程度，再加上 Google 中国面试的额外难度，算法训练还是很必要的。

在我通过 Codility 测试后，HR 问我了对题目难度的反馈，然后约了一轮电话面试，并且告知面试主要围绕算法、数据结构、系统设计、编码来进行。Google 面试的格式都很固定，45 分钟内期望你能做出 3 道题来。这 3 道题最起码要能把人人都能想出来的「笨办法」用代码写出来，否则会让面试官感到不满意。如果有些题目能够比较快地做出来，面试官就会让你优化。就算你第一次给出的答案已经是业界已知最优解，面试官都还是会让你优化，因为谁也不知道有没有人能在面试过程中突然爆发，想出一些过去没人想到过的解法。如果面试官心中已有优化的方案，在你想不出优化方案时他可能会给你提供一些提示。

一轮电话面试后，HR 就开始约到 Google 办公室的面试了。第一次约了下午 3 轮面试，还是那个很固定的格式：每轮面试 45 分钟，两轮间隔 15 分钟。整个面试流程让人感觉到很人性化：在 Google 签到后，HR 会先带你去 kitchen 拿点吃的喝的，然后把你带到面试所用的会议室。多轮面试的话，HR 中间还会来问一下你要不要去洗手间，或者多拿两瓶水。面试完毕后 HR 会来问你感觉如何，同时也会让你知道面试官的初步反馈是否跟你的感觉一致。我在 3 轮面试中有一轮感觉不太好，因为面试官只给了 2 道题，并且我最终都没办法解出来，HR 也确认了就是这一轮的反馈不好。

此外，Google 的招聘流程还让人感觉到很有效率。作为面试官，我也知道自己写面试反馈有多喜欢拖延，而且公司填写面试反馈的系统越不人性化我就越想要拖延，然而公司内部系统做得人性化的又实在罕见。Google 的面试基本上隔天就有结果，然后 HR 就会约下一轮的面试。因为我在百度的时候每周哪个时间没有会议是很确定的，所以我总是选择下周同一个时间段来面试。在经过总共 4 轮面试后，HR 说因为前面有一轮的面试官反馈不好，所以希望再加一轮面试。因为前面反馈不好的面试官比较 senior，所以这次找了一位同样 senior 的面试官来面试，于是我又去了一次 Google 办公室。

完成 5 轮面试后，HR 把材料提交给 Google 的北京招聘委员会，结果没有通过。HR 说，因为 Google 都是按照后端工程师的标准来招聘，看重算法和数据结构，前端工程师要通过不容易。因为 Google 没有专门的前端工程师，只有一个软件工程师职位，所以所有人还是必须按照一个标准来衡量。她问我如果找到专门需要前端工程师的团队，并且需要额外再面试的话，我是否感兴趣。当时 Google 是我的第一选择，我当然说感兴趣啦。

后来 HR 跟我说，她帮忙问过 Google Maps，可惜对方说不要专才只要通才。又过了几个星期，HR 发现 IME 需要专门做前端的人，于是帮我再约了一轮面试。这轮面试是在 Google 办公室做的，但实际上是视频会议，因为面试官在美国。（不确定面试官是在美国出差，还是美籍华人。）面试过程跟电话面试类似，用 Google Docs 写代码，比电话面试要好的是说话时能够见到人。

这一轮面试结束后，我的材料再次进入 Google 的北京招聘委员会。HR 说这次专门找了对前端有经验的人来审阅我的材料，结果顺利通过了。接着 HR 问我要了一大堆的补充材料，包括高考成绩和 GPA（连同成绩单），还包括当前薪酬和竞争对手的 offer（我当时有 Yahoo 的 offer），甚至包括过去的获奖和晋升经历。所有这些材料都会发往 Google 美国总部审阅，具体流程 HR 没有细说，但看 Don Dodge 的文章可以了解一些。最后我被 Google 美国总部给拒绝了，然后 HR 还是一如既往地及时沟通，并且安慰了我几句。

整个 Google 招聘流程下来，可以感觉到人性化和高效率，同时也能感觉到 HR 确实在很努力地为候选人争取机会。可以说，无论是否通过，Google 招聘流程至少能给候选人一个很好的印象。据我所知，尽管 Google 声称全球招聘标准一致，但因为中国聪明且懂算法的人实在太多，所以难度更高是很正常的。能够在 Google 中国以外的地区应聘的话，应该会容易一些。

如果你对《面试体验》系列文章感兴趣，欢迎订阅我的博客，或者是在 Twitter 上 follow @CatChen。我承诺我接下来一定会完成 Microsoft、Yahoo 和 Facebook 相关的三篇文章。此外，我的博客也接受捐赠，通过信用卡支付，金额随意（$1 起）。

最后是广告一则：如果有任何曾经参加过豌豆荚（豌豆实验室）面试的人愿意写类似的面试体验文章，欢迎联系我并把文章地址发给我，我愿意在我的博客上以链接的形式进行分享。

更新： 《Microsoft 篇》、《Yahoo 篇》和《Facebook 篇》已发布。

理想的技术面试过程

作为面试官

从在大学里面试社团大一新生，到加入百度后帮公司面试候选人，我觉得我对面试这件事一直不得要领。百度提供面试培训，也允许参考或使用题库，但我还是觉得不知道如何判断给不给一名候选人通过我这关。偶尔我会遇到非常优秀的实习生候选人，我能十分确定我要给他过，甚至想方设法确保他能来。其它时候，我觉得我的判断随机性太大，或许还不如一枚硬币做得好。

在百度做二面的时候，我往往会问一些组合问题，就是候选人需要有扎实的基础加上一定的解题能力才能做出来的。我假设一面的面试官已经问过基础问题，所以我不会再问基础问题。结果通常是，候选人的基础不够扎实，会作出一些错误的假设，甚至面对组合问题就无从下手，不知道如何分解为更小的问题然后再一步一步来解决。我不知道是否应该期望候选人全部答对，但答对小部分的状况让我无从判断。

为此我开始跟其它人讨论面试经验。Acumon 说应该针对候选人说他擅长的领域来提问，而且使用开放性问题以便了解候选人的思考方式，但我发现我遇见的大多数候选人都不清楚自己擅长什么，或者是他们自认为的强项无法达到我的预期。后来在上海跟 Winter 和 Hax 聊天时发现一个可怕的现实：大多数前来应聘的前端工程师都无法回答「position 属性取值都有哪些」以及「display 属性取值都有哪些」。随后我尝试在我的面试中先问这两个问题，发现确实有些人回答不出来取值，更多人则是无法准备描述常见取值的作用。（我甚至不把 inline-block 和 fixed 归类到常见取值里面。）遇到如此基础的问题都回答不出来的候选人，我通常会跟他告诉他正确答案，再问一些基础问题然后给他一些学习建议，最后很礼貌地送他走。

状况在我到达豌豆荚后有所改善。不是来应聘的人都非常优秀，而是我开始有感觉了。关键原因我觉得是我们不着急招人。现在我们还能应付手头上的工作，也没有快速扩张的需求，所以我们只有在遇到最合适的人选时才邀请他加入。我相信我前面的两位面试官做得足够好，然后我可以放胆地去考量「懂不懂」之外的其它方面。准确来说，这甚至不是一种考量，我只想知道我跟这个人一起工作是否会很愉快。我会以工作上遇到问题时同事跟同事间讨论的方式去跟他进行讨论，有可能是工作上实际遇到的问题，也有可能是刻意设计出来的有趣问题。（我觉得在一个充满活力的工作环境中，同事之间互相找些稀奇古怪的问题来讨论是很正常的，大家也会享受这类挑战。）如果我感觉跟他讨论问题是很愉快的过程，他能够提出有趣的想法，甚至能告诉我一些原本我不知道的事情，我肯定会给他很正面的面试评价。

作为面试者

换个角度来说，如果你作为面试者发现自己在面试的过程中能够进入这种状态，感觉如同跟同事讨论问题一样放松，那么你应该对面试结果充满信心。至少根据我个人的经验来说，感觉如同轻松愉快讨论的面试我都能得到面试官不错的评价。我明白要做到这一点很不容易，很多人在面试时都会很紧张，甚至会假设面试官一定会用各种难题来考自己，这种心态其实会把自己放在不利的位置上。我过去的经验是，我越不在乎的面试，往往我越能放松地跟面试官随便聊，结果反而越好。我很在乎的面试，反而有时候会高估面试官问题的难度，结果简单的问题没给出简单的答案，最后得到的评价反而不好。

在百度大厦的时候，我喜欢穿越二层平台，因为那里有很多小圆桌，也有很多人会选择在那里进行讨论或者面试。如果你对肢体语言有点最基础的了解，或者你就是在这方面有感觉，你会发现在那里很容易看得出哪些桌是同事间的讨论，哪些桌是在面试，以及谁是候选人。同事之间的讨论，往往大家都会很放松；面试的话，面试官也会很放松，但面试者通常处于比较紧张的状态，身体会略为前倾，就算不需要写字也会把手放在桌子上，用于支撑上半身的重量。对于有经验或者有感觉的面试官来说，这种肢体语言会传递一种不好的信号，那就是你太想要这份工作了，就算更深入的沟通后可能你会发现这份工作不适合你，但你还是会追求这个机会。

类似的场景也会出现在异性之间，下次去餐厅吃饭时你可以观察一下隔壁桌的异性交互。就算你完全不知道谈话内容，你也可以尝试从面部表情和肢体语言去判断谁在追谁。为什么有时候你追的人各种虐待你，还有充足的信心你不会放弃？因为他们看得出你把自己摆在什么位置上。在统计学的角度来说，我觉得女人在这方面比男人有优势，因为女人看的电视剧都不是白看的，她们在逛街吃饭时还无时无刻地在观察身边发生的各种剧情。就如同资深前端工程师可以只看 CSS 片段就猜出遇到了什么浏览器 bug 以及作者尝试如何解决一样，有经验的女人（又或者是面试官）要看明白你的立场太容易了。

因此，首先你要把面试看作一个平等的双向选择过程，不仅仅公司在选择你，你也在选择公司。如果面试官问的问题显得他很没有品味，或者是 HR 的某些安排让你觉得这家公司的文化很有问题，你随时可以提出说你没兴趣聊下去。这时候你反而可以比较好的发挥出来你真实的实力。对于你真的不知道的问题，你就直接说出哪部分你不知道或者不确定。同事间讨论也会遇到你不懂的问题，你平时是怎么处理的在面试时就怎么处理，面试官不会因为你直率地表达不懂某个点而鄙视你的，他应该帮你把这个点绕过去然后继续。

我觉得最好的面试建议就是 Changhao 跟我说的那句，「Be yourself」。（其实这也是很好的追女建议。）

改善面试流程

既然技术面试应该平等地讨论问题，通过感觉这个人是否能成为一名你喜欢的新同事来做出判断，那又应该如何衡量他的技术能力呢？这其实应该放在面试流程尽可能靠前的部分来做。很多外企的标准做法是，通过首轮（或前两轮）电话面试来判断一个人的技术，随后通过多轮的面对面讨论来判断这个人是否适合这家公司这个团队。我相信这套方法在美国执行起来没什么问题，因为空缺和候选人的数量差不多。

当然，上述流程来到中国后就必然会发生变化。中国有能力来做这份工作的人太多，同时还有更多的人想要来浑水摸鱼，这就导致了招聘成本大大提升。如果在中国还是用首轮电话面试来根据候选人的技术能力做一个初步的筛选，我想面试官就要疯掉了，所以大多数大公司都会在此之前加上一轮笔试。（对应届生可能是多轮笔试，否则面试官就阅卷都足以疯掉。）

有些公司会选择通过 ACM/ICPC 竞赛经历做出筛选，尽管无法保证获得最优结果，但至少能获得次优结果。招聘本来就是个搜索问题，一个在美国能有效求解的算法到中国来发现搜索空间大小增长了几个数量级，自然要想办法调整算法提高性能。这是非常理性的做法。当然它会带来一些外部性，例如说使得更多中国学生在可能不适合或不喜欢参加竞赛的前提下选择参加竞赛。

这些方法确实能把想要浑水摸鱼的人筛掉，不过能通过的人有时候还是太多了，所以接纳候选人过多的大公司往往会无端增加面试难度，问一些纯粹刁难人的题目。我觉得这没什么意思，也没在应届生面试以外的场合遇到过。既然应届生及格的太多，我觉得就直接随机抽签好了，这是最公平的做法。抽签可以通过公证过的算法来做，这比问一些候选人可能随机地知道或不知道的问题可靠多了。

最后说一下，为什么我觉得平等讨论的面试方式比问一堆问题要好。不同的面试方式，取决于你把候选人看做一个人力资源单位，还是一个有个性的人。如果你把候选人看做一个人力资源单位，他只要能完成你给出的任务就可以了，那确实是能力测试更重要。如果你把候选人看做一个有个性的人，你就需要知道他的个性能否很好地融入团队当中，这使得你在面试过程中必须把他当做一名未来的同事来看待。