每個人都有自己的人生經驗，本篇文章是從筆者的角度出發，希望可以給讀者帶來不同的視角與觀點。

從第二份工作開始，幾乎每場面試你都會被問到：「過去在公司或是專案上扮演過什麼角色？遇到過什麼樣的困難、如何解決？」

只要出現在你履歷上的工作經驗都可能會被詢問，所以請務必準備。

大綱

1. 在工作中有遇過哪些挫折、衝突，以及你的解決方式
   • 1.1 同事刻意挑選你無法處理問題的時間捅你一刀
   • 1.2 常常快到下班時間臨時開會
   • 1.3 跨部門溝通時遇到合作意願低又甩鍋的同事
   • 1.4 跨部門開會時遇到用階級壓人的長官
   • 1.5 開會冗長且不斷偏離主題
2. 描述一下你在這份工作中擔任的角色、負責的任務
   • 2.1 敘述本職工作
   • 2.2 與產品經理溝通
   • 2.3 處理主管交代的事情
   • 2.4 分配任務給組員
   • 2.5 分享印象最深刻的專案
3. 常見問題
   • 3.1 如果把事情搞砸了，你會怎麼辦？
   • 3.2 如果跟主管意見衝突如何處置
   • 3.3 如果擔任專案經理，你會如何與多個部門溝通，制定共同遵守的流程
   • 3.4 公司有跑 Scrum 嗎？你們是如何運作的？
   • 3.5 [狀況題]公司高層突然在週五下班前要求提前部署，你會如何應對？

1. 在工作中有遇過哪些挫折、衝突，以及你的處理方式

下面的內容可能由求職者主動說出來，或是被面試官問到，無論如何謹記一個原則：「要說出你是如何面對、處理這些事情，千萬不要淪為單純的抱怨！」

大家為人處世的方法不同，筆者的做法僅供參考；主要是為了讓讀者在遇到問題前，可以先思考自己的處理方式，不至於手忙腳亂。

1.1 同事刻意挑選你無法處理問題的時間捅你一刀

• 事件描述
  過去上班時有碰過同事，遇到問題不在上班時間詢問，而是等你離開辦公室後才在有總經理的群組 tag 你，說你的專案有 bug。
• 處理方式
  • 先作反思
    我會先回憶過去有什麼地方惹到他了，或是部門間是否有利益衝突；因為一個正常人沒道理在對方無法處理問題的時候，故意在有高階長官的群組 tag 他。
  • 盡快回覆
    儘管是在下班時段，但因為對方是在有高階長官的群組發佈訊息；所以我會盡快回覆，但不管對自己的程式多有自信，我都不會強調專案沒 bug，因為你此時可能在吃飯、運動、逛街，根本無法確認這個問題是否存在；筆者的回覆範例：「專案每個版本在釋出前有撰寫完整的測試案例確保功能穩定性，且通過測試部門的嚴密測試，針對 XXX 所提出的問題，我會盡快確認，並於明早 10:00 做好彙整向大家報告。」這段回覆有幾個重點：

    • 專案是經過測試，確認穩定後才釋出的。

    • 你有即時看到這則訊息。

    • 給出明確的報告時間。

      這邊舉例的是不影響系統運行且無法確認是否為真的 bug，如果是系統當機這類重大問題，你還是得即時處理。

  • 彙整報告

    • 真的有 bug
      老實承認錯誤，並承諾bug 的修復時間。

    • 如果沒 bug
      筆者報告完後，會用這段話做結尾：「感謝 XXX 在下班時間努力工作，可能是因為他太累了才會有這個錯誤回報；這部分我會再跟 XXX 溝通，希望他之後可以先跟負責的工程師釐清問題，避免類似的烏龍再次發生，抱歉讓各位長官受驚了。」

      筆者不會趁這個機會打壓對方，將對方的問題點出來、釐清責任歸屬就好；如果你沒辦法讓對方離開公司，那請做人留一線。

1.2 常常快到下班時間臨時開會

• 事件描述
  有些人一整天上班時間都不找你討論，偏偏等到下班前 10 分鐘才傳訊息跟你說有問題需要討論。
• 處理方式

  • 如果對方是故意的
    偶爾發生就算了，但如果對方是刻意如此，請明確地告知對方，你希望在上班時間討論；筆者的訊息範例：「如果有問題請在下班前一小時找我討論，這樣不會耽誤到彼此的下班時間，也有比較好的討論品質。」

  • 如果勸告無效
    如果對方在你明確告知後依然故我，筆者建議直接請上級提醒對方；有些人加班不是因為工作做不完，只是想在長官面前刷存在感，自己想刷存在感沒關係，但如果影響到其他同事就真的不好了。

    不是所有事情都一定要靠自己解決，適時的請上級支援也是有必要的。

1.3 跨部門溝通時遇到合作意願低又甩鍋的同事

職場奇葩多，遇到問題先甩鍋。

• 事件描述
  有時專案需要多個部門一起合作才能完成，但有些部門成員就是努力地拖延進度；你可能已經在 2 個月前就把功能完成並交付到對方手上，可是對方拖到最近才開始實作，但當上級問他功能怎麼還沒做完時，他會第一時間把責任丟到你身上，說是因為你功能不夠完善導致他無法作業。
• 處理方式
  • 留存證據
    職場上難搞的人太多，明明是自己的問題，卻把責任都推到對方身上；如果原本公司就有使用專案管理軟體就是一個很好的證據；如果沒有的話，建議要截圖對話紀錄並且每封 Email 都要把上級加入 Loop，以此保護自己。
  • 尋找關鍵人物
    如果你是專案負責人，但對方總是有各種理由拖延；到最後專案無法如期交付時，上級會找你麻煩，而不是找那個沒做事情的人麻煩。
    如果對方是因為部門不同而不願意配合，筆者建議你直接找對方上級溝通；但請在問題發生初期就去溝通，如果等到時程緊繃才去溝通就晚了，對方也會想辦法推卸責任。

1.4 跨部門開會時遇到用階級壓人的長官

• 事件描述
  在組織結構龐大的公司，有時開會的結論不是看哪個部門的方案比較好；而是看出席會議的長官中，誰的階級比較大。
• 處理方式

  • 先了解會議出席人員
    會有高階長官出席的會議不可能沒有會議通知；筆者會先向上級詢問這些長官在開會時的習性，因為有些長官會用階級來判斷你是否有跟他說話的資格。

  • 獲得相同話語權
    如果不幸遇到只看階級說話的長官，我會請主管邀請能與之抗衡的長官在會議列席，這樣在溝通上才有平等的話語權。

    直接請一個擁有相同話語權的人，會遠比自己以下犯上好很多；這裡是現實社會，不要以為自己是故事的主角。

1.5 開會冗長且不斷偏離主題

• 事件描述
  相信大家都有這個經驗，我們為了 A 的議題開會，但常常會開到一半就冒出 B、C、D 的延伸議題；不但造成會議時間大幅延長，有時甚至在會議結束後連 A 的議題都沒有結論。
• 處理方式
  • 以會議大綱為討論主軸
    很多會議只有主題沒有大綱，這造成了很多參與人員根本沒搞清楚開會目的，所以偏移主題實屬正常。
    如果在會議前就有把大綱發給與會人員，並在會議開始時先說明要解決的議題；把情境限制住後，就能減少非常多的延伸議題。
  • 延伸議題在其他會議討論
    開會過程中產生延伸議題實屬正常，但不建議在同一場會議中討論新的議題；除了會議容易失焦外，會議的時間延長也會使人無法集中精神。

2. 描述一下你在這份工作中擔任的角色、負責的任務

這塊原則上都是依照個人經歷敘述，面試官會挑感興趣的部分做深入詢問；下面是筆者統整常見的問題以及個人的回答方式。

2.1 敘述本職工作

目前擔任 Backend lead 並兼任專案經理。

• Backend lead
  對程式 Code Review、思考專案優化方向、負責新人的教育訓練。
• 專案經理
  與產品經理溝通了解需求，規劃專案時程、分配工作以及追蹤進度。

對內，讓團隊工程師實力成長，提升部門價值；對外，讓產品符合客戶需求，提升公司價值。

備註：其實跟自我介紹很像，說出面試官可能會感興趣的關鍵字。

2.2 與產品經理溝通

• 如果多項任務要完成
  我會先詢問每項任務的 Priority、要完成的時間；並初估開發所需時間以及人力資源配置。
• 需要跨團隊合作的任務
  我會建議產品經理找相關的 key man 一起討論，避免雙方的認知差異，導致最終結果不符預期。
• 遇到不熟悉的需求與技術
  如果碰上不熟悉的領域，我會先研究完這方面的資訊後，再跟產品經理說我預估的時程，而不會在一開始就直接承諾。

2.3 處理主管交代的事情

大部分的主管只會交代方向，比如：「幫忙規劃下個階段的企劃書。」

如果在不了解方向、時程、人力的狀態下直接開工，有大機率最後的成果與主管心中的答案不符，所以在收到任務時，我會先確認自己的思路是否與主管一致，舉例來說：

• 方向
  之前跟產品經理開會時，他有提出幾項客戶期待優化的需求，您看是否以這個為改版的主軸；其次再規劃新的功能。

• 時程
  我預計在週四早上將相關規劃整理好交給您，請問這個時間點可以嗎？

  記得盡量避免在週五以及平日下班前交企劃，這個時間點交企劃是希望主管加班嗎？

• 人力
  這次規劃的功能在人力資源上，除了團隊內部成員外，還需要與 XXX 部門合作；我這邊會先向他們的主管詢問方便合作的 schedule。

有時主管在指派任務時也沒有太多想法，所以要多做溝通釐清需求；如果時間允許，筆者會在初期提供幾個方案讓主管評估，否則加班加點到最後弄出來的產品不是公司需要的就真的悲劇了。

2.4 分配任務給組員

如果你擔任專案經理，上面交代給你的任務可能很模糊，但你向下分配的時候可不能模糊。

千萬不要把組員當成你心中的蛔蟲，指派任務時都要有明確的需求規格，像是：

• 需求來源
• 需求描述
• 影響範圍
• 驗收標準
• 預估工作天數
• 負責組員

如果需求規格寫的不夠明確，除了組員會時常跑來問你問題外，還可能做出完全無法使用的成果；儘管這個階段很費力氣，但真的要寫仔細，並且確認組員都明白自己要做的事。

每個工程師的工作效率相差很大，但在分配工作時還是要盡量做到平衡；不要讓能者過勞的狀況頻繁發生。

2.5 分享印象最深刻的專案

在我入職 3 年後，很幸運擔任一個千萬級別專案的負責人；除了撰寫程式外，需求訪談、時程規劃、易用性測試、教育訓練等工作都需要由我來做安排。

當時這個專案主要的使用者年齡落在 40~60 歲，我需要設計一個系統取代過去他們用紙本及 Excel 的作業流程；但是在溝通以及開發的過程是非常挫折的，因為網頁系統對他們來說是一個很陌生的東西，他們並不清楚自己要的是什麼；而當時的我只有開發經驗，對需求與規劃一竅不通，因此處處碰壁；再向周圍的前輩請教後才知道在前期可以先透過 Mind-Map 了解客戶需求，並利用 Wireframe 向客戶說明規劃。

不過 Wireframe 跟真實系統畢竟還是兩個概念，在系統進入第一次易用性測試後就是噩夢的開始；因為當時的流程規劃是跟承辦人還有一些長官討論出來的，但他們並不是這個系統的主要使用人員；導致系統在易用性測試時發現並不符合真實使用者的需求。

因此在易用性測試後，專案需求大幅更動，但截止日期沒有改變，且時程只剩下 1/3；我在這個時機點做了一個冒險的決定：「導入 Scrum 機制。」以此充分了解每個團隊成員的進度、遇到的困難、需要什麼幫助。在完成每個 Sprint 後，會請客戶試用確保符合需求，最後順利在時程內完成系統驗收。

一開始在承接這個案子的時候，我覺得他們有很多行為是無理取鬧；但到後來我體悟到：「只有你真正在乎的工作才會去爭辯，如果你不在乎大可讓他隨便。」所以我把自己的角色重新定位，帶著更多的同理心，從對方的視角去看問題，最後討論出來的答案往往是藉由工程師的專業以及他們的經驗揉合出來的成果。

一開始承接這個案子的時候我整天被客戶罵，但是在最後結案時，客戶主動打電話到公司向老闆稱讚我：「做事認真負責、工作效率高、溝通技巧良好；多虧了他才做出我們想要的系統。」

從一開始的四處碰壁，到最後得到甲方的尊重與認同；我現在回想起這段經歷，雖然苦澀但還是非常驕傲。

• 故事需要包含的元素
  筆者選擇用說故事的方式來回答這個問題，這邊整理故事中包含的元素。
  • 發生時間
  • 你擔任的角色
  • 遇到了什麼困難
  • 解決困難的方式
  • 自己從這個專案中學到了什麼
  • 客戶對你的回饋
  • 自己對這份專案的感悟

3. 常見問題

3.1 如果把事情搞砸了，你會怎麼辦？

我會明確說明自己在什麼時間點能夠解決，並盡力在預估的時間點前解決任務。

備註 1：第一時間千萬不要找理由搪塞，這只會讓主管更火；他此時關注的只有什麼時候可以解決問題。

備註 2：如果你真的是因為有其他的重要的事耽擱了，請把任務完成後再去跟主管解釋，此時的主管才聽得進去。

3.2 如果跟主管意見衝突如何處置

不同職位看事情的角度也會不一樣，我會先做一個聆聽者了解主管的想法，畢竟主管的經驗通常比我豐富，他會選擇這個做法可能是有一些我沒有考慮到的問題。

在了解意見的全貌後，如果我認為自己的想法有更多好處，我會先用詢問的方式，問看看主管有沒有考慮到這一塊，畢竟一個人能想到的內容是有極限的，透過一些思維的碰撞可以彌補彼此欠缺的地方，我相信有效的溝通是建立在雙方願意聆聽彼此的想法上面。

3.3 如果擔任專案經理，你會如何與多個部門溝通，制定共同遵守的流程

• STEP 1：我會先找合作部門的負責人協調，確認流程可行性與需要調整的地方。
• STEP 2：各部門負責人都認可流程後，我們會各自向部門成員再次確認是否有不周之處。
• STEP 3：各部門成員都接受後，我會開一個正式會議來公佈，以取得「全員共識」。
• STEP 4：在會議後發佈「正式流程」。

3.4 公司有跑 Scrum 嗎？你們是如何運作的？

在我們公司每個人都需要當 Scrum Master；如果只專注在自己的任務上，有時會偏離專案的方向。

我認為這樣跑 Scrum 的好處有：

• 培養從團隊的角度來看專案
• 快速回顧每個人的工作
• 解決成員卡住的問題
• 在當下確認任務，並協商出一個完成時間
• 每個 Sprint 結束後去思考有什麼部分可以再改進

開 Scrum 時會要求每個人說明以下內容（盡量控制在 3 分鐘內）：

• 昨天完成了哪些任務
• 有卡在哪些問題
• 今天要完成的事情
• 有需要哪些部門、同事的協作

3.5 [狀況題]公司高層突然在週五下班前要求提前部署，你會如何應對？

並不是高層交代下來的事情都必須答應，如果情境特殊，應該要先思考幾個問題：

• 這個任務是不是你一個人就能解決的？
• 如果搞砸了，會不會需要其他人的協助？會不會影響到公司？
• 這個任務一定要在這個時間點處理嗎？有什麼特別的理由？
• 如果按造原定計畫執行，會造成什麼損失？

筆者認為所有問題都是可以討論的，不要一開始就給自己否定答案；像是這個狀況題，如果真的發生意外，後果可能非常很嚴重，讓我們看看不同選擇帶來的後續影響：

• 接受
  如果順利部署那當然是皆大歡喜，但萬一不順利呢？

  • 注意力不集中
    今天是禮拜五而且快要下班了，你敢說自己還有 100% 的注意力在部署上？
    如果中間漏掉某個步驟、少了一個指令都可能導致部署失敗。

    若沒有 IaC（Infrastructure-as-code），在這個時間點部署根本是賭運氣；就算有，筆者也不建議在這個時間點部署。

  • 影響到同事
    如果部署失敗，問題你無法一個人解決，但已經到下班時間了；你可能晚上沒事，但你的同事呢？他們會不會有約會？
    大家急迫想下班的心情，可能會使洞越補越大，最後甚至變成整個部門留下來加班。

  • 沒有太多好處
    你部署成功，高層只會認為這是應該的，對整體職涯沒有太大幫助。
    但萬一出錯，或是假日才察覺到錯誤，那這件事對你在這間公司的職涯可說是毀滅性打擊。

    完全沒必要承擔高風險低報酬的任務。

• 拒絕
  當然不能用快要下班了這種理由拒絕，我們可以換個說法。

  • 詢問提前部署原因
    是因為客戶在假日有急迫的使用需求嗎？如果在下週一早上部署會造成什麼損失嗎？

    有時提前部署這件事，只是因為高層想要炫一波，並沒有特別原因。

  • 說明按造原定計劃的好處
    如果在周一部署有這些好處：「系統穩定性高、可有效追蹤部署後的狀況、如果發生意外可以盡快處理。」

本篇文章匯集了筆者與朋友在面試、工作上的應對進退，希望文章的內容對大家有幫助，也歡迎讀者在留言區分享自己的經驗。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571