如何通過 HackerRank 面試？

招募方看到的分數不只是通過或不通過。一份 HackerRank 測驗會同時回報好幾項內容，了解哪些指標是各自獨立變化的，會改變你分配時限的方式。

• 通過的測試案例數。每道題都會針對可見的範例案例和更大的隱藏案例集執行。空輸入、單一元素、重複項和最大規模資料都藏在隱藏案例集裡。大多數失分來自邊界情況，而不是演算法本身寫錯了。
• 部分得分。計分通常按每個測試案例計算，所以一個正確但較慢的解法也能拿到實實在在的分數。而一個沒有提交的完美解法則一分都拿不到。
• 時間與記憶體限制。如果題目設定了限制，效率不高的解法會在大規模隱藏案例上逾時，即使它通過了每一個範例案例。
• 監考報告。切換分頁、失去焦點、貼上事件，以及在開啟相關功能時的網路攝影機截圖，都會附加在你的提交記錄中供招募方查看。

其他招募平台在各個環節分別測試什麼，可以參見招募平台專題頁。

你明明已經掌握了演算法，上次卻依然丟了分，這感覺就像練習都白費了。這一節要談的是環境層面而非能力層面的問題。大部分可以挽回的分數就藏在這裡，而且挽回它們的成本很低。

• 在 HackerRank 編輯器裡練習。它不是你的 IDE。沒有你習慣依賴的自動完成，沒有除錯工具，你的快捷鍵設定也都不存在了。在真正上場之前，先在裡面完整做幾道題。
• 了解輸入範本。有些題目會給你一個已解析好的函式簽章，有些則需要你自己從標準輸入讀取。讀錯輸入範本是一種常見的失誤方式——即便邏輯完全正確，也會導致每一個測試案例都失敗。
• 選擇你偵錯速度最快的語言，而不是看起來最厲害的那種。能通過測試才是衡量標準。
• 先寫暴力解法並提交，再做優化。在時限耗盡之前先把部分分數鎖定，是投報率最高的一個習慣。
• 手動測試邊界情況：空輸入、單一元素、全部相同、最大規模。

設想一位後端工程師正在準備一場平台團隊的電話面試。他先前解決過類似的底層問題，卻在測驗的前一段時間一直在和輸入解析範本較勁，最終只提交了一份解法而不是三份。他的演算法知識從來都不是那個瓶頸。

CodePair 是一個共用編輯器，通話中會有真人在場，這讓它更像是一場圍繞程式碼展開的對話，而不是一次測驗。計分依據的是面試官的主觀判斷，沉默在這裡會顯得很不利。

• 複述題目並在動手寫程式碼之前確認清楚限制條件。
• 先把思路說出來，包括你曾經考慮過但否決掉的方案，以及否決的原因。面試官會為推理過程計分，一個被否決的方案本身就是推理能力的證據。
• 邊說邊寫。長時間的沉默是面試官對這一環節最常提到的抱怨。
• 把你的測試案例講出來。主動走一遍邊界情況，傳遞出的用心程度與非同步環節中隱藏測試所衡量的是同一回事。
• 優化之前先問一句。很多時候面試官想要的是能跑通的版本外加一段複雜度討論，而不是最優解。

模擬面試模式正是用來練習這種大聲表達思路的能力的，因為這裡的失敗往往出在表達上，而不是演算法本身。

在這個問題上說清楚，比給出一個行銷式的答案更重要。

• 受監考的 HackerRank 測驗不在適用範圍內。監考系統會記錄切換分頁、失去焦點、貼上事件和網路攝影機畫面。螢幕共用、螢幕錄製、受監考的環境，以及公司管理的電腦，都是任何助手都不適用的場景，SubcueAI 也從不這樣宣稱。
• 適用的場景是準備階段。提前進行大聲練習的模擬環節，能培養出 CodePair 環節所考核的表達習慣。
• 圍繞程式設計環節展開的行為面試和系統設計對話，都是在普通會議軟體上進行的普通面試，而這正是 SubcueAI 所面向的場景。

該平台能看到什麼、不能看到什麼，在可偵測性專題頁上有更詳細的說明。