如何扩大工作的 scope？

在美国工作的程序员都会遇到一个问题：想要晋升但经理说自己工作的 scope 不够大，又或者是影响力不够大。那要如何才能扩大自己工作的 scope 呢？

职业前期直系经理会负责为你找 scope，一步一步地给你更大的 scope，到了后面经理就会说「自己找 scope，这是晋升到下一个级别的要求，我给你 scope 就满足不了这个要求了。」既然不能依赖别人给你 scope，那要去哪里找扩大 scope 的机会呢？

这是很多人感觉到困扰的问题。假设自己在做的 scope 大小算作 1，把上下左右的外延做了也就是 1.1、1.2、1.3……的增长，这扩张速度太慢了。找一个跟自己已有 scope 相似但需要花同样功夫的 scope，那可以从 1 变成 2，但工作量跟着翻倍，拼命卷可以升一级，但 scope 大小从 2 到 3 是不可能的。况且职级线性上升时需要的 scope 是指数上升的，卷到三倍的工作量也没用，公司期望 scope 按照 1、2、4、8……的速度来增长。

---

在这篇文章里面，我们的关注点是如何找到更大的 scope，不是有了更大的 scope 后怎么做出来。怎么做出来当然是个难题，但很多人被卡在了找不到 scope，所以必须先解决这个问题。找不到 scope，不意味着找到了就有能力做出来，但找不到的时候人就会觉得自己有能力无处施展，这会导致很强的挫败感。

如何能找到更大的 scope？关键是要走出去跟更多人接触。技术再厉害的人，把自己关在小黑屋里面对着代码库发呆，是几乎不可能找到更大的 scope 的。你只能看到你已经知道的问题和机会在哪里，最多再看到一点外延，但指数级扩大的问题和机会很难闭关冥想出来。

我们可以在白纸上画三个从小到大的同心圆，分别代表：我能控制的事情、我能影响的事情、我能感知的事情。如果只考虑工作上的事情，这三个集合应该是两两子集的关系，「我能控制的事情」是「我能影响的事情」的子集，「我能影响的事情」是「我能感知的事情」的子集。

找不到更大的 scope，问题往往来自于「我能控制的事情」扩张到逼近「我能感知的事情」的边界了，然后就找不到空间继续扩张了。想要对着「我能控制的事情」大力出奇迹是很难有效果的，把工作量翻倍后 scope 依然上不去。真正能扩大 scope 的，是先把「我能感知的事情」扩张出去，有空间了再把「我能影响的事情」扩张出去，最后才能把「我能控制的事情」扩张出去。

如何能够把「我能感知的事情」扩张出去？我们必须走出去，接触更宽广的世界，接触更多各式各样的人。在一家大厂内部，这往往就是走出去跟别人聊天。我们对自己每天在做的项目、在解决的问题有太深的了解了，我们需要了解别人尝试解决什么问题、有什么问题解决不了，更大的 scope 就埋藏在那里。

---

如何走出去跟别人聊天？可以先从已经跟你有交集的人开始。肯定存在一些人，项目上跟你有合作，但有限的合作导致你们的交互很少，你不知道在合作之外他的主要工作是什么。你可以约他们喝咖啡，不要聊你已经知道的事情，问一下他在合作以外的主要工作是什么，以及他的工作有什么有意思的地方、有什么难题或者是不爽的地方。

关键是你要会聆听，他说的事情你要么理解了，要么通过更精准的问题追问。想象一下你跟他聊天后需要回来汇报跟他相关的所有信息，你自然会仔细听，甚至会做笔记，不会瞎扯一番大家爽了但谁也不记得聊了什么。这个对话应该像个自然的社交聊天，你不能如同审问对方一样获取信息。对方说的事情，你有共鸣的可以回应，你有不同观点的可以分享，这才是一个对话。

职级比较低的人，对于找职级比较高的人聊天可能存在心理上的障碍，觉得不应该浪费对方宝贵时间，错误假设自己懂的对方都懂了，所以对方不会从对话中获得任何价值。其实职级比你高的人也是人，你跟他们聊天可以提供情绪价值，有时候还能帮他们理清思路。如果长远来看你们会有更多合作，他们肯定乐意花时间跟你建立良好的信任关系，这包括花时间互相了解对方，尤其是对方的思维方式、思考问题的出发点。

刚刚开始跟几个人聊天时，你会获得大量碎片化的信息。聊的人多了之后，慢慢这些信息就会连接起来，呈现出公司内部更大的图谱。你需要在这个更大的图谱当中寻找当前运作得不够好的地方，例如说可靠性低或者是效率低的地方，然后想想你是否有想法和有能力去解决，这些都是你潜在的 scope。可能你没有信心直接玩起袖子开干，但你至少有素材跟你经理进行对话，说说你看到的机遇在哪里，让他就什么机遇更适合你提出他的看法。

熟练使用 Google 或 Facebook 内部工具毫无用处？

有一部分 Google 和 Facebook 员工总是在担心一件事情：公司内部使用的所有工具都不是来源的，离开了公司就不会再用到，花那么多年把这些工具用到熟手了，一旦离职就会变成毫无用处的沉没成本。这种忧虑显得非常围城：在大厂外面的人觉得自己使用的工具不够好，想要进大厂看看到底人家有什么黑科技；在大厂里面的人觉得自己只用闭源工具，担心因为自己不懂其它公司都在用的来源工具而失去竞争力，想要花时间学习开源工具但又没有机会。

担心这种事情并非毫无道理，但我觉得这不是一个真正值得解决的问题，而且不是一个解决后就一了百了的问题。如果此时此刻在大厂，还不如专心做好眼前的工作，等到真正换工作的时候再根据工作需要现学。真正重要的能力，不是你现在懂什么，而是需要在未知环境中摸索时你能够学得有多快。（学校里建立激励机制是错的。根据你此时此刻懂多少来决定给予多少正向或反向激励，一旦你把这内化了就会造成职业上长远的负面影响。）

---

为什么说「不懂外部开源工具」这个问题不可能被彻底解决？这本质上还是因为技术发展的速度太快，如果一门技术此时此刻用不上，你学了之后就会逐渐贬值。

很多人只看到了现在成功的独角兽在用什么技术，但现在已经成功了的独角兽都是 10 后那一代创业公司了，它们创业时赶上了 AWS 的浪潮，但那时候大家用的 AWS 跟今时今日 AWS 提供的服务根本不是同一回事。那时候大家还是用 EC2 这样赤裸裸的机器，运维还是工作的一大部分，大家尝试做运维自动化但成熟度跟今时今日比简直就是玩具。

随着这一批 10 后创业公司的成长，它们对 AWS 的用量越来越大，遇到的运维问题越来越复杂，然后才出现了现在常见的这一些解决方案：用 AWS 管理界面太手工了，所以用 Terraform 来统一管理需要用到的 AWS 资源。自己在 EC2 上安装和维护软件太麻烦，关键的是缺乏一致性，公司内部做一套统一的容器镜像吧，把所有常用的东西打包进去。很多这些解决方案都是为大规模 AWS 运维设计出来的。

然而如果你看一下 20 后新生代的创业公司在用什么，你会发现你学会前面的一切都没用。20 后创业公司一上来就用 Firebase。EC2 是什么？虚拟机是什么？容器是什么？统统不知道，也不需要知道，赶紧把东西做出来，获得用户和拿到融资最重要。Firebase 当然有它的弱点和限制，大多是 20 后创业公司在扩大规模时都会遇到 Firestore 无索引筛选慢的问题，然后要把数据迁移到 GCP 或干脆把服务迁移走。

现实情况就是这样子，如果你离开大厂加入一家 10 后创业成功的独角兽，你就必须接受过去 10 年大家在 AWS 上建立起来的复杂生态环境，但即使你学会了你依然摆脱不了原来的忧虑：这些技术仅适用于这一批公司。你跳回去大厂，这些技术就没用了。你跳到 20 后早期创业公司，这些技术也没用。等它们 10 年后成长为独角兽时，你需要为它们解决新一代技术带来的问题，而不是去纠结上一代技术已经把上一代的问题解决得有多好。

---

你的职业发展如何，受你控制且最重要的部分是你能够为别人创造多大的价值。（这也是学校激励机制从来没有帮助你内化的东西。）从懂什么技术出发思考如何优化职业发展，这本身就是错误的方向。你必须从如何创造价值出发进行思考，如果没有充足的信息进行思考那就先尽心观察收集数据。

每一家公司要解决的问题都不一样，具体的某一种技术可能为解决特定的某一个问题提供了所需的手段，但越是通用的技术越需要针对特定问题通过定制化来落地。我见过很多人把「这在我上一家公司非常成功地解决了这个问题」带到新公司，尝试重复一边解决同样的问题，最终发现没有两个问题是一样的。在新公司不接地气，过去成功过的解决方案在新公司不能落地，最终都会失败。

我观察到一些人的成功路线，是借助在上一家公司打开的眼界，在下一家公司结合实际地解决问题，然后迅速地成长。例如说，在大厂当个 L5 接手维护一个曾经非常有开创性的系统，保证它的服务质量同时在上面添加功能。没错，这开创性的工作是轮不到你做了，几年前做这件事情的人升了 L6，但这样的机会只有一次，你不是第一个把路从无到有地踩出来的人，你就没机会升 L6。但你可以把这个系统和它解决的问题搞明白，接着去一家尚未解决过这个问题的独角兽，帮助他们解决这个问题。

对你来说真正有价值的是你见过这件事情能做成的视野。一件探索性的事情知道它能做成，你就已经成功了一半。（有很多探索性的事情，最终是做不成的，至少是在你有生之年人类无法达成。）但你不能把大厂的方案直接抄一遍，你需要理解在这个相似的领域这家公司独有的问题是怎样的，然后定制一个能在这家公司落地的方案。在一家独角兽迅速成长的那几年里，很多问题都是由于规模迅速扩张而造成的，曾经帮助这家公司成功的那批人对这些问题一无所知，而你在大厂见过规模成功扩张后的方案，所以他们会寄望于你来帮助他们解决问题。因为这件事情在这家公司还没有发生过，这个问题也没有被解决过，你在这家公司做出来就算是开创性的了，于是你可以在这里升 L6。

等你升完 L6，环视四周，发现升 L7 的好机会也都被别人挖掘完了，接下来在这家公司升 L7 会变得越来越难。没关系，你需要做的是把前面这个过程再重复一遍，这家公司已经被人利用过的 L7 机会，总有下一家还在路上的公司还没有遇到过相关的问题，等着你去解决。闭源的大厂，尤其是 Google 和 Facebook 这两家，里面有很多黑科技是外面大家根本不知道能做得这么好的，知道能做得这么好就是你最大的优势。（说得直白点，小厂是「贫穷限制了想象力」，而你见识过拥有几乎无限资源的大厂的想象力能去到的地方。）

---

回到文章的主题上来，熟练使用内部工具本身没有什么特别的价值，但知道这样的工具能做出来（而别人不知道这样的工具竟然能做出来）就很有价值，深入理解这些工具是如何被设计出来的以及它们被设计出来时的历史背景也很有价值。

工程师成长到最后最重要的是什么？

有一个问题我最近在 career coaching 时连续被不同的人问了几次，第一次被问到时我想到什么就说什么，但被连续问了几次之后我觉得我需要好好思考一下。这个问题问的是，「工程师成长到最后，最重要的是什么？」

刚刚进入互联网行业的新人，往往觉得自己懂得还不够多，别人比自己厉害、比自己资深，是因为别人比自己懂得更多。按照这个逻辑进行推导，正确的目标自然是让自己懂得越来越多。再往前推导，既然每一个人的时间是有限的，那必须优先弄懂那些重要的事情，因此有了上述这个问题。大家都不想走弯路，希望找到直达终点的直线。

---

我觉得这个问题的答案并不是清晰可知的，因为清晰可知的事情迟早会被大家优化到极点。能够通过面试进入大厂的人，都聪明和勤奋到一定程度。如果存在这样一条直线，大家都或多或少地都沿着这条直线全力往前跑，最终跑出来的结果会存在一定的差别但不会存在巨大的差别，尤其是不会存在那种走直线比走曲线所应该获得的巨大优势。

那真正能够产生差异的是什么？那必然是一些别人没办法直接告诉你的事情。这是可以通过反证法证明的。如果有人能够教会你如何能够获得别人不能获得的巨大优势，他会选择教你吗？为什么？大家很容易产生一种错觉，「比我厉害的人肯定懂得比我多，这跟在学校里一样，但是他们不愿意教我所以我不如他们厉害。他们联合起来保守秘密，阻止我们获得他们拥有的知识」。

按照这样的假设，比你厉害的人当中只要有一个人守不住秘密，这种知识早就传播开来了。而且教授这种知识肯定是能赚钱的，所以比你厉害的人其实都有动机通过教授这种知识来赚钱，他们不可能真的联合起来保守秘密。这就可以反证，不是别人拥有你没有的知识而且不愿意教你，现实更有可能是他们没办法教你，或者说教你的成本太高所以不知道花时间去教。

---

有一个概念叫做「隐性知识」，英文叫做「tacit knowledge」，指代的是那些难以言述的知识。隐性知识类似于通过深度机器学习训练出来的一个模型：它可以用，它大多数时候是正确的，少数时候会出错。你没办法通过人和人之间很容易就能沟通的若干条规则把它描述清楚，因为能描述清楚的话就不需要用到机器学习了，用规则系统就可以了。你没办法很好地预测它什么时候对什么时候错，你也不太能解释它错的时候为什么出错了。

面对这样的模型，你可以选择把它整个拷贝走。但如果你不能拷贝呢？（因为人类还没有进行人脑到人脑拷贝的技术，也不确定这样的技术是否真能被发明出来。）如果你能使用这个模型但不能拷贝这个模型，你可以用这个模型作为基准和反馈从零开始训练一个相似的模型。这也是现在已知的传播隐性知识的方法：找一个把某件「只能意会不能言传」的事情做得非常好的人，你在进行训练时请他提供反馈，最终你训练出来的结果不可能跟他完全一样，但你的目标也只是获得相似效果而已。至于能否训练出来，以及要训练多久才能达到你想要的效果，这都是要尝试过才知道的。

---

现实就是这样子的：有能力进入大厂的人，通过过书本（或其他媒体）学习显性知识的效率肯定不会差。瓶颈往往出现在显性知识能学的都学了，学更多也不能变得更厉害了，但又没有意识到需要甚么样的隐性知识，或者是不知道从哪里能够获得需要的隐性知识。

所以工程师成长到了一定的阶段以后，搞明白自己需要什么以及找到跟谁能获得有效的训练是最重要的。具体怎么做就不是通过写一篇文章就能说清楚的，否则这就不叫做隐性知识了。我能给的建议是：找你相信真心关注你成长的人，请他们花时间观察你工作，问他们觉得你的成长需要什么、谁能够帮助你训练你所需要的。

互联网选大厂还是小厂：读了本书还是写了本书

这个系列上次写到《互联网选大厂还是小厂：数据中心里有朵云》，这次简短地写一个小一点的区别。在小公司，你更容易遇到同事说「我读了本书，书上说的这个事情能解决我们遇到的问题。我把书上说的事情投入实际应用后，得到了这么好的效果。」在大公司，你更有可能遇到同事说「我是这本书的作者，有问题欢迎来问我，我也可以定期组织相关的研讨。」

有资格写书的大神门往往聚集在大厂中，小厂很厉害的话或许能抢到一个这样的大神。这些人已经工作很多年了，积累也很深了，有心情就把知识整理出来写本书。科技理论的前沿往往发生在学术界，但科技落地的前沿是在大厂。大厂把学术界早就搞明白的事情拿过来，然后进行从来没人实践过的落地。在这方面，大厂提供了更多的机会去做探索。因为前人没做过，就算理论摆在那里，也不可能有书把这件事情描述清楚。

小厂正好是反面，走的路往往是无数前人已经走过的路，成长过程中遇到的问题很多其它公司早就遇到过，已经有人把解决问题的方法抽象出来写成书。这即是优点又是缺点，要看你站在什么角度去看。从创造影响力的角度来看，这是优点，一个应届生新人，不需要很强的原创性，不需要很好的研究能力，读本书就有机会为公司解决大问题，然后得到升职加薪之类的回报。在大厂，这是不可能的，写书的作者都在这里了，如果有利用这本书上的知识就能创造影响力的机会，早就已经做了，怎么可能轮到你呢？但在大厂里，你可以直接接触到作者哦，你可以跟他一起工作，直接从他身上学习，这是小厂没办法提供的。

互联网选大厂还是小厂：数据中心里有朵云

时常会有人来问我，应该加入大厂还是小厂。提问的方式有时候是很具体的，例如说「我有这几家公司的 offer，他们规模不一样，这会对我的职业发展产生什么影响呢？」有时候是很抽象的，就是讨论一下以后找工作到底应该专注于大概是什么规模的公司。我曾经想要写一篇长长的文章，从不同的角度来对比大厂和小厂的区别，最后发现很难完成。现在我决定换一个方法，想到哪里就写到哪里，写完一个具体能进行对比的角度，我就发一篇文章。

在这篇文章里，我想要对比的是大厂和小厂在规模上的本质区别。如果你希望接触到一些特大规模的技术问题，你就只能选择进大厂，因为小厂不会遇到这类问题，也就没有机会让你去接触这类问题。这里有一个很有意思的故事，叫做「数据中心里有朵云」，是个很好的例子。

Facebook 早期跟那个年代的其它公司一样，也是在别人的机房租机位开始的。后来做大了，就有了自建机房的需求。机房需要廉价的土地、电力和制冷，荒漠能够很好的满足这三个需求。Facebook 为了节能，专门设计了利用荒漠低温空气对服务器进行降温的通风系统，一旦发现室外温度比室内空调温度还要低，巨大的风扇就会启动，吸入室外温度更低的空气进来降温。

荒漠通常是零降水的，但有一次傍晚真的下雨了，导致室外气温迅速下降，机房开始从室外吸入冷空气降温。因为刚刚下过雨，室外空气虽然温度低但湿度非常高，进入室内后迅速被服务器温度加热升温。数据中心天花非常高，高温度高湿度的空气自然会往上跑，最终空气中的水分冷却后变成云。据说当时在数据中心的人听着服务器发出霹雳啪啦的火花声音，但没有任何办法去抢救服务器。他们把这次事故描述为「There is a cloud in the data center」。

Facebook 后来学聪明了，不能简单根据室外空气温度来判断是否应该吸入室外空气来降温，还要加上室外空气湿度作为限制条件。这种类型的问题，现在世界上也就只有几家公司能够遇到，因为现在绝大多数互联网公司只需要用别人的云服务，不需要自己拥有物理机器，更不需要自建数据中心。如果你想要接触到这类其它公司都没解决过的前沿问题，那只有大厂能够有足够的规模去触发这类问题，小厂根本触发不了。

类似的问题在 Facebook 其实不少，但也就只有这种规模的公司能遇上。举个例子，Facebook 曾经用 BitTorrent 来部署 web 服务器的更新，因为 web 服务器数量过多（百万级别），向每一台 web 服务器单独上传几个 GB 的编译文件效率太差。更新不是就覆盖几个 PHP 文件吗？为什么是几个 GB 的编译文件？因为 Facebook 那时候使用 HPHP 把 PHP 转译为 C++ 再编译为二进制文件。那为什么 Facebook 要发明 HPHP？因为 PHP 执行效率太差，当时有人根据历史数据进行拟合，发现 18 个月后 Facebook 的用户服务器比（用户总数除以服务器总数）将会下降到 1.0，就算 Facebook 有那么多钱买服务器，世界上也没有那么多机位放服务器，所以必须想办法提升执行效率。

所有这些规模导致的问题都是一环扣一环的，一个发明创造解决了上一个规模导致的问题，同时也带来了机遇给下一个发明创造。这种类型的发明创造只能发生在大厂里，因为小厂触发不了这个级别的规模问题，也没有充足的资源去进行发明创造。

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

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

---

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

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

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

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

---

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

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

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

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

---

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

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

赴美工作常识（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 的《面试硅谷创业公司：请把面试官当成你的同事》。

赴美工作常识（Part 3 - 英语）

在《Part 2 - 申请》的评论中有人问英语要达到何种水平，以及如何提高。其实英语也不是我的强项，只是刚刚好做到能够沟通而已。由于我在知乎上回到过一个类似问题，我就基于那个答案简单说一下吧。

Aa

首先，你要能脱离中文和翻译，纯粹地使用英语来思考。很多英语单词短语是没有对应中文翻译的，就如同很多中文字词是没有对应英文翻译一样，然而这不妨碍你在使用中文时使用这些字词传达意思。同理，很多英文单词短语你不须要知道他们对应的中文翻译，只要你能够使用它们传达意思就行了。有时候你只需要感知一个词汇所传达的形象或者是感觉就可以了，你甚至不需要能够解释清楚它是什么意思。例如说，中文里面常见的「屌丝」和「hold 住」，让你解释或许你也无法用简单语言解释清楚，但这不妨碍你使用它们传达信息。

接着，你需要把你小学时候学习语文的过程重复一遍……没错，这是最痛苦的阶段，也是最多人坚持不下去的阶段。很多人认为自己已经完成那个人生阶段了，成年后再学习新知识就应该使用更「聪明」的方法，提高效率减少痛苦。其实这种「聪明」的方法是不存在的，有时候已有经验还会拖你后退。如果你在学会游蛙泳几年后再学游自由泳，你就明白我说什么了。我在蛙泳能轻松游 1000 米的时候，学习自由泳还是从挣扎着游完 25 米开始的，然后把目标提升到 50 米、100 米、150 米、200 米……花了几年时间才能轻松游 1000 米。

在我自由泳游不动的时候，或者是在我觉得自由泳会被鄙视的时候，我就会放弃然后改游蛙泳，这就是拖后腿的地方。同理，在你可以轻易放弃使用英语的时候，其实你的英语学习效率会比你的小学语文学习效率更低，因此你应该预期更大的投入和更长的时间才能达到同样的效果。如果你预期「聪明」的方法可以减少投入或者缩短时间，那么你一定会失望，然后你就会拒绝和放弃。给自己设置正确的期望是很重要的第一步。

Bb

在进行听说读写的训练之前，你还需要有一定的单词量。词汇量就如同一个训练效率基数，并不是说词汇量少就完全不能进行听说读写的训练，而是训练效率低而已，因为你需要同时面对训练内容和不懂的单词。

话说你小学和中学总共用烂了多少本新华字典？显然你也必须在英文字典上花费同样的功夫吧。因为中文翻译没有用，所以一本英英字典就足够了。我中学时候用的是 Collins Cobuild，版本貌似是 Learner’s Dictionary，重点在于例句足够多。因为我说过了，理解一个单词精确的意思并不重要，重要的是知道怎么用它。阅读足够多的例句可以让你感受到这个单词在不同的上下文下表达什么意思，之后你再看到这个单词就可以通过类比例句来理解它的意思，当你想表达跟例句相似的意思是也可能用这个单词。

Cc

在有了一定的单词量之后，就可以练习听说读写了。因为这是写给对美国科技类职位感兴趣的人看的文章，所以我所选择的方法都是跟工作领域相关的。

听：可以从听 podcast 开始，因为免费的同时又不妨碍你做其它事情，成本极低。如果你使用 Mac 或者 iOS 的话，直接使用 iTunes 订阅就可以了。科技类的 podcast 相当得多，而且也相当地专业，因为科技领域的节目是最先尝试通过 podcast 传播的。我从大学开始听的 TWiT (This Week in Tech) 已经由当年的一个节目发展到现在二十多个节目的网络。如果你愿意花钱，则可以考虑直接去 Audible 买书来听，使用 TWiT 的优惠码 可以先免费获得两本书，然后每个月 $23 两本书。

说：这估计是一个人最难自己训练的。你可以找找自己身边有没有 Toastmasters 的活动，有些大公司（尤其是外企）会有自己的 Toastmasters 组织，否则找自己所在城市的组织也可以。如果你已经在外企工作，可以考虑加入一个跨国合作项目，每天工作进度会议必然要用英语来进行，这足以强迫你每天使用英语思考然后表达，就算只是十分钟的会议。

读：现在上 Amazon 买 Kindle 电子书已经如此方便，使用 iOS Newsstand 订阅电子杂志如此方便，我觉得这已经成为了最容易训练的项目。我一般会在 Kindle 上买一些畅销书来看，这是由于畅销书之所以畅销是因为写得足够吸引的同时保证易读性，这能在一定程度上降低阅读产生的疲劳。如果你喜欢看小说的话，畅销小说应该是易读性最高的，因为你甚至不用去思考，只要一直追剧情就可以了。

写：上 Stack Overflow 或 Quora 回答问题是很好的方法。相对于宽松的命题作文而言，回答问题的目标跟明确，要么你能回答要么你不能回答。你不能回答的就直接跳过，你可以回答的就应该尝试把你的思路解释清楚。因为你不是漫无目的地写一些你并非真正在乎的题目，所以你不用太过刻意去准备回答所需要的素材，你只需要把注意力集中在表达上就可以了。

Zz

最后回到开头的问题上来，就是要达到怎样的水平才算是足够。我觉得能够沟通就足够了，意思是你的自然语言表述能力不能比编程语言的差，凡是你能写出来的代码你都能用简单的语言说清楚。有可能你的思路绕了一个大圈才找到了结果，这就如同一个改完又改的程序，但别人其实只需要看到你最后重构过的版本。所以无论你想得有多复杂，在使用自然语言表达出来时最好是一个简单清晰的版本。如果你暂时做不到，就需要培养 awareness，知道自己哪方面做得还不够好，然后不断再练习中刻意调整。

赴美工作常识（Part 2 - 申请）

在《Part 1 - 签证》的评论中有人提到，说我还没说如何申请职位就说签证的事情了。一方面，签证的周期决定了你申请职位的时间，错过关键时间点的话就可能错过重要的机会。另一方面，传统意义上的「申请」其实不是我的强项，而我个人的做法可能对大多数人来说是不容易实践的。

首先需要说明的是，我在找工作时有两件事情是绝对不做的：

1. 大量投简历给众多公司
2. 为面试做任何应试准备

我找工作基本上靠内部推荐，所以我是不会投简历给众多公司的。这不仅仅是因为内部推荐会使得公司更重视，还因为我需要了解一家公司是否适合我。一家公司如果没办法吸引到我身边跟我志同道合的好友，那么它对我的吸引力也相对有限。（我选择豌豆荚的时候就是因为我认识里面不少人，并且这些都是我信任的人。）通过认识的人，我可以了解到这家公司的文化以及前景，这对我来说是非常重要的。

对于面试，我从来不尝试通过应试的方式来准备。我觉得我懂什么由我的兴趣来决定，没兴趣的事情我没必要通过机械训练来假装懂，有兴趣的事情我会研究清楚你喜欢跟我讨论什么都可以。这使得我能通过的面试都是我真正喜欢并且胜任的工作。当然，这不意味着面试前不能巩固一下自己已经掌握的知识，因为有些自己很感兴趣的事情一段时间不接触也会生疏，如果你拿我两年前的技术文章来问我很可能我也说不清楚细节。

把前提条件说清楚了，我们就可以进入正题了。

名声

听说过 Google PageRank 的人都应该知道，PageRank 的核心思想是把链接当做投票（或是论文中的引用），你的页面被其它页面链接的次数越多，那些页面自身的 PageRank 越高，你的页面的 PageRank 也就越高。同时，在做关键字匹配的时候链接的文字比你页面内容的文字更重要，如果有一个 PageRank 很高的页面链接到你的页面且链接文字是某关键字，就算你的页面内容完全不包含这个关键字也能用这个关键字搜索到你的页面。简单来说，你说你是谁并不重要，重要的是别人说你是谁。

基于同样的道理，其实你在简历上说你做过什么并不重要，至少没有你想象中的重要，真正重要的是在别人怎样说你。（简历的问题后面再说。）所以最简单的方式是去 Stack Overflow 上面回答问题，和去 GitHub 上面参加开源项目。

Stack Overflow 的门槛相对低一些，只要你敢于用英文和别人交流就行。问题并不比各种中文技术问答论坛要难，可能对于大部分人来说难度在于理解问题和用英文说清楚自己的答案。对我来说，通常看 10 个问题只有 1 个是可以回答的——有几个是问题质量太差而不值得回答的，有几个是不懂所以无法回答的，有几个是已经有很好的答案不需要重复回答的。如果你阅读问题的速度太低，建议还是先通过阅读技术书籍来提高，否则挑选问题的速度会很低。在挑选到合适的问题后，你就可以答题了。Chinglish 不重要，但写完一定要检查一遍避免犯低级错误。

GitHub 的话，要对一个项目作出贡献先要对它有相当的了解，所以门槛不低。我曾经见过有英文文章推荐一种很好的切入方法：找一个你感兴趣的知名开源项目，然后寻找它缺乏单元测试的地方，尝试帮它写单元测试。这会驱使你去研究待测代码，因为如果你不知道这些功能的边界在哪里，你是没办法写单元测试的。写好单元测试就发 pull request，一般对方是不会拒绝的，因为这绝对是纯粹的贡献，不会跟项目主导者所设想的项目发展方向有任何冲突。如果代码本身就写得完全不可测？那你就可以动手重构代码，让它变得可测，这同样会驱使你去研究代码。

简历

我偶尔会收到陌生人的简历，一部分是让我帮忙推荐给公司的，另一部分则是让我对简历提出修改建议的。我发现大多数人的简历都会包含过多的信息，结果就是重点不突出。

要写好简历，首先要理解别人是怎么读简历的。如果现在有 100 份简历放在你面前，要你挑 10 份还可以的，以及 1 份特别出众的，你会怎么读？可以很肯定的是，你不会把这当做考纲中的必考内容一页一页仔细读。你会先抽样一部分粗略看一遍，以便确定这些简历的基准线在哪里，然后才能确定那 10 份的期望是多高，那 1 份的期望又是多高。接着你以那 10 份的期望为筛选标准来看这 100 份简历，达不到期望的直接扔掉。有可能你最后剩下 15 份，你会再看第二遍并且扔掉 5 份；也有可能你最后剩下 8 份，这时候你凭记忆把接近这 8 份的另外 3 份找回来，再扔掉 1 份。最后，你从这 10 份里面挑明显好的 1 份出来。

可以说，这 100 份简历里面有 8 份是毫不犹豫能够留下的，有 85 份是毫不犹豫可以扔掉的，剩下的 7 份才是需要仔细阅读对比的。如果你的目标是成为那少部分人——直接通过的那少部分，而不是让人纠结的那少部分，那你就应该分析清楚自己的优势在哪里，并且只提能够证明这些优势的重点。多余的信息没必要提，提了只会降低信噪比。

为了适应人的阅读习惯，必须注意一下排版，引导读者的视线从上往下看，并且突出关键字。入门的话，读一下《The Non-Designer’s Design Book（写给大家看的设计书）》就足够了。前端工程师可能经常接触到网格式布局，其实道理书中也说得很清楚，就算你不理解的话你按照这种方式去设计简历也会发现可读性更高。

最后，现在主流放英文简历的地方应该是 LinkedIn。很多美国公司都会购买 LinkedIn 的服务来搜索简历和联系潜在的候选人，所以就算你已经有了很好的个人网站最好还是在 LinkedIn 保存一份简历副本。

在上述一切准备就绪之后，就可以接触公司了。找人内部推荐，或者在公司网站上传简历，其实都可以。值得提醒的是，如果你有计划要找人内部推荐，就先别自行上传简历，否则推荐可能被视为重复上传，最后系统有可能不承认这是推荐。

关于申请我能想到的就那么多了。前期工作做得足够好的话，可以省掉后期临急抱佛脚的麻烦。不要等到想换工作的时候才想办法证明自己的价值，要时刻保证自己的价值以便在想换工作的时候就能换工作。

理想的技术面试过程

作为面试官

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

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

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

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

作为面试者

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

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

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

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

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

改善面试流程

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

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

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

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

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

前端工程师的职业发展路线在哪？

我猜想国内很多前端工程师都想过这个问题吧。前端工程师往往属于产品研发团队，但却很容易被边缘化——后端工程师觉得自己才是主力，没有后端工程师产品就不存在了，但没有前端工程师产品还能有，只是界面非常糟糕而已。这时候前端工程师就开始感觉自己像是个外包似的，只是来帮别人完成一些任务而已，对产品没有归宿感。这时候前端工程师的职业发展路线在哪？成为一个更好的外包吗？

要做关键任务

我觉得，要别人重视你的工作，不仅仅是你做得好就行了，还要求你的工作对别人来说足够重要。这跟产品定位有关——例如说对搜索引擎来说，前端对产品的影响不会非常大，用户只要能搜索到自己想要的结果就行了。搜索引擎最复杂的交互可能就是搜索框的自动完成了，但有自动完成和无自动完成的区别到底有多大呢？跟准确率和召回率相比，有没有自动完成实在没有多重要。况且，自动完成的结果本身也依赖于准确率和召回率，所以后端工程师比前端工程师重要得多。

因此，前端工程师在选择工作时首先要选择前端足够重要的工作。重要用什么来衡量？务实的话，是钱；务虚的话，是产品。如果一个功能只能在前端实现，并且这个实现能够提高多少的转化率，使得多少原本不产生利润的点击产生利润，那么前端对这个产品来说一定十分重要。可惜往往跟钱相关的事情不由前端工程师来研究和决定，所以这部分工作还是安心交给产品设计师来做吧，让他们来决定怎么样的产品能赚钱，然后由你来完成这个产品的实现，这时候你的目标就是把产品做好。

回到刚才的问题，有些产品更依赖于后端，例如搜索引擎，当然也有些产品更依赖于前端。什么样的产品更依赖于前端？就是后端难以建立起技术壁垒的产品。这类产品要抄袭一个功能差不多的并不难，因此只有细节做得最好的能够获得足够多的用户。这类产品在 iOS App Store 上很常见——有很多 app 拥有相似的功能，而其中只有一个交互设计得最好的能够获得绝大多数的用户。尽管 app 不存在 HTML + CSS + JS 这个前端，不过道理是一样的。当年 Tweetie 能够取代老牌的 Twitterrific 成为主流 Twitter 客户端，靠的就是交互上的创新，外加不差的性能和稳定性。如果交互对于一个 web app 来说十分重要，这个 web app 自然也就需要十分优秀的前端工程师。

总结一下，由于前端工程师的价值在于实现复杂的前端细节，因此如果可以选择的话尽量选择一个细节决定成败的产品。如果产品的成败已经由后端工程师决定了，例如某某数据规模要么能做要么不能做，那么这个产品就没你什么事了。

要懂核心业务

每一个公司，每一个项目，都有它的官方语言。不是指普通话，也不是指 C++，我指的是大家围绕什么问题来展开项目，什么问题的讨论能让大家为之兴奋。举个例子来说，百度的官方语言就是搜索，跟搜索没有关系的产品也会使用「准确率」、「召回率」这样的术语用来做比喻。前端工程师有多少知道什么是「准确率」、「召回率」的？估计不多，因为前端根本没有这样的概念。这时候前端工程师要跟后端工程师沟通也就不容易了。久而久之，你对人家很兴奋在讨论的什么 O(1) 还是 O(n) 不感兴趣，人家也不理解你的 {} != {} 是什么意思，你就被边缘化了。

如果不想被边缘化，就算前端不是公司的核心业务，你也必须懂公司的核心业务，然后说着官方语言，而不是前端的方言。这就意味着，如果你在一家后端技术很强大的公司，你最好也懂后端技术。我知道国内有很多前端工程师并不是计算机系毕业的，就算是国内的教育也不怎么样，这时候你只能恶补相关的基础知识了。如果你不懂这些，就算你能把整本《JavaScript 权威指南》背下来，你说的还是方言，说官话的人还是会鄙视你。如果公司主要服务于某个垂直领域的话，你必须对这个垂直领域十分了解，随时能用这个领域的行话来沟通。

总结一下，由于每个人已经熟悉的领域都不一样，所以没办法说哪个领域更适合前端工程师。如果你原本已经有某个领域的从业经验，进入服务于该领域的技术公司总是有显著优势的。如果你进入了一个自己不熟悉的领域，那就一定要补充相关基础知识，否则你对这个领域不感兴趣，这个领域也不会对你的前端工作感兴趣。

实际例子

为什么我选择加入豌豆荚？主要考虑的还是上面两点。

我在百度的时候一直就在想，既然前端对搜索引擎来说不重要，那对什么类型的应用来说比较重要呢？当时看到 Facebook 做得不错，所以觉得社区会需要复杂的交互，而如果复杂交互做不好则会影响用户使用，因此前端对社区来说应该十分重要。现在看来，也不完全是这样子。前端对社区来说确实重要，但 Facebook 并不是一个典型的例子，它是一个前端做得尤其优秀的例子。

在我了解到豌豆荚 Windows 客户端的实现方式时，我立即意识到它可以通过我的第一个判别标准——前端对它来说是关键任务。它使用 Webkit 做了一个容器，然后把所有的交互都通过 web app 的形式做在里面，然后通过一组接口跟 native 进行交互。如果一个应用决定要这样做了，那么前端就能影响到它的成败，因为这时候前端后端的分隔线已经很明确了。如果一项功能应该由前端来做那就必须由前端来做，后端基本不可能成为实现此项功能的备选方案，这时候前端就具备了无可替代的位置。

至于第二个判别标准——豌豆荚的核心业务是什么？我觉得豌豆荚做的很多事情都是以产品设计为起点的，而这至少是我感兴趣并且也有点感觉的东西。从细节上来说，就是大家喜欢谈论的事情是一致的，例如产品如何做一些很智能的设计，最新的技术方案如何能够巧妙地帮助这些设计得以实现。Junyu 说「设计就是创造性地解决问题」，这是我喜欢的解决问题方式。这个世界上能够把逻辑转化为代码的人非常多，同时有一定数学和计算机专业基础的人也不少，因此要拼谁的解决方案更好的话那还要加上创造力。

我知道国内有很多产品设计师，在考虑产品时首先想到的是百万千万级用户量，这样无论从单个用户身上赚到的钱多么的少，最终产品还是能赚大钱。百度曾经就属于这种思维方式，但这不是我喜欢的风格，因为没有明确的目标用户定位。我知道国内由很多工程师，在编写代码时用尽各种技巧以展示自己过人的才智，但是这样的代码还有可复用性吗？除了作者本人没有人能够维护啊。不同的人有不同的品味，能够跟品味一致的人一起工作是一件幸福的事情。

额外信息

这个话题到此就结束了吗？其实不是的。关于前端工程师的职业发展，我还有很多可以说的。不过我觉得找到一份让自己满意的工作必然是其中的第一步，因为你必须对工作充满兴趣，然后才能把事情做好，所以我把这部分内容放在最前面并且先发出来了。如果你不想错过后继讨论的话，欢迎订阅本博客。

此外，豌豆荚现在还招前端工程师，包括全职和实习，有兴趣的可以联系我：catchen@catchen.me。对于全职的前端工程师，我期望你熟悉 web app 的开发与调试，如果我让你手写一个 HTTP GET 请求你连个大概都写不出来，那我就要怀疑你平时都有多少时间对着 debug console 调试 AJAX 代码了。对于实习生，我期望你至少有扎实的 web page 基础，能够用简洁的代码实现符合语义的页面。至于豌豆荚提供什么？就是我前面所说的，但还有个前提——至少我们要有一致的品味。