面試之站在面試官的角度去面試

2021-06-26 17:46:47 字數 3056 閱讀 4729

就是這些了。符合這樣標準的人就是我們公司需要的員工了。 記住這條標準。 每天**前背誦這條標準。我們公司的目標之一就是僱傭擁有這樣的潛質的人,而不是僱傭懂某些技術的人。任何人所擁有的某些具體技術都會在幾年內過時,所以,僱傭有能力學習新技術的人,要比僱傭那些只在這一分鐘知道sql程式設計是怎麼回事的人對公司更划算一點。

有頭腦確實是乙個很難定義的品質。但是讓我們看一些在面試時能提問的一些問題,通過這些提問,我們可以找出擁有這種品質的人。完成工作非常關鍵。看起來有頭腦但是不能完成工作的人經常擁有博士學位,在大公司工作過,但是在公司中沒有人聽他們的建議,因為他們是完全脫離實際的。比起準時交活兒,他們寧願對於一些學院派的東西沉思。這些人由以下特性而可以識別出來。他們總是愛指出兩個根本不同的概念間的相似性。例如,他們會說「spreadsheets是一種特殊的程式語言」,然後花乙個禮拜寫一篇動人的,智慧型的***。這篇***論述了,作為乙個程式語言,spreadsheet關於計算語言特性的方方面面。聰明,但是沒用。

現在,我們來談談完成工作但是沒有頭腦的人。他們愛做蠢事。從來也沒有考慮過將來得靠他們自己或者別的什麼人來亡羊補牢。通過製造新的工作,他們成為了公司的負債而不是資產。因為他們不僅沒有為公司貢獻價值,還浪費了好員工的時間。這些人通常到處貼上大堆的**,而不願意寫子程式。他們是完成了工作,但是不是以最聰明的方式完成工作。

面試時最重要的法則是: 

做決定介紹

應試者參加過的專案

無法回答的問題

c語言函式

你滿意嗎?

設計問題

挑戰你還有什麼問題?

能認真地去解釋事情。某些人被我拒掉的原因就是他們不會用普通人能明白的語言去解釋他們做過的專案。很多任務科專業的人總是以為所有人都知道bates理論(譯者注: bates theorem,一種經濟學的理論)或者peano公理組(譯者注: peano's axioms,數論中的一些定理)是什麼。如果應試者開始滿口行話了,讓他們停一停,然後你說,「能幫我個忙嗎?就是為了練習一下,你能把剛才說的用我老祖母也能理解的話說一遍嗎?」但即便如此, 有些人還是繼續用那些術語, 而且根本沒法讓人明白他們在說什麼。天哪!

如果這個專案是乙個團隊專案,看看他們是否在有承擔領導責任的跡象?乙個應試者可能會說:「我們用的是x方法,但是老闆說應該是y,而客戶說應該是z。」我會問,「那麼你怎麼做的?」乙個好的回答可能是「我設法和團隊中別的人開了個會,然後一起搞出個辦法...」壞的回答看起來象,「嗯,我什麼也不能做。這樣的問題我解決不了。」記住,聰明並且能完成工作。要搞清楚某人是否能完成工作的乙個辦法就是看看他(她)過去是否傾向於完成任務。事實上,你可以主動要求他們給你個例子證明他們能擔任領導作用,完成任務。-例如克服公司的陳規陋習。

現在我們談談清單上的第三款,無法回答的問題。這很有趣。這個主意的關鍵在於問一些不可能有答案的問題,就是想看一下應試者怎麼辦。「西雅圖有多少眼科醫生?」「華盛頓紀念碑有多重?」「洛杉機有多少加油站?」「紐約有多少鋼琴調音師?」

關於程式設計問題,我通常要求應試者用c語言寫一些小函式。以下是我通常會出的題目: 

注意,通常你不會希望他們寫的**多於5行,因為你沒有時間理解太長的**。

現在我們來詳細看一看其中幾個問題: 第乙個問題: 逆序乙個字串。我這輩子還沒有見過那個面試者能把這題目一次做對。所有的應試者都試圖動態生成緩衝區,然後將逆序的字串輸出到該緩衝區中。問題的關鍵在於,誰負責分配這個緩衝區?誰又負責釋放那個緩衝區?通過這個問題,我發現了乙個有趣的事實,就是大多數認為自己懂c的人實際上不理解指標和記憶體的概念。他們就是不明白。這真叫人吃驚,無法想象這種人也能做程式設計師。但他們真的就是!這個問題可以從多個角度判斷應試者:

第三個問題可以考考面試者對c的位運算的掌握,但這是一種技巧,不是一種品質,所以你可以幫助他們。有趣的等他們建立了乙個子函式用來計算byte中為1的位的數目,然後你要求他們優化這個子函式,盡量加快這個函式的執行速度。聰明的應試者會使用查表演算法(畢竟這個表只有 256個元素,用不了多少記憶體),整個表只需要建立一次。跟聰明的應試者討論一下提高時間/空間效率的不同策略是十分有意思的事情. 進一步告訴他們你不想在程式啟動時初始化查詢表。聰明的面試者可能會建議使用緩衝機制,對於乙個特定的byte,只有在第一次被查詢時進行計算,然後計算結果會被放入查詢表。這樣以後再被查詢時直接查表就行了。而特別特別聰明的面試這會嘗試有沒有建立查詢表的捷徑,如乙個byte和它的置1的bit數之間有沒有規律可循? 

當你觀察應試者寫c**時,以下一些技巧會對你有幫助: 

不可避免的,你會在他們的程式中發現bug,於是我們現在來到了第五個問題:你對**滿意嗎? 你可能想問,「好吧,bug在**?」這是來自地獄的一針見血的問題,要回答這個問題可要大費口舌。所有的程式設計師都會犯錯誤,這不是問題。但他們必須能找到錯誤。對於字串操作的函式,他們通常會忘記在輸出緩衝區加上字串結束符。所有的函式,他們都會犯off-by-one錯誤(譯者按:指的是某個變數的最大值和最小值可能會和正常值差1)。他們會忘掉正常的c語句結尾的分號。如果輸入是零長度字串,他們的函式會執行錯誤。如果malloc呼叫失敗而他們沒有為此寫好錯誤處理**,程式會崩潰。一次就能把所有事情做對的程式設計師非常,非常,非常地少.不過要是真的碰上乙個的話, 提問就更有意思了. 你說,"還有bug"。他們會再仔細地檢查一遍**。這個時候, 觀察一下他們內心是否開始動搖了, 只是表面上勉強堅持說**沒有問題。總之,在程式設計師寫完**後,問一下他們是否對**滿意是個好主意。就像regis那樣問他們!(譯者按,regis philbin是美國abc電視網的遊戲電視節目主持人,他的口頭禪是「這是你的最後的答案嗎?」)

第六部分:關於設計的問題。讓應試者設計某樣東西。jabe blumenthal,excel的原始設計者,喜歡讓應試者設計房子。jabe說,曾經有乙個應試者跑到白板前,畫了乙個方塊,這就是他的全部設計。天哪,乙個方塊!立刻拒絕這樣的傢伙。你喜歡問什麼樣的設計問題?

於是我們來到了第七部分,挑戰。這部分很好玩。在面試中留心一下, 當面試者的回答絕對的百分之百毫無爭議時, 你可以說: " 嗯, 等一下等一下." 然後花上兩分鐘玩一下魔鬼的遊戲(譯者按,原文為devil's advocate,魔鬼代言人指的是違背自己的良知,為錯誤**的觀點辯護). 記住一定要在你可以肯定他正確時和他爭論。

這個很有意思.  

軟弱的應試者會屈服。那我就和他說拜拜了。

堅定的應試者會找到乙個辦法說服你。他們會以甘迺迪**的口才來說服你,「也許我誤會了你的意思,」他們這樣開頭,但是正文仍是堅定地站穩立場。這樣的人我就僱傭。

站在面試官角度看面試

當你走近會客室,面試過程就開始了,當然你得不卑不亢,謙虛謹慎,除了這些放之四海皆準的原則,你還應該知道。面試就是個溝通,讓對方認識到你的實力,並且你也了解到是否喜歡並且能做這個工作,後者可能很多人沒有意識到。溝通很奇妙,每個人都說自己能很好的和別人溝通,在面試官看來,溝通不是讓你不停的附和或者滔滔不...

面試你的面試官

大多數面試都是面試官從簡歷,學歷,經歷,技術,為人上對你 乙個求職者 一番拷問,以確定是否是他們想要的人。而這些對找到適合你的工作的確沒什麼用。某公司某職位需要你,而某公司某職位不一定是你想要的!如果你想找到適合你的公司 如果你想找到適合你的職位 記得面試你的面試官,沒錯!做出很重要的職業決定前,面...

面試官感悟

其實之前也面試過幾個人,但都是零星的跟著別人一起,我也只是偶爾詢問一兩句就結束了。昨天這是一場真正的大型招聘會,而且面試也是相當規範,面對的還是社招。對於我這種初出茅廬來說,這是第一次真正接觸參與的一場招聘會,想起要面那些比自己工作年限還長的人,心裡很沒底,有點小擔心和緊張的。當然一整天下來也算體驗...