面试结尾HR必问的问题，就是上一家公司的离职原因，作为多年的资深架构师，我做过多次终面，听到过千奇百怪的答案，有的真诚，有的官方，有的遮遮掩掩，有的情绪愤怒，这个问题是有正确答案的，今天就来和你分享一下。

1、真实的离职原因

其实离职无非就是两类原因，一类主动，一类被动。

主动，要么钱少，要么心累，但大多数情况都是钱少心又累。

被动，要么被行情拖累，要么末位淘汰，要么违纪被发现，这个问题只要不回答的稀碎，都不会影响你被录用。

2、避开下面两个错误答案

2.1、 破口大骂前公司前领导

有可能真的是你的前领导，做人做事很差劲，但是真实的面试中，不要这么说。

一般而言，面试官，会无形中把自己代入到你的领导的角色中，如果你现在这么骂别人，那面试官会觉得，后面你会不会骂他。（这是人性使然）

一家公司，只要是真正做事的公司，做到一定规模，对leader的要求还是比较高的，出现那种非常差劲的领导的可能性，比较低，在你批评你前领导的时候，很有可能别人会更相信是你自己的问题。

如果真的遇到那种特别垃圾的领导，那你就陈述事实即可，不要做过多的评价。倡导一些公平、正义、积极向上的价值观即可。

2.2、和上家公司闹翻，包装的离职原因被拆穿

尽量，在任何时候，都不要和上家的公司闹翻，当你从一家公司离职的时候，上家公司对你唯一的把柄就是，它具备一定的评价你的权力。

如果，真的是公司有巨大的问题，比如那种不给发工资，裁员不给赔偿的这种，那就直接走流程，该仲裁仲裁，该咋办就咋办。维护我们正当利益，也是我们的权力。如果这家公司在这种情况下，给你使绊子，你其实只需要提供完整的证据链，证明这家公司不行即可。（这种情况下，大家其实都是理解的）

面试官为什么会关心离职原因这个问题，因为如果你是违纪或者末尾淘汰，他们担心把你招进来，再出现类似的风险。钱少心累，这些都是正常理由，面试官天天面试，他们都能理解。

3、描述离职原因的场景

如果你觉得钱少，你就说多久没涨薪，你也要养家糊口，工作是为了更好的生活。

如果你觉得心累，你就说前公司管理比较混乱，发挥不出来个人价值，自己做的更多都是无用功。

如果钱少心又累，还是说钱少吧，这个理由更好一点。

如果从差的公司往好的公司跳，也可以顺便夸一夸新公司，就说想到更好的平台发展，想获得更大的个人提升。

如果是部门裁测，或者公司大规模裁员，直说就行，这也不是你的问题，就像最近某大厂30%的裁员，在圈子里一般都藏不住。

如果是末位淘汰或者违纪，只要不和前公司闹翻，不用提，就说钱少或者心累。

如果你和前公司闹翻了，这就有点麻烦，大厂全员背调，你只能直说，把自己放在受害者的身份包装出来，中小公司的话，普通员工背调的可能性不大，不用提了，就说钱少或者心累。

如果真的离职原因实在说不出口，那还是去中小公司。

社区一直讨论的一个主题，到底是react好，还是vue好？

我的答案

本人对这个问题的答案是这样的：

1、react给了我们更大的自由度，我们可以以任意的方式，组建我们的代码结构，我们可以操控的代码细节更多，也就能在更多的细节上面，对我们的代码进行更细致的优化。

2、react在书写的过程中，驱动我们对数据、UI有更清晰的认知。我们必须对他们的运行细节，ui变化，数据流向，有明确的认知边界，才能对我们的项目，进行清晰的掌控。

3、vue2，它是死板的，明确的定义了数据的申明在哪里，生命周期在哪里书写，函数和事件在哪里书写，我们几乎很少有可发挥的空间。

4、vue2，数据的双向绑定，让我们可以忽视数据内部真正的变化边界，我们需要的时候，直接无脑赋值就能得到我们想要的结果。

导致的结果

这是这两个框架，不同的api，给我们的客观印象。同时因为团队的差异，它们又导致了一些问题。

1、react框架的项目开发，它注重细节，注重每一个数据的驱动，这就导致了，用这个框架的前端团队必定要有一定的极客精神。它的过度自由，导致了我们甚至可以随意定义我们数据的管理规范、组件的划分、甚至任意的代码结构。

但是，这正是一个团队最可怕的东西。它导致了不可控。

2、vue2的项目开发，它是简单的，容易上手的，并且它就是一个固定的写法规范。

• 它的vue文件，就是由标准的html、js、css三部分构成。
• js里面，数据定义，生命周期，函数和事件，都有固定的地方。

这是vue2作为一个框架的缺点，代码可以控制的比react少，书写代码的细节上，性能可控性小。但是，作为团队视角，它提供了一个团队最重要的东西——相对简单、相对可控。

React项目，我们可以从哪些方面提升代码的水准

评价一个项目的代码水平到底好不好，有这么几个方面。

1、代码性能和质量。

代码性能和质量，有些是项目工程层面的内容，有些是代码实现方面的内容。

项目工程层面：代码包的体积大小、首次加载的效率、首屏渲染时间、用户可操作时间。

代码实现方面：渲染效率、是否卡顿、大数据量的处理、虚拟列表、图片加载、分块渲染等等。

2、代码整体的层级划分

目前，现阶段的大多数前端，能做到的基本的目录结构划分，也就是我们的src下面，有这么几个主体目录：

• index.js/index.tsx，整个应用的入口文件。
• router，整个应用的路由配置文件。
• pages，整个应用的页面层级组件，一般router中的一个path，就对应这里的一个组件。
• components，全局的基础组件。
• service，api请求相关的服务封装。
• redux，整个页面的数据管理存储。
• utils，全局某些通用能力/配置，放置在里面。
• assets，全局资源文件（图片资源、静态js库、svg、字体文件等等）

以上基本上是每一个前端工程的共识，但是除此之外，我们应该还有其他的共识。

1、页面pages，尽可能的组装业务，进行集中的资源调度。

也就是，我们尽可能的把业务相关的东西，都往pages层次的组件进行集成。

当我们从路由中，得到这路由对应的pages，往往预示着，它是一块相对独立的业务。比如：文件列表页、文件详情页等等。而对于人类而言，在一处地方看代码，比在多处看代码，更容易。

2、页面pages，尽可能的进行统一的数据管理。

在pages层面，进行统一的数据管理，数据管理往往是这么几种情况，从redux接入全局数据进行管理，向pages调度的子组件，通过props传递数据，或者针对Provider全局数据的注入的使用。（至于为什么，可以继续看下面数据管理部分）

3、页面pages，在拆分组件的时候，层级不应该过于多。

在pages的组件层面，很有可能，我们会遇到非常复杂的业务，导致我们的pages层面的组件，变得非常臃肿，这个时候，我们需要进行组件拆分，但是我建议，再只多拆分1层业务组件，不要拆分多个不同层级的组件。组件的层级过多，数据通信的复杂度就会提升，代码的可读性就会降低，如果这个时候，再配合不好的数据管理习惯，屎山代码，就已经形成了。（具体是为什么，可以继续看下面的组件拆分部分）

4、 每一个单元应具备原子性 。

pages层面，调度的每一个单元，应该具备一定的特性—原子性。

一个函数，只完成一件事情，比如事件响应，数据处理。

一个组件，它是纯粹的，它只和传递给它的props有关，和其他无关。

一个业务组件，也就是在pages过于复杂的情况下拆分出去的组件，虽然它具备业务属性，但是对于pages来说，它也是相对独立的。

3、组件的层级划分

个人比较推崇的组件层级划分方式：

• pages层，pages层很简单，就是代表页面的意思，每一个路由path，它都对应一个page。
• 业务组件层，一个page，很有可能很复杂，我们需要一定的设计，把这个页面分成几个块，然后由pages统一调度，实现我们的业务。
• components层，也就是纯粹的UI组件，它只和props有关系，和其他无关。全局任意的地方，都可以调度。

为什么这么拆分呢？其实这是这么多年，针对真实业务场景，综合思考下来，得到的比较好的实践方式，形成这个组件划分的原则，是基于以下几个方面的思考。

1、辨识度高。

每一个路由，对应一个pages组件。

每一个components中的组件，都有与业务无关的纯UI组件。

根据业务的复杂度，中间产生了一层业务组件。

每一种组件，各司其职，边界清晰，方便我们看到一个组件，就知道这个组件是干嘛的的一种标识。

pages层的组件，进行统一的调度，数据管理，对接redux，组件拼接，事件交互等等。一个文件中的代码，阅读起来，也更加的容易。

业务组件，当pages层的组件，过于复杂的时候，我们把业务相对独立的单元，拆分出来，形成我们的业务组件。业务组件是可以对接redux，也可以有自己的数据状态，各种事件交互。（业务组件的核心，在于如何巧妙的进行边界设计，具体请参考下面的业务组件层的拆分思路）

components层的UI组件，纯粹的UI组件，与业务无关，在全局可复用。

2、结合业务拆分、代码可读性、复用性的一个综合结果。

多数情况下，我们可能没有一个清晰的思路，去做组件的划分工作。

遇到复杂的业务，我们本能的就进行组件的拆分，当时写的时候，没有考虑太多，但是写到一半，会发现，这个组件的变动，可能会引发其他组件的数据变动，我们就遇水搭桥，见招拆招，有些用redux解决，有些用props父子传递数据进行通信。

保持这样的习惯，我们可能拆分一个又一个组件，props传递了一层又一层，等过一段时间一看，自己都看不懂，自己写的代码是啥。

这是本能的，不想思考的，总想简单化的把项目完成。但是往往导致的结果是：本来简单的项目，代码写的越来越复杂！！

pages层面，负责数据的整体管理，组件调度，那么我们的通信就会比较方便，相当于pages层就是这个页面相关的业务的通信中心，我们基本上，能够通过props父子组件传递消息。

props父子组件，传递消息，注定了组件的层级不能过多，过多就会导致，数据就像套娃一样，一层又一层，导致可读性降低。

业务组件的出现，是为了解决，过于复杂的页面业务，我们可能需要进行拆分，把能够单独拆分出去的结构，独立出来，这样不仅从业务上进行了模块的拆分，也能提高不同模块的代码可读性。

那么，业务组件层的拆分思路是什么呢？

3、业务组件层的拆分思路

其实原则上，这里需要我们进行深入思考，哪些模块是独立的单元？页面中的哪些模块，和业务主体通信较少？

这其实就是核心，代码倒逼我们进行设计，进行深入思考，进行深入的业务理解。

思考点1：某一个模块，是不是相对独立的UI模块？

思考点2：某个模块是不是单独的业务单元？

思考点3：某个模块拆分出去，通信的代价到底大不大？

思考清楚这些，其实本质上，你思考的是，你的代码架构问题，你以什么样的视角，来解读你的UI、数据、业务的关联关系。

有了这些思考，你一定可以拆分相对合理的业务组件层。

4、数据管理的划分

多数前端，写代码的时候，并不会有数据中心，数据流向这些概念。

很多人还停留在，完成UI，渲染数据的层面。

如果是这样的思路，无论是组件划分，还是数据管理，注定做的一塌糊涂，代码成屎山是必然的。

组件划分的思路，其实也是一种数据管理的思路。

1、pages层，从天然的业务视角来看，他天然就是一块业务的集合，所以pages层作为一块单独的业务数据中心，它天然合适。

2、components层，我们定义了它，只和props相关，和其他无关，它被其他组件调度，天生注定了它通过props传递数据的行为模式。

3、业务层组件，我们定义了它是pages下面的一块单独业务，我们有必要对它进行合理的设计，它与pages组件的关系，是主模块与子模块的关系。可以通过props通信，也可以接入redux通信。

4、redux，大多数情况下，我们其实不需要用它，当数据的通信，不满足业务场景的时候，redux就是我们的解决方案。它真正的业务价值，在于跨pages的通信。比如，某个页面状态的更改，另一个页面状态，也跟着更改。

redux另一种常见用法：

redux的特性，在umi或者其他框架中，把redux作为数据管理中心来使用，所有的页面状态，业务相关的数据，都定义在redux中，所有的接口请求，用户行为，都是通过redux的dispath进行触发行为，来更改数据，数据通过props流入各个组件中。

这种方式，其实也是各种推崇的一种方式，但是这种方式对人的要求也高，表明了我们团队中的每一个人，都要熟悉并且接受这种数据管理的方式，才能写出相对一致，可读性高的代码。

只要其中的一部分人，不接受这样的数据管理方式，代码的管理它就会变得混乱，有些初始化数据，可能在pages组件中，有些可能发生在redux层，作为阅读者，很难排查代码执行的路径。

现实场景说明：

我们大多数情况下，对于redux的使用，并不清晰，redux的使用，是混乱的。

本不必要的数据，可能放在redux中管理。

本不必须接入redux的组件，非要接入redux。

redux中的dispath，调用的地方，千奇百怪。

数据的流向定义，完全杂乱无章。

这些东西，对于一个项目，都是灾难性的影响，它会导致，我们代码的迭代难度，急剧上升。

前言

作为一位资深架构师，我面试过形形色色的候选人，见过各式各样的简历，听过各式各样的自我介绍，坦白说，大多数人根本不会面试。

简历筛选环节，首先hr会根据业务的情况，筛选掉百分之80的简历，然后简历到我这里，我一般会在剩下的百分之20中，再筛选掉一半人。

在面试环节，根据岗位情况，面试到合适的候选人，大概来面试的同学中，有三分之一，是达标的。

面试通过后，大概就是谈薪环节，一般而言，只要薪资预期相差不大，这个节点应该能够把岗位确认下来。

在每一个环节，都有一些需要注意的要点，如果能够提前把一些雷点避开，我们面试入职的成功率，会很高很多，那么，我们求职者在面试环节，到底会有哪些需要避雷的点呢？

1、简历一定要写好，它是敲门砖

那么，什么样的简历，是一个好的简历呢？

1、求职目标明确，并且符合市场的需求。

当下的市场，是一个存量博弈的市场，这个阶段的企业，首要的目标是赚钱、存活下来。所以企业对人的要求，更多的体现到能真正解决问题，收拾一些烂摊子的候选人。或者是在技术上，能够有独当一面的能力，给出的需求，能给人家切切实实的做出来。

与之相对应的，就是整个招聘市场，我们会发现，初级岗位几乎断崖式的减少，甚至很多公司，已经关闭的初级岗位的入职渠道。并且随着AI时代的到来，这个现象，变动的格外剧烈。

所以，当下的场景下，我们的简历，不管是谁，在降低薪资预期的同时，应该实实在在的锻炼自己的能力，让自己真的能独当一面。并且把这种能力体现到简历上。

2、简历要体现成长性

对于刚工作三年以内的同学，他的简历的目标，应该体现比较高的发展潜力上。比如，具备扎实的前端基础知识，从前端新手，到一个成熟的前端开发者的转变，甚至在一个公司中，慢慢有了主导业务开发的能力，在态度上，要具有极客精神，积极好学的一面。

对于工作3到8年的同学，他的简历的目标，应该体现到技术/业务的领导力上，如果做技术，在简历的履历中，尽可能的看到从前端开发工程师到高级前端开发，甚至到技术专家的转变上。如果做业务，简历上应该能够看到，从前端开发，到高级前端开发，再到前端leader的角色转变。我们简历中的技术内容，也应该符合这个角色的变化。

对于年纪更大的同学，他的简历目标，应该体现到成熟的管理能力/技术上的架构能力，当然在现实中，两方面其实都挺难的，但是我们每一个技术人，都有一些自己的特质，比如你技术还在及格线以上，那做一做高级开发，也是可以的，如果你的沟通协调能力不错，你还可以做一做前端基层管理。

3、简历中的内容，要具有深刻的价值

我们的工作履历中，只要有工作，一定能提炼出有价值的东西。

比如，单独完成一个项目/一个模块，你在其中提升了哪些能力？你的技能体系，到底能完成哪些事情。团队因为有了你，到底有哪些改变？

比如，你在简历中，如果写了，组件库建设经验，那你就真的，得在这方面，有比较深入的做了一些东西，解决了一些问题。

比如，你在简历中，写了精通xxx，那就是真的，你在这个方向上，做了比较深入的研究，至少在面试官问你的时候，你不至于出错。

2、以积极的心态，自信的状态去面对每一场面试

在这么多年的面试中，那些真正淡定从容的面试者，属于极少数人，但是每一个，都会给我留下不错的印象。

积极的心态，自信的状态，代表着你是一个成熟的个体，企业用人做事，一定会选择一个成熟的个体，帮它完成它的业务。而成熟的个体，也代表着，更高效的沟通，勇于承担责任等等一些优良品质。

社会是一个竞争关系，消极/软弱/不自信，并不能让一个人在竞争中，多一些优势，反而在绝大多数场合，增加了自己的劣势。

而我之所以一直强调这个点，就是因为大多数人，真的存在这样的问题。

当然，如果作为自身，真的很难克服这个点，那么就好好历练，争取每一次面试，都比上一次更好一点。

3、沟通要有节奏感

大多数时候，程序员的一大缺点，就是自说自话。

什么是一个好的沟通？好的沟通，第一步一定是倾听，听明白别人在说什么，然后再回答问题。

如果你的回答，和人家面试官问的东西，牛头不对马嘴，那么首先可以判断的是，这个人一定是一个沟通比较困难的人，企业用人做事，沟通是效率的前提，沟通都那么费劲，合作起来怎么可能顺畅。

自说自话的回答的另一个巨大弊端，就是让面试官觉得自己不被尊重，这会让他觉得，他说了半天话，别人压根就没关注他说的。

良性的沟通应该是，哪怕在没听懂的时候，也愿意向人家面试官，再次尝试沟通理解。比如你可以这么说：“抱歉面试官，您可以再详细的描述一下吗？”

人往往对自己处于同频的人，产生好感，有节奏感的沟通，就能快速让双方进入那种同频的交流状态。

我的初衷

作为一位架构师，我深知我们程序员这个群体，在面试中有各种各样的问题。

很多时候，我们讲前端面试，讲技术的有很多，但是讲针对面试的反思的人，很少。

后续，我依然会针对面试的这个场景，谈一谈我们可能会遇到的各种问题，期待与大家一起向上成长。