Tips to share

Here is the link. 


接着跟大家说一些面试的技巧。

1）面试官的心态
面试官要看的，不是你会不会做题。会做题的人很多，好的engineer ！= 会做题的engineer。你要做的是在最有限的时间里展现这点。即使题不会做，也要展现出一个好的engineering thought process跟technical communication。

2）Coding Round
绝对不要秒做！
绝对不要秒做！

绝对不要秒做！

上面说了，要有好的thought process跟communication，拿到题要先思考所有的edge case，input形式，需要的run time和space complexity，逐一跟面试官沟通。当然，绝大多数的情况下，他们会说yeah assume XYZ，但是要他们说了才可以，你自己瞎assume肯定会挂的。
然后尽量不要像是背的。太极拳的精华在招意，不在招式，同理，解题的精华在思维，不在代码。最好的方式莫过于现场跟面试官先讨论逻辑和数据结，然后写出一些common test cast，然后代码一边写一边说，现场找到bug并且完善，会比闷头写码秒解好很多。而且秒解非常容易招很难的Follow Up，因为面试官不确定你是否真的理解还是只是做了题。
还有就是互动非常重要，写代码的时候尽量同时解释自己的思维，为什么要加一个storage variable，为什么选择这样的subroutine，为什么用这个library里的数据结构等等，然后写完别等他们问，直接说这个Runtime和Space complexity是什么，还有什么其他的方法，那些其他方法的complexity是什么等等，显示出自己是经过考虑才选择出这样的代码结构。很多国人小朋友都觉得沟通有障碍就不说话，但是这样不是明摆着自己承认不会交流吗？要记得，花这么多时间刷题的同时也要同时在沟通上面下功夫。
最后最后，要想想test case要怎么写，这个现在经常问，想想你在刷题的时候LC会有什么样的test case卡到你，写这些test case的人当时的想法，会很有帮助。

3）System Design
这个也是沟通的环节，个人倾向是先把所有的Use Case写出来，然后写出所有会需要的component，schema和大概的API，然后在开始做设计。重点是根据每一个Use case做出相对的实现，比如这个A Use Case需要high availability，所以我选择这个技术实现，这个B Use Case需要Atomic transaction，所以我要做这样的实现。跟Coding一样，要确定好scope和其他supproting的系统，比如Facebook/Linkedin经常问News Feed，你要问我需不需要考虑Relevance，sorting，context等等，大概率是不需要，但是你要展示出你在思考这些问题。然后Scope也要问清楚，这个东西的User是谁，deliverable是什么，我们需不要handle infrastructure scaling，需不需要handle各种UGC storage，后台的partition tolerance和load balancing和data duplication等等。一般情况下main design部分都会让你skip，然后选一两个比较精的部分问follow up，所以当你问这些scope的同事，心里面也该有个大概的底应该要如何实现。

4）BQ
BQ应该是最重要的环节，前面说了，会写码的人很多，能解决问题的人很少，能带领团队解决问题的人少之又少。这里所有BQ的问题都是为了验证3点。
a）你有没有problem solving skills？你解决问题有没有一定的策略，有没有办法确保相同的问题不会发生，有没有办法确保其他人不犯相同的错误，碰到自己没法解决的问题如何处理，自己直接导致的问题会如何处理，如何面对多个stakeholder不一致的方向及要求等等
b）你有没有leadership skills？团队有问题的时候你会怎么帮忙？遇到bug你是只修bug还是能深究问题并且surface给management，能不能在团队有困难时go above and beyond，能不能有效的沟通并且解决矛盾，在沟通的时候有没有对他人立场的认知和理解，并且就这个理解给出对他人最有用的答案等等
c）你有没有self awareness？你对自己的期许是什么，你最强的能力是什么，你在什么情况下会under perform，你明不明白自己在这个group里能起到多大的作用等等

面试官问的所有傻屌问题想要的答案都是你有没有一些上述的quality，而你要做的就是好好嗦发。一个好答案分成起承转合。
起：历史背景，为什么有这样的情况，其他人为什么没管，这个情况的consequence是什么
承：讨论自己的思考过程，为什么最后选择了这种方法解决问题，其他没有选择的方案有什么pros and cons
转：具体解决问题的时候遇到了什么样的困难，如何克服，学到了什么
合：最后结果，问题是否完美解决，后续有什么follow up，是否给你的org或者group带来了正面的影响等等

讲的时候多观察面试官，感觉他有问题的时候可以停一下，如果有什么笑点的时候也可以停一下缓和气氛（例如策划经常该需求，android native各种坑，samsung的OS多他妈傻逼之类的）。

5）Time to ask questions
一般情况下，能把问题答完都至少会pass，但是要有strong feedback你短短的几分钟问答就会很重要。我个人喜欢的问题是问Tech culture，比如我在用别的组的系统，发现不能实现我想做的功能，如果要加入这个功能会否给我这样的自由度，其他组会不会不高兴，将来的ownership和maintenence会如何分配，或者我会问有没有一些centralized的文档库，或者central services org，比如你之前碰到过的问题，花了很长时间才找到答案，我将来如果入职也遇到相同的问题会不会也需要花一样久的时间去找这些答案。如果对他们的业务不熟，也可以就问面试官他的经历，他来这儿几年，在那些组干过，具体业务是什么，觉不觉得有继续学习的深度和广度（要凸显自己热爱学习新技术），如果跟management提出想要跳出comfort zone会不会有阻力等等。尽量开始一个问答对话，尽量让对方感觉亲切。

最后希望所有同学都能找到自己心仪的offer！