【面试专题】|技术&架构设计提升系列:面试题目及解题的正确姿势(1)

​----- 学习笔记 -----

今天是咱们第一节,我想和你聊一聊:研发工程师想提升面试竞争力,需要具备的三个技术认知是什么

   

在我参加研发同学述职的时候,发现几乎每个人最后都会用一页 PPT 来规划自己的未来职业发展,比如:我目前处在初级研发工程师阶段,下一步要成为中高级研发工程师,最终要成为一名研发架构师。 

但是在进一步地追问后,大多数研发同学对自身技术发展的认知,仅停留在学习了哪种新的技术,掌握了哪种新的开发框架,觉得这样就能把技术做好,就能成为架构师。

可是现实情况是:你觉得技术满足应聘部门的要求,可还是面不到想要的职位。这其实与技术认知不足有很大关系,你达不到一个高级研发或者是架构师该有的思维层次,在面试时,自然很难讲出自己的技术价值与亮点,就会影响面试竞争力。

而今天这一节,我会从架构设计认知、分析问题的认知、能力边界认知三个角度出发,讲解研发工程师如何提高自己的技术认知,在面试的过程中更加体现价值和竞争力,进而获得满意的 Offer。

对架构设计的认知

在开篇词中提到,面试官通常会在考察完候选人基础技术能力之后,再问一些关于系统架构设计上的问题,这时如果你回答得比较好,很容易得到面试官的认可,也会掩盖个别技术问题上回答的不足。

但实际上,很多研发同学对架构设计的掌握和理解是欠缺经验的,系统设计问题只能回答出表层的技术名词,落地没有实际经验,拔高没有理论支撑。那你怎么回答面试中的架构设计问题呢?

关于架构设计的问题,一定要立足于点、连接成线、扩散成面,用这样的思路回答才能让面试官满意。下面就通过一个例子,来帮你理解什么是回答架构设计问题该有的认知。

例子 

我曾面试过一名研发工程师,他在介绍过往经历时,称自己在重构一个负责交易流程的系统时,将其拆分成报价系统、促销系统,以及订单系统,而当时他们只有两个人负责交易系统的开发工作。

针对他的经历,我的问题是:你们只有两个人负责这个交易系统,为什么还要做系统架构拆分?而且拆分之后会带来其他的复杂度,你是怎么考虑的?

 

系统拆分的架构设计问题,在面试中很常见,候选人给出了四个层面的回答。 

从订单系统层面来看,由于交易流程中的订单系统相对来说业务稳定,不存在很多的迭代需求,如果耦合到整个交易系统中,在其他功能发布上线的时候会影响订单系统,比如订单中心的稳定性。基于这样的考虑,需要拆分出一个独立的子系统。 

从促销系统层面来看,由于促销系统是交易流程中的非核心系统,出于保障交易流程稳定性的考虑,将促销系统单独拆分出来,在发生异常的时候能让促销系统具有可降级的能力。

从报价系统层面来看,报价是业务交易流程中最为复杂和灵活的系统,出于专业化和快速迭代的考虑,拆分出一个独立的报价系统,目的就是为了快速响应需求的变化。

从复杂度评估层面来看,系统拆分虽然会导致系统交互更加复杂,但在规范了 API 的格式定义和调用方式后,系统的复杂度可以维持在可控的范围内。

**这样的回答很好地表达了应聘者对系统设计的思考与理解。因为他说出了原有系统中关于订单、促销和报价功能耦合在一起带来的实际问题,这是立足于点,又从交易流程的角度做系统设计串联起三个系统的拆分逻辑,这是连接成线,最后从复杂度和成本考量的方向夯实了设计的原则,这是扩展成面。**

案例分析

 如果你是这名应聘者,会怎么回答呢?很多研发同学一提到架构设计就说要做拆分,将一个系统拆分成两个系统,将一个服务拆分成两个服务,甚至觉得架构就是做系统拆分,但其实并不理解拆分背后的深层原因,所以往往只能回答得比较表面,无法深入背后的底层设计逻辑,那这个问题的底层逻辑到底是什么呢?有这样四点。

  • 为什么做架构拆分?通常最直接目的就是做系统之间解耦、子系统之间解耦,或模块之间的解耦。

  • 为什么要做系统解耦?系统解耦后,使得原本错综复杂的调用逻辑能有序地分布到各个独立的系统中,从而使得拆封后的各个

你可能感兴趣的:(架构师,面试专题,面试,架构师)