為什麼面試程式設計職位的問題這麼難？
我必須說，我討厭程式設計的面試問題。為什麼它們這麼難？
如果你曾經使用過 HackerRank 之類的工具或讀過一本編程面試問題的書，你可能會同意我的看法。是的，整個行業都圍繞著編程面試和準備而存在。
我討厭那些面試問題。在網絡上，並不是每個人都同意我的觀點。似乎很多人想要繼續這種“傳統”。
幾年前，我決定不再從事合同工作/自由職業，並參與了許多不同公司的招聘過程。
在我意識到我基本上是不可雇用之前，這是另一個故事。我所指的不可雇用，是指我除了為自己建立自己的產品和資產，而不是為別人建造產品，無法為任何其他人工作。
我申請的公司中有大約一半的公司都有進行實踐性的“在家完成”項目的初步篩選。
沒人要求我實現FizzBuzz，或者其他經常被描述為“必須知識”的算法。
我們可能被誤導以為每一個招聘過程都像在 Google 那樣。我讀到有人花了一年準備 Google 的面試，結果申請時被拒絕了。可悲。
有無數的小型和中型公司從不使用嚴格而乏味的技術面試，以白板為基礎，涉及算法和數據結構等主題。没有 Google 和（噢！）Stack Overflow。
當然，了解這些主題是很不錯的，我認為你應該真正了解它們。
我也明白其中的思維：這些問題基本上都一樣，只是有 10-20 個變化。實現冒泡排序。好的，我能做到。他們只是想聽你在這個主題上的推理方式。你如何處理這個問題。但實際上，這只是解釋你記住了一個問題的內容。如果求職者是剛畢業的話，他們可能會記得得很清楚。如果求職者有 5 年的實際工作經驗，他們可能不會記得了。
FizzBuzz 更合理。它不是在學校教的，這個問題可以在 3 分鐘內解釋清楚，而且你可以對它進行推理。
但是如果我負責組織我公司的招聘，可能作為一個 CTO，我永遠不會讓一個人站在白板前，讓他們實現FizzBuzz。為什麼？首先，這完全沒有用 - 你將永遠不需要在現實世界中實現它。
其次，這給應聘者帶來了很大的壓力。很多人在這種情況下表現不佳，我也是其中之一。我可能只能展示出我價值的 10%，因為我無法在這樣對我來說陌生的環境下很好地發揮作用。
DHH（David Heinemeier Hansson，超受歡迎的 Ruby on Rails 框架的創建者）曾經說過: “我在白板上寫冒泡排序會失敗”
這太糟糕了，也許只能用來測試應聘者的神經。這完全不同於測試一個人對公司的價值，如如果我正在招聘一名程序員，進行編程等測試。
你在傳統的白板面試中能解決的任何問題都與程序員的實際工作沒有任何相關性。
我必須思考一下我上一次花時間決定要使用哪些算法，更不用說實現一個全新的算法了。那麼為什麼人們總是被問到這些問題呢？
這是一個指出大公司也在朝著更好的方向發展的推文:
我們更新了發送給前端工程師候選人的內容，以更好地反映 Facebook 對這個職位的面試過程。我希望這能幫助人們準備他們的面試! pic.twitter.com/EvTyKbugYT
— Dan Abramov (@dan_abramov) February 12, 2019
實際知識。向我們要求這個。
我記得在一次面試中我得到了一個很酷的問題：描述一下當你進行 Google 搜索時會發生什麼。這是一個開放式的問題，並且它是一個關於網絡協議和發生的細微差別的對話的開始。這是一個聰明的問題。
沒有白板，因為這是一個遠程的 Zoom 通話。
另一次面試是基於我在 React 上實現的編碼挑戰，離線完成的。我有 7 天的時間（實際編碼只需要 3 小時就夠了）。招聘過程的剩餘部分都基於我在這個代碼上所做的工作。
所以，對於“為什麼面試程式設計職位的問題這麼難？”這個問題，我的答案可能是“因為公司的招聘過程有問題”，你或許應該思考“我真的想在那裡工作嗎”？
跳過面試不是更好嗎？最好的做法是有公司直接聯繫你去為他們工作。你可以用各種方式做到這一點：社交網絡是其中一種常見的方式。在會議上、在 Twitter 上、在 GitHub 上…有很多種方式。一旦你認識並保持與一個或多個公司的員工保持聯繫，下次有職位空缺時，你肯定可以列入候選人名單。尤其是他們認識你並珍視你的價值。
總之，這只是我的簡單意見。