前端面试【有感而发】

2015/09/16 · HTML5,
JavaScript · 1
评论 ·
面试

原文出处:
聂微东(@聂微东)   

首先,这篇没有具体的面试题;

其次,这篇仅是我个人的面试态度;

最后,在这金三银四的跳槽季里,祝愿各位找到好工作。

俺第一次做面试官是2011年,想起那时自己真的很紧张(不管做什么头几次都紧张哈),可是还是在希望在面试者面前留个比较专业的印象,所以总是装作很淡定,记得那时总会放一件修身小西装放公司,专门用来面试的时候穿的,装成熟,你懂得。现在回忆起那时的点滴,不由自主的会嘴角上扬:)

图片 1

——————————- 低调的分割线 ——————————-

 

“全世界都缺前端” ——
这话总会被提起,PM尤其是喜欢这么说,而且还是在工作推动的过程中(我会告诉你我这是在黑PM么)

面试一直是俺工作中重要的一块,而且自己也喜欢去参与面试(工作忙爆的时间除外)。原因究竟为甚其实我自己也说不上来,可能是因为心里希望在工作时可以与聪明的人合作吧;也可能是希望通过面试push自己去主动了解行业新的技术…Anyhow,也就一头扎进了面试官的行列,且乐此不疲。

图片 2

前端回忆录  

8年前的前端做些什么?页面重构(HTML+CSS)和实现页面交互(JS+CSS);jQuery也是在8年前诞生(06年8月发布V1.0);

4年前业内提出大前端,这直接让前端职位在产品和业务中变得更加重要,甚至是最重要的存在,在以前的技能基础上又需要掌握一门服务端语言和少量数据库的经验(从那时开始身边经常有朋友由后端转前端);

2年前的前端界Node开始疯狂火热,且一扫各种前端论坛、开源项目,狂热者更提出“JS一统WEB开发”的头号,数据结构简单点的网站建设只需要一个工程师即可搞定,那就是前端,叼炸天呀;

Now,全端工程师???maybe…

移动互联网风光依旧,前端更是无处不在。

可是… …

招人真心难,招前端更难,招个好前端难上加难有木有~~

图片 3

主观意识 & 经验主义  

工程师每轮面试时间一般为一小时左右,除非面试官对你没有兴趣,否则不会十几分钟就打发走你(我厂要求面试至少20分钟)。而且就在这差不多一小时,面试官要判断你是否符合招聘的岗位,这本身就是一件非常挑战的事情。正因为这样,所以面试官的决定都有一定的风险和主观意识,这不可避免。

许久以前看过一篇跟面试相关的文章,具体内容说什么忘记了,不过里面有一句话给我印象深刻,大概意思是:“很多面试官希望能招到个像自己的人,和自己类似的人”。很容易理解这句话,因为和自己类似所有更容易引起自身的关注,而且记忆会更深刻。这个“类似”俩字我理解应该至少包括几个方面:技术方向、性格、思维方式等。

我也同意会带着主观意识去面试,但我认为这并不是什么糟糕的事情。

具体点说,我会考虑你是否会push甚至引导团队的成长、与你合作是否会愉快,这也是我参与面试的原因之一。在此,希望你静静思考下,你在团队中是否属于这类人,至于是与不是由看官您自己评判了:)

图片 4

技术一面  

通常情况下工程师面试都有几轮?不管几轮都很正常,反而很少有听说只有一轮面试的,所以这里说的一面是纯技术的面试。

有时我会为面试面到一名优秀的同学而高兴不已,因为聊天会很畅快,而且决定很明朗。

更多时候我会比较纠结,因为我需要考虑给不给面试者通过我这关。正因如此,其实很多时候我做的每个选择都有一定的运气成分。

俺初期做面试官的时候,基本都是我主动来发问和出题,用自己的主观意识去考察面试者的方方面面。那时想当然的认为,这份岗位需要这些XX技能和用到这些XX技巧,所以如果面试者具备这些知识点就可以通过。

再后来面试的经验提升了,想明白了学习能力、思维方式和技术能力同样非常重要,所有会主要针对面试者比较擅长的领域来【交流、讨论】。

在面试这个过程里,我现在总会在正式面试之前,和面试者说句话:“面试就是聊天,我们简单聊聊吧”。

图片 5

本来想随便配个图,可是看到这个图片突然想起一首儿歌:丢肥皂 丢肥皂
轻轻的放在小基友的后面 大家不要告诉他 快点快点捉住他,快点快点捉住他…

好吧,节操碎了一地。

 

我的期待  

下周已经安排有六个面试。请思考,作为一名面试官应该对你又有怎样的期待?

俺的面试时的问题一般不固定,因为我不喜欢背题的做法。

有一定工作经验最好,当然没有也同样有机会,而且有工作经验对于面试也不一定都是好事。

PS:工作年限和项目经验决定了你的知识储备,所以也会有针对性的调整难度和问题。

 

在我看来评价一名同事是否优秀其实很简单, 看看他是否够【专业】就行了。那么合计合计,你自己对待工作是否对得住专业俩字。至于怎么理解专业俩字,还是见仁见智吧。

简历造假或者过分夸大。夸大自己的工作确实也属正常,可是如果夸大、夸大程度都需要有底线可言。经常会看到简历上写着精通XX,比如jQuery,然后面试的一问没有读过源码,对其细节原理说不出所以然来,这还不如不写。

记得前不久在微博上看 @朴灵 说过:“如果你的GitHub上没有任何项目和代码,简历上还是别填GitHub地址了,没啥好处的。”

期待你不要紧张、而且自信,让自己好的一面尽量的展现出来,努力把面试官当成你的同事,你只是与他探讨工作中的问题。甚至可以多提些自己觉得有意思的想法,如果能够和面试官一直存于一个较愉快的谈话环境,相信你的面试结论上,面试官一定不会吝啬对你进行正面的评价。

图片 6

总结  

面试其实也是修心的过程。

我毕业初期时找工作也并不顺利,不过多次在找工作面试的过程中经常会遇见很好的面试官,就算你没有达到他们的岗位要求,他们还是会中肯的给你一些靠谱的建议。这些面试过程就非常的美好,其实结果不一定是最重要的,过程也一样美妙,不是吗。

最后,请带着你积极的心态,好好享受每一次面试。

祝好

2 赞 3 收藏 1
评论

图片 7

前言

最近作为面试官,参与了多场专场面试,短期内大量的面试,面对不同风格,性格迥异的面试者,让我对面试这件事本身产生了一些思考,结合自己的一些理解和技术领域特有的定级制度,我们不妨来聊聊技术面试这回事。

文/沐丞

如何准备一份「工程师范儿」的简历?

何为技术面试

我所理解的面试,是一场围绕着两个角色 – 面试官 & 面试者
之间的一场“对接之旅”, 如何在短短的30分钟内, 让彼此更多的了解对方,
就像两个不同的形状的卡口,不断的调整彼此认知,进行思维对接,最终完成面试。由此我们大致可以将面试划分出几种失败的场景。

如果你是一个经常跳槽换工作的人,一定会经历很多场面试,也会遇见各种各样的面试官。通常这些面试官的风格会很不一样,因为他们的岗位不一样,级别也不一样,个人性格修养也会有很大差别。有些面试官比较直接了当,有些则讳莫如深。之前在一篇《对不起,我删了你的简历》的文章中介绍了一些简历筛选阶段的潜规则,今天就再来谈谈面试阶段的潜规则。

定制简历

1. 互怼型

面试官完全不看面试者的简历,仅从自己的技术领域出发,对面试者进行考察,面试者往往会有一种被
diss 了的感觉,脾气不好的可能会进行反向
diss,然后一场面试就变成了带点火药味的攻防战。

有的面试者在一轮面试下来后可能会自我感觉良好,觉得充分展示了自己的优势特长,自身的经验资历也符合岗位要求,可是到最后却不了了之。其实你可能不知道的是虽然在面试过程中面试官并没有明确表态,甚至让你觉得他很欣赏你,很多时候是面试官出于礼貌或是公司要求,其实他在心里早已经把你淘汰。

我自己的经验是,每个岗位的具体要求都不同,因此大家不要用一个通用的简历去应付所有的岗位,最好是根据特定公司的特定岗位来定制简历。当然这并不是让大家编故事,而是突出与目标岗位匹配的经验和能力。大家去应聘一个开发或者测试工程师,和去应聘一个
Team Leader
或者技术经理的角色是完全不一样的。比如,如果我要去应聘一个有管理性质的岗位,我就会在简历里适当突出我曾经从
0 组建了一个 10 人的技术团队,里边有多少资深 Java
开发工程师,多少数据库工程师等等,这样就会更有说服力;同理,不同的技术岗位的需求也是有区别的。大家写简历的第一个目标,就是让简历在筛选阶段生存下来。因为往往一个岗位会收到大批简历,如果简历不能写得很清晰,让
HR 觉得很适合,很有可能在开始就被刷掉了,没有机会去面试。

2. 尬聊型

面试者对自身的认知有限,简历上几乎体现不出有价值的内容,缺乏经验的面试官不知从何问起,或者面试者的简历虽然详实,但所有的问题都点到为止,场面一度陷入尴尬,就像一场尬聊,这种情况下,经验丰富的面试官可能会通过一系列问题来确定面试者的能力边界,从而构建出面试者的能力模型,如何做到这一点,我们后面聊
:)

一般正规的大公司对面试官都有一定上岗要求,出于公司形象的考虑也会有一些统一的话术。你是进入下一轮,还是要再跟其他候选人对比考察,还是直接淘汰你都有统一的说法。就算是淘汰,很多时候为了照顾面试者的颜面也不一定当场表态,会先说一些客套话,让你回去等消息之类。但是你等到的消息或许就是一封觉得你不适合岗位要求的统一模版的官方邮件。

突出亮点

3. 一边倒

面试官或者面试者占据绝对的主动,但是彼此沟通并没有形成体系,往往在某个细节上进行过于深入的沟通,一方占据优势导致另一方疲于应付,最终形成一边倒的局面,结果无非是

  • 面试者:“这煞笔真水”
  • 面试官:“这哪来的2B”

从上述的一些场景中,我们不难发现,面试失败的原因可以归纳为2类:

  • 面试者缺乏自我认知,没有把自身的优势体现出来,简历中没有很好的勾勒自己的能力模型,给面试对接过程带来了很高的启动成本
  • 面试官缺乏问问题的技巧和经验,不能够通过问题确定面试者的能力边界,从而勾勒出面试者的能力模型,导致最终产生不全面,甚至错误的判断

(图片来自网络)

我见过很多简历都会写自己既会 Java,又会 JavaScript,还会
Python,一下写十几行。这个本身没有错,但最好能突出自己的核心技能,比如,“我有
8 年 Java 开发经验,很擅长 Java 并发或者 Java
安全”。但要注意的是,我们在突出亮点的时候,也不要过分浮夸,因为有时候当我们发现一个简历有太多“精通”、“深度掌握”这类词,第一感觉是怀疑,而不是觉得这个人很牛,所以要适当的把握程度,事实是基础。另外,项目经验上,我建议按时间顺序由近到远排序,最好体现目标岗位的匹配度,突出自身项目的难度和价值,以及自己在项目中的作用。这样就能进一步帮助面试官判断候选人的能力和在团队中的位置。

何为能力边界 & 能力模型

俗话说人力有穷尽,每个的能力在任何方向上都会有尽头,这个尽头便是你能力的边界,我们经常在游戏中看到一种五边形,每个顶点都代表一种能力,角色在这个五边形中不同能力的数值最终构成了一个角色的能力模型,譬如敏捷型
/ 力量型 / 智慧型
等等,而作为技术工程师,确定自己或者确定一个人的能力模型是及其困难的事,尤其是在短短的几十分钟内,通过一场面试,那更是难上加难,故而如果面试者能对自己的能力模型有很好的认知,面试官有丰富的经验技巧和对应的知识储备来验证这个能力模型,那面试的过程就会非常高效。

有些面试者可能在面试的中途,甚至前几分钟就已经被面试官在心里打了叉。我来举一些例子,供大家参考。

用事实和数据说话

面试者如何勾勒自己的能力模型 & 面试官如何确定面试者的能力边界

回到面试者本身,因为不同的技术背景的公司对于同一层级的能力模型的定义可能存在偏差,譬如同样是高级前端工程师,对于专业能力的理解,可能会因为技术栈的不同而产生变化,一个使用
React 技术栈的公司对于能力相同,但是使用 Vue
开发的工程师给出的评价可能会低于使用 React
的工程师,而这种技术变量的存在给面试本身带来了很多的不确定性。尤其是对于面试官如果相应的知识储备不够,那评价可能就会更加失真了,所以作为面试者,我们应该从自身的角度出发,尽可能在简历中给出一个可评估的能力模型,让面试官能够更好的了解,愉快的完成对接,这里我罗列了一些边界的点,尽可能从相对通用的角度来定义工程师的能力模型。

情形一:业务面试没有做足准备的情况。这样的面试者我遇到的最多,比如来面试不打印好简历。很多面试者认为既然招聘单位收到了简历,那么在预约面试后面试官就会自己打好简历等你上门,这是一个很大的误解。

对于工程师,定量比定性更重要,因此要让面试官和 HR
体会到大家的经历或亮点是可度量的事实。比如在简历中强调“我非常善于快速学习”固然有帮助,但如果配上一句“我在两个星期之内就学会了
Clojure
语言,做了一个撮合系统”,更能体现出“快速学习”能力。还有很多人会表述比较含糊,比如在简历中写“我大幅度提高了系统性能”,但作为面试官,我可能不清楚这个“大幅度”到底是什么概念。因此大家最好写的明确一些,比如“我在一个四核
8G 的配置上,把吞吐量从 2000 QPS 提高到 8000 QPS,平均的请求是 100K
bytes 等等”,这样就会非常有说服力。

基础能力

体现技术的基础技能的掌握情况,以前端举例,可能包括通用计算机基础,例如基本的数据结构和算法,像堆栈,队列,数组,树,链表等定义,和常规的操作等;前端技术基础,对
JavaScript的理解,对 http 协议的理解,css / html
掌握和理解以及其底层的协议和规范的理解和掌握;业务能力基础,包括对实际用于业务开发的技术掌握的情况,譬如对
React 的理解,对 Vue 的理解,如果是公共技术团队则可能涉及 Webpack
打包构建方面的理解,也可能是对 nodejs
的理解;仔细观察,不难发现,基础能力边界是一个层层推进的过程,面试者可能具有丰富的业务经验,但是如果你要理解
React 的底层实现,就一定会去学习树的数据结构和算法,看到JSX,就会想到
babel 是如何解析的,这里涉及到编译原理的前端部分,而这些又绕不开对
JavaScript的理解,从而形成一条清晰的基础能力链条,如果你的简历能体现这些,面试官就能很快的核对出你的基础能力到底是否扎实,作为面试官,我们从业务基础能力往通用计算机基础方向去不断的发问,形成一条问题链条,就能考察出面试者的基础能力是否扎实,对于那些只局限于
API 使用的情况,那基础能力上的评价就是相当低的。

预约面试的人很可能只是HR助理,他们只是负责预约面试,告诉你时间地点。但是你首先参加的可能是业务面试,业务部门的人工作繁忙,收到的简历也特别多,如果不是特别重要的应聘者根本不会费心去打好简历。还有就是一天可能面试多轮,有的面试官有你的简历,但是在面试完之后他要去写评语,不一定会给到下一轮的面试官。

公开成果很加分

专业能力

相对于基础能力聚焦于技术领域,考察的是技术工程师中的技术两个字,而专业能力则考察技术工程师中的工程两个字,一个优秀的工程师,一定具备良好的工程项目设计,管理,推进能力。一个软件工程从无到有的过程,其最初一定是设计,如果一个技术工程师没有任何设计一个项目的经验,那这一项一定是不合格的,如果他有,那设计的方案是否合理,是否具备良好的扩展性,可维护性,就是需要考察的一个点,因为有了设计,那一定需要将设计落地,这个过程就是工程项目的推进,作为工程师,他如何推进,如何落地一个设计,这中间是如何管理的,如何控制项目风险,确保设计最终能够被落实到项目中,这些都是考量的点,面试官可以持续的深入去了解从设计到落地的全过程,并通过工程项目的复杂性来判断他专业能力的高低。这也是在基础能力通过的前提下,给一个技术工程师评级的关键。

你来面试,准备几份打印好的简历怎么了?这是有多难?如果不打印,你至少也有一个Pad之类的工具来展示电子版的。当有面试官问你要简历,你说没有,你也没有办法展示,那么即便后面他也问了问题,其实你可能已经被淘汰了。

比如是开源项目的贡献者,有一个很有内容的博客,在 Github
上提供了很多被采纳的 PR,发表过哪些技术论文,在 QCon 或者 ArchSummit
上做过分享,或者写过哪些著作等等。像这些公开可见的成果,远比自己评价自己更有效果。

沟通能力

任何工作都离不开沟通,尤其是技术工程师,在团队协作中跟不同的角色产生的沟通,更是团队能否有效率的持续完成任务的关键,那如何体现自己的沟通能力
/ 面试官如何考察一个人的沟通能力?

第一应该是直接感觉,在面试过程中,对方是否能够很好的说明自己的优势,并获得面试官的认可,这本身也是沟通能力的体现,但光靠这个可能还不够。所以第二点,又回到了之前的专业能力上,面试者所完成的工程项目的复杂性直接体现了他沟通能力,譬如这是个跨部门跨团队的大项目,他能够拿到比较好的结果,那沟通能力一定不会太差,如果一直都是做一个人的项目,或者是从没有
owner
过一个项目,那沟通能力可能很难被评估出来,这时候不妨问些有引导性的问题,譬如:“是否遇到过工作上的难点,需要同事协助?”;“有主动去和其他部门的人沟通,完成一些工作么?”,如果都没有,那只能靠第一感官了……

没做足准备的情况还有就是需要展示作品的岗位,比如设计师的岗位。我也遇到过一些面试者来面试不准备好作品,这些人可能之前投简历时以为附带了作品链接,面试官已经看过,这同样是一个很大的误解。

简历形式

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注