每個人的性格不同，不要去追求所謂的完美解答；而是去尋找適合自己的環境。

這邊筆者依照類型統整了經常遇到的經典面試題，並附上筆者認為回答時要注意的重點與忌諱。

1. 離職原因
   • 1.1 為什麼想換工作？
   • 1.2 什麼情況下會想離職？
2. 工作環境
   • 2.1 聊聊自己期待的工作地點、內容、氛圍，並做個排序
   • 2.2 你了解我們公司的產品嗎？
   • 2.3 你覺得自己適合這個產業嗎？
   • 2.4 你期待加入什麼樣的團隊？
   • 2.5 你有無法合作的人嗎？
3. 薪資
   • 3.1 你的期待薪資是？
   • 3.2 為什麼你覺得自己值得這份薪水？
   • 3.3 你的期待薪資與現在的薪水相比漲幅有點太大
4. 自我成長
   • 4.1 平常會怎麼精進自己的能力？
   • 4.2 會不會覺得自己學得太雜了？
5. 未來規劃
   • 5.1 你在未來 3~5 年有什麼樣的職涯規劃
   • 5.2 你進入公司後會想得到或學到什麼？
6. 其他
   • 6.1 有沒有應徵其他公司？
   • 6.2 說說看自己的優點
   • 6.3 談談自己的缺點

1. 離職原因

不管對前公司抱有多少不滿，請不要在面試時由你口中表達出來。

就算遇到面試官在批評你的前公司：「聽說你前公司高層的管理作風很有問題，朝令夕改，決策錯誤也不願意承認。」

筆者也強烈建議你不要附和，婉轉的帶過就好：「每個人都有自己的管理風格，我也是從前公司學到很多東西。」

1.1 為什麼想換工作？

重點：要說出具體的原因，跟面試的公司有關聯性更好

• 單打獨鬥轉為團隊合作
  我現在這份工作是專案外包公司，大部分的專案都是單打獨鬥，這讓我累積了非常多的實戰經驗；但也讓我意識到儘管自己可以完成每項任務，但我對後端開發這塊更有心得，我希望可以在自己擅長的領域做的更加出色，並期待與優秀的團隊一同打造出受到市場認可的產品。
• 完成階段性任務，想突破舒適圈
  在 3 個月前，我已經完成公司期待的產品；現在產品的結構趨於穩定，只剩下一些細節需要擴充與維護。
  我希望趁自己年輕的時候多嘗試不同的領域，來這裡面試前我有先做功課，了解貴公司是一個年輕有衝勁的團隊，是我所嚮往的工作環境。

筆者會用「生涯規劃」做開頭，然後再把話題轉移到面試公司身上。

1.2 什麼情況下會想離職？

忌諱：盡量避免批評前公司

請用委婉的方式說出真實理由，也許會失去一個 Offer；但至少避開了自己的雷區。

• 辦公室政治
  我希望公司的成員都是團結一心，努力想把產品做好；我無法接受好的產品因為派系鬥爭而被犧牲。
• 常態加班
  如果有緊急狀況我可以配合公司加班，但我無法接受常態加班；我希望自己可以在工作與生活間取得平衡。
• 加班沒有加班費
  員工加班是為了幫公司解決問題，如果公司沒有支付這塊的酬勞；除了違反勞基法外，辦公室的氣氛也會非常低迷，我無法在這樣的環境下工作。

因為說真話失去的工作機會不需要太留戀，假設你就是因為無法接受每天加班 3 小時才離職；你在面試時又不提出自己無法接受常態加班，搞不好這間公司每天要加班 6 小時。你不說出自己無法接受的點，進去後崩潰能怪誰？

備註：勞方與資方的思維模式差異極大，如果你今天直接說是因為薪水凍漲、加班沒錢、升遷遇阻而想離職；面試官就會認為是你能力不足、團隊溝通有問題、沒做好向上管理；會將原因歸咎在求職者而非公司，所以請模仿上面的方式換句話說。

2. 工作環境

2.1 聊聊自己期待的工作地點、內容、氛圍，並做個排序

• 工作地點
  我希望工作地點的通勤時間不超過 30 分鐘，因為通勤時間太長會壓縮到睡眠時間；進而導致上班的精神狀況不佳。
• 工作內容
  在工作內容方面，我期待有挑戰性的專案，即使是沒接觸過的領域我也很樂意學習。
• 工作氛圍
  在工作氛圍方面，我希望同事間可以互相幫助，在開發遇到難題時能夠討論並解決。

筆者個人排序：「工作地點 > 內容 > 氛圍」

2.2 你了解我們公司的產品嗎？

重點：一定要事先了解/試用過面試公司的產品

• 用稱讚作為開頭
  我覺得貴公司不僅是有願景的公司，更是一群具有實力實現願景的團隊。
• 簡單敘述產品
  在來面試前，我透過一些報導了解貴公司近幾年在大力推動「數位轉型」。
  而貴團隊目前開發的這款 App 我也有下載；在使用的過程中我感受到開發人員對使用者的用心：
  • 功能貼合使用者的日常生活需求。
  • 打破傳統思維，可以更靈活的使用點數。
  • 結合地圖讓抵達新生活圈的人，可以快速知道周圍有提供哪些好康活動。

備註：有些公司除了要你敘述他們的業務之外，甚至會請你提出哪裡可以改善；這個問題可以事先搜尋網路的評論，但請用優化而非批評的角度來敘述。

2.3 你覺得自己適合這個產業嗎？

重點：要對產業有基礎的認知，說出自己與產業相符的特質

我認為這個產業有以下特點

• 技術快速輪動
  我本身是一個勇於嘗試新技術的人，我相信唯有不斷增強自己的技術才能走在時代的前段班。
• 產品服務第一線客戶
  不怕客戶提需求，只怕沒有客戶；我對待產品的態度就像是自己的孩子，我希望它可以越來越好。
• 未來發展潛力大
  這個產業目前還是藍海市場，公司也在快速發展的階段；而我對環境變動的適應力很強，相信自己能跟著團隊一起成長。

2.4 你期待加入什麼樣的團隊？

我希望加入一個願意溝通的團隊；主管在這個團隊中有自己的主見，但也願意聽取成員的建議；而同事都有自己專精的領域且願意互相交流成長；在面對困難時，大家會齊心協力設法解決。

2.5 你有無法合作的人嗎？

忌諱：避免用前公司的人來做舉例

• 拒絕溝通的人
  如果合作對象拒絕溝通，那專案很容易因為這個人而卡在某個功能無法 Release，嚴重影響開發進度。
• 情緒管理有問題的人
  如果合作對象完全看當天的情緒來決定如何做事，那產出的品質與效率將完全無法預估；總不能把事情交給一個未爆彈做吧？

3. 薪資

3.1 你的期待薪資是？

重點：請說出一個明確的數字或是區間，不要再說出：「依公司規定了。」

如果你說的是一個區間，那區間的最低值要在自己能接受的範圍之上，因為公司通常都是採數字區間裡最低值來核薪。

面試官或是人事會依照你說出的數字決定後續走向：

• 符合行情
  如果學經歷都符合需求，通常就不會繼續往下問了。

• 略高於行情
  你要能說出自己跟其他工程師的差異，公司才可能願意用高於行情的價格僱傭你。

  通常會往「3.2 為什麼你覺得自己值得這份薪水？」發展。

• 符合行情，但想要壓你薪水
  有不少公司會詢問求職者上一份工作的薪水，甚至在核薪階段要求提供薪資證明文件；這部分就由讀者自行斟酌，因為提供與否各有利弊。
  這邊來說一下弊的部分，如果你在沒良心公司待太久，就算功績卓越，薪水也無法跟上市場價格；因此部分面試官會用這個理由來壓你薪水。

  通常會往「3.3 你的期待薪資與現在的薪水相比漲幅有點太大」發展。

備註：筆者在接受面試前會先了解這個職位的預算範圍，故此階段會直球對決；若讀者尚未確認公司預算，請先試探公司的底線。

3.2 為什麼你覺得自己值得這份薪水？

重點：說出自己與其他工程師的差異

• 硬實力
  • 我擁有的技術與職缺相符，可以快速上手成為即戰力。
• 軟實力
  • 過去跨團隊溝通、資源協調的經驗讓我知道如何保護團隊並且爭取資源。
• 其他
  • 寫文章、寫書的經驗讓我擁有極佳的資訊統整能力。
  • 下班後的學習除了開拓自己的視野外，我還會將新的知識與技術帶到公司，讓大家一起成長。

3.3 你的期待薪資與現在的薪水相比漲幅有點太大

重點：用能力談薪水，而不是用年資

我相信透過這幾次面試，貴公司對我的能力與經歷是有所了解的；我認為自己開出的期待薪資是符合市場價格的，也相信貴公司在核薪上，是依照人才的能力，而不是用過去的薪資來做衡量。

備註：此問題在期待薪資漲幅超過 20% 時較容易出現。

4. 自我成長

4.1 平常會怎麼精進自己的能力？

重點：列出具體事項，最好有陳列在履歷上

• 技術文章
  在下班後我會持續精進自己的技術，並透過撰寫技術文章將知識內化；為了要給讀者呈現最正確的知識，我也需要看大量的資料做為輔助，這個過程讓我學習到更完整的知識。
• Side Project
  常常有朋友跟我分享他們的靈感或是工作遇到的困難，如果剛好這些問題是能夠用技術解決的，我就會動手把它實踐出來，像是我之前曾用爬蟲技術解決小編朋友搜集資料的需求。

4.2 會不會覺得自己學得太雜了？

重點：證明這些學習對工作帶來的幫助

我學習的技術會分成兩種，一種要到達專業的深度，另一種則是拓展我的眼界。

像是我具備伺服器端的知識，在開發前端、後端的時候就會比其他工程師注意更多細節，對資源的管控也有更深刻的體悟。

撰寫技術文章在訓練我溝通表達與教學的能力，你要對技術有深刻的理解，才有可能用自己的語言讓其他人理解。

而寫 App 讓我從不同的角度去思考後端 API 的設計，更深刻的體會到回傳的格式、HTTP Status Code 對開發者的重要性，這些經驗讓我之後跟 App 工程師合作時更加順利。

我相信沒有白走的路，過去的經歷都會成為未來的養分。

5. 未來規劃

「人生就像射箭，夢想就像箭靶，如果沒有箭靶，你每天拉弓有什麼意義？」── 銀河補習班

5.1 你在未來 3~5 年有什麼樣的職涯規劃

重點：說出自己的具體規劃

如果有榮幸加入貴公司

• 短期
  我會先熟悉工作所需技能、了解專案；並學習產業知識，讓自己的能力能夠完全符合職位所需。
• 中期
  期待自己能擔任跨部門溝通的角色，為團隊帶來更大利益，並朝管理職的方向發展。
• 長期
  希望自己可以擔任團隊的 Leader，帶領團隊為公司創造更多價值。

備註：依照自己的職涯規劃敘述就好，並不是每個人都想往管理職發展，公司需要多元的人才。

5.2 你進入公司後會想學到什麼？

重點：想學的東西最好要跟產業以及你現在的技術有關聯性

以電商產業舉例

電商這個產業的 Know-how 對我來說新的領域，儘管我有自學一些高併發高流量以及 NoSQL 的知識；但面對真實的 Big Data 數據處理、NoSQL 與 Relation Database 結合的應用，都還是需要再學習並與前輩請教的。

6. 其他

6.1 有沒有應徵其他公司？

筆者建議照實回答：「有。」有些公司問這個問題是因為他對你感興趣，想了解有沒有潛在競爭者。

應該很少人準備換工作，卻只應徵一間吧？

如果公司對你非常感興趣，他們甚至會詢問你是否有拿到其他公司的 Offer、具體的待遇是多少、你什麼時候要做決定。

如果遇到上面的情境，恭喜你獲得薪水談判的權利；但這並不代表你可以獅子大開口，只是談判空間更大而已。

6.2 說說看自己的優點

重點：說出的優點必須要有實際案例作證

當面試官問到這個問題時，很多人都會反射性的用形容詞來回應，比如：「積極進取、樂於助人、懂得應對進退…」如果你只用形容詞回答，面試官是不會接受的，在沒有實際例子包裝前，一切的形容都毫無意義。

筆者會建議改成這樣表達：

• 積極進取
  下班後繼續充實自我，目前已經在 Medium 平台上發表了 60 餘篇技術文章；並且在 GitHub 上面分享自己的 Side Project。
• 樂於助人
  我會為團隊的新進成員準備 OnBoard 文件，帶他們了解工作所需的技術與知識，使新人快速融入這個環境成為有效戰力。
• 懂得應對進退
  我會注意職場上的禮節，像是主持會議時會穿著得體的服裝、與長官交流時不會因為私下交情而沒大沒小、如果請假出去玩會帶當地的特產與同事分享。

6.3 談談自己的缺點

忌諱：說自己沒有缺點，或是說出來的缺點不是缺點

很多求職者會回答一些根本是優點的缺點，比如：「做事太過積極造成同事壓力、擇善固執不懂得妥協…」聽到這類回答時，面試官會覺得有說跟沒說一樣，就像是從參考書裡面抄來的，毫無靈魂。

筆者建議關於缺點的回答可以從缺乏的技能出發，說出缺點的同時也要提出你打算如何改善它；盡量避免說性格上的缺點，因為面試官無法確定你的性格是否會改善，但技能是可以培養的。

筆者建議的回答結構：

• 缺乏的技能
  我在一開始兼任專案經理的時候缺乏時間管理的概念、也無法分辨任務的輕重緩急；導致上班時間幾乎都在開會、整理需求，下班後才有時間著手規劃與執行任務。
• 如何改善
  但我覺得用加班解決問題不是一個好方法，所以我開始閱讀時間管理的書籍，像是理查．柯克的 80/20 法則。
  這本書讓我知道如何過濾掉不必要的會議、需求，學會分清楚每個時間點該做的事情。
• 接受建議
  在專案管理方面我還有很多需要學習的，我也非常樂意接受您的指導，希望在未來我可以透過這些技能，幫助公司提高更多的生產力。

後記

讓你變強的不是面試，而是面試後的每一次整理；若缺少這個步驟，你下次還是會犯同樣的錯誤。

你未必認同我的回答方式，我的回答也不可能適合每一位讀者；請依據自己的人生閱歷給出最合適的回答。

本系列「面試」的主題到今天告一個段落；接下來會分享「職場」上實用的技能與建議。

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

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

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

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

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

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

大綱

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