Myth About Tech Hiring

Starting from many years ago I started to notice a very interesting trait in IT industry hiring (here by IT industry I mean positions that require extensive software coding) - the interviewer could potentially go straight into "let's solve some coding challenges" without much exchange of greetings. The process of the entire interview could concentrate on a very concrete and thought-intensive problem and you are expected to solve it in an unambiguous way by writing down your compilable code and explain why and how it works. This is unimaginable in even neighboring industries like electrical engineering, not to mention finance, consulting and other fields that pay more attention to soft skills. I am not saying that doing code challenges is the only component of all technological hiring in the IT industry (though in many cases it is the sole part), yet everybody working in this realm knows that if you show any signs of weakness in this part companies do not bother moving forward to assess other (glittering) facets of you.

The style of this type of hiring has incurred much criticism, especially by some senior level professionals who argue that coding at toy scale, no matter how proficient you can do, does not necessarily reflect your true engineering capabilities. In 2015 there was news that Google turned down Max Howell, the author of Homebrew, because he was "unable to flip a binary search tree on whiteboard", so ironic that someone who "created tools for Google engineers' daily use is denied a position in the company". From a logical point of view, it's hard to believe that guy could not code flipping a binary tree with bare hands. I would rather guess that such a trivial coding challenge made the coding guru irritated that the whole interview process became an unpleasant journey from then on.

Yet, given the scale of Google, such hiring process is fully understandable and almost inevitable to a giant tech business. Simply put, companies at the scale Google can afford to lose any talent. An optimized hiring workflow is all about hiring best talents statistically, and we all know that if something is statistical, there is no guarantee anymore - you could be the false positive or false negative. Recruiters are told to hire the best 10% in the job market, not Person XYZ who ranked No. 1 (in fame) in the industry.

Now we can take a look at how these tech giants, bearing in mind the goal to hire the best talents statistically, settled with the interview schemes we see today. Why are they so obsessed with coding challenges, some of which are even so hard and obsolete that you rarely think about and make use of in your daily work. A plausible argument to this is - these coding challenges test your fundamental knowledge. For example, how can you expect someone to comprehend and improve a distributed database system if he/she has no idea about implementing an in-order traversal of a binary search tree? But this viewpoint becomes vulnerable as coding challenges are evolving to be unprecedentedly difficult as time goes by. Nowadays, even recruiters recommend professional interviewees using several weeks "sharpening coding skills" before embarking on a real interview. The funny thing is - as a programmer who exercises coding at work each day, why would I be advised to devote extra time to prepare for a coding challenge? Superficially, it says at least two things. First, the code challenge is a digression from your work routine; second, the code challenge is hard and if you don't prepare well, you fail. This seemingly irrational coding challenge, I would argue, is actually quite effective in terms of being effectively selective. Remember the famous reasoning about a peacock's ostentatious tail that has no survival advantage in nature? It's all about show-off - if the peacock can live with such a useless drag without being preyed, it must have got incredible surviving skills. The same logic applies to here - if you are able to devote a couple of hours to interview preparation after work for several weeks (without being fired by your current employer), grasp so many coding gotchas and tricks, and perform well in 5 consecutive intensive interviews - wow, you are the smart, energetic guy we would want to hire! None the less, If you happen to belong to the fraction of people that do amazing things in big projects but perform awkwardly in coding challenges, sorry, life is too short (also too costly) to tailor our hiring process for you. In fact, a grueling hiring process not only filters down the most adaptive candidates (with regard to a fierce career competition) but also distills the group of people who are seriously considering a career move. After all, who would want to go through such daunting process if all they want is taking a random shot?

Back to Max Howell's rejection by Google, the implicit message Google conveyed to Mr. Max Howell might contain another fold - if you are mad at being asked to flip a binary tree on the whiteboard, we have reasons to believe you might have problems in executing your superordinate's instructions. Technology must be submissive to capital: this is called Capitalism.

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末含滴,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子谈况,更是在濱河造成了極大的恐慌,老刑警劉巖赡茸,帶你破解...
    沈念sama閱讀 219,490評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件治筒,死亡現(xiàn)場離奇詭異友多,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,581評論 3 395
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來拾酝,“玉大人材诽,你說我怎么就攤上這事脸侥∈。” “怎么了?”我有些...
    開封第一講書人閱讀 165,830評論 0 356
  • 文/不壞的土叔 我叫張陵,是天一觀的道長租悄。 經(jīng)常有香客問我,道長恩袱,這世上最難降的妖魔是什么畔塔? 我笑而不...
    開封第一講書人閱讀 58,957評論 1 295
  • 正文 為了忘掉前任谅辣,我火速辦了婚禮搓扯,結(jié)果婚禮上椎椰,老公的妹妹穿的比我還像新娘。我一直安慰自己沾鳄,他們只是感情好慨飘,可當(dāng)我...
    茶點故事閱讀 67,974評論 6 393
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著译荞,像睡著了一般瓤的。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上吞歼,一...
    開封第一講書人閱讀 51,754評論 1 307
  • 那天圈膏,我揣著相機與錄音,去河邊找鬼篙骡。 笑死稽坤,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的糯俗。 我是一名探鬼主播尿褪,決...
    沈念sama閱讀 40,464評論 3 420
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼得湘!你這毒婦竟也來了杖玲?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,357評論 0 276
  • 序言:老撾萬榮一對情侶失蹤忽刽,失蹤者是張志新(化名)和其女友劉穎天揖,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體跪帝,經(jīng)...
    沈念sama閱讀 45,847評論 1 317
  • 正文 獨居荒郊野嶺守林人離奇死亡今膊,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,995評論 3 338
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了伞剑。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片斑唬。...
    茶點故事閱讀 40,137評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出恕刘,到底是詐尸還是另有隱情缤谎,我是刑警寧澤,帶...
    沈念sama閱讀 35,819評論 5 346
  • 正文 年R本政府宣布褐着,位于F島的核電站坷澡,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏含蓉。R本人自食惡果不足惜频敛,卻給世界環(huán)境...
    茶點故事閱讀 41,482評論 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望馅扣。 院中可真熱鬧斟赚,春花似錦、人聲如沸差油。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,023評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽蓄喇。三九已至发侵,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間公罕,已是汗流浹背器紧。 一陣腳步聲響...
    開封第一講書人閱讀 33,149評論 1 272
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留楼眷,地道東北人。 一個月前我還...
    沈念sama閱讀 48,409評論 3 373
  • 正文 我出身青樓熊尉,卻偏偏與公主長得像罐柳,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子狰住,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,086評論 2 355

推薦閱讀更多精彩內(nèi)容