原文地址:传送门1 | 传送门2
感谢博主!
1. 控制面试节奏
面试官在考察什么?专业知识,始终都是专业知识。
有一种常见的想法,“我有一个朋友/同学,技术还没我好呢,去了ABC公司,年薪有n k”。先不谈该同学到底有什么方面更优秀,身为一个学过统计学的程序员,绝不能认同拿个例代替整体的思路。
在面试之前,我们可以先找个招聘网站,按自己的地域、年限、技术做一个分类,然后看一眼中位数所处的大致薪酬区域,这个区域就是你谈价的基本盘,在这个基础上再用其他方式来操作方差。话又说回来了,自己清楚和向他人证明,是两码事,最后还是得看专业知识。
一般来说,专业我会考察三个方面:基础知识掌握程度,自己工作中应用到的工具\框架是否熟悉,本公司需要用到的技能有无了解。
工具、框架千千万万,你在客场作战,如何把面试节奏控制在手中呢?
a、写一份合适的技能表
我这里不谈最漂亮的,不谈最专业的,我强调的是,最适合你的技能表。
一个前提:面试官会看你技能表上的所有关键字。
你写出的技能,可能是加分项,也可能是陷阱。在这个前提下,提供一份能让自己应付自如的技能表,十分必要。
如何界定合适,是一个技术活儿。我这里提供一个可以实际操作的指南。
html,css,js,jquery,dojo,nodejs,ext,java,.net,php,dom4j,junit,jsonpath,tomcat,weblogic,redis,hadoop,oop,spark,svn,cvs,gitmangodb,jsp,servlet,tcp/ip,udp,spring,hibernate,mybatis,struts,springmvc,intellj idea,eclipse,vs,blablablabla……
看见这一堆,你能不能分清楚,哪些是前端技术,哪些是后台技术?哪些是解释性语言,哪些是编译型语言?哪些是基础知识,哪些工具和框架?哪些是数据库,哪些是web容器?等等。
这里说到的第一个重点就是,合适的分类。
我个人更加推崇按技术类型划分,比如:
基础 |
OOP,GoF,tcp/ip,udp,java |
前端技术 |
html,css,js,jquery,dojo,websockect |
后端技术 |
jsp/servlet,nodejs |
常用框架 |
spring,springmvc,mybatis |
常用工具 |
dom4j,fastjson,svn,git |
web容器 |
tomcat,weblogic |
数据库 |
mysql,Oracle,db2,mangodb |
开发工具 |
ecilpse,idea |
首先说明,做到了合适的分类,也还没构成一份合适的技能表。
在这份分类里,很多关键字是跨域的,你把git放到开发工具里,tcp/ip放到网络里,又或者把前端后台都总结为web开发类技术,虽不严格,也没有什么人会反对。
是的,分类本身可以不严格,但不能出错。如果前端技术里出现了一个php,面试官也会迷之沉默吧。
第二个重点,合适的掌握程度。
对这些技能做一个了解程度的分级,说明一下常见分级在面试官眼里的含义:
了解 也就是用过接触过的程度。
熟悉 能灵活使用该技术,知道相关的基础知识点,能搭建、配置,能解决常见错误。
精通 这个可不得了,你得有作为“专家”的自信才能如此填写,也就是,不管你遇到没遇到过的问题,问你,你就理所当然的要解决。
我这里提出几个原则:
但凡你有精通的技术,一定要特别突出的写在最前面,勾引面试官提及相关问题。
但凡只是你了解的技术,一个字都不要谈,它们都可能是扣分的陷阱,当然它们并不是没用,可以在面对面交谈的时候自己主动提及,为什么要被动的让对面来提问?
但凡是你熟悉的技术,你得确定自己是否真正熟悉,有什么好办法呢?答案是写blog,很多东西你以为你懂了,一旦下笔描述,就会遇到困难,写blog也是个二次学习的过程,这个过程会让你对原理性的东西有更多的思考。
懂得了以上,那么,上面那份技能表我们可以做一个筛选,并加上描述。比如:
基础 |
精通Java和面向对象编程及其设计模式 |
前端技术 |
熟练掌握html/js/css前端开发技术,熟悉jquery及相关UI库 |
后端技术 |
熟悉servlet原理,熟悉ssh框架 |
web容器 |
熟悉tomcat |
数据库 |
熟悉标准SQL语法,熟悉mysql数据库,熟悉mangodb数据库 |
常用工具 |
熟悉dom4j,fastjson |
做完了这些,技能表就精简到了一定程度了。这份技能表达到合适了吗?
第三个重点,合适的技能。
有一些技能,并不合适写上去。
举一个例子,我经常看到有人说,我熟悉XML。
XML,我们知道,它是一种描述性语言,在开发中我们长用来作为序列化工具使用,它仅仅是个“描述”而已,那么,你到底是熟悉它什么呢?
有人可能说了,我熟悉dom4j,也熟悉xpath,那么这还稍微靠谱一些,xpath和正则表达式,我们都可以归纳入“基础”一栏。但是拿dom4j出来说,就不大合适。
为什么?因为它也仅仅是个用于解析XML的工具,一个合格的程序员,是要做到看一眼它的API就能自行使用的。
总结,它们使用起来太简单,不值一提。
所以,不要提。
不过呢,凡事有两面性,简单的东西也说明其容易理解,如果能谈出原理性,就又转变为了加分项。
比如“熟悉XML设计规范”,至少就要求你知道标记里每一个属性的含义和用处。
比如“懂得dom4j原理”,至少就得知道dom4j的建模思路。
最后一个重点,漂亮的布局。
这里我用了漂亮,不是合适,我们来看看上面的技能表,其实,“分类信息”这一列,就很多余,只要你合理的排布,对方自然是知道这一栏的,“熟悉”“精通”其实又表达得很模糊,对于不同面试官,界定的方式可能又不一致。这里推荐五百丁的简历模版,比如这张技能表:
b、把面试范围控制在自己的主场
一般情况下,做到了上述部分,就算是划好了道儿。
“我遇到个傻X面试官,老问我前端问题,我搞大数据的,问毛线前端!”
没遇到过也听说过这种事吧?
解释一下这种情况的产生,面试官的水准不一定比你高,也不一定有很多招聘的经验。于是,有那么部分负责招聘的技术,就爱把问题往自己熟悉的方向去引,又或者,干脆就是想问倒你。
面试官平时也就是个程序员,你所熟知的东西可能不是他的领域,如果让他开口问你,难免会不欢而散。这里提供一种沟通方式:“你说的这方面我不熟悉,我是做XXX的,要不我和你说说XXX和XXX?”
一般来说,如果不是傻,面试官是不会拒绝的,不管领域相距多远,都还是会有思想上的相通,说得有理没理都能体现出来。
做到这些,面试的节奏基本就握在了你手里,对于你自己熟悉的内容,如果做不到侃侃而谈,那,就是另外的问题了。
2. 理解面试官的思路
先解释几个理解上的误区。
a、招聘应该看水准,而不是学历
专科里也有优秀人才,这是不可否认的,但是个人去应聘是个人的事,公司要招聘是统计学上的事。假设不同学历的人才排布满足正态分布的话,高学历的峰值肯定是在低学历的正方向的。
学历门槛能用来节约面试精力,并不是针对个人。对于个人而言,如果没有学历,提高能力当然还是正事。
b、堆砌使用过的框架并不能增加你面试的好评
对于这些框架的理解才算。不要追求宽泛而全面,全面不是坏事,一旦被人问及了不那么熟悉的东西,很容易被连带着否定其他优点。深入解释一个问题,比“我什么都懂”是有优势的。毕竟,能深入理解一门技术的,理解其他技术就很容易。反之不亦然。
c、形象和谈吐,很重要。
这是个“看脸”的世界,如果没有好的外表,请做到整洁干净,如果不擅长言辞,请放慢语速,清晰的有条理的表达。
是为了给面试官好印象吗?不光如此,在技术达不到忽视一切的时候,干净的外在、清晰的表达,就不会被人质疑团队融入能力。
d、不要怕谈工资
但凡水平足够,只管开出自己期望的工资,工资估算方式之前已经提过了。如果怕工资谈低,就不要说出会让自己后悔的数字,如果怕谈太高了找不到工作,正常的公司会对心水面试者回复“我们只能开这个工资,但我们有XX奖励,XX奖金,你看看能不能接受”。
e、毕业生基础最重要。
在随意找工作之前,请打理好自己的基础,做好万全的准备。公司招不到人,和求职者找不到工作,是同时存在的。在全国各地,有大把的工作时间灵活、薪资丰厚的工作等着你们,不要急于一时,静下心来,把学过的基础知识概念背一背,谈工资的灵活性就大些。
基础不好的同学,请抛弃我很努力我学习能力很强,我可以不要工资,给我一个学习机会就好的想法。
基础,是所有问题中最重要也是最简单的一环,如果在学校时候没有学好,要怎么让人相信你的努力和学习能力呢?
一个刚毕业的学生,如果基础不扎实,对于公司来说,可能是负资本。一方面,需要一个老员工来做培训,另一方面,成长性可能达不到期望。
一个培训公司的培训周期也就半年,如果只是复习基础,难道你的成果会比培训公司那种什么都教的要学得少么?
话又说回来,毕业生请把握第一份工资,这不是钱的问题,而是会给开低价的公司不会认真培养你,你愿意把社会生涯的第一年浪费掉么?
3. 切勿说谎
这一条太重要,所以单独放这里说。对于不了解的东西,直白的说不懂就好了。
“有个谁,啥都不懂,靠吹就拿到了高工资。”
相信这种事情的,请不要做程序员了。
1、不要拿个例当整体;2、那是别人不是你。
如果不是基础知识,一般是不会扣分的。有时候,是该公司要求“懂XX技术”,有时候是面试官的话术陷阱。最忌讳的就是说谎,猜中了没事(猜的中吗?),猜错了,你觉着面试官会怎么想?
1. 招聘会上的招聘材料的准备
一场招聘会上公司林林总总,面试者要了解你公司,只有他晃过去的那几秒钟,一张意义鲜明的海报,就特别重要。
很多海报自己设计得漂亮,公司介绍得高大上,愿景理念口号特别响。有用吗?产品们常说的一个道理,做得好是0,符合用户需求才是1。
那么,面试者的需求是什么?下面列一些关心的点,顺序与关注度相关:
a、提供的岗位有哪些
来看看几个例子,文案一:
Java工程师
必须条件
【必需条件】
(1)清晰的逻辑,深厚的编程功底,熟悉设计模式,掌握Java及其相关技术
(2)对技术研究感兴趣,有较强的学习能力
(3)熟练的英文阅读能力,以便迅速掌握最新技术
(4) 熟悉Java 多线程及网络编程
(5)能够适应中短期出差;
【优先条件】
(1)java 后台服务开发经验
(2)熟悉Eclipse插件体系
(3)擅长JVM之上的其他语言(如Scala,Groovy以及BeanShell等)
(4)学习研究过大量开源软件的源码和架构
(5)丰富的报表开发经验
(6)熟悉Linux/Unix操作系统
(7)有工作流引擎相关的经验
(8)有金融行业或者较大项目设计开发经验
再来看看文案二:
Java软件工程师
熟悉掌握Java语言及面向对象思想,熟悉运用各种设计模式
初始岗位:运行平台开发工程师 、图形化开发工具 IDE 工程师 ,技术支持工程师
这两份出自本公司同一场地不同期的招聘会,相隔时间不过月余,后面这份文案的招聘效果,就要好一些。
招聘会上的面试者时间是很有限的,你写得再长,对方也只会提取招聘文案里的关键字,此其一,如果有个面试者停留下来认真阅读你的文案了,太过精细的内容会吓阻他过来面试,就算这上面的每一个要求他都能满足。
由上,我们可以推论得出,其实,文案二也不够好,好的职位要求文案只需要关键字!
比如:
我们需要:JAVA开发 前端开发 大数据工程师 .Net开发
如果希望加上特定的限制,就应该使用特定的关键字,真要考核也不是靠文案排查,最终还是面试官的事情。担心这样表述很模糊么?想想这个问题,如果一个Java开发者不懂其内涵的基本职责,他通过面试的概率也不高吧?
b、福利待遇有哪些
对薪资有底气的,就放上工资,有年终奖绩效奖的,就放上绩效奖。
住宿补助,电脑补助,交通补助,电话补助,用餐补助有什么写上什么。对于老员工来说,补助在工资里几乎无法觉察,而且,很多补助是你有我有大家有,那有什么写上来的必要呢?
可是,这些钱对毕业生来说,很重要,而且人人都不写,就你写了,这就是优势。
就我个人经验,福利里最吸引人的,是包食宿。毕竟一线城市房租贵。
c、公司行业和规模
这方面就没什么好说的,有一说一,唯有一点要注意:不要灌输情怀!
真情怀不是靠说的,说出来的情怀就是又累又没钱给你。
这对于只是看海报来了解公司的面试人来说,是个负面印象,最好杜绝。
2. 一些面试的小小经验
很多人都经历过一些奇葩面试官吧?当自己作为面试官的时候,请意识到对面的这个人以后可能是你的同事。不装逼,防雷劈。
下面提供一套面试的方法论(主要应用在3年以下经验的招聘),基本能把面试时间控制在5~30分钟,而且,自采用这套方法以来,没有失误过。
一般而言,面试的过程是笔试(可省略)->机试->技术面->人事面。
第一个前提,每一个步骤都要发挥它应有的价值,比如笔试,就应当划分一个严格的分数线,针对招聘目标区分档次。
第二个前提,你和面试者的时间都很宝贵,为了照顾对方的面子而进行下一轮面试其实是伤害,双方都很尴尬的,有这个时间不如提供职业咨询和建议。
在笔试和机试部分,达不到要求的,可以考虑按分数直接谢绝,如果担心误伤(毕竟有些笔试题出题意图就很诡异),可以考虑把分数线降低。
技术面部分,请确定你的招聘目标,是专研技术的研究者?还是走上市场的现场实施?对于不同的面试者,不要提出和你要求无关的问题。
如何筛选问题?对外包面试人提问spring的aop实现原理,就不太合适,因为你不需要他去研究spring,而应当偏重在问题解决上,比如JVM每隔几天就会因为内存溢出挂掉,要要从哪里入手解决。我会把我的问题划分为三个方面:
基础类,框架原理类,框架应用类。
假如面试的是研发人员,基础类和原理类就属于必查,实践类就属于加分项。
基础类问题:
每个类型都可以继续往下细分,这里以基础类作为讲解,我会提三个问题:
1、什么是面向对象
2、说一个你最熟悉的数据结构
3、说一个你最熟悉的算法
第一题是必须题,后面两道都是用于加分。
很简单?说一个事实,在我两省十多所大学四年的面试经验中,这三道题能过滤掉八成的毕业生。来看我怎么提问的:
问题一:
该问题的难度以“吃方法”分野。
之前基本是考察语法和封装性,以及对基本概念的重视程度。在提示之后依然没有意识到自己错误的,坚决不用。
吃方法属于进阶题,看着很简单,对于很多程序员来说就是直觉性就明白的问题吧?其实,这是需要多种能力的:
a、猫吃老鼠,要能理解猫是一个类,吃是一个方法,老鼠是一个类,作为吃的参数;
b、猫吃鱼同理,吃老鼠和吃鱼这两个行为,本质上来说,都是吃食物
c、食物是单独是个接口,老鼠和鱼都是它的实现类。
看,面向对象分析理解,抽象能力,继承和多态的应用,接口和类的理解,具备所有这些,才能快速准确的做好这个吃方法。
问题二:
说一个最熟悉的数据结构,又或者,简单一点,说一下LinkedList和ArrayList的区别。相信很多面试者都遇到过这道看上去很蠢的题,网上有很多答案,他们说的基本都没错,但是,按这些答案来回答,不会给出很高的评价。
这样提问:为什么LinkedList查询会比ArrayList慢?又或者,如果java没有提供LinkedList,你要如何实现出来?
这里考验的能力有两个,两者有其一,都可以打出高分。
1、对于需求的理解能力
2、阅读源码的兴趣和能力
链表的定义是“表由一系列结点(链表中每一个元素称为结点)组成,每个结点包括两个部分:一个是存储数据元素的数据域,另一个是存储下一个结点地址的指针域”。
把这一段话当成需求,那么,名词有:表、结点、数据域、指针域。
同时又能得出它们的包含关系,表里有多个结点,结点里有数据域和指针域两个部分。
完成了这一部分分析,自然就能设计出对应的LinkedList类。查询为什么会慢呢?查询对应的是get方法,get(i)自然是要从头结点的指针域迭代i次,取出对应结点数据域,这个迭代过程导致了慢。
无论是通过自行分析还是阅读过源码懂得这个道理的,都说明具备一定能力或潜力。
问题三:
说一个最熟悉的算法?
其实这里考验的是多个层级:
1、是否有认真准备面试
2、数理逻辑水准
3、算法水准
拿最常见的排序算法说事。
能说出任意排序算法原理,说明至少有认真对待面试。
能说出快排、桶排、堆排等复杂一点的排序算法,并且能指出得到最差和最优结果的输入,这一部分,需要面试者能在脑中模拟算法运行,根据算法本身的原理,来解释为什么快和慢。
有认真学习过算法,理解时间复杂度本身是什么概念。
举个例子,一个算法的平均时间复杂度是O(1),另一个是O(n),真正执行的时候,前者会比后者快吗?
答案是不一定,因为我压根没提输入是什么。
如果不能理解O(n)描述的是趋势,那么,对算法的理解就还未入门。
又比如,如何计算一个归并算法,比如T(n)=T(n/2)+n/2的时间复杂度。这一方面考验了算法,一方面又考验了在校时的学习能力。
框架原理和应用类问题:
面试官需要明白,框架问题回答不上来,并不说明对方比你差。
每个人的专精方向是不一样的,框架这种事,也就是个工具学习和经验的问题。用业务相关问题问同行的老鸟,能够理解,来问毕业生和新手,问并不使用该框架的老鸟,就很莫名其妙。
对于这种情况应该如何考察呢?
框架不一样,思想有相同。
1、询问对方最熟悉的框架
2、询问框架使用中遇到的最困难的问题
3、有没有阅读过框架源码,解释一下框架某部分功能的实现原理
对于自己最熟悉的框架的了解程度,能说明面试者的真实水准。
有些新手使用框架的时间都很短,那么,可以换个方式出题,比如:“你知道spring的依赖注入吧?假设spring没有这种功能,让你来写这个,会如何写?”
依赖注入并不是什么黑科技,了解反射理解面向对象的程序员,都能答出个一二三四。
总结
公司和员工是双向选择关系,应聘者大可不必把自己放到“求”职的低位,面试官也请勿趾高气扬。
不管招聘还是应聘,无非就是了解自己和对方的需求,然后展现优势,而已。
------------------------------------------------------------------------
感谢博主,请大家支持原创!
原文地址:传送门1 | 传送门2
告辞!