前言

在面试官眼里的简历应该体现哪些？更看到的是职场的经验分享。今日早读文章由知乎@尹锋投稿分享。

正文从这开始～

在职业生涯中，可能因为给的钱不够，可能因为委屈了，也可能看到了更好的机会，也可能因为被裁掉了，都会想要换个工作。如果决定了，在找工作之前尽量好好准备，我觉得花上一个月时间准备都不为过。这里就从简历、面试和职业规划几个方面和大家聊一下，如何准备一次技术面试。因为我是前端工程师，所以很多题目都是使用 JavaScript 实现的，不过应该都比较容易看懂。

简历

格式

HR 和一些技术招聘者应该都有这个体会，简历的筛选和查阅非常耗费精力。所以我们需要准备一份容易识别和找到的简历，比如 Word 和 PDF 格式，最好是 PDF。同时遵循以下命名规则：

姓名-岗位-职级（建议初级、高级、资深、专家）

比如，尹锋-前端工程师-高级.PDF，现在有很多人会通过微信发送简历，所以我收到了简历第一步都需要把简历下载下来，然后按照上面的格式重命名，然后在发给 HR，无形中增加了一些不必要的工作。有很多人把简历挂在网上，还有些人设计了非常精美的 SPA 网页简历。其实这种简历处理起来更麻烦，因为很多公司，简历都要录入系统，简历接收者需要一个个手工填写。如果舍不得 SPA 网页浪费的话，也可以在显眼的地方，提供一个 PDF 文件下载的地方。

简历尽量写的好看一点，至少简洁一点，这是作为一个前端工程师最基本的修养（如果简历连基本的布局都没有，还怎么相信你能够做好网页布局呢）。甚至还有简历贴上了杀马特风格的个人照，一股浓厚的城乡结合部风扑面而来，这种简历一般难留下好印象。所以简历一定设计的优美一点，其实简洁最好，方便简历查阅者能够快速了解你。

说完外表了，聊一下内在，简历不仅仅只是展示工作经验，更重要的是展示个人能力！

指导简历写作的文章很多，这里不赘述，只强调两个方面，个人描述和项目经历部分，以及一些需要注意的地方。

个人描述

用简短的几句话描述好自己能做什么，比如

• 开发并维护公司的 Web App，能解决各种业务场景问题

• 具备跨终端的开发能力，上线两个 App

• 从 0 开始组建过10人的前端团队

• 有后端开发经验，掌握 RESTful API、GraphQL 接口设计和 Nginx 配置

主要介绍自己做过什么能做什么，HR 能快速了解你的整体情况，如果是初级工程师，没有这么多项目经验，就可以写项目中的某个功能模块以及自己的学习情况。

项目经验

很多简历的项目经验，就是列出了了项目名字、采用的技术、自己完成的模块，这样并不能很好的展示个人能力。如果能介绍一下背景、过程、如何技术选型的、遇到的问题以及如何解决和项目的结果，那么这将是一个很好的项目经验。

项目经验，尽量挑能代表技术水平的和自己熟悉的项目，宜精不宜多，最忌讳贴出一大堆项目，每个都是半吊子，这很容易给面试官留下很不好的印象。而且简历里面列出的项目应该好好复盘，要能够经得住面试官各种穷追猛打，如果自己还能够做出拓展，那就是很好的加分项。

其他需要注意的地方

附带 GitHub 和博客地址，一般来说，看完博客的内容，对面试者就有个基本的认识了，如果博客写的很好的话，将是很好的加分项，这也从另一方面说明了，平常好好写博客的重要性。

剔除掉不相关的内容，比如投递的是社招职位，那么学校里面做的项目，除非很 match 且有重要意义，一般可以去掉。不要让这些不能加分的内容出现在简历里面，帮 HR 省时间就是帮你提高命中率。

不需要华丽的辞藻，有些简历用词那个威武雄壮，其实 HR 并不买账。

慎用“精通”这个词，特别是“精通”很多技术，我之前就收到一份简历（其实这样的简历很多），写的很好，五年工作经验，精通 JavaScript、React 相关技术栈列出了很多英文单词，和我们的要求非常匹配，但是面试的时候。并非如此，你能想象一下你满怀期待的拿着简历，把上面精通的技术问了一个遍，结果都只是自己看了文档，写过一些 Demo 或者项目经验比较少，了解的并不深入。这种感觉就像你特别饿的时候，外卖叫了一份饺子，结果都没有熟，那种心情你能理解吗？

最后，简历最好与能力匹配，稍微夸一下自己，这样尽可能争取到更多的面试机会，同时也容易给面试官留下靠谱的印象。

面试

面试的时候提前想好自我介绍，把握好面试的前几分钟，让面试官建立起良好的正面认知，也就是通常说的第一印象。后续的面试中，面试官都会尽量去往这个认知靠拢，支持自己对你最初的正面判断，哪怕是你出现了一些小失误。

另外就是简历中的项目经验，提前一定要好好复盘，尽量深入一点。面试的时候会有比较大的比重是介绍项目经验，如何做技术选型，遇到过哪些问题，是如何解决的，重点要提现出自己的思考，这部分基本是送分题，一定要表现好。因为项目因人而异，就不深入了，我们聊点其他的技术面试。

在面试过程中，必须搞清楚面试官问题的含义，不要急于回答，因为你可能还没有理解面试官的真实意图，容易掉入陷阱。这个时候就不是会不会回答问题这么简单了，还可能给面试官留下急于表现、不靠谱的印象。比较好的做法是按照你的理解，复述一下问题，同时了解面试官为什么要问这个问题，他是在考察什么。

可以肯定的是，面试官都希望招聘到聪明、有潜力、基础扎实、来了就能干活的人。所以反过来，面试者需要给面试官留下这样的印象。下面我们将从技术、态度、学习能力、解决问题的能力等几个方面一一展开。我会从面试官的角度出发，讨论我在面试时会关注哪些地方，也会站在面试者的角度，如何不动声色的给面试官留下以上印象。

技术

技术方面要考核的点太多了，就那我所在的前端来说，HTML、CSS、JavaScript，数据结构算法，计算机基础，CSS 又有各种定位、CSS3、SASS、LESS，JavaScript 又有 ES5、ES6、ES7、ES8，各种编程范式，各种前端框架类库 Angular、React、Vue，React 相关的又有 redux、react-router、React Native，要是写下去，这篇文章的字数将能以非常的速度增长。

接下来我说一下我作为面试官时会关注那些技术点吧。

基础知识

前端基础，包括 CSS 布局方式、Flex，JavaScript 基础，我会从一些基础的问题，然后层层深入，比如我最喜欢问的一个问题就是：对于数组，用的最多的方法有哪些？

基本都知道 concat，join 方法，如果能正确区分 slice，splice 传对参数的话，可以过滤出部分人，能熟练使用 map，reduce，filter 还能道出 map 和 for 的区别的话，又能过滤掉一部分人，如果面试者还能继续扩展，由 map，reduce，filter 引申到函数式编程的话，那就可以聊一些更深入的话题了。

比较常见的一个面试题还有字符串反转，这是一道很简单的题，很多人给出一个 for 循环的答案，然后就完事了。

function reverse(str) {  
  const len = str.length  let newStr = ''
  for (let i = 0; i < len; i++) {
    newStr = str.charAt(i) + newStr
  }  
  return newStr
}

这段代码并没有问题，但并不是一个好的答案。这个时候面试官大多会引导面试者去优化他，去完善他，或者能否提供更好的解决方案。如果能够在提供多种方案，并能够比较优劣的话，将会是一次比较好的面试。下面给出几种方案：

// 异常处理情况就先忽略了

function reverse(str) {
  if (str.length === 1) {
    return str
  }
  return str.slice(-1) + reverse(str.slice(0, -1))
}

function reverse(str) {
  return str.split('').reduce((prev, next) => next + prev)
}

function reverse(str) {
  return str
    .split('')
    .reverse()
    .join('')
}

第一种方法使用递归实现，第二种方式巧妙的使用 reduce 实现了，第三种方式使用数组和字符串的原生 API 实现，也是一种最简洁的实现，可读性非常高。这三种方式都是比 for 循环更高级一点实现方式，for 循环是指导计算机怎么样一步一步实现这个功能，引入了好几个中间变量，事实上，我本来不需要关心变量怎么开始，怎么结束，这与我们要解决的问题无关。递归很好的避免了这个问题，只是告诉计算机我要做什么， reduce 版本实现也是如此，不知道大家注意到了没有，其实这两种实现有点函数式编程的味道了。没有引入中间变量，屏蔽细节，告诉计算机我要做什么，而不是怎么做，非常简洁明了。关于函数式编程可以参考 如何优雅的编写 JavaScript 代码，文章后半部分有关于函数式编程的讨论。

这里都是由一些很小的问题，引发出一连串的思考、优化，甚至可以引发出不同编程范式之间的讨论，接着又去讨论面向对象编程和函数式编程了，当然这个也是一个体现面试者知识广度和深度的一道题。如果你能就一个问题展开深入的对话，那么会是很好的加分项。那么怎么做到这样子呢，首先我觉得这并没有很速成的方法，需要我们在平常工作开发的时候，不是完成一个功能就 OK 了，还需要去不断的改进他、优化他，思考与之相关的解决方案，做好分类整理、总结等等，然后可以输出到博客，面试之前好好过一下博客，找回曾经的感觉。

HTTP 协议

HTTP 协议应该是前端开发打交道最多的一个协议了，这里自然有很多可以聊的地方，最基本的 Method，Header，Status Code，HTTPS，接着可以聊抓包、正向代理、反向代理，还可以聊跨域 CORS，这里面学问又大的去了。一个最基本的认知，这里涉及到 CORS 规范制定者、浏览器厂商、前端开发者、后端开发者等各自角色的作用以及要做的事情，如果这个可以解释清楚的话，那么理解基本差不多了。在深入的话，可以聊复杂情况下，提交表单时，Cookie 怎么传，各个 Header 的具体设置情况，以及为什么要这么设置，这里面又会涉及到一些安全的问题。 CORS 不是设置一个响应头那么简单的事情，如果这方面遇到的问题越多，就说明他的项目经验很丰富，一个人的基础是否扎实、是否有潜力、解决问题的能力，在面试官的心中，已经有个底了。

说到 HTTP 协议，想起了前段时间，一位面试者在知乎上吐槽面试官总是问各种原理，这里贴出面试情况，以及部分知乎网友的回答。

问： HTTP 原理是什么？

答：超文本传输协议

问：工作原理

答：地址解析-封装 HTTP 请求数据包-封装成 TCP 包，建立 TCP 连接（TCP 的三次握手） - 客户机发送请求命令-服务器响应，返回数据-服务器关闭 TCP 连接 。

问：为什么通过这几个步骤后就可以

答 ：。。。。

偏右的回答：

没必要质疑面试官自己是否真的懂他自己问的问题，面试的问题是很大程度是为了形成区分度，找到你比我们屌的那个领域（打动点），而并非用来体现面试公司和面试官牛逼的。

我经常问一些我好奇但是完全不了解的知识（此处没有心虚），目的是为了找到那个你比我钻研得深的某个领域。如果你说不上来，那大家差不多，也没必要苛责。如果你说得上来，我会觉得你加入团队会给我们带来多元性。如果你在短短时间内还能把我给教明白了（或者让我以为我听懂了），那么恭喜你，你比我屌，我这关基本过了。

我是很认同这一点的，总是希望招聘到能把事情说清楚、学习能力强、有各个领域知识的人，特别是在某些其他领域有专长的人，这有很多好处

• 为团队注入新鲜的血液，扩大整个团队的知识并集

• 培养团队良好的学习环境

• 在以后解决问题的时候，容易收集到更多的各种背景下的解决方案

数据结构和算法

很多前端面试者都会问，要不要准备算法的面试题。根据我的粗浅的个人经验来看，前端开发中对算法的要求不是很多（并不是没有要求），那些为了算法而算法的做法不太可取。因为一个常见的情况是，出了几到算法题，面试者答不上来，或者有几个面试者之前复习了这些算法，能够答出来，仅此而已，不能完全到达筛选的目的。相对于算法我更看重数据结构的设计，这是一项很有用的技能，实际工作中使用场景非常多，举几个简单例子

• 省市区级联选择器

• 文件目录的显示（组织架构层级的显示），如果能扩展到增删改优又是加分项

• Redux 中 State 的数据结构的设计，这个设计直接决定了整个项目的开发难易程度

再祭出我喜欢出的一道题，就是实现微信的我的 My Posts 列表，不是 Moments 哦，这里涉及到整体设计、数据结构的设计、基础布局、分页等等。

对于以上场景，如果数据结构设计的合适，将极大的减少编码量，以及降低代码复杂度。这些都是从实际使用场景出发，更容易区分出面试者的实际设计经验。

框架类库

在过去几年，前端开发领域可谓风起云涌，革故鼎新。前端领域正像海绵一样吸收着来自各个领域的优秀思想，涌现出了很多框架和生态：Angular、React、Vue、React Native，可以说是一年一个新框架，各领风骚几百天。

大部分面试会聊到技术选型、框架对比，当然比较多的面试者只有一个主流框架的项目经验。比如说 React，这时候我一般会问这样一些问题

• React 有哪些优劣，在使用的过程中遇到过哪些问题，怎么解决的，Best Practice

• Redux 里面 Store 的数据结构怎么设计，有什么心得

• 在 React 项目里面，数据流具体是怎么流动的

然后会有一些特殊场景或者复杂场景，应该怎么处理

当然也会很多面试官喜欢考察源码，比如 Redux、Provider、connect、middleware 的具体实现，这就需要自己花时间阅读理解了。

对于面试者而言，技术视野和经验，当然越多越好，如果缺乏的话，一般会主要考察成长潜力，比如做事情的态度和学习能力。

态度

加班

面试的时候会不可避免的谈到加班的问题，如无特殊情况，这块应该还是要留下一个好印象。

根据平常网络上面的反馈来看，很多人是抱怨加班比较多，特别是无意义的加班，我觉得这个问题的原因不是某一方这么简单，肯定有管理层的原因，也有普通员工的原因。但是基本都是吐槽，很少有人想过要去改进这种状况。抱怨是解决不了问题的，公司也不愿意招聘只抱怨而不去解决问题的人。

我再稍微说一下我的看法，我喜欢不严格考勤和不打卡的考勤制度（这还叫考勤制度吗