1. 如何考察架构能力？
在评估架构师的能力时，主要关注三个核心维度：判断能力、拆解能力和取舍能力。
判断能力：这是指架构师是否能够精准地识别和分析业务需求中潜在的复杂度。
拆解能力：这是指架构师是否具备足够的技术深度和广度，能够设计出合理的架构来解决复杂问题。
取舍能力：这是指架构师是否能够权衡各种利弊，选择最合适的实施方案。
2. 架构设计复杂度
架构设计面临的复杂度主要来源于两个方面：业务复杂度和质量复杂度。
业务复杂度：这是指业务本身所固有的复杂性，主要表现为业务难以理解、难以扩展。
业务规模：业务规模越大，涉及的模块和数据就越多，复杂度也就越高。例如，微信作为一个拥有数亿用户的社交平台，其业务复杂度远高于一个简单的博客系统。
业务流程：业务流程越长、分支越多，复杂度也就越高。例如，一个复杂的金融交易系统，其业务流程涉及到用户认证、风险评估、资金划转等多个环节，每个环节都有可能出现各种异常情况，因此复杂度非常高。
业务关联性：业务之间的关联性越强，相互依赖越多，复杂度也就越高。例如，一个企业资源计划（ERP）系统，涉及到财务、采购、生产、销售等多个部门，这些部门之间的业务紧密相关，需要进行大量的数据交互和流程协同，因此复杂度非常高。
质量复杂度：这是指系统需要满足的各种质量属性的要求，例如高性能、高可用性、成本、安全等。
高性能：指系统能够快速地响应用户的请求，处理大量的并发访问。例如，一个电商网站需要在促销期间承受巨大的流量压力，因此需要具备高性能。
高可用性：指系统能够持续地提供服务，即使在出现故障的情况下也能快速恢复。例如，银行的支付系统需要保证 24 小时不间断运行，因此需要具备高可用性。
成本：指构建和运维系统所需要的各种资源，包括硬件、软件、人力等。在满足业务需求和质量属性的前提下，需要尽可能地降低成本。
安全：指系统能够保护用户的数据和隐私，防止各种安全威胁。例如，涉及到用户敏感信息的系统需要具备严格的安全措施。
业务复杂度和质量复杂度是正交的，也就是说，一个系统可能同时面临高业务复杂度和高质量复杂度，也可能只面临其中一种复杂度，或者两种复杂度都比较低。
3. STAR 面评技巧
STAR方法是一种常用的面试和面评技巧，可以帮助应聘者清晰地、结构化地描述自己的经历和贡献。
Situation：描述具体的背景和情境。
Task：描述你所负责的任务和目标。
Action：描述你为了完成任务所采取的具体行动。
Result：描述最终的结果和你的贡献。
4. 如何回答面评/面试问题
在回答面评或面试问题时，需要根据问题的类型，采取不同的回答策略。
What（是什么）类问题：这类问题通常关注的是结果，需要简洁明了地回答事情本身以及最终的结果。
How（如何做）类问题：这类问题通常关注的是过程，需要详细地介绍解决问题的方法和步骤。
Why（为什么）类问题：这类问题通常关注的是原因，需要深入地分析背后的原理和思考。
在面试中，Why类问题通常是最重要的，因为这类问题最能考察应聘者的技术深度和思考能力。
5. 面评/面试常见问题
不要试图通过多说话来避免被问到不会的问题。
不会的问题要坦诚承认，并尝试引导到自己熟悉的领域。
6. 面评技巧
根据不同的场景选择合适的介绍方式。
向非本业务领域的评委介绍自己的业务时，可以使用“产业链图”，帮助他们快速理解业务的整体结构和价值链。
向本业务领域的评委介绍自己的业务时，可以使用“业务/系统大图”，详细地展示系统的架构和模块组成。
7. Result 好坏怎么说
结果不好的项目，要区分原因。
如果是由于不可控的因素导致的，例如业务调整、市场变化、政策变化等，可以讲，但要实事求是地分析原因，总结经验教训。
如果是由于自己的原因导致的，例如过度设计、错误选型、技术能力不足等，不能讲，否则会给面试官或评委留下负面印象。
结果特别好的项目，如果技术难度不高，也不建议讲。
8. 没有架构经验怎么办
对于P7级别的面试，可以通过深入研究1~3个流行的开源系统来弥补。
对于P8级别的面试，如果没有实际的架构经验，基本不可能通过。
-
