pair programming面试，到底考察什么

最近约了一些面试，都是pair programming。这到底和算法有啥区别？是不是题简单了，但是代码量变多了？ 常见的考题都有啥？大家有没有这方面的题库，或者面筋可以分享的？

我觉得这完全是考交流能力。我合作顺心的就是沟通频繁，讲自己解题思路的人。即使内向也要多说想法，没有最细，只有更细。然后就是能不能接受对方意见，以及怎么统一意见，然后得到大家都满意的结果。跟刷题关系不大。有的时候并不会用到最优解。因为费时，费力，难维护。让对方理解你说啥是重点。讲每种解法优缺点。时间空间复杂度。可能中小厂用得多，因为没有必要优化到底，干活舒心更重要。大厂我也没去过。

如果是code signal 并且有test cases需要跑通的话的话

1. 写代码速度（java吃大亏 python比较有优势） 关系到你是否能全做完
2. 交流
3.bug数量， 因为bug 越多，观感越不好，而且debug时间需要浪费的越多

多交流沟通，确保自己的想法面试官是认可的，出现分歧也多听取他的意见，然后找到一个共同的解决办法。实际就是日常工作和同事讨论问题吧。

说是pair programming，其实也还是你在想思路写代码，面试官主要听着。只不过越来越多的题目，不是leetcode那种类型，而是让你实现一套business logic，实现的过程中需要跟面试官反复交流确认需求而已

以我的经验，保持交流沟通，代码思路什么的其实不是最最重要的。速度才是最重要的，包括通过交流快速确定面试官心目中的正确解法，快速写code以及完成几乎全部followup。

1. 快速确定面试官心目中的解法，两分钟没想出来就问问可不可以先写你自己心目中的解法。
2. 快速写完code并且快速跑通debug，不要写太多edge case error handling，可以和面试官说你知道这里有个小问题但后面有时间再补。（所以如果你是java选手，个人建议还是把python掌握一下单纯用来面试，不难的)
3. 写完一个stage，可以主动要followup，不要和面试官过多讨论tradeoff什么的，除非面试官主动问。
4. followup 一般是越来越难，所以前面一两个问题一定要快，千万别纠结。你一开始可能想写得漂亮，后面难度上来了可能要推翻之前写的，前面写得再漂亮也白写。