前端面试一位7年工作者：成也“7”年，败也“7”年

故事

在众多面试中，对于那个工作了7年的面试者，我印象很深刻，因为最开始拿到简历的时候，我一摸:"这简历，好厚啊！"再一看，工作7年。
于是我去找了我的领导，我说:"这人我应该没法面试，我工作经验都没他一半高啊。咋面？"
领导说:"没事，你先去聊聊，怕什么，就当是技术交流，别当成面试。"
面试的过程中我们聊的技术问题，他都没有回答的很好，他的技能就像一块大平板，一眼望去，什么都会一点，但是稍微一深入探讨，就两眼一抹黑了。
面试的最后，我直接给他说:"在整个面试的过程中，其实你有些问题回答的是不太好的，可能今天我们的面试就到这里了，但是我还想请问你一个问题，你可以不回答。你工作了7年了，应该有很多行业内的朋友呀，为什么没有内推呢？而且你的技术能力和你的工作年限有点不太匹配。"

他回答了我，大概的意思是这样的：

• 我刚参加工作的时候，计算机行业还没那么火，大多数都是传统公司，所以我一直就在传统行业里面，属于比较内向的人，也没有刻意的去积累人脉。
• 期间换了几家公司，没有一家是真正意义上的互联网科技公司，我也一直是做开发工作。
• 最后的这家公司是把我辞退了，辞退之前，我还是一个底层的老员工。
• 但是我努力想往管理岗发展，但是最终不得人意。
• 由于最近几年一直想往管理方向发展，更多的是注重业务了，家庭方面的事情也越来越多，有时会影响工作。
• 技术方面就有点停滞不前了。最终导致这样的局面。

听了之后，我说：

• 你是我的前辈，我很尊重你，但是我从我的角度再加上你刚刚的面试表现来说，你说的这是一部分原因，而且不是主要原因。
• 我觉得主要原因是，对于技术你失去了追寻的态度。在过去的这几年里面，你只要对于每次碰到的问题，稍微深入地研究一下，思考一下，整理一下，然后再找一项技能深挖下去，日积月累下来，今天的结果应该会大不一样。
• 我理解你，也许是在家庭和工作的双重压力下，迷失了方向。

后来，我把他送到公司门口，他已经走出去了，又转过身来和我握了一下手，他握的很用力，说:"谢谢！"
我在面试结果描述那一栏写的是:

此人专业技能与工作年限不匹配。不建议进入下一轮面试。

面试结束之后，我把面试结果反馈给我的领导，领导看到我写的评语，意味深长的一笑，对我说:"和我预想的一样，年龄大，工作年限长，但是技术一般"。
之后，他用力握我手的场景有时候会不由自主的在我脑海里面浮现。
仿佛在鞭策我：前车之鉴，要警惕啊。

从思考框架到基本原则，到具体最佳实践

小编不想制造焦虑，小编只想说的是保持危机感。这位从业7年的面试者他所说的问题不排除会发生在我们身上，所以无论是刚入行的前端小伙伴们亦或者是在按自己职业规划发展的小伙伴们，都要有居安思危意识。小编今天讲讲思考框架、基本原则及具体最佳实践这三个层次，这三个层次要是相得益彰，那么形成的知识体系是稳固的，这对于我们工作上生活中都很有用。

思考框架

最上层的思考框架往往是一些哲学问题，无非就是保安经常问你的那三个问题：

• 你是谁？
• 从哪来？
• 到哪去？

还有类似的 WWH：

• Why？ → 目的、理念
• What？→ 定义、概念、现象或成果
• How？ → 具体操作方法、措施

那么对于我们程序员来说， 我们把上面的三个问题转换下就成为：

• 这是啥玩意？
• 解决什么问题？
• 怎么解决的？ 思想 → 流程 → 实现

比如产品经理给你一个需求，套用这个框架，你可以问他：

• WHY？为什么要这个做这个功能？ 它可以给用户带来什么价值？ 或者说能给公司带来什么收益？ → 没价值，就没有做的意义
• WHAT & HOW ？ 什么样的用户会用到这个功能，他们在什么场景下使用，他们又会怎样使用它？实现这个功能就只有这种方式吗？还有没有其他方案？ → 可以衡量这个功能是否有经过认真思考的，是不是合理

再比如面试招人为例，把上面的三个问题转换下就成为：

• 你觉得你现在处于什么水平？有哪些不足
• 你的目标是什么？想加入什么样的团队？

• 你有什么计划？
  这个思考框架，虽然简单，却可以受益终生。

  原则

  接下来是在思考框架指导下的原则。这些原则相比思考框架要具体一些，是针对特定领域的思想指导，在处理某个特定领域的问题时会更有用一些。

比如面向对象设计的 SOLID原则为例：

• S 单一功能原则: 认为“对象应该仅具有一种单一功能”的概念
• O 开闭原则: 认为“软件体应该是对于扩展开放的，但是对于修改封闭的”的概念。
• L 里氏替换原则: 认为“程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的”的概念。
• I 接口隔离原则: 认为“多个特定客户端接口要好于一个宽泛用途的接口” 的概念
• D 依赖反转原则：认为一个方法应该遵从“依赖于抽象而不是一个实例” 的概念。依赖注入是该原则的一种实现方式。

还有KISS（Keep It Simple ,Stupid）原则等，小编就不展开来说了，小编说一个个人比较受用的原则：DRY(Don't repeat yourself)原则，更好理解、或者说更有实践性。

DRY 原则简单说就是识别你的重复代码，思考，然后重构它。

如果你在编程时养成了这种习惯，你会发现你的代码自然而言会有比较良好的结构，同时也可能符合上述各种原则一些特征（实际上它们本来就是交叉和相通的）。

或者说，经过 DRY 原则下的刻意训练，你会形成一种编程品味( 敲黑板，这也是大厂考点)。

具体的最佳实践

再往下更具体，这是在原则指导下、经过实践总结出来的最佳实践/设计模式。可以用于指导解决具体的领域问题。最佳实践通常是别人实践总结出来的，对我们来说是站在巨人的肩膀上，是捷径，让我们可以少走点弯路。

举大家比较熟悉的例子，最典型的莫属于面向对象的《设计模式》它就是属于这个层次的知识，设计模式就是在 SOLID 原则指导下的具体实践：

结束语

小编整理了知识体系的形成，也整理了前端面试题资料，学习是要有方法要有积累，每天一点的进步，一点的改变，最终的受益就是你自己。

由于篇幅原因就没有列举资料题目，需要完整版前端面试题资料的小伙伴们，直接点击这领取就可以了噢。最后想说的是：加油，未来可期！