这是朋友圈的一个截图，是调侃也好，搞笑也好，如果是真的，不禁想了下，是什么让他如此傲娇呢？是能力，是自信。
相信每个人都希望成为这样的人，不为工作愁，不为生活忧，不为面试虑，不为金额苦，开心的，快乐的做自己喜欢的事。
不为工作而工作，是为了兴趣而工作！
但这只是少数人能达到的，我等普通人仍走在尚未成功的革命道路上，坎坷前行。
关于面试过程中如何应对，技术方面依赖项目背景展开讨论，可以深入到某一个领域、细节进行交流，来判读对技术掌握的程度。
业务方面则更多的是经验的积累，做过此方面的聊起来容易，没做过即便你了解一点，但是要串起来也很难，就像前一篇在梳理跨境电商内容时，因为没真正深入接触过，写起来就尤为生疏。
本篇想根据个人的理解再来阐述下，面试时关于互联网电商系统或业务流程的相关内容，希望看完可以帮助你知道了解一些内容。
整体框架
无论是技术，还是产品，如果从事的是互联网电商的工作，都应该有一个全景图，这里称之为整体框架。
关于系统应该有一个系统结构图，业务应该有一个业务的整体流程图，专业点叫系统/业务架构图。
个人觉得这方面很重要，因为面试时你不清楚会讨论到哪一个部分，虽然我可能不熟悉具体的一个子系统，但我知道它与哪个系统有依赖，业务流程是什么样的。在面试时，你不会以摇头而结束，多少能表达一些自己的内容，进而引入到自己熟悉的部分。
系统架构
系统结构图，最好自己能够利用viso或相关工具画一个，一般情况它的布局是自顶向下分层的，自左向右分块的。
第一层 包括各个前端系统，如app,小程序，公众号，网站等，如果有线下店的还应该包括门店POS销售终端。
第二层 包括后端服务或业务系统，如果往高大上说就是业务中台，它是根据业务将基础服务层组装在一块，为前端系统提供服务的。
第三层 可以叫基础服务，每个服务都满足单一原则，颗粒要适度，现在都采用spring cloud架构，这一层也可以说是微服务。
第四层 就是数据存储，数据缓存等这些，有的数据是经过抽取、清洗过的，有的是直接从数据库获取的，此部分还应该包括日志的分布式存储。
从左向右，有基础配置中心，有监控平台、运维平台等这些技术内部管理系统。
在系统架构图中，需要把各个子系统都罗列出来，对应的服务也应该根据作用域放在业务中台还是基础服务中，做到心中有数。
在描述系统架构时，要把相关的子系统说成是XXX平台，这样显得大气上档次，否则就有点软件作坊的感觉，适当的夸大系统是允许的，也是必须的。
如监控平台、订单处理中心、对外开放平台、日志管理平台、渠道平台、运营平台、通能促销平台、商家平台、配送平台等等，实际上这些平台只是由不同研发组负责的不同系统而已，相对于中小型电商企业来说，单量、数据量、并发量都达不到一定的量级，如果真的做平台，真有点不合适。
如果研发岗，聊到系统架构，就不得不聊到分布式、微服务等这些技术，服务是如何治理的，采用的分布式服务框架是什么等。
对于高并发，缓存等应做为重点内容准备，将你使用过的技术归置一下，总结一下，再参照技术的面试宝典，相信没有问题，而对于产品岗了解大块就足够了。
网络上有很多系统框架图，基本上都大同小异，上面我所说的只是一个简单例子。
业务架构
关于业务，研发和产品都应该熟悉，尤其后端产品和研发。
由于我们做的就是应用系统的开发，所以离开业务则意味着失去了骨架，有血有肉的产品才有活力。
业务架构就是要把业务按照某个流程将涉及的模块串起来，可以以数据流转也可以以用户的操作流程进行。
去年曾整理过一篇《以商品流转来了解系统模块》，为此也进行了相关系统的细化，有兴趣的可以翻来看看。
每个公司的业务都非常的复杂，也都不一样，所以业务架构画好了可以清晰的了解每部分、每个阶段的流程，画的复杂了可能就无法辨识了。
其实互联网电商离不开物流、信息流、资金流和商流，可以分别的以这几个流来入手来梳理流程，从主要流程到次要流程，最后到一些细节。
关于业务架构图在网上查了，有很多都是罗列出各个系统而已，这些对于我们了解业务没有太大益处。
最好按照以某一流为基线如物流开始，将涉及到的业务系统模块或功能画出来，中间伴随着数据的流转与钱的收付与核销。
从准备工作开始，到采购、销售、最后到财务结算为终结点，如果有了一个这样的全流程，在面试聊业务时，你应该可以应付自如。
几年前曾和公司相关同事真正的去画一个这样的大图，目的是识别出要做没做的和应做没做的工作，讨论以何为基线去画，就尝试多次，后来根据先根据业务模式区分出几块如自营业务、平台业务、线下业务等，然后再按照商品的流转从前到后进行，涉及到的系统模块全部标识出来，最后到财务终结。
其他人有没有收获我不得而知，个人觉得收获颇多，我觉得这样的业务架构图或叫业务流程图才真的有用。
从上到下分业务模式，从左至右以泳道图的方式按业务模块划分，每个业务模块拆为不同的子系统或功能，粒度可以自己决定。
业务流程应该是一个闭环，有开始有结束，将所有的相关的系统都体现出来。
深入了解子系统
框架帮助我们有了整体的认识，但公司的子系统太多了，相信每一个开发和产品都清楚，想梳理时都会觉得头疼。
我记得原来的公司想引入外部软件服务商系统时，曾梳理过一次公司内部使用的子系统多达几十个，似乎公司组织架构中每个部门都有其使用的系统。
这些系统我们打包一起称之为ERP，想想也是挺有意思的，你目前所在的公司有多少系统，数一下！
对于子系统，我们可以按照标准ERP模块来分类，有重点的去梳理，因为我们不可能全部都理清楚，如果研发同学，系统之于后端服务，数量还是能接受的。
一般的子系统可以按照「为什么有这样有一个系统，解决了什么问题，目前存在的问题」等几方面内容去整理出一个表格，以便有人问起时，可以回复。
属于个人工作范畴的系统则要梳理出功能模块级别，同时要知道后端对应的服务，此部分利用思维导图比较好。
曾看过一位离职同事交接的资料，他将采购部分的内容利用思维导图进行了详细的梳理，感觉非常不错，后来他去了京东，相信其会有很好的发展。
子系统和细节，一般是面试的重点，它可以针对系统的业务流程进行详细讨论，对于系统的设计有针对性的提问，对于具体细节选择性的提问。如果应聘产品岗应该还会让你提出创新的内容，给出一个场景临时讨论方案。
好久没有面试也好久没有面试人了，但我始终觉得，作为研发，要深入了解系统的流程，技术方面纵然重要，但不要忽略业务的重要性，业务规划好了系统会设计好，反之系统会显得超级臃肿，操作复杂。
作为产品，要以根据当前系统来考虑如何改进业务流程，从而改进系统，不能因系统原来就是这样，就绕开它，击碎它重塑才是最好的选择。
见惯了太多的系统几年来一成不变，每日的工作就是修修改改，无聊至极。
在子系统梳理时一定要有侧重点的，有针对性的去细化，去思考，增加自己成功的砝码。
成功项目的准备
社招是要有经验的，无论开发还是产品，纸上谈兵后续会有一定的风险。
要准备三五个有代表性的项目作为面试的资料。
项目要大，但别吹的太大，要是能够为公司带来销售或节约成本的项目，相较于同行业的公司，项目要有特点。
首先，要明确个人在项目担任的职责
这个要夸大自己，要么是项目负责人，要么是核心项目成员，在项目中承担很大的责任和工作。
其次，要熟悉项目
项目最好涉及多个系统模块，如果仅涉及一个子系统的改动，那么此项目应该称之为一个需求或任务。
要了解项目范围，项目背景，项目里程碑，项目上线后的效果等内容，如上线后带来XXX万元销售额，并发数达到1W你负责的模块依然稳定，要有具体的「数字支撑」。
项目熟悉程度，可以看出你对业务的理解和系统设计的能力等。
第三，要多组协作或多人配合
这个是证明你的管理能力的，并不是每个研发或产品都是带团队的，但面试公司往往会考察你的管理能力和沟通能力。
在此部分，要理清楚在项目实现过程中整体的进展是什么样的，真正的项目组织者是如何解决冲突的。
将他人的经验经过思考总结，便是自己的，这一点我们不必脸红。
大胆的夸夸自己
这里要说的就是，同样一个职位，技术和业务较好的可能面试不成功，但另一位技术和业务偏弱的有可能会成功，为什么会这样？
其实这就是综合能力（技术、业务、其他）体现，研发大部分人是不善于吹捧自己的，面试时都会如实的讲述一些内容，现在看来这是「特别吃亏」的。
适当的夸大个人的能力都是能够接受的，因为当你面试成功后，你可以针对自己的不足去学习，而且在工作中也不是所有要求的技术和业务或管理都一次性用上的。
要学会边工作边学习，善于将个人优势展现出来，隐藏个人不足，偷偷的去学习没有什么不对的。
会吹牛，会表现，会隐藏，这样的人才是牛X的，不要以此瞧不起他们，而应该向他们学习。
总结
又针对面试按我的理解胡乱白唬一篇，但我觉得如果做到脑中始终有一个整体结构图，有接触过的系统组成、分类等相关内容，重点系统要知其细节加上几个成功的项目准备，相信聊的过程会很愉快，最后如果你再会吹牛，好好侃侃，不信他不晕。
但这些对于准备充分的，真有水平的面试官还是会暴露其缺点的，准备应该是长期的，一直的。
本来计划写一篇两万字左右的内容，将业务流程逐块进行描述，串联，但是工作量太大了，而且太长了看的人也会累，所以作罢。
