一下都是我面试的经验和教训，欢迎各位大牛指正或者补充
首先，要端正观念，写代码只是最后一步，是在对方完全理解了你的意图之后的最终表 述，所以，在写代码之前，一定要跟对方把你的意图表述清楚，一定不要在对方不懂你 的想法的情况下就开始写代码，大忌，大忌！
其次，写代码之前，大脑里面要有个大picture，不能想到哪儿写到哪儿。是你的大脑 在写代码，而不是白板上你的手在代码。你的手只是一个printer里面的喷头而已，是 它把你大脑里面的代码print到白板上，你的大脑才是控制那个喷头的芯片。所以，写 之前，你要看着那个白板打个腹稿，想想一下白板上可能有哪些代码，比如定义哪些变 量，哪些if else，哪里退出，call哪几个function，等等。
第三，你在白板或者纸上写代码的过程中，一定要跟面试官交流，让他知道自己在干什 么。每次提笔之前，告诉他，我前面写了啥，然后我准备写啥，这个写的过程，是前面 跟面试官讨论问题结束之后的具体反映。
第四，如果有重复的代码，一定要用一个变量或者一个function表示。本来面试的代码 就不长，还有重复的代码会很ugly。比如类似current->next要使用很多次的话，可以 定义一个新的local的指针；再比如在for或者while循环里面，要check什么值de时候， 千万不要用计算公式，因为会反复计算；你要delete一个node的时候，可能很多ifelse 里面都有delete p，应该拿到最后一行去delete。
第五，某个单独的过程，能够用function表示就用function表示，比如在一个for循环 里面做一件什么事情，如果这个过程很长，比如大于5行，你最好就写一个单独的 function，然后这个function里面去具体定义这5行。这样有几个好处，思路清晰，方 便修改，你在这里写一个function表示前面这个主function就算写完了，这也可以保证 你写的function都很短。
第六，for while循环里面的early return，如果for while循环里面有条件不满足，可 以直接return，不要等到循环结束了，再来check那个值后判断return啥
第七，input一定要check，哪怕面试官说不需要check，你写代码的时候也要check，这 是告诉他你知道这个point
第八，如果需要allocate memory，你先在白板下面最后一行把free的代码写了，这个 是大问题！
第九，一般面试官会写一个signature，但是那个signature不是你想要的怎么办？比如 他给你一个input只有一个string，但是你平时练习的function需要长度，比如要你 check是否bst，只给了一个一个root，这些你都要大胆的定义一个helper function， 然后在他给de那个function里面call你自己定义的。不光是如此，helper function可 以很直观的把题目de意义表示出来。
第十，一定要注意哪些变量是index，那些是size，一般lai讲index操作起来更加简单 ，不用考虑加减1的问题，但是size转换成index，都或多或少会涉及到加减1的问题。
第十一，要大胆的使用递归，面试的问题不可能很难，也不可能很长，当你stuck的时 候，就思考递归。递归最大的好处就是简单直接方便理解，比如基本所有tree的问题， 都是递归，还有不少数组问题，search问题等等。使用递归de时候，要大胆的使用前面 第九条说的helper function，很多时候多传一个参数会让问题很简单。
第十二，不要指望一次性把代码写完，要学会使用手中的erase，边写边改，比如我前 面提到的一些代码的优化问题，写着写着，你就会知道哪儿重复代码可以归并，哪儿可 以写一个function来代替了，碰到这样的情况，一定要改，让面试官知道，我懂这个。
第十三，如果中途面试官打断你，你要大胆的交流，要么告诉他他指出的bug我知道， 要么及时改正那个bug，所以，前面第一第二条非常重要，因为只有你自己知道自己在 干什么后，就不怕面试官打断，哪怕有bug，也是一个改正的问题。
第十四，切记，切记，写完了一定不要很快跟面试官说，我写完了，然后就转过身去了 。你写的code一定一定一定一定有问题的，一定一定一定一定要写几个test case自己 跑一边，一定一定不要怕改自己的代码，这个时候当着面试官改自己的代码，一定加分 ，不会减分的。我们小时候考试的时候都知道做完题目了要检查，这里写code也是一样 的啊，更何况小时候只要答案，这个code还要看过程呢！
第十五，test case 跑完了，修改一些问题，转过身来，跟面试官说，你看，我最开始 准备干啥，我现在干了啥，这个是干啥，那个是干啥，也就是把前面我说的第一条第二 条给面试官解释一遍，告诉他，我的代码真实准确高效的反映了我最开始跟你解释的算 法问题。
第十六，写完了之后，如果可能，你自己拍个照片纪录一下方便以后学习。
一口气总共写了16条，各位大牛见笑了，欢迎大家交流，指正和补充！
关于面试：
面试的时候碰到遇见过的题，有人觉得自己演技好可以装作没见过，一点点改进到最好
的办法。但我演技比较差，而且每次去面试也都被强调“如果你之前见过这道题，一定
告诉我”，所以每次都从实招来。招我也招的很详细，是听说过但不知道细节，还是见
过一个类似的但不一样的，还是见过但没想过，还是见过想过但从没写过，还是已经写
过了。而且我不觉得他知道我见过这道题之后换一个我从没讲过的题是对我很不利的事
，我的理由如下：
1. 一看到题就立刻抛出最好的办法，并且几分钟就一气呵成写好bug free的代码，要
么是个大牛，要么就是之前练过，而且还是很熟练的程度。判断的方法之一就是等写好
之后，把题的要求改一些，限制一些条件，看怎么改。或者写好之后不允许使用最优解
法，要求写次优解。
2. 面试我的工程师，并不是想让我帮他们解决这个问题，而是想知道我怎么解决这个
问题的。他们更关心，如果以后碰到了谁也没见过的问题，能不能灵活运用自己掌握知
识设计一个算法来解决。但很可惜的是越来越多的面试题被曝光、被退休，这些题只能
用来测试实现代码的能力了。所以在保证解决问题，时间空间可以接受的情况下，要告
诉他们自己是怎么一步步走到这个解法的。一边想一边说的确很困难，但分析一下输入
输出，画个图，确定自己真的理解题意，并且问清题目所有的细节，到了这一步解法通
常就很明显了。
我一直很讨厌“细节很重要”这句话，但这是事实。更无奈的是，在面试过程中，自己
不知道自己在哪个细节做得不够好，也不知道出题人会怎么解读自己犯的错误。
0. 动笔写之前一定要描述自己的解法，一步一步解释清楚，如果他认可了，再开始动
笔。动笔之前不妨把问题拆成几个小问题，每个问题独立解决。
1. 争取在对方指出bug之前自己找出来（拼人品）。
2. 自己要做什么，要说出来。比如要先从一个不够优化的解法入手，准备写出可用的
代码之后再优化，那就告诉他，并问他是先写一个出来，还是接着想别的解法。写完之
后，自己还没测试，还不确定是不是少了哪些情况没考虑或者有没有bug，那就告诉他
“我还没完成，让我从头到尾看一遍，测试几组数据”。大多数情况下，当你很快的写
好了程序，并且从头到尾按照程序流程测试了几组数据之后，如果他满意了，他自然会
告诉你“that's good, let's move on”。
我觉得对于onsite面试，想知道自己的表现情况，几乎是不可能的事情。因为自己并不
知道他事先准备了几道题，也不知道其他人的表现情况。假定是多人竞争特定岗位，而
不是达到一个绝对的水平，可能自己45分钟很顺利的写了两三道题，觉得自己表现很好
，但其他竞争者表现的更好。即使对方是测试自己是否达到一个绝对水平，而通过测试
自己的交流能力、代码风格等主观因素，和写代码的质量和速度的客观因素，我身为应
聘者依旧很难在出结果前知道自己是否满足要求。所以还是版上那句话，面完回来就不
用想了，move on，该申请别的公司就申请，该准备别的面试就准备。有好消息最好，
没有好消息也不耽误事。