工程師面試簡報範例：用軟體專案講清楚架構、取捨與成果

工程師面試簡報可以從一個你親自參與、能回答追問的軟體專案開始。先說使用者遇到什麼問題，再用架構、替代方案、測試與成果證據，讓聽眾看見你的決策。下面以六張投影片示範：問題、限制、架構、取捨、成果、復盤。頁數是本文的練習安排，實際時間與格式仍以邀請為準。

如果你已有專案素材，可以先用 專案深挖：技術選擇、商業邏輯與責任 練習回答，再把答案整理成投影片。連結是英文練習題；本文的繁體中文範例則直接展示每頁要放什麼、怎麼講，以及哪個追問會暴露證據不足。

哪些是官方要求，哪些只是準備建議？

官方資訊：Microsoft 的技術面試說明包含問題解決、設計、Coding、測試，也提到過往經驗與技能應用。這支持「準備專案中的具體決策」這個方向，但該頁沒有規定所有軟體工程師都必須做六頁簡報。不能把本文模板當成 Microsoft 或其他公司的固定關卡。Microsoft 技術面試說明

個人經驗資料：104 於2024年刊出的文章，由作者轉述資料科學領域的交流經驗，提到有些面試會要求說明論文或專案，並建議預想每頁追問。這是特定領域、較早的經驗分享，不是台灣所有工程師的現行招募規則，也不是兩份獨立、同一招聘期的候選人報告。104：資料科學面試準備

本文的推論與練習建議是：當招聘方要求專案簡報時，用一個完整案例呈現決策，比堆疊多個只講得到表面的成果更容易展開技術討論。以下的「非同步CSV匯出」專案、分工、限制與數字全部是虛構教學範例，不是候選人的真實履歷，也沒有實際執行該系統的效能測試。請換成自己能證明的內容。

開始製作前，向招聘方確認時長是否包含問答、可否用投影片、聽眾角色、語言，以及是否需要展示程式。若只要求口頭說明，就保留同一條故事線，不必強行分享投影片。簡報是承載證據的工具；格式確認會決定哪些細節放主線、哪些留在備用頁。

先選能講清楚的專案，再選漂亮的模板

挑選專案時，先寫下自己做過的決策、可以展示的證據，以及仍記得的失敗。假如某個專案規模很大，但你只調整一個畫面，不要把整套平台設計都說成自己的責任。你可以深入講那個畫面的狀態管理、錯誤復原與測試；範圍小而完整，仍然有技術內容。

在教學案例中，營運人員需要匯出資料。原本的HTTP請求要等CSV產生完成才回應，資料量增加後常碰到等待上限。團隊考慮把匯出移到背景處理。假設你的責任是任務API、狀態轉移與故障測試，同事負責前端輪詢，平台團隊負責儲存權限。這個分工必須出現在簡報裡，而不是被一個「我主導」概括。

若是學校或個人專案，就直接說使用者數、部署方式與測試環境。「我在本機驗證了重複請求」與「系統曾承受真實尖峰流量」是不同的證據。沒有商業成果時，可以展示需求修改後的實作差異、測試發現的缺陷、回復流程或使用者回饋，不需要捏造流量與營收。

六張投影片：每一頁都帶出一個決策

下面的頁面標題可以直接作為排版起點，但內容必須替換成你的真實專案。先把每頁標題寫成一句可辯護的結論，例如「背景處理讓使用者能追蹤任務」。再只放能支持該結論的圖、比較或數據；完整程式碼、所有欄位與測試紀錄留在備用資料。先讓面試官理解主線，再沿著問題深入。

第一頁：使用者需要知道匯出何時完成

投影片範例文字：營運人員發起大量CSV匯出時，等待畫面可能超時；重按按鈕又可能造成重複工作。目標是讓每次匯出有可查詢的進度與明確的完成或失敗狀態。

畫面可以放「按下匯出→長時間等待→不知道是否重試」的三格流程。口頭補充：「我們先處理使用者無法判斷任務狀態的問題，再評估生成檔案本身的速度。」這句話把產品困擾與技術目標接起來，也避免把非同步當成萬用效能解法。

預期追問：「你怎麼知道這是重要問題？」真實簡報應放經核准的客服案例、失敗紀錄或使用者訪談摘要。如果手上只有自己的觀察，就說它是待驗證的假設，不能改寫成大量客戶回報。第一頁不需要列出整個公司的產品線。

第二頁：可靠接受任務，比立即算完更重要

投影片範例文字：已接受的任務要能查到狀態；同一提交重試不得建立第二份邏輯任務；暫時性故障可重試，但不能永遠重試。使用者只可存取自己有權下載的檔案。

這一頁同時列出你的責任：任務API、狀態模型、重複請求處理、故障測試。旁邊標出同事與平台團隊的部分。口頭說明：「我提出了狀態轉移與冪等性契約，和前端同事確認輪詢需要哪些欄位；儲存權限設計由平台團隊審查。」提案、實作與批准是三種不同的工作。

預期追問：「為什麼不直接延長HTTP逾時？」你可以回答它是可比較的方案：改動少，但連線仍然被長工作占用，而且使用者重試與進度查詢的問題尚未解決。不要只說「非同步比較好」；把選擇連回這一頁的限制。

第三頁：圖上的箭頭，要能說明成功與失敗

投影片範例是一條精簡路徑：瀏覽器提交→API驗證→任務表；背景工作者領取任務→產生CSV→物件儲存；API再從任務表回傳狀態。為了讓範例集中，本版用資料庫任務表供工作者輪詢，不另外畫一個沒有解釋一致性的訊息佇列。

API先驗證請求與權限，在資料庫提交任務紀錄後回傳Job ID。工作者以原子方式取得處理權，讓同一任務在當下只有一個有效的領取版本；租約到期不代表舊程序已停止，因此仍須防止舊版本提交結果。任務紀錄包含狀態、嘗試次數、領取版本與租約期限。若工作者停止回報，租約到期後可由下一次嘗試接手；更新結果時比對領取版本，避免舊工作者覆寫新的狀態。

口頭帶讀時，先走一次成功路徑，再挑一個故障：「若檔案上傳成功，但寫回完成狀態前程序退出，重試怎麼辦？」本例讓每次嘗試使用獨立物件路徑，只有成功提交到任務紀錄的路徑會對使用者可見。落單檔案之後清理，下載請求仍要驗證權限。這不是宣稱工作只執行一次，而是控制哪個結果可見。

還要說明資料來源的邊界。若使用者要求某一時點的一致資料，本例在重試時必須讀取同一份固定輸入快照；否則應明確定義為各次嘗試讀到的資料。不要只靠一個Job ID就宣稱CSV內容永遠相同。你可以把快照成本留作備用頁的取捨。

預期追問：「流量增加十倍時，先壞在哪裡？」可以提出待測假設，例如資料庫掃描待處理任務、CSV讀取或物件上傳；再說會用查詢時間、排隊時間與工作者利用率定位。沒有負載測試時，就不要把猜測包裝成已驗證瓶頸。

第四頁：比較兩個真正可行的方案

投影片範例用三欄呈現需求、選擇與代價。重點是讓聽眾看見你為什麼接受某種成本，不是把沒選的方案寫得一無是處。

決策	本例的選擇與理由	接受的代價
同步等待或背景工作	背景處理讓使用者查詢獨立任務狀態	多出狀態API、工作者與回復流程
任務表或獨立訊息佇列	任務表減少初期跨系統寫入協調	要處理領取競爭、索引與輪詢負載
相同提交如何辨識	以使用者範圍內的冪等鍵識別邏輯提交	要定義鍵的期限，以及同鍵不同內容的拒絕行為

口頭補充：「如果任務量增加到輪詢與領取成為瓶頸，我會再比較訊息佇列，但也會一起設計任務紀錄與訊息發布的一致性。」不要直接加一個服務名稱，就跳過資料庫已寫入但訊息沒送出的情況。本例的冪等鍵以「使用者＋鍵」建立唯一約束，檢查內容並在同一交易中建立任務；並行提交不能只靠先查再寫。AWS 的技術文章也討論了呼叫者提供識別碼，以及記錄識別碼與變更的原子性，但不代表本文設計已在AWS驗證。AWS：安全重試與冪等API

預期追問：「你有沒有選錯過？」可以談真實曾遺漏的條件。套用本例，就是起初只測正常完成，後來發現必須測狀態寫回前的中斷。若這只是你現在想到的風險，請說是復盤發現，而不是杜撰一次正式環境事故。

第五頁：成果必須保留量測起點與分母

成果頁最容易把不同數字放在一起，製造不存在的改善。同步版回應的是「檔案生成完畢」，非同步版快速回應的是「任務已接受」。兩者即使都叫API latency，也不是同一件事。

下表全部是虛構數字，用來示範怎麼報告。假設在相同資料快照、相同資源配置與相同請求排程下，每版接受100筆任務，各筆輸入皆為10萬列，並讓每筆任務都有完整的120秒觀察窗。這些條件只是教學設定，本文沒有執行這項基準測試。

指標	同步版示例	背景版示例	可支持的說法
接受請求至取得可查詢Job ID	未提供此能力	p95為0.2秒	使用者較早取得可查詢的任務識別
提交至檔案可下載，成功任務的p95	18秒	19秒	本例沒有顯示檔案更快產生
120秒內完成／已接受任務	92/100	99/100	本次示例的限時完成率增加7個百分點

第一列不能計算成「從18秒降到0.2秒，所以匯出快了90倍」。第二列只對成功任務計算分位數，失敗的八筆與一筆必須另外保留；否則慢任務被排除，也可能讓數字看起來更好。第三列要說明每筆是否只計一次、何時算接受、取消如何處理，以及超過120秒是否算未按時完成。

預期追問：「完成率差異真的是你的設計造成的嗎？」一次比較只能支持有限結論。真實測試要保存負載、版本、快取條件、重試設定與原始樣本，再重複量測並檢查差異是否穩定。若同時換了硬體與查詢方式，就要把干擾因素說出來。沒有實驗證據時，可以說觀察到改善，不能直接斷言唯一原因。

第六頁：下一步要由目前的限制推導

投影片範例文字：本版建立了任務狀態與回復契約；仍需驗證領取競爭下的吞吐、落單檔案清理，以及權限變更後的下載行為。下一個優先項目是把故障注入與回復結果放入持續測試。

口頭收尾可以是：「如果重新開始，我會先定義提交、接受、完成三個時間點，再寫效能目標。架構改成背景處理後，我們需要追蹤整個任務，而不只看HTTP成功率。」這比「學到溝通很重要」更能顯示哪個判斷已改變。

預期追問：「如果只能多做一件事？」依風險選擇能驗證契約的工作。例如先測工作者中斷後是否有任務永遠停在處理中，再做不影響正確性的介面美化。真實優先順序仍需連回使用者影響與團隊限制。

讓成果頁經得起追問的四格備用卡

為每一個重要結論準備四格：證據從哪來、量測條件、你做了什麼、還不能證明什麼。這張卡不一定投影出來，但它會暴露簡報中的空白。若「提升可靠度」那一格只有一張成功畫面，就補上失敗路徑與回復結果，或縮小你的結論。

宣稱	可準備的證據	還不能直接推論
重複提交不產生第二個邏輯任務	同使用者、同鍵同內容，以及同鍵不同內容的並行測試	所有外部副作用只發生一次
工作者中斷能回復	領取後、上傳後、狀態提交前的中斷測試	所有網路分割和故障組合都已覆蓋
個人負責核心設計	經核准可分享的提案摘要、測試與修改紀錄	同事的工作也都是自己完成
完成率有改善	同一分母、觀察窗與負載下的原始結果	正式環境與所有使用者都會有相同比例的改善

如果被問到不記得的數字，可以回答：「我記得量測的是提交到可下載的時間，但不確定當時p95的確切值；我能先說明如何取得樣本與排除失敗任務。」手邊沒有完整指標時，仍可清楚說明測量方法、已知結果與缺口。不要用臨時編出的精確值填補停頓。

控時、保密與沒有投影片時的版本

如果招聘方給十分鐘報告、另外留問答，本文建議第一、二頁合計兩分鐘，架構兩分鐘，取捨兩分鐘，成果兩分鐘，復盤與收尾兩分鐘。這是排練配置，不是公司規則。若十分鐘包含問答，就先縮短主線，而不是等到最後一頁才發現沒有討論時間。

排練時請朋友在第三頁打斷，要求你解釋重試；回答後用一句話接回主線：「這是我們接受背景處理額外複雜度的原因，下一頁比較它和同步方案。」能從不同位置進出故事，通常比背熟每句講稿更實用。英文面試也可先練核心句：「The request is accepted, but the export is not ready yet.」技術名詞後面接行為，能減少歧義。

保密版本應保留推理，但移除公司機密、客戶識別與未獲准分享的數據。可以用抽象元件、公開可用的練習資料，或經批准的正規化數值，並明示處理方式。若抽象後已無法說明核心決策，選另一個專案；不要拿不相關的公開圖假裝成自己原系統。

最後準備一段不看投影片也能說的開場：誰遇到什麼問題、你負責什麼、哪個取捨最難、結果由什麼證據支持。需要更完整的口頭追問路徑，可接著閱讀 軟體專案深挖指南。以下英文題目可分別用來檢查責任、取捨與復盤；它們不是任何公司的統一簡報評分表。

完整練習題目（英文）	可檢查的簡報內容
Resume Project Deep Dive: Tech Stack Choices, Trade-offs, Business Logic and Ownership	確認技術選擇、商業邏輯與個人責任連成一條主線。
Project Deep Dive: Proving Technical Depth and Cross-Team Alignment	用具體決策說明技術深度與跨團隊協作。
Design and explain your project architecture	不看稿重畫架構，說明成功和故障路徑。
Walk Through Your Proudest Project, What Made It Special, and What You Would Change	講清楚專案價值與重新來一次會改的決定。
Senior Project Deep Dive: Design Rationale, Your Most Complex Project, Questions for the HM	為資深職缺準備設計理由，以及對主管的具體問題。

完成排練後，刪掉無法回答「為什麼」的裝飾性內容，補上最薄弱的一項證據。讓每張投影片都能指向一個你做過的決策、一項可說明的結果，或一個誠實保留的限制，能幫助你檢查簡報是否準備完整。本文範例不代表公司評分標準，也不能代替真實專案證據。

Sources and Further Reading

• Microsoft：Technical interviews，官方技術面試說明
• 104職場力：資料科學家面試經驗與準備，2024年個人交流經驗文章
• AWS Builders’ Library：Making retries safe with idempotent APIs