最近有一個關于技術面試的發(fā)現(xiàn):很多簡歷漂亮的應試者面試的失敗率其實很高歇父。有這么幾個失敗模式:思路糊涂逝慧、解題方向迂回,毫無分解地把所有邏輯扔在一個大函數(shù)里面苔严,最后代碼錯誤連篇(比如說把數(shù)組的指數(shù)和內(nèi)容搞混甩恼、off by one蟀瞧、if 不用 else沉颂、漏掉幾個if case什么的),或是缺乏測試的概念悦污。這些誤區(qū)如果有點準備或是培養(yǎng)一些好的面試習慣铸屉,其實是可以避免的。
不同公司的面試目的不太一樣塞关。類似于Google和臉書的大公司喜歡在白板上考算法和數(shù)據(jù)結構抬探,其實也就是你的算法101課有沒有上好。類似于Stripe和Clever的小公司喜歡考你的專項(如網(wǎng)絡前端帆赢、移動端、或者運維大數(shù)據(jù)什么的)线梗,也讓你自帶電腦當場寫能編譯能運行能測試的app椰于。其實這是因為大公司往往都有很龐大而復雜的系統(tǒng)、所以技術決定中效率很重要仪搔,同時也有大把有經(jīng)驗的員工可以慢慢培養(yǎng)你上手(比如臉書就有6周的bootcamp瘾婿、谷歌前3個月也會給你一個專門拿來上手的bootcamp項目)。小公司則需要你立刻馬上能寫出能用的東西烤咧,所以會看重你會不會用他們的技術展偏陪,以及能自己在沒人帶的情況下能否寫出可用并靠譜的代碼。當然各種公司也會根據(jù)職位煮嫌、需求笛谦、和心情(也就是當天一共有那些面試官能面)調(diào)整面試的種類和考點。
每個公司都有自己的面試風格昌阿,他們到底看重什么樣的技能和什么樣的人饥脑,以及以往都面過什么樣的題,你大可在glassdoor上面搜一下懦冰。當然每一個公司有那些利弊和面臨哪些問題灶轰,glassdoor上面也有。很多小公司其實很重視讓應試者提問的面試環(huán)節(jié)刷钢,特別是在后期面試的時候笋颤。因為這能看出來你到底有多了解你面的公司以及他們的市場,他們也會由此判斷你到底是真心想去呢内地,還是只想多拿一個offer以便跟別人談談價伴澄。
舉個例子,有一種Coding面試瓤鼻。它的目的不是考算法秉版,是考你能不能想明白一道邏輯相對比較復雜的題,寫出正確易讀的代碼茬祷,并且顯示出對測試和邊緣情況有良好的直覺清焕。適合面coding的題目大約有兩種:一種是模擬某種體系或游戲(某紙牌游戲或桌游、模擬某種簡單的流程),需要你充分理解一個相對復雜體系并且選擇合適的數(shù)據(jù)結構去表現(xiàn)它秸妥。另一種是一個運用很多語言基礎并有很多邊緣情況的題滚停,如數(shù)組和字符串的處理分析運用和正則表達式。目的是考你對你自己選擇的語言的熟悉度粥惧、也考你對測試和邊緣情況的習慣和直覺键畴。為什么重視這個?也許是因為每一個沒有考慮到或者測試到的bug或者邊緣情況會導致幾個月后有人很多晚上不能睡覺突雪。
這種面試有這么幾種常見的失敗原因:
思路問題
沒思路直接寫代碼起惕,然后代碼變成巨大一坨的nested while / for loop和好幾個實際上重疊的cascading if,最后自己被自己寫的東西繞暈咏删。其實你最該做的第一件事就是確保你正確理解了面試官給你的題目惹想。一種失敗模式是應試者解一個多玩家游戲,花了大量時間去寫出2玩家版的精確代碼督函,但是要最終寫n玩家版的時候發(fā)現(xiàn)2玩家的版本完全不能generalize嘀粱。這種情況其實可以不糾結于立刻寫代碼,可以花點時間確保你的解題思路正確辰狡、從而確保你的代碼分解比較合理锋叨,然后整段代碼很好讀。
光說不寫宛篇。這里的失敗模式是應試者做一個關于字符串運用的題娃磺,糾結了半天這個字符串到底是要從頭開始parse還是從尾開始parse,到底是要用遞歸(recursion)還是用while loop些己,到底要在哪個level of abstraction分成兩個不同的函數(shù)豌鸡,最后扔出了一堆聽起來很高大上可是這個簡單的題目根本用不到的算法和數(shù)據(jù)結構的名詞可是扯了30分鐘就是沒寫出一行代碼來。其實從頭parse還是從尾parse段标,本質(zhì)上沒那么大的區(qū)別涯冠。雖說能簡單iterate的東西你用遞歸有那么一點點非主流但只要你代碼干凈也沒人會歧視你。重點是30分鐘后白板上沒有代碼逼庞,你說出一朵花來也沒有用啊……
代碼可讀性蛇更、測試、和邊緣情況
代碼中off by one, array out of bounds, missing if cases, division by zero, empty string其實都是很容易犯的錯誤赛糟。我們自己容易看不清派任,但是經(jīng)常看我們寫代碼的人經(jīng)常比較容易可以看得到璧南。所以你一個函數(shù)寫完的時候掌逛,最好自己讀一遍看看有沒有這些bug。最好不用面試官提醒你就自己改掉司倚,如果全部代碼寫完了豆混,最好也不用人提醒篓像,自己拿一個輸入的例子把代碼過一下,看看有沒有漏掉的邊緣情況和bug皿伺。如果你覺得沒有员辩,最好也把你所有的假設重申一下,確保你跟面試官在同一條線上鸵鸥。比如假設你假定輸入必須是正數(shù)而面試官沒有給你這個假設的話奠滑,他就會認為這是你漏掉的邊緣情況。函數(shù)和變量的命名妒穴,其實不要求你在白板上長篇大論宋税,畢竟時間少寫字慢∷嫌停可是要避免的一種情況是自己把自己繞暈弃甥,然后在代碼里面出錯。這里的一個例子是應試者把數(shù)組的指數(shù)叫i
汁讼,數(shù)組的內(nèi)容叫curr
。本來要i%1000
阔墩,可是每次都寫成curr%1000
嘿架,但curr
其實是個字符串。這樣的無心之錯不是不可以有啸箫,但是如果太多耸彪,也許體現(xiàn)的是你函數(shù)和變量的命名有點問題,自己把自己繞暈了忘苛。這一類型的問題大多是小問題蝉娜,有一兩個無傷大雅,然而基本上是個減分的效果扎唾,積小成多召川,太多了也就致命了。
祝好運胸遇。