最近在面试，发现现在面试官，尤其是大厂的面试官都很喜欢问一些开放性的问题，比如：说一下你们系统的特点或者说一下你觉得你所做的系统业务复杂度比较高的地方等。个人看法是这些问题发散程度比较高，发挥空间比较大，考查的往往是综合实力，答得好离OFFER就是一步之遥，答不好就是自己挖坑把自己埋了。
下面是我个人对这类问题的一个粗浅的回答见解，有说的不对或者不周全的地方环节还请批评指正。
这类开放题往往会问三年以上的程序员，考查的主要是对系统和业务的理解程度以及利用技术去反哺业务的能力。通过我之前的面试经历，我认为有下面两个雷坑千万要注意。
第一，不要一直一直一直讲业务。这是我刚刚开始面试出现的问题，当面试官问我系统的时候，我可以把整个系统的来龙去脉甚至是老板怎么谈合约的细节都讲出来，然而，当问到具体的技术复杂度时，就会说用了XXX框架，XXX中间件，写了XXX的功能，熟练到爆炸的CRUD。可想而知，这样的回答并不能让人满意（内心OS：说到底不就是招我写CRUD吗？！）
第二，不要陷入技术细节。经过对上述回答的反思后，再面对这个问题时，我脑海中第一时间想到的就是自己做过最熟悉的一个功能，或者独立设计研发的系统；继而描述一个场景，比如文件导入计算、秒杀等业务场景，再把多线程、IO等技术怎么使用的，怎么解决并发、超卖等问题的细节说一遍，其间更是掺杂了XX公众号里的百万级并发或者亿级流量的技术细节，讲的天花乱坠。然而最后得到的结果往往是技术扎实，但是项目的复杂度不怎么够。（内心OS：我都亿级流量百万并发了，还不够？！）
其实，对于工作四年左右的程序员，尤其是没有接触过一线的互联网系统的程序员来说，能达到我上面说的第二点已经算可以了，至少，收获一份还算不错的OFFER是足够的了，但是作为一名有上进心的程序员来说，这还远远不够，要思考怎么才算答到勉强让面试官满意的地步。（这一段我吹自己的O(∩_∩)O~，可以忽略）
下面介绍一下我的解答思路。
第一步，对业务的介绍要言简意赅。不能把业务介绍的太详细了，说的太多，就会淡化我们负责的那块功能的重要性。介绍的时候首先要把公司的整体业务方向囫囵的描述一下，然后直奔主题，说我负责的是哪块功能，强调这块功能的重要性，以及最后这个功能的成果如何（比如承载了几千万的流量，扛住了几十万的并发等）。
第二步，对复杂度的介绍要紧扣关键词。先来解构一下复杂度这个词。按照李运华老师所著的《从0开始学架构》这本书中所讲，系统的复杂度来源主要有三个，分别是高性能、高可用、可扩展性。也就是说，在回答与系统复杂度相关的问题时，要紧扣这三个词来做文章，尽量做到自然。
第三步，对系统的介绍不要一步到位，要循序渐进。所有的系统一开始都肯定是紧耦合，没有服务化拆分的。因此，如果一开始就说用了XXX中间件、XXX的RPC框架、多线程工具、IO框架等，最多只能证明你有使用XXX工具或者框架的能力，不能体现你有识别复杂业务系统和解决该系统难点的能力。
接下来是我根据自己所做过的项目，粗略的总结的一个模板。
业务背景：
技术方案：
迭代演化：
