基礎知識漫談(6):面試官在想什么
大約四年前,剛開始負責招聘的時候,偶會在面試者身上花去近40分鐘的時間,面試完之后,又不能描繪出該應聘人的全貌,有了幾次不成功的招聘之后,我做了一些總結,本篇文章將從應聘和招聘兩個方面分別討論。
(一)找工作指南
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技術”,有時候是面試官的話術陷阱。最忌諱的就是說謊,猜中了沒事(猜的中嗎?),猜錯了,你覺著面試官會怎么想?
特此聲明:因此文章個人認為總結的很到位,很有價值,特此轉載!轉載地址:http://www.cnblogs.com/anrainie/p/5630485.html
web前端 數據庫
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。