f*t
1 楼
F
电面和onsite都是在西雅图本地面的。此分部是在downtown附近租的两层，有近360度
的景观，十分漂亮。分部总共有不到200人，很多是从微软来的，从A挖来的倒不多，原
因不明。午饭质量不错，小分部就不指望有中餐咯。
电面
1. 国人大哥，问了几个常见题，最难的题具体细节记不清了，大概是01矩阵上的DFS，
随便聊了会儿直接拿到onsite。
Onsite
1. 白女，亚马逊manager出身的女工程师，主问culture fit问题，比如为什么想来FB
。Coding题是恶心的罗马数字。因为鄙视这道题所以没在leetcode上刷过，还好是简单
题，很快写出来了。
2. 一个搞后端处理data的中国哥们，问sort linked list。随手写了个merge sort过
关，merge的时候没用dummy node方法，if语句用的很多，比较蛋疼。讨论了一下具体
的算法复杂度，直接背答案的人估计会被考倒。所以说做面试题的目的主要还是掌握算
法并能灵活用于解题，不太可能所有题都能练到随手就写出最优算法bug free的程度。
3. 午饭不算正式面试，跟一个呆了六七年的front end developer谈话。他说话有气无
力，感觉生命都被FB榨干了一样，最终也没聊出什么有意思的话题来。
4. 一个看上去很强壮的老美，广告组的，问设计题。FB用户每天发非常多的status
update，要求设计一个系统，能够对最近几天内的update进行关键字搜索。我回答建一
个index，每个单词对应一个status update id的列表，查询结果是取列表的交集。我
对大数据处理完全没经验，不清楚这轮会被鄙视到什么程度，反正从结果看是pass了……
5. 又是中国哥们，一看就像技术牛人。有两个长度为n的数组，分别存放螺钉和螺母。
它们之间是一一对应的关系，而没有大小相同的螺钉或大小相同的螺母。现在有个机器
人，它能拿起一个螺钉和一个螺母，试着把它们拧在一起。如果成功，返回0，如果螺
钉大于螺母返回1，小于则返回-1。初始情况下两个数组是shuffle过的，需要设计一个
算法让机器人帮你sort两个数组，使得两边相同index的螺钉和螺母是一对。
这题虽然不是新题但我也没见过，虽然上来就想到肯定得用quick sort的思路，还是一
时纠结住了。经提示才想出正确算法，是两边同时做partition。代码倒是很容易写，
写完后又被要求分析复杂度。
6. 一个亚裔带了一个围观的老美，两人加入FB的时间都不长。题目是在BST里找两个
node的LCA。我当时头脑发昏，写了一个common binary tree的解法，因为要处理各种
edge case，代码十分冗长。后来才发觉得他问的是最简单的变种，二分查找就行了。
快结束时就随便聊了，围观的老美挺能侃，虽然shadow面试理论上不应该说话吧……主
要谈及FB工程师文化，有没有类似于G的20%时间政策。他们说FB还在扩张期，没资源搞
跟主业不太相关的项目，比如自动驾驶汽车，但如果想的话可以参与其它组的项目。还
有就是hackason几天牛人能搞些cool的东西出来。一般都说FB比较辛苦，平时做其它
project的时间不会有多少吧。
G
电面
1. 在G呆了6年的烙印，问了得到一分钟内request次数。虽然是常见题，可惜没准备过
，好不容易写出一个queue的版本。后续问题是怎么测试，回答用spring的dependency
injection提供需要的时间，他貌似满意了。
2. 貌似烙印，在G呆了7年，目前工作是自动驾驶汽车。
第一题是给一个函数Object getRandom(List list)，先问了怎么实现，接着问如果抛
出IndexOutOfBoundException怎么debug、问题可能出在什么地方和如何在无法修改这
个method所在library的情况下进行workaround，保证data contract不被破坏。我说问
题有可能出在多线程环境下，写个wrapper，多调用几次，直到返回一个结果为止。
第二题是写一个小程序，从文件中读一行，做一个regex matching，如果match就写进
另一个文件。只要写伪代码就行，随手写了。然后他问如果读一行需要3秒，regex
matching要1秒，写要5秒，处理一行总共要9秒，如何进行优化。我以为他要问map
reduce，因为不懂所以很紧张，结果他说这是个一次性的task，就在developer
desktop上运行，不用考虑分布式计算以及升级硬盘到SSD之类的，光从软件上优化。我
想了半天，也只有弄成pipeline，省掉不是性能瓶颈的regex matching这1秒，最终处
理一行还是要8秒。他貌似同意我的说法。我觉得这可能是他工作中真实碰到的问题，
也不知最后是如何解决的，要我说就上SSD吧，最简单了……
Onsite
1. 面相严肃的白人，问的内容比较非主流——code review。有一个NoSQL Db的
interface能查询某个key对应的value，某人用这个interface实现两个table的query
result aggregator，并且还有一段unit test。加起来只有短短20行代码，让我喷40分
钟，还要讲正确的实现方法是什么。不知道这是哪倒霉intern写的代码，也许N多面试
的人狂批……这个大概是针对有一定工作经验的人的测试，没在大公司干过的new grad
碰到肯定瞎了。感觉我虽然讲了很多，还是没有完全答出他想要的内容。
2. 头发像是用了飘柔的白人，害得我一直在想象他头发随春风飞舞的样子，也许分散
了做题的注意力:(
貌似是临时拉来充数的，从头到尾不是在笔记本上找题，就是突然随口问一句又说题目
不好再换道其它的。纠结半天问出经典题：实现insert, delete, getRandom都是O(1)
时间复杂度的数据结构。知道算法的话写起来不难，中途他追问了一下hashmap的原理。
最后没几分钟时他突然开始问一个设计题，要实现一个service，接到request后call N
个其它service获得data，组合起来返回结果给caller。正好我们组有个这样的service
，我直接把我们的实现说出来了，是先为N个service生成一个input/output的
dependency graph，再按topsort的顺序call。他就问如果有1000TPS怎么办，我说我们
组的做法就是scale up，因为这种service一般是read-only的，不用太考虑
consistency问题，直接加服务器并做好cache问题不大。他说他们组以前是这么做的，
我顺水推舟问现在怎么做的，他神秘兮兮地没回答。后来我想了一下，估计他们是用
distributed queue搞了一个asynchronous的系统。
3. 烙印，一开始跟他谈我的工作内容，明显觉得话不投机。被问了怎样serialize和
deserialize一个tree。这又没准备过，临时写了个serialize成json的实现，后来又扯
了下层序遍历。感觉他肯定给了我negative。
4. 午饭时间是我向HR点名指定的1337哥陪同，感觉好幸福……
5. 貌似欧洲白人，长相挺nerd。问了极其恶心的text justification。这题虽然在
leetcode上AC过，当场还是不出意料地写了一白板bug。他也知道这题麻烦，但毕竟写
的不好，估计给我的多半是negative。
6. 50岁老美，工作内容是往搜索结果里加与用户隐私信息相关的内容，态度很和蔼。
问了一道老题，给一个一次只能读4k字节的函数int read4096(byte *buff)，要求实现
能读任意字节数的int read(byte *buff, int n_bytes)。他说如果愿意的话可以用
java写，我想了想，java的IO根本不会，还不如用C++呢。本来一年多几乎没碰过C++，
只是面试前在leetcode上拿几道练了下手，写的过程却意外地顺利，写完后跑了一个普
通test case，没看出问题。
他又追问，加一个让文件指针返回到文件头部的函数reset()，要求实现把文件指针移
到任意字节处的函数seek(int n_bytes)。在原来的基础上改改，倒不算难。我发现有
edge case没处理好，他看时间不多就说不用再改，结束了面试。
总结：
F周五onsite，过了一周后星期一拿到offer，速度比较快。G有点慢，不过在我拿FB
offer催的情况下一周多给了电拒。FB的HR十分耐心，愿意等G结果出来后再跟我谈。我
因为太懒就没面别家，于是又一次体验不到幸福的烦恼，直接签了唯一的offer。
F的package还是很有竞争力的，new grad也能达到150k，确实比A强很多。比较吸引人
的地方是6周的boot camp结束后自由选组，然后立即开办绿卡。后来我又跟F的一个
manager电话交流了一下，F相当支持开源，（我觉得）有趣的组也多。今天正好看到扎
克伯格带头游说，呼吁一系列针对STEM的移民改革，这样的公司值得一去:)
这次过后算是跟G面了总计11场，感觉好累，不会再爱了。。。
电面和onsite都是在西雅图本地面的。此分部是在downtown附近租的两层，有近360度
的景观，十分漂亮。分部总共有不到200人，很多是从微软来的，从A挖来的倒不多，原
因不明。午饭质量不错，小分部就不指望有中餐咯。
电面
1. 国人大哥，问了几个常见题，最难的题具体细节记不清了，大概是01矩阵上的DFS，
随便聊了会儿直接拿到onsite。
Onsite
1. 白女，亚马逊manager出身的女工程师，主问culture fit问题，比如为什么想来FB
。Coding题是恶心的罗马数字。因为鄙视这道题所以没在leetcode上刷过，还好是简单
题，很快写出来了。
2. 一个搞后端处理data的中国哥们，问sort linked list。随手写了个merge sort过
关，merge的时候没用dummy node方法，if语句用的很多，比较蛋疼。讨论了一下具体
的算法复杂度，直接背答案的人估计会被考倒。所以说做面试题的目的主要还是掌握算
法并能灵活用于解题，不太可能所有题都能练到随手就写出最优算法bug free的程度。
3. 午饭不算正式面试，跟一个呆了六七年的front end developer谈话。他说话有气无
力，感觉生命都被FB榨干了一样，最终也没聊出什么有意思的话题来。
4. 一个看上去很强壮的老美，广告组的，问设计题。FB用户每天发非常多的status
update，要求设计一个系统，能够对最近几天内的update进行关键字搜索。我回答建一
个index，每个单词对应一个status update id的列表，查询结果是取列表的交集。我
对大数据处理完全没经验，不清楚这轮会被鄙视到什么程度，反正从结果看是pass了……
5. 又是中国哥们，一看就像技术牛人。有两个长度为n的数组，分别存放螺钉和螺母。
它们之间是一一对应的关系，而没有大小相同的螺钉或大小相同的螺母。现在有个机器
人，它能拿起一个螺钉和一个螺母，试着把它们拧在一起。如果成功，返回0，如果螺
钉大于螺母返回1，小于则返回-1。初始情况下两个数组是shuffle过的，需要设计一个
算法让机器人帮你sort两个数组，使得两边相同index的螺钉和螺母是一对。
这题虽然不是新题但我也没见过，虽然上来就想到肯定得用quick sort的思路，还是一
时纠结住了。经提示才想出正确算法，是两边同时做partition。代码倒是很容易写，
写完后又被要求分析复杂度。
6. 一个亚裔带了一个围观的老美，两人加入FB的时间都不长。题目是在BST里找两个
node的LCA。我当时头脑发昏，写了一个common binary tree的解法，因为要处理各种
edge case，代码十分冗长。后来才发觉得他问的是最简单的变种，二分查找就行了。
快结束时就随便聊了，围观的老美挺能侃，虽然shadow面试理论上不应该说话吧……主
要谈及FB工程师文化，有没有类似于G的20%时间政策。他们说FB还在扩张期，没资源搞
跟主业不太相关的项目，比如自动驾驶汽车，但如果想的话可以参与其它组的项目。还
有就是hackason几天牛人能搞些cool的东西出来。一般都说FB比较辛苦，平时做其它
project的时间不会有多少吧。
G
电面
1. 在G呆了6年的烙印，问了得到一分钟内request次数。虽然是常见题，可惜没准备过
，好不容易写出一个queue的版本。后续问题是怎么测试，回答用spring的dependency
injection提供需要的时间，他貌似满意了。
2. 貌似烙印，在G呆了7年，目前工作是自动驾驶汽车。
第一题是给一个函数Object getRandom(List list)，先问了怎么实现，接着问如果抛
出IndexOutOfBoundException怎么debug、问题可能出在什么地方和如何在无法修改这
个method所在library的情况下进行workaround，保证data contract不被破坏。我说问
题有可能出在多线程环境下，写个wrapper，多调用几次，直到返回一个结果为止。
第二题是写一个小程序，从文件中读一行，做一个regex matching，如果match就写进
另一个文件。只要写伪代码就行，随手写了。然后他问如果读一行需要3秒，regex
matching要1秒，写要5秒，处理一行总共要9秒，如何进行优化。我以为他要问map
reduce，因为不懂所以很紧张，结果他说这是个一次性的task，就在developer
desktop上运行，不用考虑分布式计算以及升级硬盘到SSD之类的，光从软件上优化。我
想了半天，也只有弄成pipeline，省掉不是性能瓶颈的regex matching这1秒，最终处
理一行还是要8秒。他貌似同意我的说法。我觉得这可能是他工作中真实碰到的问题，
也不知最后是如何解决的，要我说就上SSD吧，最简单了……
Onsite
1. 面相严肃的白人，问的内容比较非主流——code review。有一个NoSQL Db的
interface能查询某个key对应的value，某人用这个interface实现两个table的query
result aggregator，并且还有一段unit test。加起来只有短短20行代码，让我喷40分
钟，还要讲正确的实现方法是什么。不知道这是哪倒霉intern写的代码，也许N多面试
的人狂批……这个大概是针对有一定工作经验的人的测试，没在大公司干过的new grad
碰到肯定瞎了。感觉我虽然讲了很多，还是没有完全答出他想要的内容。
2. 头发像是用了飘柔的白人，害得我一直在想象他头发随春风飞舞的样子，也许分散
了做题的注意力:(
貌似是临时拉来充数的，从头到尾不是在笔记本上找题，就是突然随口问一句又说题目
不好再换道其它的。纠结半天问出经典题：实现insert, delete, getRandom都是O(1)
时间复杂度的数据结构。知道算法的话写起来不难，中途他追问了一下hashmap的原理。
最后没几分钟时他突然开始问一个设计题，要实现一个service，接到request后call N
个其它service获得data，组合起来返回结果给caller。正好我们组有个这样的service
，我直接把我们的实现说出来了，是先为N个service生成一个input/output的
dependency graph，再按topsort的顺序call。他就问如果有1000TPS怎么办，我说我们
组的做法就是scale up，因为这种service一般是read-only的，不用太考虑
consistency问题，直接加服务器并做好cache问题不大。他说他们组以前是这么做的，
我顺水推舟问现在怎么做的，他神秘兮兮地没回答。后来我想了一下，估计他们是用
distributed queue搞了一个asynchronous的系统。
3. 烙印，一开始跟他谈我的工作内容，明显觉得话不投机。被问了怎样serialize和
deserialize一个tree。这又没准备过，临时写了个serialize成json的实现，后来又扯
了下层序遍历。感觉他肯定给了我negative。
4. 午饭时间是我向HR点名指定的1337哥陪同，感觉好幸福……
5. 貌似欧洲白人，长相挺nerd。问了极其恶心的text justification。这题虽然在
leetcode上AC过，当场还是不出意料地写了一白板bug。他也知道这题麻烦，但毕竟写
的不好，估计给我的多半是negative。
6. 50岁老美，工作内容是往搜索结果里加与用户隐私信息相关的内容，态度很和蔼。
问了一道老题，给一个一次只能读4k字节的函数int read4096(byte *buff)，要求实现
能读任意字节数的int read(byte *buff, int n_bytes)。他说如果愿意的话可以用
java写，我想了想，java的IO根本不会，还不如用C++呢。本来一年多几乎没碰过C++，
只是面试前在leetcode上拿几道练了下手，写的过程却意外地顺利，写完后跑了一个普
通test case，没看出问题。
他又追问，加一个让文件指针返回到文件头部的函数reset()，要求实现把文件指针移
到任意字节处的函数seek(int n_bytes)。在原来的基础上改改，倒不算难。我发现有
edge case没处理好，他看时间不多就说不用再改，结束了面试。
总结：
F周五onsite，过了一周后星期一拿到offer，速度比较快。G有点慢，不过在我拿FB
offer催的情况下一周多给了电拒。FB的HR十分耐心，愿意等G结果出来后再跟我谈。我
因为太懒就没面别家，于是又一次体验不到幸福的烦恼，直接签了唯一的offer。
F的package还是很有竞争力的，new grad也能达到150k，确实比A强很多。比较吸引人
的地方是6周的boot camp结束后自由选组，然后立即开办绿卡。后来我又跟F的一个
manager电话交流了一下，F相当支持开源，（我觉得）有趣的组也多。今天正好看到扎
克伯格带头游说，呼吁一系列针对STEM的移民改革，这样的公司值得一去:)
这次过后算是跟G面了总计11场，感觉好累，不会再爱了。。。
