在即時程式設計面試中使用 AI 助理

你可能擔心即時程式設計面試裡的 AI 助理要麼是魔法、要麼是陷阱。本節解釋它在 45 分鐘程式設計回合中究竟做什麼，以及哪些工作仍然得由你自己完成。一句話：它負責聆聽、轉錄與建議——它不會替你打字。

在 Zoom、Google Meet 或 Microsoft Teams 上的典型程式設計面試中，面試官會朗讀或貼上一道題目，然後看著你在 CoderPad、HackerRank 或 Google Doc 這類共享編輯器裡作答。像 SubcueAI 這樣的助理會同時擷取你的麥克風與面試官的系統音訊，即時轉錄題目，並在你自己螢幕上的浮動視窗中給出候選人一側的建議——一個該問的澄清問題、一種暴力解法、一段複雜度分析，或一份程式碼骨架。

你仍然要自己讀題、提出澄清問題、講清取捨並親手寫程式碼。這個助理更像一位飛快地在你耳邊低聲提示的結對程式設計夥伴，而不是替你解題的自動完成。想更深入了解音訊擷取管線，參見 工作原理專題。

最常見的翻車方式就是把浮動視窗的內容照著唸出來。面試官能察覺到長時間的停頓、用詞的突然變化，以及答非所問、忽略他們剛提出的追問。幾個有幫助的習慣：

• 先開口，再瞥一眼。在看任何建議之前，先用自己的話把題目複述一遍。
• 用它來梳理結構，而不是照搬句子。讓它提醒你用哪種模式（two pointers、monotonic stack、topological sort），程式碼自己寫。
• 把複雜度分析換成自己的話。如果浮動視窗顯示 O(n log n) due to sorting，先說清為什麼需要排序，再給出這個上界。
• 面試官打斷時就別看它。先回答房間裡的那個人；建議還會在那兒。

設想一位後端工程師正在面試某公有雲廠商的 L5 職位。題目是區間合併的一個變體。她沒有從頭到尾唸浮動視窗給出的解法，而是問了兩個她本來就想到的澄清問題，在共享螢幕上勾勒出暴力解法，只在確認零長度區間這個邊界情況時瞥一眼浮動視窗。整場面試聽起來就是一次正常而出色的發揮，而不是一段背誦。

即時程式設計面試形態差異很大，助理的有用程度也相差很多：

• 很合適：在 Zoom、Google Meet 或 Microsoft Teams 通話中，你共享一個瀏覽器分頁開啟 CoderPad、HackerRank、LeetCode 或 Google Doc，面試官看著你打字。
• 部分合適：白板式回合，你只口頭講解程式碼而不執行——助理能幫你梳理結構與複雜度，但所有書寫都由你完成。
• 不合適：有監考的平台（HackerRank proctored、CodeSignal certified、Karat）、要求你共享整個螢幕而非單個分頁的面試、被螢幕錄製軟體錄下的帶回家測試，或者在公司統一管理、無法安裝軟體的筆電上進行的面試。

SubcueAI 是原生的 macOS 或 Windows 應用程式——沒有會加入通話的會議機器人，也沒有瀏覽器擴充功能。浮動視窗只存在於你本地的機器上。這種設計避免了機器人參會者那些明顯的破綻，但它並不能繞過螢幕共享或監考軟體。完整而誠實的限制清單請見 可偵測性專題頁。

SubcueAI 創辦人 Aaron Cao 在設計這款桌面應用程式時秉持一個理念：候選人在程式設計回合中要操心的事已經夠多了，所以設定應該一次做好、然後就拋諸腦後。一份合理的面試前清單：

• 提前一天就安裝並登入，而不是通話前五分鐘才弄。
• 用你真實面試將要使用的同一個平台（Zoom、Google Meet 或 Microsoft Teams），和朋友做一次彩排。
• 確認麥克風與系統音訊都在被擷取——面試官的音訊才是驅動轉錄的關鍵。
• 把浮動視窗放在第二台螢幕上，或放在你瞥一眼就能看到、而眼神不會明顯移動的角落。
• 專門用一次模擬練習不使用它，這樣萬一出問題你也有退路。

分步的安裝與音訊設定見 教學頁，方案與額度詳情見 價格頁。