【个人经验/新人帖】面向面试刷题法（顺便求大米）

经历了一些面试后，我改进了一下我的刷题方法，总结一下供小伙伴们参考（顺便狂求大米！）

一般来说，面试时候解决算法题的通用步骤是：
1，澄清需求
2，解释思路
3，写出代码
4，人肉测试

因此在刷LeetCode的时候，我开始尝试以下的方式刷以尽量和面试贴近（实际面试里也follow相同的步骤）：
1，只看基本题干，不看示例
     实际面试里，面试官可能给出示例，也可能不给。即使给出示例，也很可能不包括corner case。
     看完题干后，我尝试从题干自行组织示例，通常包括一个没有corner case的理想示例和至少一个corner case。
     在LeetCode里我给出示例后会和其自带的例子比较，看是否理解有误和遗漏corner case。在面试里，我则和面试官review这些例子。
     这样的好处是：测试用例构造 + 需求澄清  一起搞定！
2，简单描述思路 + 提供时间和空间复杂度
     在正式面试时候，我通常会在电子白板（如Jamboard)上用简单文字（或者简洁伪代码）描述思路，和面试官确认思路对头后再写代码，这个中间也可能用到之前构造的测试用例来验证想法；面试官没有疑问后，我就开始分析时间和空间复杂度。这样的好处是：a) 确保思路得到认可；b）可以节省时间，例如面试官可能觉得你的方法正确，但是可以优化，可能会不需要你写实际的代码而跳到follow up（例如有没有更好的时间复杂度的算法）。
     类似地，在做LeetCode题目的时候，可以在白纸上用简单文字（或者简洁伪代码）描述思路，然后带入之前的测试用例检查。虽然此时没有人和你确认，但是针对自己的思路跑一遍测试也同样有帮助。
3，写出实际工作代码
      如果1，2都做好了，其实这一步至少思路转码，只要熟悉对应的编程语言和有一定练习，应该都是水到渠成。这一步在刷LeetCode和实际面试中都一样。
      如果做了#2，在实际面试中，只需要解释某段代码对应思路里的什么部分就好了。面试官也比较容易跟上思路。
4，人肉测试 + 再次review时间和空间复杂度
      仍然用#1构造好的测试用例跑代码，这是为了防止从思路到代码（#3）过程中出现的“翻译”错误。此外，面对代码，相对来说时间和空间复杂度的估算要容易了，这个时候可以再次review一下之前提供的是否正确。

马克一下，今天的币投完了