求助于别人的正确姿势

什么情况下应该求助于别人？求助于别人是否就是伸手党，就会被人鄙视？我在做 career coaching 的过程中发现这是个常见问题，决定拿出来专门写一篇文章。Facebook 的 Bootcamp 在这方面对新人做了很多意识方面的训练，非常值得参考。

在 Bootcamp，专门有一个区域是给 mentor 提供 office hour 的，目标类似于学校里的 office hour（课后问答），如果作为新人的 bootcamper 在工作过程中遇到了问题，可以去这个区域进行提问。新人当然会问：那我该什么时候去提问？标准答案是：如果你自己捣腾了一个小时还是毫无进展，你就该去提问了。

跟学校作业不太一样的是，Facebook 布置给 bootcamper 的任务并不是标准答案已知的练习题，而是实际项目中不紧急也不重要的任务，每一个任务都不一样，mentor 不会提前知道问题，也不一定总能找到正确答案。新人在 office hour 提出问题后，mentor 都会问「那你都尝试了哪些办法？」如果有人说不出来，那 mentor 都会说「你先回去自己捣腾一下，如果一个小时了都毫无进展再回来提问」。

在新人解释完自己尝试过的办法后，如果 mentor 知道答案，可能会直接告诉他答案，把相关文档的链接发给他；如果 mentor 也不知道答案，他会亲自动手，把新人写了一半的代码拿过来 debug，试着解决问题；如果 mentor 解决不了，但知道谁可能提供有效帮助，他会把新人介绍过去。

就这样简单地一个过程，它强调了几种在 Facebook 成功必要的意识：

1. mentor 必须授人以渔，bootcamper 必须求学捕鱼，不可以伸手要鱼。之所以问你尝试过什么办法但不成功，是因为接下来 mentor 必须要告诉你或者示范给你看什么办法能成功。你不能说「我捕不到鱼，请给我一条鱼」，正确的提问方式是「我用这样的方式捕鱼，我试过了但什么鱼也捕不到，请教我正确的捕鱼方式」。
2. 即使面对你完全不懂毫无经验的问题，动手开干是最好的学习方式。动手开干不一定是写代码，动手开干也可以是搜索和研究。这跟在学校课程遇到问题存在一个本质的区别：学校课程能遇到的问题，都有已知答案，已知答案都属于一个清晰明了的知识体系，教材总能站在一个对该领域无所不知的角度帮你讲清楚一切。实际工作上的问题，往往你只能获取到碎片化的相关信息，然后再加上你自己的捣腾，产出一个可用的结果。你必须拥抱「真相在一定程度上不可知」然后冲上去捣腾。
3. 你能直接接触到的人不一定有你需要的信息，你需要学会找到正确的人来获取正确的信息。这也是跟学校成体系的知识和课程结构很不一样的。在学校，你可以假设教这一课程的人对课程知识范围无所不知，你去 office hour 提问肯定能得到答案。在工作上需要获取的信息，有可能需要经过多个节点才能获取到，这个人建议你问那个人，那个人建议你问另一个人。你虽然不确定要经过多少个节点才能获取到你需要的信息，但你最好有一套方法能够收敛你和目标的距离。

修炼好这几种意识，即使不在 Facebook 工作也能让你更好地在需要时求助别人。即使你做不好后面两点，你至少要把第一点做好。

---

我在 career coaching 时有时候会遇到客户这样的顾虑：我向比我资深这么多的人求助，会不会是很浪费他们的时间？面对这种自我怀疑，你必须调整心态，把自己放在一个能够双赢的角度来思考你们的处境。

首先，你要确定你想要求助的事情确实重要。如果是工作上遇到的问题，你要确定解决这类问题是符合公司利益的，站在公司的立场来看这类问题确实值得解决。这时候无论是你解决还是别人解决，这类问题都是要解决的，这奠定了双赢的基础。

接着，你求助的态度必须是「请教会我捕鱼。我也不想总是找你要鱼，所以教会我捕鱼是符合双方利益的双赢选择。」对于公司来说，这是个三赢的选择，公司解决了符合公司利益的问题，你学会了可以重复使用的技能，帮助你的人将来不需要反复地帮助你。

最后你当然要把这实践执行到底，不能在别人教你捕鱼时捕到一条鱼就走人。尽管这一条鱼满足你此时此刻的需求，但很可能你还没有扎实的学会捕鱼，下次又要劳烦别人。你表明了你想学，你就必须比教你的人更投入地学。

---

「求助于别人的正确姿势」应该有一个镜像话题「帮助别人的正确姿势」。这是新手 mentor 时常会遇到的问题：我觉得帮助我的 bootcamper 非常消耗时间，但我不帮他又不行，怎样把握这个度呢？我可以下次写一写这个话题。这个话题不仅仅对 mentor 有用，对 mentee 也有用，因为在知道 mentor 如何才能更高效地帮助你之后，你也能更高效地利用 mentor 的时间。

这篇文章首发于我的 Patreon，对同类文章感兴趣的话可以考虑在 Patreon 上支持我，付费订户可以提前至少一周阅读到我的最新文章。同时也欢迎大家通过邮件或 RSS/Atom 免费订阅我的博客。

面试题：开发新功能和重构老代码之间怎么选？

最近面试的多家公司当中，有至少一家尝试在行为（Behavior Questions，或 BQ）面试中问我这样的问题。尽管可以去猜这家公司到底更重视迭代速度还是代码质量然后从对应的角度去回答，但正确的答案只有一个，那就是不要回答这个问题。

---

第一原理（英语：First principle），哲学与逻辑名词，是一个最基本的命题或假设，不能被省略或删除，也不能被违反。第一原理相当于是在数学中的公理。最早由亚里士多德提出。——Wikipedia

对于所有商业公司来说，第一原理永远是商业，不是产品也不是技术。（「商业」和「业务」在英文里都是 business，在这里不针对中文进行区分。）产品的存在是为了服务于商业，技术的运用是为了服务于产品和商业。脱离商业探讨技术上的取舍毫无意义，因此如果被问到先开发新功能还是先重构老代码，必须要从商业的角度进行回答。

开发新功能对产品和商业有什么影响？重构老代码又有什么影响？这是你必须和面试官探讨的问题。面试官可以会提供更多具体的场景信息，也可能让你陈述不同场景下不同的取舍。我可以提供一些不同场景的例子。

---

如果我们是一个创业公司，或者是大公司的内部创业，正在做一个探索新市场的新产品。大家对这个新市场不是特别有信心，希望尽快通过产品验证市场是否存在，不存在的话就换方向或者撤销团队。这时候重构代码的优先级就很低了。或许几个月后发现假象中的新市场并不存在，现在的代码写得再烂，几个月后都随着产品下线而全面删除，谁在乎它烂呢？

这背后是有真实的故事的。Facebook 曾经做过一个针对拉美的应用，叫做 Flash，跟 SnapChat 很类似但这是在 Facebook 主应用之外的一个独立应用。Flash 花了 3 个月就发布了第一个版本，我们团队跟 Flash 团队合作，基于他们的代码进行二次开发，有时候会因为代码质量踩坑，我们非常希望 Flash 团队维持很高的代码质量。但他们的目标就是快速验证拉美是否存在一个低端用户的 SnapChat 市场，所以他们就一直往前冲。又过去了三个月，他们团队进行了一次内部讨论，到底接下来应该继续往前冲，还是先重构一下代码以便将来跑得更快，最后他们选择了继续往前冲。

我们团队虽然不喜欢他们这个决定，但这是一个正确的决定。做决定之后的三个月，他们做了最后的冲锋，把值得做的事情都尝试了一遍，最后的结论就是这个市场不存在或者说不值得做。Flash 应用下线，代码全部删除，团队解散。重构并不会改变这个结果，之后稍微推迟这个结果。从商业的角度来说，重构导致了近期成本，但不会带来长期收益，所以不应该进行重构。

---

如果我们是一个做券商的金融创业公司，那取舍的方向就可能很不一样。我们的首要目标是评估代码出现逻辑错误导致的财务风险。如果我们做的只是现金业务，财务风险是有上限的，也就是所有用户存放在我们这里的现金总量。在最坏的情况下，我们可以把所有用户存放在我们这里的现金都归还给用户，然后可能再承担对应的监管机构罚款和诉讼赔偿，损失的总额是可以进行估算的。如果我们涉及到证券业务，财务风险可能就是不封顶的，因为证券交易可能涉及杠杆和做空。

在进行这种讨论时，需要注重两方面的思维能力：

第一，对商业运作涉及的风险有基本的认识。可以不是很懂面试这家公司的具体商业模式，但要有商业常识和词汇，能够跟面试官进行这方面的沟通，然后才能进行商业上的趋势。

第二，坚持第一原理思维。不要为了控制商业风险就进行重构，而要思考控制商业风险的最佳手段是什么，用这来判断重构是不是合适的技术手段。商业风险有很多非技术的控制手段，例如说买保险。就算是技术手段，也不一定需要是重构，可能提高测试覆盖比例的性价比更高。总之不要为了合理化重构而找一个商业上的理由，那如同拿着锤子找钉子，本末倒置。

---

从这一道面试题可以推导出来一个更加广泛适用的思维模式：不要别人问什么你就答什么。考试（包括 LeetCode 形式的上机考试）往往把人训练为问什么就答什么，因为问题是没有协商空间的。但在面试的时候，一个大活人随时准备好跟你对话，你必须先对问题进行协商。

这是我在做 career coaching 中时常会提醒客户的事情。尤其是面试 senior 或以上职位时，搞清楚面试题的第一原理很重要，你找到了第一原理然后才能围绕第一原理进行解题。至于引出问题的说辞，例如「开发新功能和重构代码之间怎么选」，这其实不是重点。有时候这个说辞可能是个「X-Y 问题」，但我们期望资深的程序员有侦测和解决 X-Y 问题的意识。

美国互联网公司大多数都是要撤出中国的

很多美国互联网公司在中国的业务做不起来，最终选择从中国撤出，在我看来都能用一句话来解释，「就缺一个李开复」。

---

我曾经非常近距离地观察过某美国互联网公司尝试进入中国的过程，后来也了解了一下其它公司的故事，基本上中国甚至是亚太地区做不下来都是同一个原因，那就是亚太部门得不到充足的自主权（autonomy）。

同一个故事，在不同的公司、不同的部门反复重演。这可能发生在一个经理和一个总监之间，或者是一个总监和一个副总裁之间，反正都是一对直接汇报的上下级。在这对关系当中，上级之所以成为上级，就是因为过去的成功经历。他参与了公司夺取美国甚至是美洲市场的过程，然后带领公司夺取欧洲和非洲（EMEA）市场。他在这个过程中爬到了公司职级的顶端，现在被委以重任，要把久攻不下的亚太市场打下来。

这个级别的人很清楚这件事不是自己亲历亲为就行的，必须搭建一个专业的本地团队。他从本地公司把人才挖过来，或者从本地其它外企挖。这个人是本地业务的专家，他很清楚怎样做才能成功，他能够搭建自己完全本地的团队。一开始这一切都是欣欣向荣的样子，公司有充足的预算来冷启动一个本地团队，公司上下看着这个团队成长的速度都都觉得进度非常满意。

本地团队搭建好了，真正要开始从本地竞争对手手上抢流量了，问题就会慢慢暴露出来。这一对上下级当中，下级是本地业务的专家，对于如何抢占本地市场他有他的方法。但是亚太市场跟欧美相差得实在是太远了，他做的事情他的上级无法理解，于是他要在两者当中选一个：

一个选择是做上级能够理解并且认可的事情，只有上级认可才能获得更多资源，自己才能爬职级。即使这些事情在本地市场完全没效果也没关系，等大家发现自己实际上打不下来这个市场时，自己已经爬上去了，可以跳槽了。

另一个选择是做正确的事情，然后不断被上级质疑。这时候上级在欧美市场的成功经验会成为最大的障碍。上级从自己的经验来看，下级做的事情都是徒劳的，都不会有结果。别说结果了，他甚至不知道如何衡量进度。他不知道如何向上汇报这个本地市场当前的进度，但不能展现良好的进度就很难获取更多的资源，最终影响自己爬职级。这时候他也只有两个选择：

一个选择是信任下级，让他做正确的事情，即使自己不理解。抛弃自己在欧美市场的成功经验，选择相信自己挑人的眼光，豪赌自己选对了人。这其实是非常难做的一个决定。作为一个投资人，你会投资给一个你完全看不懂甚至进度也测量不了的业务吗？这不是一个理性的选择，大多数爬到这个职级的人都不会做这样的选择。

另外一个选择是亲自下场。既然下级做不出自己满意和能够向上汇报的进度，想想自己在欧美市场的成功经验，相信自己能做得不差，干脆自己做好了。这时候这对上下级之间的矛盾就出现了。（理论上他还有第三个选择，那就是换下级，希望下一个下级是正确的选择，能够做出令人满意的进度来。但这本质上就是回到第一步。）

很多美国公司最后就死在这一步。自己所有的成功经验都来自于欧美，把成功经验投入到亚太地区导致失败，但请本地专业人才来做又难以衡量进度和结果。这时候唯一可能能赢的选择是盲目地提供给本地团队相当高的信任程度，让他们有充足的自主权做他们认为正确的事情。有可能本地团队所招到的其实是人渣而不是人才，他们都在浪费公司资源追逐私利，但不愿意赌的话就不可能成功。

---

跟亚太地区比的话，欧美地区是如此地同质化国家之间的区别可以忽略不计。我在美国互联网公司观察过亚太地区不同国家的数据，不同国家之间的文化差别如此之大，一个产品、一种策略在某个国家的数据完全不能用来预测另外一个国家的趋势。

把亚太区拆开，我们只看东亚的数据，中日韩这三个国家的数据没有什么相关性。再把国家拆开，例如说看港澳台地区和内地的数据，依然没什么相关性。亚太市场实在是太难了，每一个国家和地区都不同，都需要进行针对性的产品和运营优化。尝试把整个亚太区看作一体的公司，最终会发现在一个国家适用的产品在另外一个国家不使用。

举一个具体的例子：Facebook 的定位是把现实生活中的好友关系映射到社交媒体上，Facebook 不希望用户把它作为网上匿名交友平台，所以要求用户使用真实姓名。这在 Facebook 拿不下来的日本市场遭受巨大的阻力，为此只能给日本用户开特例，允许他们使用网名。Facebook 对日本用户做调研时发现他们的态度是「我上网时用的就是我网上的名字和身份。就算是现实生活中的朋友，在网上也叫我网名而非真名。我不愿意在 Facebook 上用真名。」

再举一个例子：十多年前百度曾经有一个目标叫做「划洋而治」，意思是占领太平洋这一边的市场但不参与太平洋另一边的竞争。百度进军的第一个国际市场是日本，为日本做了一个全新的贴吧，比当时的中国贴吧要先进，编辑器支持富文本，发贴可以有彩色文字、可以嵌入图片等等。这个产品当然没能占领市场，最后对日本用户进行调研，他们说「我们不需要富文本编辑器，我们习惯使用纯文本编辑器。但是我们必须要有 Emoji，没有 Emoji 我就不用了。」那可是 Emoji 还没标准化为 Unicode 的年代，日本不同运营商使用不同编码表示 Emoji。

---

回到我最初所说的「就缺一个李开复」，我真正想表达的意思是这些美国公司都缺一个同时能够在公司高管圈内混得开且在深入了解中国的人。如果这两项技能分别来自于两个人，那就会出现我前面所说的上下级矛盾。能够在公司高管圈内混得开的上级跟深入了解中国的下级难以达到心灵默契的状态，前者觉得后者没有做出来合理的进度，后者认为前者完全不懂中国市场。最终中国市场做不起来，撤出中国就是理性选择了。

Facebook 工程师文化独特之处

我在 Facebook 工作了 7 年，结合 Facebook 之前和之后的其它公司的经验，我觉得 Facebook 的文化有些独特的地方值得分享一下。尽管我说了「独特」，这不代表其它公司绝对不会这样做，有些公司有相似的文化，有时候相似的文化用力程度不一样得到的结果也不一样。

工程师对产品结果负责任

我见过很多互联网公司只看工程师产出的技术成果，实际产品结果或商业结果在考评中占的比例很大。Facebook 从高级工程师开始，考评主要看对产品结果的产出，而且有时候非常数据驱动。

考评只看技术的公司，或者是 Facebook 没到高级工程师的级别，只要把技术做极致了就行，产品得不到提醒，公司的商业没有变得更成功，工程师都不用负责任，锅可以甩给产品经理。一款新产品一个新功能做出来，代码可靠从不崩溃，性能优化做足从来不卡顿，界面跟设计师出的图完美吻合，等等等等，工程师就算是优秀的工程师了。如果团队的目标是提升用户留存率，这个技术上完美的新功能发布后留存率不仅仅没有上升还下降了，工程师不需要负责任，考评受罚的只有产品经理。

这种模式的问题是工程师和产品经理目标不一致，更容易产生利益冲突。工程师说「我就是要做这个技术上这么复杂的项目，否则晋升委员会觉得我技术不够不让我晋升」，产品经理说「这个项目消耗你很多时间还不太可能提升产品留存率，同样的时间你可以做好几个有可能提升留存率的功能了。」在极端情况下，这会让双方对立。我在百度时就见过一个例子，只是把工程师换成设计师：设计师说这样设计好，产品经理说那样设计好，双方都只是在利用主观判断说服对方，最后产品经理说「如果做你的设计，KPI 掉了你负责任；如果做我的设计，KPI 掉了我负责任。你想要对 KPI 负责任吗？」设计师立即闭嘴。

考评主要看产品结果的公司，把技术做到极致没用，产品完成指定目标才有用。如果团队的目标还是提升用户留存率，留存率提升了，达到预订目标了，工程师和产品经理（以及其它角色）都能考评过关，远超过预订目标的话还能获得奖励；留存率没有提升，或者是提升不够，工程师和产品经理的考评都会受罚。

工程师不能甩锅给产品经理，两者的目标高度重合。工程师知道，「产品经理指错路」不是借口，产品达不到预订的目标就要受罚。因此 Facebook 的工程师往往非常了解自己在做的产品的指标和数据，他们会花时间去看分析产品数据、阅读用户调研报告，而不是等待产品经理搞明白要做什么了再分配任务。如果工程师坚信产品经理指错路，那就必须自己找到正确的方向然后把结果做出来。没有结果就要受罚，可能是不及格的绩效，可能被炒掉，Facebook 不接受任何解释只看结果。

这种模式可以驱动一个产品团队坐下来好好合作，想方设法利用每一个成员的能力，因为只有这样才能达成目标。如果工程师觉得自己擅长做技术且只喜欢做技术，在这种环境下迟早被炒。所有人都在一条船上，要死一起死。「喜欢做什么」有时候就要给「什么必须要做成」让步，因为做不成船就沉了，大家一起死。

这种模式在自顶而下划分任务的公司不可能成功，只有鼓励自底而上解决问题的公司才能成功。自顶而下的公司，就如同只有船长有权向下发布命令，而且很多时候不需要解释命令的意图，所有船员都觉得自己只要执行命令就好，不需要关注其它人在做什么，不需要理解整艘船是如何运作的。如果船快要撞上冰山了，没有船员会觉得自己有能力和责任阻止船真的撞上去，因为只有船长知道船是怎么运作的，其它人只能无奈的等船沉没。

Facebook 的各级经理都鼓励下属自行定义「什么叫做成功」，如果经理觉得成功定义得合理，就放手让下属自己想办法把事情做成，不需要告诉下属「做什么才能成功」、「如何做才能成功」。如果产品团队主动提出「留存率增长 10% 叫做成功」，只要经理觉得这是对公司合理的贡献，产品团队自己想办法把留存里提升 10%。这样做才能要求产品经理和工程师一起对产品结果负责任，因为「当初是谁定义成功就是留存率增长 10% 的？」

基础架构被视为内部产品

有一些公司会强行在内部推广自己的基础架构。基础架构要进行不向下兼容的升级时，所有内部用户必须派人负责升级。据我所知 Google 就是这样做的，例如说 Google 的某个基础架构服务要从 1.0 升级到 2.0，但它们的 API 是互补兼容的，那用到这个服务的所有团队都必须安排工程师负责更新自己的代码，改为调用 2.0 的 API，否则 1.0 一旦下线这个团队就无法使用这个服务。

Facebook 正好是相反的，基础架构在一定程度是也被看作是产品，只是用户是内部用户而已。那作为产品，当然自己要想办法找到自己的用户，自己要想办法把用户留住，自己想办法扩大用户基数，等等等等。一个新的基础架构出来，没有名气，没有成功案例，必须自己想办法推广和招揽用户。潜在的客户可能说，「你这东西看起来不错，但我不是很确定用了是不是真的对完成我的目标有帮助，我也没空学习和使用你的东西」。遇到这种情况，Facebook 的基础架构团队就跟外面的 SaaS 服务提供商一样，要想办法讨好用户，例如说「没关系，我们团队派专人来帮助你们学习和使用我们的东西，觉得好用的话你们接着自己维护，不好用的话也不浪费你们资源」。

当初 React、React Native 等技术出来时也经历同样的过程，在没有名气之前作者就要想办法推广、说服别人来用自己的东西。外面只看到它们发布时的光环，没看到早期推广的各种困难。2016 年我曾经负责调研 React Native 是否适合用户增长部门使用，因为用户增长主要靠做实验，实验周期受客户端升级周期限制，React Native OTA 升级可以突破客户端升级周期限制。在我做完调研后，我给了大大的一个「NO」，因为 Facebook 主要的用户增长来源自 Android 而当时 React Native 的 Android 版性能（加载速度和内存消耗）实在是不行，和内部其它服务的整合也满地是坑。

基础架构不仅仅新品需要推广，升级也需要推广。「你们出个 2.0 跟 1.0 不兼容？我们一个高级工程师需要花三个月时间改写我们的代码才能兼容 2.0？那我们不升级了。你们准备准备暂停 1.0 的服务？没关系，我们自己出机器，我们自己跑一个 1.0 的实例，反正公司内所有组可以访问所有代码。你们准备把 1.0 代码改得面目全非？我们现在立即 fork 你们的代码！之后我们自行维护一个 1.0 的 fork。」

不向下兼容的基础架构升级往往还是要想方设法讨好已有用户。「你们可以继续用我们的 1.0 服务，但 2.0 性能更好哦。你们组的目标不是转化率吗？你们之前也做过实验，证明了转化率和性能高度相关，提升性能就能提升转化率。我们来算一下，提升这么多性能就能提升这么多的转化率，这绝对值得你们一个高级工程师花三个月来做啦。」工程师既要做销售又要做客服，实在不容易。

既然基础架构被视为内部产品，那产品有的压力基础架构也有。新的基础架构如果在一定时间内无法获得充足的用户，那就很可能被要求终止。已经垄断内部市场的基础架构也不能松懈，如果服务不稳定，内部用户不开心，他们会用脚投票。这些用户团队可能会自己做一个仅适用于他们的服务来取代你的基础架构，也可能有其它人做一个跟你竞争的基础架构然后趁机挖你的用户。

救火比防火更容易获得回报

Facebook 的文化有优点也有缺点。因为公司非常数据驱动，考评倾向于用数据说话，没有数据等于没有干活，完全不看你有没有苦劳，这导致防御性措施很难吸引人去做，因为成功阻止了坏事发生时你没办法收集数据说你成功阻止了多少件坏事、它们可能有多坏。

喜欢写测试的工程师进入 Facebook 往往会因为多写测试而受到惩罚。「你能证明这些测试实际带来的好处吗？你能量化这些好处吗？不能的话你还不如去做新功能，至少新功能能帮助提升产品指标。」不能量化的事情在 Facebook 是很难吸引人去做的。很多工程师技术非常好，但用数据讲故事的能力不行，这种事情就没办法做。

懂得用数据讲故事的话，好像测试这种不能直接量化的东西，可以找参考数据间接量化。「我们分析了去年的每一次事故并且确定其中 n 次是可以被测试防范的，考虑到今年我们团队多了 50% 的人，如果有测试的话我们今年可以防范了 1.5n 次事故。」如果经理认同这种推理的话，你就可以安心写测试了。（如果真的有人明年回来分析今年的事故的话，你最好能证明其中没有一次事故能被测试防范。」）

这种间接量化还是必须等坏事发生过了才能使用，如果你在坏事尚未发生之前就成功阻止了这一类坏事的发生，你没办法证明你工作的价值。这就导致了一个很不好的现象，我往往用以下的比喻来解释：

假想你是一个小镇的消防队队长，你四处去检查镇上有没有违反消防规范的地方，有你就叫负责人整改。这个小镇上所有人都狠你，见到你来检查消防就叫你滚，因为你给大家制造麻烦而没人觉得这些麻烦带来了任何好处。小镇的商户联合起来说每年这百分之几的成本都是你造成的，没有你的话就能有更高的利润。

在消防队队长这个职位上，你只能默默地等待火灾发生。一个房子烧着了你还不要着急去救，救了大家就会说「火灾的损失也很有限嘛，不知道花那么高的代价去防火」。你利用这个时间着手准备灭一场大火。等房子烧了一片了，小镇居民在路上奔跑呼喊了，你就去救火吧。（当然这一切的前提都是你真的有能力救火。）之后你要颁布什么新的消防规范，所有居民都会主动配合。

这就是为什么 Facebook 内部那么多问题处于起火状态，因为不起火就没有救火英雄。

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

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

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

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

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

时常会有人来问我，应该加入大厂还是小厂。提问的方式有时候是很具体的，例如说「我有这几家公司的 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 这种全公司统一招聘的。虽然大厂内的每一个团队都好像小厂一样，拥有此时此刻特定的招聘需求，但因为团队数量足够多，所以在统计学上大厂可以无视这些差异按照一个标准来招人。由于大厂的招聘标准如此的稳定和可预测，针对大厂的招聘标准做准备反而更容易。你可以尝试搞清楚大厂的招聘标准，搞清楚后这套标准不会变来变去。一旦你满足了这套标准，你不需要太过关心个体差异。

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

---

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

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

如何有理有据地说服其他程序员

TL;DR 当两个相对聪明和胜任的程序员对同一个问题持有截然不同的观点时，往往问题出现在大家对问题的定义不一样。争辩观点对错的往往并不能达成一致，这时候必须先确认大家在讨论的是同一个问题。如果没办法对齐（align）问题，尤其是当双方的优先级（priority）不一致时，争辩问题的解决方案是不可能有结果的。

人际矛盾

人际矛盾是行为面试（behavior interview）中常见的考点，作为面试官我自己经常问相关的问题。例如说，我在 Facebook 时就经常问以下两个问题：

1. 有没有试过你和你的同事各持不同的观点，而且双方都坚持认为自己是对的，最后你成功说服了对方？
2. 把上面的问题反过来，有没有试过最后你被对方说服了？

对于不同级别的程序员，我们对人际矛盾有不同的期望值。初级程序员，就算不能把矛盾解决，至少不能把矛盾激化。高级程序员，需要有能力把矛盾化解掉，从而推动自己的项目前进。更资深的程序员，需要有能力梳理组织当中错中复杂的利益和矛盾关系，优化组织提高效率。

在这篇文章里，我们的关注点是如何化解人际矛盾，这是很多初级程序员需要学会的技能，也是很多高级程序员需要持续提高的技能。在 career coaching 过程中，我时不时也会遇到客户提出这方面的问题，我给出的方案都是类似的，因此我觉得用一篇文章来解释会更好。

两个聪明人解同一问题……

我还在 Facebook 时，一个非常资深（总监级别）的华人程序员在一次吃饭时分享了一个观点：如果两个聪明人尝试解决同一个问题，但他们各自得出了不一样的答案，往往并不是其中一个人错了，而是他们拥有的信息不一样，各自根据自己拥有的信息进行推理就会得到不一样的答案。这时候双方必须先互通有无，把自己拥有的信息都摆到台面上来，然后再一起利用眼前的信息解决问题。

这一个观点是我的理论基础。我见过很多人因为意识不到这一点而陷入无效的争辩，甚至激化双方情绪。尤其是强调逻辑思维能力的程序员，很容易推理出这样一个结论：因为一个问题必然有且仅有一个正确的答案，又因为我和你的答案不一样，所以我们两个当中至少有一个人是错的。因为我很确信我自己是正确的，所以你必然是错的。因为你是错的，所以你比我笨。

这个推理过程是正确的，但前提是两个人在解决的是同一个问题。否则就如同考试后对答案发现两个人的答案不一样，争辩半天谁对谁错后才发现这场考试分 A 卷和 B 卷，大家做的根本不是同一道题。很多聪明人都犯过这样的错误，也就是跟别人争辩为什么自己的解法是对的，而忘记了检查大家是不是在做同一道题。

先定义问题再讨论解法

对于很多名校毕业或者大厂工作的程序员来说，其实自己和身边的人都已经足够聪明了。如果发现自己在跟别人争辩观点争辩不出来结果时，最好就先审视一下双方是不是在讨论同一个问题，如果不是很确定的话就先把问题定义清楚。当然，复杂的问题不可能方方面面都定义得很清楚，还是会涉及很多假设。如果双方对约束和优先级做了不同的假设，得出不同的结论是很正常的。所以我会建议大家先明确约束和优先级都有哪些。

对约束进行不同的假设

两个人从广州出发去北京，A 说往左走，B 说往右走。这时候看起来「从广州去北京」是同一个问题定义，但可能 A 想着的是去机场搭飞机，B 想着的是去火车站坐火车，所以走了不同的方向。如果两个人对于交通工具没什么看法，那澄清一下自己假设使用的交通工具矛盾就化解了。「我以为我们去搭飞机呢，原来你想着的是坐火车。我其实没什么所谓，你想要搭什么我们就一起走吧。」

但如果有更深层次的原因导致他们做出这样的假设呢？例如说，B 没有钱搭飞机，他只能坐火车。这就是一个约束了，加上了这个约束问题定义就不再是「从广州去北京」，而是「用有限的钱从广州去北京」。如果 A 不知道 B 有这个约束，那 A 和 B 在解决的就不是同一个问题。接着 A 和 B 可以就飞机好还是火车好大战五百回合，但矛盾仍然是解决不了。要化解这个矛盾，就必须要让 A 知道 B 有一个钱的约束，之后问题可能多种解法。A 可以说「那我陪你一起坐火车吧」，也可以说「我多出点钱请你搭飞机吧」。但如果 B 觉得没钱搭飞机是一条必须隐藏起来的信息，那这个矛盾就非常难解决了。（你需要一个情商非常高的 A，在获得这一条信息后按照这个约束来解题，同时又不暴露自己掌握了这一条信息。）

---

我在管理某个 iOS 的团队时就遇到过由于对约束的假设不一致带来的矛盾。我们在做一个新的 app，一边是两位很资深的程序员，他们拥有丰富的创业经验，他们用创业的风格迅速的写了一版原型；另一边是几个大厂培养出来的高级程序员，他们接过这个原型，把它打磨成最终能发布的产品。这种一边是特种兵另外一边是正规军的配合，很快就出现了矛盾。其中有一个矛盾我印象深刻，因为这个矛盾明显就是由约束不一致造成的。

正规军觉得特种兵写的原型代码是渣渣，接手后就开始大规模重构，按照 iOS 的思路把东西都封装进不同的 ViewController 里面。特种兵觉得正规军在浪费时间重构，正规军觉得这样做才符合大厂规范。这个矛盾我深挖到底，才发现源头来自于哪里。在特种兵打头阵写原型时，他们负责解决的是最难的技术问题，因为这些问题交下去给别人写可能就解决得不够好。其中一个技术挑战是，这个 app 在云端有三万张照片时，客户端要能够流畅地滚动和浏览照片。这个挑战在原型中是解决了的，但重构的过程中为了进行封装，一个原本 O(n) 的算法就被迫重写为 O(n^2)，于是客户端在有三万张照片时滚动就不再流畅。

这里的隐藏约束就是「有三万张照片时要能流畅滚动」，这是当初特种兵带头立项时定下来的需求之一。但这没有很好地沟通给所有人，所以当正规军接手后就不知道有这个需求。在没有这个约束时，重构一下能提升接下来的工作效率那当然应该重构，于是就重构到不再符合这条约束了。这个矛盾的本质跟前面的例子一样，「显示云端照片」和「显示三万张云端照片且能流畅滚动」不是同一个问题。

对优先级进行不同的假设

A 和 B 又要从广州去北京了，这时候 B 已经有钱搭飞机了，但 A 反而想要坐火车了。A 尽管有钱搭飞机，但他最近想要存钱投资，觉得坐火车省钱更好。B 则想要快点到北京，多一点时间在北京玩。这时候看起来问题都还是「从广州去北京」，但两个人的优先级是不一样的。A 要解决的问题是「用尽量少的钱去北京」，B 要解决的问题是「用尽量少的时间去北京」，这自然会导致不一样的解法。

不同优先级带来的矛盾更难解决，因为有时候就算双方都把自己的优先级摆上台面了，但因为双方都只在乎自己的优先级不在乎对方的优先级，问题定义无法达成一致，最终问题不可能被好好解决。如果 A 坚持要省钱，B 坚持要省时间，那就算双方把问题定义清楚了，还是不能一起解决。最终的方案可能是，A 提前出发坐火车，最后跟 B 同一时间达到，这样 A 省了钱同时 B 省了时间，但两个人就不能同行了。

---

这种矛盾在那些前后端明确分工的公司还挺常见的：后端的优先级是自己少干活，最好就是 API 数据结构和数据库直接存在映射关系，复杂的场景就让前端调用多个不同的 API 然后自行组织数据维护状态吧。前端的优先级也是自己少干活，最好前端要做的每一件事情都只需要一个对应 API 调用就能解决，如果多个 API 调用之间需要维持状态那就应该由后端来维持。这种优先级的矛盾，如果双方都隐藏起来不说，再怎么争辩什么是「更好的系统设计」都没有用。如果双方愿意把自己的优先级说清楚，明白到对方的苦处，找个折衷方案，各自承担一部分的负担，那才能把矛盾化解掉。

总结

最后总结一下，当你发现你跟别人争辩不出结果时，尤其是你觉得自己是对的但对方好像也有道理时，你最好检查一下你们是不是在解同一道题。往往你会发现你们在解的不是同一道题，这时候你们就应该先讨论问题的定义，把问题定义清楚往往很快能找到一个双方都同意的结论。当然有时候因为双方优先级不一致，无法接受同一个问题的定义，那就是另外一类问题了。有空我可以再写写如何应对优先级不一致造成的矛盾，大家可以订阅/关注我，这次就先写到这里。

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 测评》。

AlgoTogether 算法面试小班（信息更新）

我们三个月前发布的招生信息仍然有效，现在再补充一些新信息。

免费学习材料

我们不提供试听课，但我们免费提供一部分的学习材料，方便大家来了解我们的教学风格。这里面包括两段教学视频，和两道 LeetCode 中等难度题目的解题思路文档。大家可以打开以下链接填写你的基本信息后获得上述免费学习材料：

https://techcareer.typeform.com/to/IKKYnObZ

如果看完免费学习材料后觉得我们的教学风格对你胃口的话，请尽快来付费报名哦，因为我们的第四期马上就要开始了。

教练及助教信息

我们的教练团队越来越大，并且新增了助教角色，所以必须向大家公布一下我们最新的团队信息。以下是我们详细的教练信息：

• Wilson: ACM/ICPC 金牌选手，毕业后回校训练学生并带队参赛。在 FANG 有多年的面试官经验。
• Cat: 从小学开始参加编程竞赛，一直参赛到高中获取保送。在 FANG 面试 ~200 名候选人并培养了 ~50 名新面试官。
• Michael: 在 FANG 拥有丰富经验的面试官。

除了一流的教练外，我们还有非常优秀的助教：

• Leaf: AlgoTogether 优秀毕业生，成功从非科技行业转入互联网行业。
• Tiger: 在读计算机博士生，曾在 FANG 实习。

学生评价

以下是我们收到的学生评价，大家可以参考一下，看看我们这个班的强项是否对你有帮助。

jhs：

第二期学员反馈：1. 题目分类清晰内容丰富，一轮项目结束以后对不同类型的算法题会建立起比较直接的大脑反应。对于准备刚开始刷题或者刷了一段时间题摸不清套路的同学很有帮助，对我个人的提升是解题速度更快了。 2. 比较喜欢 mock interview 的环节，能够最大限度的锻炼你 think loud 的习惯，这对于在北美求职的同学来说，这种习惯可能会让你在面试中更有优势。 3. 教练经验丰富，回答很多公司招聘时的实际问题。而这些问题很多时候只有一定经验的面试官才会有，对于求职者来说非常有帮助。

Tianqiang：

第二期学员。之前在知乎上有看到这个项目的介绍，比较感兴趣就报了一期。当时 Leetcode 刷了差不多 200+。项目每周总结的 topic 的题目做下来之后归纳总结，后面碰到类似的很快就有思路。我个人觉得帮助最大的是 Mock Interview，现实生活中很难找到有大厂招人经验的人来 mock，全英文交流以及白板或 codeshare 环境和 leetcode 刷题的感觉完全不同，重点在于与面试官的沟通与交流，习惯后真正面试时也不会过于紧张。推荐刷了很多题但是还不够自信面试的同学尝试这个项目。

Yuqing：

我是第二期的学员，算法知识方面的帮助很多同学都有提到，我也不再多说了，除此之外我觉得这个项目最大的亮点是每周的 presentation 和 mock 都可以得到大厂面试官的点评。面试的时候可能题会做但是怎么能清晰的表达出来自己的想法，把自己的算法和面试官讲明白同样也很重要。在这个项目中能知道专业的面试官希望听到什么样的回答，怎么能更有效的和面试官沟通，这一点是很多其他算法班没办法做到的，对我的帮助也非常大。

FlynnGao：

作为第二期的学员，说一下感受。首先一个给课程结构一个好评，本身预期以为有算法学习讲课，但实质通过模拟面试的讲解和更注重整个面试流程的各种问题，也可以从另外一个方面更加深入理解算法题目。面试过程中可能遇到的各种问题都有解答，有更加全面理解面试流程的效果。算法题的选择上个人觉得整体中等偏简单一些，当然也是为了更加方便整合整个模拟面试流程。对于学员的各种问题回答和表现的评估，AlgoTogether 的几位老师也表现出色。顶着时差基本全部的课都上完了，我给到 85 分。

罗凯：

第一期学员发表一下感想。1.题目归纳的很有条理，基本上跟着项目走下来 leetcode 上大部分题目都有思路了。 2.教练业界经验很丰富，回答了很多关于实际工作的问题，也给出了很多代码风格如何优化的建议。3.同学都很认真，每周一次 mock 的时候听同学讲也收获挺多的。很多题目的想法是 leetcode discussion 里面也没有的。教练也非常有耐心，有一次周二晚上讲一个比较难的题目，一直讨论了快半小时，我这边东边都 11 点多了。4.项目每周大概十个题，要都弄懂还是要花点时间的。做 mock 对真实面试帮助挺大，需要自己思路清晰，代码能跑到把代码讲清楚这之间也是有距离的，需要练习一下。

SKY：

作为第一期的学员，还是非常推荐这个项目的。教练很上心水平也很高，有问必答。每周的资料都很有针对性，涵盖面很广。最后一周还有教练自己收集总结的的最新大厂 OA 以及面试题，受益匪浅，在这里说一声谢谢。

邮件咨询

如果你看到这里了都还犹豫不决，那你发一封邮件给我进行咨询吧，在邮件里说一下你找工作的计划、你对找工作的决心有多大、你觉得现在的瓶颈在哪里，然后附件发送你的简历（或粘贴你的 LinkedIn 地址）。我会回信跟你分析一下你的现状，给你一些建议。

algotogether@techcareer.io

AlgoTogether 算法面试小班（第四期招生）

AlgoTogether 上周日宣布第三期招生，不到一周时间就全部报满了！一开始我们开放了 20 个名额，结果到周五晚上就全没了。周五一天之内有 8 个人报了名，把剩下的名额都抢光了。因为还有学生特别想要报名，周五没抢到名额就跟我联系，我周六悄悄加了 5 个名额上去，当天就消耗完了。

考虑到 AlgoTogether 如此热门，仍然有学生想要报名，我决定立即开放第四期的报名和支付。第四期预计 10 月 31 日开始，到明年 1 月 2 日结束。课程格式跟第三期相似，但会在第三期快要结束时根据第三期收到的反馈做轻微调整。如果你原本想要报名第三期但错过了，可以点击以下链接报名参加第四期：

https://techcareer.io/programs/algotogether

如果你还不是很了解 AlgoTogether，以下是第四期的详细信息如下：

这门课程适合什么人？

这门课程适合下定决心要在美国一流科技公司找一份软件工程是（Software Engineer）工作的人。这门课程对于首次找软件工程师工作的人来说价值最大，例如说应届生或从其它行业转专业过来的人。找全职和实习都适用。对于有工作经验的软件工程师来说，如果最近一年没有做过面试的准备，通过这门课程来准备面试也是一个很好的选择。

这门课程的价值在哪里？

我们的核心价值是「授人以渔」，因此课程的价值如下：

1. 学会以面试官的角度进行思考。在面试过程中，公司对你的评价不仅仅在于代码的正确性和性能优化。我们会向你解释面试官是如何评价面试者的，这是你不可能通过 LeetCode 学习和训练的技能，你学会这些技能后就可以用面试官的视角审视自己，找到自己应该提高的地方。
2. 基于面试场景的训练模式。LeetCode 是训练对着机器做题，面试需要的是对着人解题。我们假设你对前者已经有一定的经验，着重训练后者。后者涉及的技能包括：如果通过提问理清面试官的需求、如何清晰地陈述自己的思路、如何接受面试官的反馈和提示。
3. 给自己下一个破釜沉舟的决心。如果你想要下定决心，在限定时间内做完指定数量的题目，同时完成指定数量题目讲解和模拟面试，我们会保证你对你自己定下的目标负责任。
4. 理解解题思路而非背诵面经和答案。一知半解就去大量做题的话会导致背诵面经和答案的现象。我们强调学习和理解解题思路，然后通过适量的练习来学会如何灵活运用。以不变的解题思路去应付不断变化的面试题目。

课程结构是怎么样的？

整个课程总共 9 个星期的时间。每个星期我们有 3 个天会进行 Zoom 视频会议，另外 4 天进行线下各自的练习和 Slack 上的交流。

每周教练挑一个主题，例如说动态规划（Dynamic Programming），然后围绕这个主题布置 15 道作业题。你有一周的时间来完成这些题目并且提交结果，你至少需要提交 10 道题目的代码和 1 道题目的详细解题思路。所有学生都完成提交后，助教会组织大家投票选出最优秀的解题思路，并且安排题目讲解（Presentation）和模拟面试（Mock Interview）的时间和人选。教练会在整个过程中针对学生表现提供反馈。

我们每周三、周六和周日晚上 7 点（Pacific Time）通过 Zoom 视频会议进行教学、答疑 、题目讲解和模拟面试。不进行 Zoom 视频会议的日子每天同样时间在 Slack 上进行专题讨论。

课程教练是什么人？

我们的教练都在一流科技公司拥有多年的工作经验和面试官经验。我们的首席教练曾多次获得 ACM/ICPC 竞赛奖牌，此外还培训其它学生参赛获奖。我们的助教团队都有一流科技公司的工作经验，且近期经历了面试找工作的流程，非常能理解正在经历这个过程的学生需要什么。

课程使用什么语言教学？

为了保证跟面试过程和工作环境一致，整个 AlgoTogether 采用全英语沟通。学生毕业后，可以加入微信校友群，使用中文沟通。

如何报名和支付？

请打开以下链接然后选择第四期（10 月 31 日到 1 月 2 日）进行报名和支付：

https://techcareer.io/programs/algotogether

如果你看到这篇文章时已经错过了第四期，可以打开链接然后选择你需要的那一期进行报名和支付。

AlgoTogether 算法学习小组（第三期招生）

我开了一个叫做 AlgoTogether 的算法学习小组，面向在美国寻求软件工程师工作（实习或全职）的人。头两期学习小组的效果不错，第二期学生对项目打分 4.4/5.0 分，对老师打分 4.8/5.0 分（数据），所以我决定继续做第三期学习小组。针对头两期学生的反馈，我对第三期学习小组进行了调整，增加了提供标准化反馈的模拟面试环节，设立了学生共同维护的解题思路库。

我知道仅仅通过 LeetCode 准备算法面试是不够的，因为面试并不以题解的优劣来衡量你。你需要让面试官想要和你共事，这需要说服他你能跟他一起通过编程解决难题。AlgoTogether 是一个有教练指导的学习小组，帮助你训练多方面的面试能力，让你在面试时成为面试官的最佳未来同事。在这个学习小组中，你不仅仅需要解题和编码，你还需要练习沟通你的解题思路、接受模拟面试和倾听来自别人的反馈。我们的教练是 ACM/ICPC 奖牌得主，也曾带队其它学生参赛获奖，此外还是大型科技公司中富有经验的面试官。我们保证你投入到面试准备的每一滴汗水都能有充分的回报。

以下是往期学生对 AlgoTogether 的评价：

SKY：作为第一期的学员，还是非常推荐这个项目的。教练很上心水平也很高，有问必答。每周的资料都很有针对性，涵盖面很广。最后一周还有教练自己收集总结的的最新大厂 OA 以及面试题，受益匪浅，在这里说一声谢谢。

罗凯：第一期学员发表一下感想。1.题目归纳的很有条理，基本上跟着项目走下来 leetcode 上大部分题目都有思路了。 2.教练业界经验很丰富，回答了很多关于实际工作的问题，也给出了很多代码风格如何优化的建议。3.同学都很认真，每周一次 mock 的时候听同学讲也收获挺多的。很多题目的想法是 leetcode discussion 里面也没有的。教练也非常有耐心，有一次周二晚上讲一个比较难的题目，一直讨论了快半小时，我这边东边都11点多了。4.项目每周大概十个题，要都弄懂还是要花点时间的。做 mock 对真实面试帮助挺大，需要自己思路清晰，代码能跑到把代码讲清楚这之间也是有距离的，需要练习一下。

为了保证跟面试和工作环境一致，整个 AlgoTogether 采用全英语沟通。以下是 AlgoTogether 的详细信息及报名链接。$800 的 early bird 价格到 8 月 29 日周六结束，之后将变为 $1,000 的正常价格。

What is this program?

AlgoTogether is an algorithmic problem study group with a coach. The program focuses on all necessary skills for coding interviews: problem-solving, coding, debugging, articulating solutions, taking feedback. The coach leads the meetings and mock interviews and makes sure that students learn these skills in a way that they can reapply to new problems in real interviews.

What is the value of this program?

1. Understand how an interviewer evaluates you. You are evaluated beyond correctness and optimality. If a company only evaluates these two it will replace human interviewers with LeetCode to save money. You should learn what’s missing beyond your LeetCode practice.
2. Practice like you are in an interview. You will practice articulating your solution to an interviewer and taking hint or feedback from an interviewer. That’s what you don’t experience if you simply practice with LeetCode.
3. Hold yourself accountable. Are you willing to commit to finishing a certain amount of problems within a specific time frame? If you can commit, we will hold you accountable and prevent you from slacking.

Who is this program for?

People who are highly committed to getting a software engineer job at one of the well-established tech companies. It’s best for people who are seeking a software engineer job for the first time, for example, newly graduated students. It’s also good for experienced software engineers who haven’t done interview preparation for more than a year.

What is the structure of the program?

The program is 9-week long. We meet in Zoom 3 times a week and practice together offline through other days.

Each week the coach picks a theme (e.g. dynamic programming) and assigns 10+ problems within this theme. You have one week to work on them. Then all students submit their solutions, share their thinking processes, vote on other students’ sharing, practice presenting solutions, and get mock interviews. The coach will provide support and feedback throughout the whole process.

We meet on Wednesday, Saturday, and Sunday 7 pm (Pacific Time) in Zoom to have lectures, office hours, solution presentations, and mock interviews. We convene on Slack on the other days at 7 pm (Pacific Time) to discuss a focus topic.

Who is the coach?

Our coach has many years of experience working and interviewing candidates at well-established tech companies. He is also an ACM/ICPC algorithm competition medalist and has coached other students for the competition.

How much does it cost?

Early Bird: $800. (Before 8/22 23:59 Pacific Time.)

Regular: $1,000. (After 8/23 00:00 Pacific Time.)

We think it’s the right price to identify committed students and hold everybody accountable. You will be able to pay with a credit card. It’s non-refundable once the payment goes through.

When does the program start?

We start on 8/29 Saturday and end on 11/1 Sunday. We plan to stop accepting signup and payment on 8/28 23:59 Pacific Time.

How do I sign up and pay?

Please open the following page and click the “purchase” button to start. We will contact you through email after successful payment:

https://chen.cat/algotogether

Update: Please open the link from above and check out the latest program’s date and price, and then signup.

《牛油果烤面包》回顾（Part 5 - 中国）

我在这个系列的第一篇文章里面就说到过，当初为了用最低的成本和最短的时间把节目推上线，我们选择了使用 Anchor 这个平台做发布。它如同 YouTube 一样免费和易用，当然也如同 YouTube 一样无法在中国访问。在节目上线后我们很快就意识到这个问题，于是费了很大功夫进行调整。

---

喜马拉雅是我们的第一个尝试，因为它是国内的平台所以它有义务保证内容可以在国内访问到。在得知 Anchor 在中国无法访问时，我们第一时间去注册了喜马拉雅，并且把我们的节目同步发布到喜马拉雅。之后斯图亚特还去注册了企鹅 FM 和荔枝 FM，但因为手工多平台发布的成本高，但又收获不了多少收听次数，最终放弃了。现在国内的平台就只做喜马拉雅。

提到喜马拉雅就不得不提一下 Apple Podcasts 在中国那一套心照不宣的特殊做法。如果你正常地使用 Podcasts Connect 提交一个播客的 RSS，默认这个节目不会出现在中国区。Apple 通知你节目通过审核时，这仅仅是意味着节目通过了 RSS 格式审核，但这跟中国一点关系都没有。之后 Apple 会默默地审核你的内容，决定你是否能发布到中国区，整个过程不会有任何的沟通，审核不通过也无法上诉。因为我们一开始使用的是 Anchor，它的 RSS 在中国根本无法访问，自然 Apple 不会把我们的节目发布到中国区。

想要把节目发布到 Apple Podcasts 的中国区，民间有一个办法，那就是用喜马拉雅导出的 RSS。因为喜马拉雅本身在中国，所以 Apple 乐意发布任何来自喜马拉雅的 RSS。为此我们专门在喜马拉雅后台申请了导出 RSS，然后把 RSS 添加到 Podcasts Connect。为了避免听众看到我们的 Apple Podcasts 上有两个节目分不清哪个是哪个，我们把喜马拉雅导出的那个叫做牛油果烤面包中国版。

---

考虑到喜马拉雅不是一个泛用型播客平台，为了方便中国的听众使用 Overcast、Pocket Casts、Castro 等泛用型播客应用收听，我们又花钱购买了 Typlog 的服务并且把每一集的内容同步发布到 Typlog。作为付费平台，Typlog 的灵活性比 Anchor 和喜马拉雅都要好很多，而且大多数时候能在中国访问到，不过也有极少数时候用户会报告不能访问。

Typlog 值得一提的是节目文本内容的编辑灵活性。Anchor 和喜马拉雅对内容都是有限制的：Anchor 不允许多层套叠的 bullet points，如果我们写了多层的就必须手工改为一层的。喜马拉雅连 bullet points 都不支持，只能人手在每一行文本前加个星号表示这几行是个 bullet points。Typlog 完全没有这些限制，而且可以用 Markdown 语法来写，非常符合我的编辑习惯。

在建立好 Typlog 发布后，我们就逐步把各个平台收录的 RSS 地址从 Anchor 改为 Typlog 了。这样做是为了保证中国听众就算是通过 Overcast、Pocket Casts、Castro 等平台搜索到我们节目后能正常收听。可惜最近发生了一系列事情，使得很多这些泛用型播客应用被 Apple 中国区下架了，估计这些应用的中国用户将来只会变得越来越少。

---

最后，为了保证我们的品牌、域名和链接掌握在我们手上，不受任何一个发布平台的干预和限制，我选择了建立我们自己的网站。我们的域名 avocadotoast.live 最初只是简单地指向到我们的 Anchor 页面或喜马拉雅页面（根据访问来源国家智能指向），但这样子我们得不到任何网站分析数据，不知道有多少来自中国的用户因为指向错误而打不开 Anchor。为此我决定利用静态网站生成器编写我们自己的网站，每一集节目都要能在我们的网站上打开和播放。

网站的主体是我一个周末连夜赶工做出来的，之后花了不少时间打磨和提升自动化程度。现在只要我们发布到 Typlog、喜马拉雅或 Anchor，我们的网站就会自动更新，保证最新一集总能在我们自己的网站上看到。为了兼容中国和非中国用户的体验，我们的网站还设计为从多个音频来源进行播放，如果其中一个音频来源播放失败就自动切换到下一个音频来源。这样就算中国听众无法访问某些音频来源，最终还是会切换到喜马拉雅的音频来源从而保证播放。

制作这个网站的详细技术抉择我觉得可以单独写一个系列，就不在这里详细展开。有兴趣了解这个项目背后细节的话，请通过邮件或 RSS/Atom 进行订阅。如果我接下来还有时间继续写这个系列的话，我会写一写我们进行远程录音的经验。尽管我之前已经写过录音剪辑经验，但现在大家不能面对面录音了所以我们又摸索了一套新方法来做远程录音。这个话题我们下次再聊。

《牛油果烤面包》回顾（Part 4 - 选题）

之前写了 3 篇《牛油果烤面包》的满月回顾（1 2 3），现在准备继续写下去。当然满月早就过了，甚至连半年都不止了，然而又没到一周年，所以文章标题就不再提及时间啦。上次我们说到了我们从个大平台都能获取到什么样的收听数据，那这次我们就说一说我们是怎么做选题的吧。

要说选题，那必须先说一下我们的受众定位。这在我们几位主播之间其实没有非常统一的观点，我们有人更在乎在美国的中文听众，也有人更在乎来自中国的听众。来自中国的听众又可以细分为更多的类型：有些是已经接触到比较多英文信息和海外信息的，那就比较类似在美国的中文听众；有些技术研究得很深入但只熟悉中文的术语，遇到英文的就比较难听进去；有些技术了解不深，希望多听听浅显易懂的科普内容，对深入话题不感兴趣。因为我们在这方面没有统一，所以选题时也没有刻意针对哪一种中文听众类型来做，每一期的受众会略微不一样。

---

我们选题一般会有两种风格：一种是侧重专业性的，一种是侧重娱乐性的。前者的目标是让听众爽，后者更多是主播和嘉宾自己爽。

我们先说说前者吧，我们在做这类选题时一般优先从我们身边的朋友里找专业人士，想想他们熟悉的专业内容如何能够塑造成相对科普一点的话题，保证讲述过程中的趣味性和故事性。然后我们就会跟这些朋友说，希望找他们来录一期节目，问一下他们是否愿意，然后再协商什么能说什么不能说。因为他们工作领域和公司的限制，可能有些事情他们能多说，有些事情他们不能说，这些都是要提前说好的。

因为我们强调自己是一个科技性的节目，所以我们找的很多专业人士都是自己的同行，也就是科技行业的从业人员。推荐系统、人工智能硬件加速、人工智能在传统行业的落地、搜索引擎、计算机视觉、激光雷达都属于这种类型的节目。当然我们身边也有不少朋友在非科技领域有非常深入的见解，我们也会请他们来介绍他们的专业。私人飞行执照、美国公务员、美国个税、疾控中心、Airbnb 短租房东、桌游、电子游戏都属于这种类型的节目，因为作为主播我们自己也不是很懂，所以录制节目的过程也是我们自己学习的过程。

至于娱乐性节目，主要就是我们自己想要说，说完了还想要分享给大家听，所以我们就录了。这方面的选题是非常随性的，总之有主播想要录，我们有档期就录。这类型的节目包括互联网信息获取、在家办公、台北旅游、托斯卡纳旅游、伊朗旅游。此外还有一些选题是介于专业性和娱乐性之间的，我们做不到非常有深度的专业内容，但我们觉得嘉宾有独到的经历和见解非常值得分享，于是我们就会去录：中美互联网公司异同、美国裁员、冻卵、硅谷春晚。

最后还有一类特殊的选题，叫做蹭热点。我们还是希望我们的节目能够获得快速增长的，而蹭热点有时候是个很有效的办法，虽然不一定能成功。（这是我在知乎回答问题的经验啦，回顾了一下得票最多的答案，有一部分是蹭热点而来的。）这部分选题的时效性非常强，某个事件发生后必须尽快完成录音、制作和发布。我们的第一期节目iPhone 11 发布会就是这种类型，后面还有BlizzCon、CES（1 2）以及下周马上要发布的 WWDC。

---

回顾我们的选题，从播放量来看最可靠的是专业性题材的节目。这些节目我们可以持续做，只要我们能够一直找到新的专业话题，在一定程度上来说我们可以「量产」这种类型的节目，而且每一集都会有比较高的播放次数，但并不是最高的播放次数。那最高的播放次数来自什么呢？这需要的不是专业见解，而是情绪上的刺激。要让听众一看到题目就能产生情绪上的反应，以下是一些例子：

• 美国裁员这一集刺激的是大家恐惧的情绪。在美国拿着工作签证的人都知道，一旦被裁员那就有可能被迫离开美国，之前那么多年投资在留学和工作上，就差那么一点拿不到绿卡是一个巨大的损失。这一集的播放次数非常高。
• 中美互联网公司差异成功的刺激到了中国程序员对行业内卷的负面情绪，大家都想了解一下其它国家的互联网行业从业体验是怎样的，所以播放次数也很好。
• 搜索引擎通过在标题中提及百度的没落而刺激到了中国网民对百度的厌恶情绪，很多人不仅仅收听了这一集的节目，还在评论种表达了对百度的不满。

有意思的是，人类确实更容易受负面情绪的驱动，在收听播客时也如此。这是现代市场推广所才去的一个常见手段，当然最终会导致民众两极分化，这又是一个新的问题。我们在选题时不会刻意的去选择挑起负面情绪的话题，但从结果上来看确实这样的话题效果更好。

为什么美国网银转账那么慢：ACH 详解

我刚刚来到美国时就发现美国网银的转账速度很慢，往往中国网银一天甚至实时能完成的转账，在美国需要三天甚至更久，不过后来习惯了也就没再仔细思考这件事情。我最近加入了 Robinhood 的 Funding 团队，我们团队负责用户资金转进、转出 Robinhood 账户，为此我好好学习了一下美国网银转账背后所使用的 ACH Transfer 机制。现在终于可以来向大家解释一下为什么美国银行的转账速度那么慢了。

我这篇文章主要参考了 Gusto 关于 ACH 的系列博客（1 2 3 4 5），大家喜欢看原文的话可以去看看。在开始之前，我们来解释一下下文要用到的概念：

• ACH：Automatic Clearing House。这是一套自动清算系统，是金融机构之间使用计算机进行自动清算的协议。
• NACHA：National Automated Clearing House Association。这是一个制订 ACH 标准协议的机构，并且负责管理 ACH 网络。
• Federal Reserve。美联储，实际运营 ACH 网络的机构。
• ODFI：Originating Depository Financial Institution。这是代表发起 ACH 操作一方的发起方银行。
• RDFI：Receiving Depository Financial Institution。这是代表 ACH 操作接受一方的接受方银行。

---

在美国的金融机构之间进行金额不是很大的转账，往往使用的都是 ACH。一个 ACH 操作中通常会涉及到 5 个参与者，他们分别是：发起方、发起方银行（ODFI）、美联储（Federal Reserve）、接受方银行（RDFI）、接受方。举个例子，Alice 是 Bob 的雇主，Alice 要发工资给 Bob，那么 Alice 就是发起方，Alice 的银行就是发起方银行，Bob 的银行就是接受方银行，Bob 就是接受方。

假设 Alice 发工资给 Bob 的那天算作第 1 天，Alice 的银行会要求 Alice 在特定时间（假设是 7:00 PM）之前发起这个操作，超过这个时间就算是下一个工作日的操作了。为此 Alice 必须在第一天的 7:00 PM 前发起一笔 ACH 操作转出 Bob 的工资，与此同时 Alice 的银行会在 Alic 的账户余额上减去 Bob 的工资。这是第一步。

Alice 的银行（也就是发起方银行）会在午夜把记录了这一笔 ACH 操作的 ACH 文件发给美联储，然后美联储把这个 ACH 文件转发给 Bob 的银行（也就是接受方银行）。这是第二步。

Bob 的银行会在第 2 天清早（假设是 5:00 AM）处理这一笔 ACH 操作，把工资加到 Bob 的账户余额上。这是第三步。如果一切顺利的话，事情到这里也就结束了，工资成功从 Alice 的账户转到 Bob 的账户上。但是如果发生异常的话，那就还有两步要走。

什么情况可能导致异常呢？Bob 可能填错账户号码了，Bob 可能把 checking account 错误标记为 savings account 了，Bob 还可能注销账户了，有各种原因可能导致异常。这些都叫做 ACH Return，会导致一笔 ACH 操作失败。值得注意的是，跟中国的网银不一样，Alice 作为发起方不仅仅可以转钱给 Bob，只要 Bob 签署了正确的 ACH 授权，Alice 还可以要求从 Bob 那里收钱回来。这时候 Bob 余额不足或者是 Bob 撤销授权等等的情况，都会导致异常。

在第三步里，Bob 的银行在第 2 天清早会处理这一笔 ACH 操作，如果它发现有异常的话它可以把 ACH Return 发给美联储，但这个 ACH Return 最晚可以在第 3 天结束之前发出。按照最坏的情况考虑，ACH Return 会在第 3 天和第 4 天之间的午夜由 Bob 的银行经过美联储发送给 Alice 的银行。这是第四步。

Alice 的银行会在第 4 天清早（再次假设是 5:00 AM）处理这一笔 ACH Return，然后把 Bob 的工资归还到 Alice 的账户余额上。这是第五步。整个过程耗费了 3 天的时间，准确来说是 3 个银行工作日（bank day）的时间。

一般来说，Alice 发工资给 Bob，如果 Bob 的银行没发生异常，Bob 是不会提出异议的，毕竟钱是多了而不是少了。但如果 Alice 发起的 ACH 操作是从 Bob 那里收钱，Bob 的银行没有遇到异常不代表 Bob 不会提出异议。跟 Bob 的银行不一样，Bob 本人有 60 天的时间提出异议（dispute），然后就会导致 ACH Return。Alice 的银行收到 ACH Return 之后，就要把已经给了 Alice 的钱拿回去。如果 Alice 的账户已经没有那么多钱了，Alice 的银行就赔钱了。

因此 Alice 的银行进行 ACH 操作向 Bob 收钱后，收回来的钱该不该给 Alice，是全额个 Alice 还是部分给 Alice，具体什么时候给，这些都是开放性问题，不同的银行会做不同的策略。有些银行会等到第 4 天才把钱给 Alice，因为第 3 天结束后 Bob 的银行就不再可能因为异常（如 Bob 账户余额不足）而返回 ACH Return 了。

有些银行会因为 Alice 长期的良好表现而信任 Alice，在第 2 天就提前把全额或部分给 Alice。如果金额比较大，Alice 的银行担心 Bob 在第 3 天结束后提出异议，那 Alice 的银行还可能要进行更多的沟通协调，向 Bob 的银行确认这真的是 Bob 授权了的，那就会拖更长的时间。

---

希望上述信息能够解释清楚为什么美国的网银转账这么慢。

如果大家对 ACH 文件的格式感兴趣的话，可以读一读这篇文章，里面做了简单介绍。实际的文件格式，请以 NACHA 官方手册为准，那是一本几厘米厚的砖头书籍，我们 Funding 团队就有一本今年最新版本的。

Real Dev 测评

Real Dev 是一个我称之为「实战项目的 LeetCode 平台」。跟 LeetCode 相似的地方是，Real Dev 也是一个 OJ (Online Judge)；跟 LeetCode 不同的是，Real Dev 不需要大家解决算法难题，但要大家解决工业界常见的实战问题。举个例子，Real Dev 的 Hello World 问题要求大家做一个最简单的 web 服务器，打开 /hello 页面的话服务器要返回 "REAL WORLD"。

以下一些是 Real Dev 的问题：自动完成组件（Autocomplete/Typeahead）、短地址生成服务、数据分页 API、响应式配色、JavaScript 到 TypeScript 迁移、克隆 Yelp。这些项目比 LeetCode 的算法题更贴近工业界，更像是软件工程师日常工作需要做的事情。做这些项目时需要用到的技术框架也是工业界所用的：Node.js + Express 或者是 Python + Django。

优点

• 解题过程更像是软件工程师日常工作。
• 能够练习使用常见框架，例如 Express 和 Django。
• 有官方的问题讨论板块。

缺点

• 题目数量不够多。
• 每道题都要从头开始搭架子。

这次的测评不附送任何折扣链接。Real Dev 是我以前在 Facebook 的同事离开 Facebook 之后做的，他们现在正在做全站打折，由每个月 $20 打折到 $10，这已经是非常便宜的价钱了。大家想要试用的话，直接打开 https://real.dev/ 就可以了，有一部分题目是免费也能访问的。

AlgoTogether 算法学习小组（第二期招生）

更新：请访问 AlgoTogether 新版网站，了解最新一期的时间和价格，并进行报名。

我开了一个叫做 AlgoTogether 的算法学习小组，面向在美国寻求软件工程师工作（实习或全职）的人。第一期学习小组的效果不错，学生对项目打分 4.3/5.0 分，对老师打分 4.7/5.0 分（数据），所以我决定开第二期学习小组。针对第一期学生的反馈，我对第二期学习小组进行了调整，最主要的区别是增加了模拟面试的环节。

我知道仅仅通过 LeetCode 准备算法面试是不够的，因为面试并不以题解的优劣来衡量你。你需要让面试官想要和你共事，这需要说服他你能跟他一起通过编程解决难题。AlgoTogether 是一个有教练指导的学习小组，帮助你训练多方面的面试能力，让你在面试时成为面试官的最佳未来同事。在这个学习小组中，你不仅仅需要解题和编码，你还需要练习沟通你的解题思路、接受模拟面试和倾听来自别人的反馈。我们的教练是 ACM/ICPC 奖牌得主，也曾带队其它学生参赛获奖，此外还是大型科技公司中富有经验的面试官。我们保证你投入到面试准备的每一滴汗水都能有充分的回报。

为了保证跟面试和工作环境一致，整个 AlgoTogether 采用全英语沟通。以下是 AlgoTogether 的详细信息及报名链接：

What is this program?

AlgoTogether is an algorithmic problem study group with a coach. The program focuses on all necessary skills for coding interviews: problem-solving, coding, debugging, articulating solutions, taking feedback. The coach leads the meetings and mock interviews and makes sure that students learn these skills in a way that they can reapply to new problems in real interviews.

What is the value of this program?

1. Understand how an interviewer evaluates you. You are evaluated beyond correctness and optimality. If a company only evaluates these two it will replace human interviewers with LeetCode to save money. You should learn what’s missing beyond your LeetCode practice.
2. Practice like you are in an interview. You will practice articulating your solution to an interviewer and taking hint or feedback from an interviewer. That’s what you don’t experience if you simply practice with LeetCode.
3. Hold yourself accountable. Are you willing to commit to finishing a certain amount of problems within a specific time frame? If you can make the commitment, we will hold you accountable and prevent you from slacking.

Who is this program for?

People who are highly committed to getting a software engineer job at one of the well-established tech companies. It’s best for people who are seeking a software engineer job for the first time, for example, newly graduated students. It’s also good for experienced software engineers who haven’t done interview preparation for more than a year.

What is the structure of the program?

The program is 8-week long. Each week the coach picks a theme and assigns problems within this theme. Students have one week to work on them. Then they present their solutions and get mock interviews at the weekend meeting. If they need help they can join the mid-week meeting to discuss. The coach will lead both meetings.

Who is the coach?

Our coach has many years of experience working and interviewing candidates at well-established tech companies. He is also an ACM/ICPC algorithm competition medalist and has coached other students for the competition.

How much does it cost?

$800. We think it’s the right price to identify committed students and hold everybody accountable. You will be able to pay us through a credit card. It’s non-refundable once the payment goes through.

How do I sign up and pay?

Please fill out the information in the following signup form:

https://chen.cat/algotogether–2020q2

We might not be able to accommodate everybody. We will contact you through email with payment instructions if you are selected.

Update: Please visit AlgoTogether’s new website for the latest program’s date and price, and then signup.

System Deep Dive 系统设计小班

我开了一个叫做 System Deep Dive 的系统设计小班，面向在美国寻求软件工程师工作的人。系统设计面试跟算法编码面试有相似的地方也有不一样的地方。相似的地方是，你都需要让面试官想要和你共事，这需要说服他你能跟他一起解决复杂系统的设计难题。不一样的地方在于，系统设计问题没有标准答案，不存在 LeetCode 这样的系统为你的训练提供实时反馈。

System Deep Dive 采用教练带领学生探索复杂系统的小班教学模式，帮助你接触常见的系统设计面试题，模拟真实面试过程——鼓励你多提问题了解系统需求，引导你把问题分解成子问题，给机会你独立解决具体子问题。教练会对你的解题过程提供反馈，最后还会展示部分系统代码，帮助你加深对设计难点的理解。

我们的教练曾在大型科技公司中担任 tech lead，有丰富的系统设计经验和面试经验。此外他还创办了自己的 startup，帮助其它科技公司通过实战项目筛选候选人。我们保证你投入到面试准备的每一滴汗水都能有充分的回报。

为了保证跟面试和工作环境一致，整个 System Deep Dive 采用全英语沟通。以下是 System Deep Dive 的详细信息及报名链接：

What is this program?

System Deep Dive is a system design practice group with a coach. The program not only teaches you all the necessary skills to excel at a system design interview but also practices designing complex systems together. In each session, the coach would lead the students to dive deep into a complex system problem and explore different design choices together. Students are encouraged to ask questions and deliberate trade-offs because that’s the best way to learn.

What is the value of this program?

• Get a feel for the real system design questions asked in interviews. We’ll pick the most popular system design questions asked in industry and elaborate on different paths they lead to. You will learn how to design a real system. We’ll explain in-depth about the usual structure to answer such design questions.
• You will ask questions and lead discussions like in a real interview. System design interviews are open-ended by nature. In a real interview, candidates will do most of the talks. We will tackle the problem together as a team and you will ask questions and get answers from the coach or other students. In this way, you can understand deeply and learn the trade-offs better among different design choices.
• You can see how a complex system works in real life. Interviewers often dive deep into the system design to see whether you were actually involved in the project. You might get stuck if you haven’t seen the real thing. We will demo some code and configuration of different system components. In this way, you will understand better, for example, what load balancer does and how the cache is built.

Who is the program for?

People who are committed to getting a software engineer job, have coding experience but lack the experience of designing a complex system.

What is the structure of the program?

This program is structured session by session. Each session will take 2 hours talking about one or two similar system design questions in depth. There will be 4 parts in a session:

1. In the first part, you’ll be asked to discuss and walk your thoughts out for the question just like in an interview.
2. In the second part, the coach would challenge you and guide you through different directions of the problem. Students are also encouraged to discuss and it’s a perfect time to explore the pros and cons of design choices.
3. In the third part, the coach will talk about the common strategy to tackle such a design problem so you can learn the framework tackling it yourself.
4. Lastly, the coach will demo with real code to illustrate different parts of the system in real life.

Who is the coach?

Our coach has many years of experience designing complex systems and interviewing candidates at well-established tech companies. He’s also the CEO and founder of a startup specialized in helping tech companies hire engineers through practical projects.

How much does it cost?

We’ll be running a series of sessions as a pilot program and charge by each session. A session will cost $200 with a limit of 8 students. Once a session is full, we’ll stop accepting registration and move candidates to the same session of a later date.

What sessions are available?

We will offer the following sessions in the pilot program:

1. System Design Interview Skills: understanding the problem, breaking it down, exploring each subproblem, deliberating trade-offs and articulating decisions. (3/4 7pm–9pm Pacific Time)
2. Design an Autocomplete. (3/11 7pm–9pm Pacific Time)
3. Design a Facebook/Instagram/Twitter Newsfeed. (3/18 7pm–9pm Pacific Time)
4. Design a Customer Service Center. (3/25 7pm–9pm Pacific Time)

We plan to offer each session once in the pilot program. We will adjust them based on feedback and repeat these sessions after the pilot program.

How do I sign up?

Use the following link to sign up for the pilot program and pick the sessions you are interested in:

https://chen.cat/system-deep-dive-pilot-program-signup

If you are interested in the sessions after the pilot program (or if you are reading this after the pilot program signup is closed), sign up for the wait list with the following link:

https://mailchimp.catchen.me/system-deep-dive-wait-list

We will contact you through email after you signed up.

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