面試時前公司的技術可以講到什麼程度：在守住 NDA 的同時讓成果清晰的 6 階段框架

🆓 免費文章 · 任何人都可以免費閱讀

核心結論 面試中不能說的，不是電路圖、程式碼、數字，而是機密本身；必須說的，是問題的結構、本人的判斷、驗證方法。當成果故事不是以「做出了什麼」來講，而是以「在什麼條件下、如何決定了什麼取捨」來講時，就能在不違反 NDA 的情況下展現實力。用下面的 6 階段框架準備，即使是敏感專案，也能安全地、但不空洞地說明。

面試官真正想聽的，不是機密資訊

在半導體、EDA、設計驗證的面試中，應徵者最常犯的錯誤分為兩種。一種是因為擔心 NDA，把所有回答都以「很難詳細說明」作結。另一種則相反，直接把製程節點、區塊名稱、內部工具流程、客戶名稱、未公開的效能數字都說出來。這兩種都會成為被淘汰的理由。前者是沒有證明實力，後者則是給出訊號：這個人來到這家公司後，也會用同樣方式說話。

面試官的評估重點很明確。第一，這個人是否真的完整擁有過困難的問題，並做到最後。第二，結構化問題、提出假設並驗證的方式，是否可重現。第三，是否理解保密義務，並能自己設定界線。這三點，即使不說機密數字，也能充分證明。反而是不說數字也能說服人的應徵者，更能獲得信任。

特別是在 STA、Physical Design、DFT、驗證等與客戶專案、PDK、函式庫資訊交織的職務中，設定界線的能力本身就是職務能力。在面試中說明界線的行為本身，就展現了實務手感。

能說與不能說之間的界線

把界線分成「是否公開」與「可識別性」兩個軸，就會變得簡單。已經透過論文、專利、學會發表、產品頁面、徵才公告等公開的資訊，可以在以來源為前提的情況下談。反之，未公開的專案名稱、客戶名稱、內部代號、精確的時程與良率、電路拓撲的細部參數、原始碼與腳本原文、PDK 的非公開數字、尚未上市產品的規格，則不說。

模糊的領域最重要。例如「在 7nm 級製程中，負責包含大容量 SRAM 的 SoC 的 signoff」這種程度的泛化，通常被視為允許範圍。反之，如果把節點、廠商、產品系列組合起來，就能識別出特定專案，就必須再抽象化一層。用「先進製程」、「行動 AP 級複雜度」、「數億 gate 規模」等方式，給出規模感，但去掉識別資訊。數字也是如此。不用絕對值，改用比例與方向來講。不要說「把時脈從 1.83GHz 拉到 2.1GHz」，而是說「把相對於目標頻率不足的 margin，恢復到兩位數百分比的水準」，這樣成果傳達到了，機密也守住了。

面試官也有可能直接追問敏感資訊。這時不要以拒絕作結，而要提供替代說明。轉換成「那個數字我不能說，但當時的決策基準是這樣的」，評估就不會中斷。守住界線又延續對話，是核心技術。

打造出成果故事的 6 階段框架

下面的框架可以套用在任何專案。把每個階段用一兩句話準備好，就能調整出 3 分鐘版與 10 分鐘版的長度。

第 1 階段 — 脈絡 (Context)： 以泛化的方式說明是哪種產品、處於哪個階段。例：「處於即將量產的階段，signoff 品質會影響整體時程。」不要放入客戶名稱與代號。

第 2 階段 — 問題 (Problem)： 把觀察到的現象定義成可測量的形式。不要說「時序很差」，而要說「在特定 corner，setup margin 不足，而且原因尚未分離是 clock skew 還是 cell delay」。把問題定義好的經驗，本身就是實力。

第 3 階段 — 假設與分離 (Hypothesis)： 說明把原因拆開來驗證的方式。說明看了哪些報告、固定了哪些變數、做了哪些比較實驗。在這個階段，比起工具名稱本身，分析程序更重要。商用工具的一般功能是公開資訊，但公司專用腳本與流程的細部實作則不說。

第 4 階段 — 本人的決定 (Decision)： 說明兩三個替代方案與選擇的理由。面試官看的不是正解，而是取捨。是用更多面積換取路徑繞行、犧牲電力來增加 buffer，還是因為時程而限制 ECO 範圍，這類判斷是核心。不要用「團隊決定的」含糊帶過，要把本人主張的部分與其依據分開。

📩 在持續關注這個主題嗎？

財報·報告·HBM供需的後續分析，每天10:30（KST）寄到您的信箱。 免費訂閱 →

第 5 階段 — 驗證 (Validation)： 說明如何確認決定是正確的。提及重現條件、corner 與 mode 的範圍、迴歸測試、審查程序。在半導體工作中，說明驗證範圍，比說明做出了結果更能獲得信任。

第 6 階段 — 結果與回顧 (Result & Lesson)： 結果以比例與質性變化作結，回顧則以下次要改變的點作結。像「之後把同類型的問題做成檢查清單，讓它能在初期就被抓到」這樣的句子就足夠了。即使不誇大成果，也能成為留下學習的故事。

依職務而不同的敏感度

即使是相同的框架，每個職務要特別小心的地方也不同。RTL 設計者要避開微架構中具獨創性的部分與未公開的功能名稱，把故事移到介面與驗證觀點上會比較安全。Physical Design 與 STA 負責人，因為 PDK、函式庫、客戶流程很敏感，所以不用數字，改講方法論。DFT 負責人，比起測試覆蓋率的絕對值，更強調結構性限制與解決方式；驗證負責人，比起未公開錯誤對產品的影響程度，更強調建立假設直到找到錯誤的過程。

處理 EDA 工具的職務又不同。工具已公開的指令與一般用法可以說，但在客戶那裡看到的設計資料、內部重現案例、錯誤報告原文則不能說。以「在某個客戶的設計中……」開頭的句子，幾乎總是危險的。必須抽象化成模式，像「在大規模階層結構設計中，記憶體使用量急劇增加的模式……」。

不只在轉職面試，在準備學會發表、撰寫作品集、寫履歷 bullet 時，也適用相同基準。如果立下原則：履歷只壓縮放入故事的第 1、2、6 階段，第 3～5 階段在面試中口頭展開，文件外洩的風險也會一起降低。

如何回答常見的壓力問題

對於「不能告訴我具體數字嗎？」這個問題，回答「精確數字我不能說，但可以說明改善前後的相對變化，以及造成那個變化的方法」。對於「是哪個客戶的專案？」，提供替代資訊：「客戶名稱我不能說，但設計規模與複雜度大概是這個程度」。對於「能直接給我看那個腳本嗎？」，要堅定地說不行，但轉換成「不過我可以用流程圖說明該腳本所執行的驗證邏輯」。

重要的是態度。如果猶豫或過度道歉，反而會引起懷疑。事先定好界線的人，會簡短而平靜地回答。面試前先為自己的故事做一份禁用詞清單，現場出錯的機率就會大幅降低。專案名稱、客戶名稱、內部工具的公司內名稱、精確的節點與時程，是那份清單的基本項目。

反過來，向面試官提問時，也會展現相同的手感。避開刺探新公司機密資訊的問題，改問職務的問題類型與驗證文化、工具環境可公開的範圍，會比較好。守住界線的人，在提問中也會顯露出來。

FAQ

Q1. 履歷上可以直接寫前公司的專案名稱嗎？ 如果是已公開的產品名稱，或論文、專利中已知的範圍，就可以寫；但原則上不寫代號與未公開的專案名稱。以產品系列與角色為中心來寫，避免可識別的組合。

Q2. 在作品集中放入截圖或部分程式碼，說服力不會提高嗎？ 可能會提高，但風險大得多。公司內資料的截圖與程式碼，其所有權大多屬於公司。改用本人新做的範例程式碼與公開資料，來展現相同能力的替代作品集，會比較安全。

Q3. 面試官持續要求具體數字時，該怎麼辦？ 清楚說明一次界線，並提供替代說明。面對反覆要求，也要維持相同的語氣。這個情境本身，可能就是評估保密能力的過程。

Q4. 已經公開的學會論文中，我參與的內容可以說嗎？ 在已公開論文的範圍內，可以談本人的貢獻。但不要擴展到論文中沒有的後續數字，或內部版本的改善事項。

Q5. 職涯初期，故事看起來很小，該怎麼辦？ 不要誇大規模，把問題定義與驗證範圍具體化。即使是小區塊，只要假設分離的過程清晰，故事就足夠有力。

行動清單

• ☐ 選出 3 個主要成果，用 6 階段框架各寫成一頁
• ☐ 為每個故事另外寫下禁用詞清單（專案名稱、客戶名稱、代號、敏感數字）
• ☐ 把所有絕對數字改成比例、範圍、方向的表達
• ☐ 大聲練習 3 分鐘版與 10 分鐘版，並計時
• ☐ 事先準備好應對 3 種壓力問題的轉換句子
• ☐ 履歷只放入第 1、2、6 階段，細部方法留待口頭說明
• ☐ 面試後回顧自己說過的內容，檢查是否有越界的表達

📩 今天錯過的分析，明天早上寄到您的信箱

每天10:30（KST）Daily Silicon與財報·機構報告核心解讀搶先送達。訂閱後可選擇韓語/英語/日語新聞通訊，中文深度分析每日在網站更新。

免費訂閱 →

免費 · 無垃圾郵件 · 隨時退訂