「講一次你在時間壓力很大、或多個任務同時逼近的情況下完成任務的經驗」是行為面試的高頻題。它表面問「你抗壓嗎」，真正考的是：你會不會優先排序？能不能在資源/時間不夠時，分清什麼最重要、砍掉什麼、並把取捨講清楚？
最容易講壞的方式：① 「我就是拼命加班把全部做完」——這不是能力，是沒有策略（而且不可持續）；② 「我每件事都做到完美」——顯得不懂取捨、不切實際；③ 把壓力歸咎於別人（都是同事拖累）。好的版本要展現一套優先排序的方法：判斷輕重緩急 → 砍範圍不砍品質 → 主動溝通預期 → 交付最關鍵的。
這篇用一次「趕死線」的專案示範，怎麼用 STAR 把它講成展現判斷力的故事。
先記住：壓力題的「加分訊號」
| 訊號 | 反例 | 加分的講法 |
|---|---|---|
| 優先排序 | 「我全部都做」 | 「我先判斷哪個影響最大、先做它」 |
| 砍範圍不砍品質 | 「品質我打折」 | 「我砍掉非核心功能，但核心做到穩」 |
| 主動溝通預期 | 默默硬幹 | 「我提早跟關係人對齊『先交什麼』」 |
| 保持冷靜有系統 | 慌亂救火 | 「我把任務列出來、按影響/急迫排序」 |
💡 核心心法：壓力題的主角不是「壓力多大」，而是**「你如何用優先排序把有限的時間，投到影響最大的地方」**。展現「會判斷、敢砍、會溝通」這條線，就是高分。
一個好用的排序框架（講故事時可帶出）
- 影響 vs 急迫（艾森豪矩陣）：重要又急迫 → 先做；重要不急 → 排程；急但不重要 → 委派/簡化；不重要不急 → 砍。
- MoSCoW：Must（必須）/ Should（應該）/ Could（可以）/ Won't（這次不做）——壓力下保住 Must、砍掉 Could/Won't。
- 砍的是「範圍」，不是「品質」：核心功能要穩；非核心功能延後或拿掉。
逐字稿示範（中文，~370 字）
數字、情境為示範用，練習時換成你自己的真實經歷。
「【S】 有一次我們的產品要趕在一個對外 demo 前上線，但時間只剩原本估計的一半，而我手上同時還有兩個既有任務在跑。
【T】 我的目標是：在這個硬死線前，交付一個能順利 demo、且穩定的版本——但顯然不可能把原訂功能全部做完。
【A】 我沒有直接埋頭狂寫,而是先花十分鐘做優先排序。第一,我把所有待辦列出來,用『對這場 demo 的影響』和『急迫度』兩個維度排序,清楚分出 Must / Should / Could。第二,砍範圍而不是砍品質——我把幾個『看起來酷但 demo 用不到』的功能直接移到下一版(Could/Won't),把火力集中在 demo 主流程這條 Must 線,並確保它真的穩(該寫的測試不省)。第三,主動溝通預期——我沒有自己硬扛,而是提早跟 PM 和主管對齊:『這次先交這條核心流程,這幾個功能下一版補。』讓大家對『會交什麼、不會交什麼』有共識,而不是 demo 當天才發現缺東西。同時我把另外兩個既有任務中,可以延的先跟對方談好延期。
【R】 demo 當天核心流程順利跑完、沒有出包;那些被我砍到下一版的功能,事後也證明 demo 根本用不到。我學到的是——時間壓力下,最重要的能力不是『做得更快』,而是『判斷什麼可以不做』:把有限時間投到影響最大的地方,並讓所有人對取捨有共識。」
English Script (~250 words)
"[S] Once our product had to ship before an external demo, but with only half the originally estimated time — and I had two existing tasks running in parallel.
[T] My goal was to deliver a stable, demo-ready version by this hard deadline — but clearly I couldn't finish all the planned features.
[A] Instead of just grinding, I spent ten minutes prioritizing first. One, I listed every to-do and ranked it on two axes — impact on this demo and urgency — sorting clearly into Must / Should / Could. Two, I cut scope, not quality: I moved several 'cool but unused-in-the-demo' features to the next version (Could/Won't) and concentrated firepower on the demo's main flow — the Must line — making sure it was genuinely solid (I didn't skip the tests that mattered). Three, I proactively managed expectations: rather than carrying it silently, I aligned early with the PM and manager — 'we'll ship this core flow now and add these features next version' — so everyone shared an understanding of what would and wouldn't be delivered, instead of discovering gaps on demo day. I also negotiated a short delay on the deferrable one of my two other tasks.
[R] On demo day the core flow ran smoothly with no incidents, and the features I'd cut turned out to be unneeded for the demo anyway. My lesson: under time pressure, the key skill isn't 'going faster' but 'judging what not to do' — putting limited time where impact is highest, and getting everyone aligned on the trade-offs."
面試官最愛追問的點（先準備好）
-
🎤 「如果所有任務看起來都很緊急、都很重要呢？」 → 展現判斷力：我會逼自己用客觀標準（對目標的影響、deadline 的剛性、阻塞了誰）強制排序——「都重要」往往代表還沒想清楚，真正排下去一定有先後。必要時找 stakeholder 一起確認最高優先。
-
🎤 「你怎麼決定哪些功能可以砍？」 → 強調對齊目標：以「這次的核心目標（demo 跑通）」為準繩，不直接服務目標的就是可砍的；而且我不是自己決定，是和 PM/主管對齊後砍，確保共識。
-
🎤 「砍了範圍，品質會不會也跟著掉？」 → 守住底線：我砍的是範圍（少做幾個功能），不是品質——留下來的核心功能該有的測試與穩定性不打折。這個區分很重要。
-
🎤 「事後看，你的取捨對嗎？」 → 誠實+反思：以結果看核心流程順利、被砍的也確實用不到，所以取捨對了；就算有判斷失準的，重點是我有方法地排序並溝通，而不是亂砍。
💡 應對追問的原則：壓力題的追問都在測「你是有系統地排序，還是只是瞎忙」。每次都回到「判斷輕重 → 砍範圍非品質 → 對齊溝通」這條線。
打磨清單（套用到你自己的故事）
- 選一個真實、有硬死線或多任務衝突的情境（壓力要具體）
- Action 要有「我先排序」這一步（用影響/急迫或 Must/Should/Could）
- 一定要展現「砍範圍而非砍品質」的取捨
- 要有「主動跟關係人溝通預期」（不是默默硬扛）
- Result 收在「核心如期交付 + 取捨事後證明合理」
- 避開三大地雷：只會加班、全做到完美、怪別人
- 中英雙語同一結構，念出來控制在 2-2.5 分鐘
結語
時間壓力題真正在問的是:當時間不夠、任務太多,你能不能冷靜地排序、勇敢地砍掉非核心、並讓所有人對取捨有共識? 這是工程師從「執行者」走向「能獨當一面」的關鍵能力——因為真實工作永遠資源不足,懂得取捨的人才扛得起重要的事。
把故事寫成 STAR,核心放在「判斷輕重 → 砍範圍不砍品質 → 主動溝通」,再用「核心如期交付」收尾。這樣這題就從「我很能加班」變成「我會在壓力下做對的取捨」——後者才是面試官想要的人。這是 STAR 系列第八篇,延續克服難題、快速學習、Ownership、失敗教訓、模糊需求、衝突處理,構成一套完整的行為面試準備。