春招開始了,這一週面試了7個同窗,下週估計更多,累的夠嗆。面試下來發現一些值得注意的細節問題,記錄下來供你們參考,不着急找工做的同窗呢也能夠根據這些內容來修正本身的學習方向。前端
PS:我所在的行業是互聯網,崗位是前端工程師,目前會承擔一面(技術面)的職責。vue
本文同步發表在個人我的博客:面試中值得注意的問題git
我的博客的評論系統加了郵件通知,有什麼想和做者說的建議在我的博客留言哦es6
後續如有變化,將只在我的博客更新,恕此處再也不修改github
<!-- more -->面試
這裏不從正向去教你們如何寫一份好的簡歷,只是把我遇到的簡歷中的一些問題暴露出來幫助你們避過一些「雷區」。vuex
是的,你沒看錯,首要的原則就是保證簡歷沒有錯別字。雖然咱們這個行業對錯別字沒有挑三揀四的習慣,可是有錯別字給人的第一印象就很很差,尤爲你的自我評價還寫着一個「細心,對本身要求高」就顯得很諷刺。編程
主要出如今一些比較長的句子中,因爲助詞等使用不當,整句話顯得十分拗口,雖然結合專業背景不難猜到面試者想表達的意思,可是真的會讓人懷疑你的語文水平。那麼咱們爲何要注意語句通順的問題呢?首先文字功底也是溝通能力的一種體現,其次對於這個行業其實有不少文字工做的機會,好比設計文檔、代碼註釋、項目總結等。若是你簡歷裏有太多語言表達方面的弱點,會給你減分不少。後端
檢查簡歷是否通順也有個很簡單的辦法,就是讀出來,用眼睛看有的問題不容易看出來,可是當你讀出來的時候語句不通順的地方你本身會感受到彆扭的。前端工程師
簡歷的項目按照時間線倒序排列,就是距離如今較近的項目放在前面,較遠的放在後面。這樣放更能體現你的成長軌跡。
有的公司在發JD的時候會註明簡歷命名格式,若是沒有格式要求建議簡歷命名包含如下信息:
簡歷擁有良好的命名能夠給HR、面試官等提供不少方便。簡歷的命名就像書的名稱同樣,要讓人一眼能看到他想找誰的簡歷。
這種問題常見在跨專業找工做的場景。想找前端的工做,可是簡歷裏寫的不少項目和前端無關。(面試官也看不懂,你寫了有啥用?)固然,若是是編程這個大領域的能夠寫一寫。對於和你求職意向相關的項目,能夠展開寫寫。項目經歷要包括如下幾個要點:
今天看到一份簡歷,先寫了本身工做過的公司。而後寫了項目,項目命名又包含了「XXX公司XXX部門的某某項目」,這裏很明顯公司名稱有點冗餘,並且不少項目堆在一塊兒也看不清一個總體的狀況。因此我比較推薦的公司名稱、工做時間等信息加粗加大做爲表頭,下面是這個公司的項目按照時間的倒序排列。對於大多數人,公司數目和項目數目也不會太多,這樣同樣就能看出你待過幾家公司、哪家公司項目多一些等信息。
大公司有着嚴格的資料篩查制度,面試流程也較爲嚴格
如今投遞簡歷的方式有多種多樣:
大多數場景下,內推的好處是簡歷跳過HR(至少在咱們公司是這樣)直接到老闆面前。博取到面試的機會的機率更大一些。畢竟HR可能由於各類因素掛掉你的簡歷 ,而用人部門更多的看你的技術水平。對於大公司,內推成功一名員工是有獎勵的,內推的員工級別越高,獎勵越大。
如今一些公司會轉發內推碼,經過改方式投遞簡歷會進內推流程。這裏我要告訴你的是,內推和內推也是不同的。考慮以下幾個場景:
你猜猜哪一個內推方式更有效率?因此若是你在一所不錯的學校,建議你跟學姐學長們搞好關係,沒準找工做時候有大用處。以我爲例,不少找我內推的同窗和朋友,我會先看簡歷,若是水平正常,剛好部門須要,就會發給老闆看看,若是水平通常,想靠內推走後門,我通常就會回答:「簡歷給HR了,有消息他們會通知你的」。畢竟,內推也是以個人我的信譽作擔保,不能退給老闆太水的簡歷。
須要提醒你們的是,一些內推的人留的郵箱不是公司郵箱,這種場景下要額外注意內推消息的真實性,避免上當受騙。
其實面試官的問題背後都有一些目的(這是一句廢話),一般會從如下幾個方面考察:
面試官喜歡問的問題基本是爲了獲取上述幾個維度的信息。對應的提問方式也分爲幾類:
這類問題一般用來考察一些基礎知識,尤爲當你項目經歷不是很豐富時候,會直接了當的問一些基礎知識,這類問題一般都有標準答案。一些稍微複雜的問題,經過你回答時候概括總結的程度也能看出來你是掌握了這個知識點仍是在照本宣科的背答案,我更喜歡那些用本身的語言說出要點的同窗。舉幾個例子:
-……
這裏頗有意思的一點是有的同窗回答一些問題模棱兩可,可是回答較複雜的問題卻能比較標準(可是不熟練),有太明顯的準備面試的痕跡,這是一個減分項。
好比會跟你就一個項目提到的技術進行討論,通常會先問你基本的使用狀況,而後漸漸深刻看你是否知道改技術的底層實現。這類問題的特色是由淺到深,答案比較開放式。不少同窗爲了回答問題而回答,生搬硬套,明明是團隊選擇了這個框架本身就跟着用了,還非要說一堆本身不熟練的理由,這種也會比較減分。好比:
我我的比較偏心這類問題,由於這很容易看出你是喜歡鑽研的人仍是隻是停留在看文檔寫demo的階段。不少同窗的學習僅僅停留在對着文檔寫demo的程度,或者只是循序漸進的實現功能,其實只要在學習的時候沒遇到一個問題就多思考爲何,每調用一個API就思考它的底層實現,很快你會有很不同的收穫,用一句俗語解釋就是「知其然,知其因此然」。
面試的一個目標就是測試你能力的邊界和潛力,因此我比較喜歡就某些問題一直問道你不知道爲止。對於回答不上來的問題,進行適當引導,看你可否思考出解決方案。對於你沒有遇到過的業務場景,看你思惟的嚴密性等。這類問題,及時回答不上來,也能夠說一些大概的思路,不要瞎答,也不要不答。