如果你也獲得了出版機會，又或是懷抱作家夢準備參加比賽；也許這篇文章能讓你寫作的過程更加順利，並與出版社一同打造出理想的作品。

大綱
一、從獲獎到出版的流程
  ① 撰寫出版社要求的資料
  ② 洽談合約
  ③ 撰寫初稿（Word）
  ④ 校稿（PDF）
  ⑤ 正式出版
二、洽談合約時，要評估好自己能「準時」交稿的日期
  ➤ 預計交稿日
  ➤ 預計出版日
三、從 Markdown 到 Word 會遇到的阻礙
  ➤ 文章的階層與樣式
  ➤ 彩色變黑白
  ➤ 文章分頁問題
  ➤ 程式碼顯示
四、撰寫初稿時的注意事項
  ➤ 程式碼格式化
  ➤ 名詞定義
五、繳交初稿時要做的溝通
  ➤ 封面建議等書名確定後再來決定
  ➤ 給編輯格式最齊全的章節做排版
  ➤ 如果想調整樣章的排版
六、校稿時要有的心理建設
  ➤ 這本書是專業書籍，不是文學作品
  ➤ 在校稿過程你將經歷的心境轉換
七、校稿的注意事項
  ➤ 編輯修改後的稿件，自己要再仔細看過一遍
  ➤ 正式送印前，筆者建議要做的檢查

一、從獲獎到出版的流程

我們先了解整體的流程，而後筆者在針對容易忽略、犯錯的點提出建議。

① 撰寫出版社要求的資料

1. 作者基本資料表
2. 整理全系列文 Word 檔（用來初估實際成書的頁數）
3. 自我新書規劃

交付上述文件後，就靜待出版社的聯繫。

② 洽談合約

過一段時間後，出版社會有專人與你洽談合約，主要商議以下幾點：

1. 書籍頁數範圍
2. 印刷色彩
3. 預計交稿日（可能會區分成「樣章、50%稿件、完整稿件」幾個進度）
4. 預計出版日

③ 撰寫初稿（Word）

你要將得獎作品從 Markdown 轉換成 Word，千萬不要把它理解為單純的 Copy & Paste，你會在許多方面遇到阻礙與迷惘。

假使你對作品的自我要求很高，通常隔幾個月再看自己當初的稿子，會發現許多可以再更臻完善的部分。

④ 校稿（PDF）

交稿後就進入「校稿」，在這個階段你需要與編輯密切合作，「出書」對大部分的人來說都是第一次，筆者會在這篇文章中提醒你要注意的細節。

⑤ 正式出版

如果出書是為了圓夢，那到這裡就可以給自己放個假，去好好慶祝了；但如果想達成更多的成就，你就要開始思考宣傳的部分。

實際作業流程還是看出版社的規範，上述步驟僅供參考。

二、洽談合約時，要評估好自己能「準時」交稿的日期

出書是一個重要的里程碑，但完成一本書也需要投資大量的時間。

預計交稿日

以筆者舉例，因為平日的工作任務繁重，只有下班後和假日才有時間撰稿。

得益於過去出版的經驗，去年比賽時我幾乎是用出書的標準在寫文章，想說如果幸運得獎，我只要微調一點內容就可以出版了。

但儘管如此，我把它重新整理成 Word 的初稿就花了 2 個月（75~100小時），除非你是單純的複製貼上不管優化，不然在整理的過程中一定會發現許多可以更臻完善的部分。

如果你得獎作品的文字較少，在擴展內容方面會需要花更多的時間處理，這個部分可以參考筆者去年分享的「文章倍化術」。

因此除非你對自己的文章品質非常有自信，又或是工作較為輕鬆可以在上班時間偷偷趕稿，不然筆者建議從「撰寫初稿 Word」到「預計交稿日」至少要 2 個月。

跟專案管理的概念相同，我們寧可在這個階段多估一點時間，也不要把時程抓得太緊；否則當你在截稿日交不出東西時，會嚴重影響出版社後續的作業流程，同時失去雙方合作的信賴感。

預計出版日

不是把初稿交給出版社後你就沒事了，對筆者來說，出版最痛苦的環節不是撰寫初稿，而是反覆校稿。

我先承認自己是一個對作品很龜毛的人，如果只是單純的想出版一本書，在這個環節也可以大而化之，可能 1 ~ 2 校就直接送印；但如果你跟筆者一樣對品質有極高的要求，可能會有更多的校稿次數。

但無論你寫得多好，在短時間內看相同的內容 2 遍以上都會感到精神疲乏；如果想要減少這份不適感，建議在交付稿件給出版社時就力求完美。

「預計交稿日」到「預計出版日」這段時間中除了校稿外，你還要跟編輯討論並完善書籍的「封面、封底、作者介紹、宣傳語、推薦序…」等資料；因此筆者再次提醒未來的作者們，在「預計交稿日」交付的不是「草稿」，請以最高的標準來看待他。

三、從 Markdown 到 Word 會遇到的阻礙

我也很希望用複製貼上就能搞定這一切，但實際做起卻發現理想很美好，現實很骨感。

文章的階層與樣式

使用 Markdown 時，我們不用去管內文的階層與樣式，直接使用預設的就好了；但轉到 Word 時就頭大了，因為你需要先定義好所有樣式，不然你的排版會亂七八糟。

這邊建議你要區分的層次有：

• 章節大標（ex：Ch 1）
• 章節小標（ex：Ch 1.1）
• 段落小標（ex：Ch 1.1.1、或用較大的字體搭配鮮明的樣式）
• 內文

你可能需要設計的樣式有：

• 編號格式（ex：像是你要用 1 2 3，還是 a b c；或是單純用 bullet 區分）
• 內縮註解（放備註用的）
• 引文（在正文開始前，你想說的話）
• 提醒文字框（可能放這章節的總結、段落的提示、重要警語）

彩色變黑白

除非你選擇彩色印刷，不然變成黑白基底的時候，有一些細節你需要重新考量：

• 畫面截圖的顏色對比度夠高嗎？文字是否清晰？
• 重點都是用粗體顯示嗎？要不要設計一些不同的樣式來表達？

文章分頁問題

網頁可以一直往下滾，但書籍是左右翻頁；如果你內文的程式碼佔很大比重，就要考慮是否把它切分成幾個段落，盡可能不要出現跨頁的顯示。

我是說「盡可能」，因為筆者知道很難每段程式都辦到。

程式碼顯示

筆者這邊是採用 Word 提供的外掛「Easy Code Formatter」，它可以讓程式碼在 Word 上顯示的相對優雅。

放程式碼時如果能做到以下幾點會更理想：

• Word 的左右寬度有限，無法像 IDE 一樣無限延伸，所以盡量不要讓一行太長。
• 一段程式碼的行數盡量控制在 50 行以內，不然在閱讀上會有跨多頁的問題。
• 重要的函式、演算法請用粗體標示，讓讀者更容易抓到重點。

四、撰寫初稿時的注意事項

程式碼格式化

相信能獲獎的都是各領域的大神，在 Coding Style 方面我就不贅述了；但程式碼格式化的部分請多加留心，比如：「結尾分號是否統一」、「縮排 2 格還是 4 格」，如果書中的程式來自不同專案，就很容易有這類型的疏失。

名詞定義

1. 前後一致：當你提及某個專業技術的名詞時，請盡量每個章節都使用統一的名詞，避免讀者混淆以為是不同的技術。
2. 中英文提示：如果有些章節用英文，有些章節用中文，可能會增加讀者閱讀理解的困難度；如果有發現這種情形，可以在第一次使用時將中英文都列出，後面再擇一顯示即可。
3. 名詞備忘錄：通常書寫到後面頭都暈了，因此建議自己建立一個名詞比對表作為備忘錄。

五、繳交初稿時要做的溝通

如果排版上你有自己的想法，請一定要在前期提出！ 越到後面調整起來越困難，也容易有遺漏的部分。

封面建議等書名確定後再來決定

封面跟書名最好有直接關連性，但在初稿剛交出去時，書名的變動性其實還蠻大的，就像筆者原本腦洞大開想用「修煉」做為封面的主視覺。

當初書名大概列了快 20 個版本吧，現在各位看到的最終版本，是筆者在瘋狂騷擾周圍朋友反覆投票後所決定的。

給編輯格式最齊全的章節做排版

在正式排版前，編輯會先產出一個排版的「樣章」供你確認格式。

筆者建議挑選一個格式相對來說最複雜的章節，如果一個章節無法包含所有格式，就把特殊格式都挑出來，請編輯幫你試排。

以筆者舉例，在我的書中除了「目錄、大標、小標、表格、內文…」等常規格式外，還有「流程圖、提示框、段落階層…」等特殊格式。

樣章的作用就是統一這些格式，讓作者與編輯在校稿的過程更加順利！

如果想調整樣章的排版

收到第一版樣章時，你可能會想做一些調整；但建議先跟編輯開個會，了解為何會這樣設計，畢竟他們是這個領域的專業人士。

如果會後還是想調整排版，千萬別對編輯說：「我不知道自己要什麼，我只知道這不是我想呈現的。」

編輯大大們已經夠辛苦了，別要求他們連通靈都要會啊！

筆者建議請編輯修改排版時，要提供明確的「排版範例」；如果你只是感覺不對又無法用文字表達，直接跑實體書局去找答案吧，這會比你在網路上模索來得更有效率。

六、校稿時要有的心理建設

在校稿的過程，許多作者都會萌生出：「現在放棄，明天就可以送印嚕～」的想法。

但都已經走到最後一步了，會把這個想法付諸於行動的作者應該很少；大多數的人在校稿階段，更容易產生跟自己過不去的心理。

這本書是專業書籍，不是文學作品

有時原本看起來很順的文字，在校稿時會變得怎麼看都不順眼，因為我們想把最好的一面傳達給讀者。

但這種字字斟酌會使校稿進度變得非常緩慢，可能花了大量時間，但產出的內容對讀者來說卻沒有多大幫助。

站在專業書籍的角度，比起文字行雲流水，更重要的是知識的正確性；文字有點卡頂多閱讀起來不順，但如果知識面有錯誤，就可能導致讀者在日後做出錯誤的判斷。

我們的目標讀者是工程師，他們需要的是明確的語言，簡單的邏輯。

在校稿過程你將經歷的心境轉換

隨著校稿次數增加，你的注意力會逐漸渙散：

• 一校：不放過每個錯漏字！想交出最完美的作品。
• 二校：恩…這句話會不會讓人誤解？來調整一下好了。
• 三校：大體上看得懂就好了。
• N校：%&$&%^&%^@。

通常到第三校的時候，大部分作者的精神力已經逼近崩潰邊緣；因此我們寧可花多一點的時間、精力在第一次校稿上，也不要分成太多次校稿，同樣的內容看太多次會麻痺，就算有問題也很難察覺。

七、校稿的注意事項

一本好書的誕生，需要作者與編輯的齊心合作；不要把挑錯誤這件事都丟給編輯，身為作者我們要對自己的書負起責任。

編輯修改後的稿件，自己要再仔細看過一遍

在一校的時候除了看文字是否通順、邏輯是否有誤外，還要注意以下問題：

1. 是否有「錯誤的內容、缺漏字」：在稿件重新排版成 PDF 後，因為每頁能容納的內容不同，所以我們會獲得全新的視覺體驗，此時更容易察覺過去沒發現的問題。
2. 文章的特殊符號「➔➠✔」、emoji「😃😅😇」是否如預期呈現：這些符號在不同作業系統（ex：android/windows/macOS）會有各自呈現的樣式，如果 PDF 上的內容跟你預期不同，建議提供「截圖」。
3. 每頁的內容編排：因為書籍是左右翻頁，不像網頁一直往下滾就好；有些資訊放在「上一頁」或「下一頁」可能會有更好的閱讀體驗。

正式送印前，筆者建議要做的檢查

• 再檢查一次封面、封底：確認文字通順、排版合理、內容無誤。
• 快速瀏覽內文的每個頁面：確認要調整的內容皆如預期校訂完畢。
• 重要的資訊是否無誤：像是書籍範例程式的下載網址、表單連結。

後記

筆者的經驗分享到這裡就告一個段落了，希望每位大神都能出版一本自己理想中的書籍。

文章的最後為自己的新書打個廣告，如果你最近有轉職的需求，或是對現在的職涯感到迷茫，可以參考看看喔（歡迎路過按讚）～

天瓏網路書店 | 給全端工程師的職涯生存筆記：從履歷×面試×職場打造無可取代的軟實力 (ChatGPT加強版) (iThome鐵人賽系列書) 出版商: 博碩文化 出版日期: 2023-05-04 定價: $650 售價: 7.8 折 $507 語言: 繁體中文 頁數: 416 裝訂: 平裝 ISBN: 6263334576 ISBN-13: 9786263334571… www.tenlong.com.tw

寫作＆比賽經驗分享
▋ 文章倍化術！解決字數不足、篇幅不夠的 9個實用秘訣
▋ 我希望在參加 [iT邦幫忙鐵人賽] 前就知道的事
▋ 出版書籍經驗分享
▋ 我希望在寫書前就知道的 N 件事 ── 出版之後（本篇）

如果你是一個有野心且不安於現狀的人，薪水談判是你一定要去做的事情。

在閱讀這篇文章前，你可以先思考幾個問題：

• 你入職多久了？
• 入職後的薪水有調整過嗎？
• 你滿意現在的薪水嗎？
• 你想跳槽是因為工作環境問題，還是薪水不夠？
• 你對公司有什麼具體貢獻？
• 如果公司願意給你應得的待遇，你想要多少？

本篇文章想跟讀者探討內部加薪這個議題，如果有辦法在熟悉的環境中持續成長，應該沒有多少人想在陌生的環境中從零開始吧？

大綱

1. 薪水談判前的準備
   • 1.1 準備自己的成果
   • 1.2 撰寫有說服力的證據
   • 1.3 安排談判時間
2. 薪水談判時的注意事項
   • 2.1 千萬不要使用紙本或是 Email 要求加薪
   • 2.2 引導談判流程
   • 2.3 不要讓對方覺得是你有求於他
   • 2.4 被拒絕時的應對進退
3. 完賽感言
   • 3.1 趨吉避凶真的很重要
   • 3.2 致謝

1. 薪水談判前的準備

不打沒把握的仗，你為了這一天已經努力了這麼久，千萬不要因為一時的情緒，就在毫無準備的狀態下去敲長官的門。

1.1 準備自己的成果

只有初階的工作才會因為你花了更多時間使公司賺更多錢，高階的工作只關心你有多少產出、為公司帶來什麼利益。

• 最容易被無視的加薪理由
  如果你加薪的理由是：「我感覺自己很努力」、「我已經在這間公司待很久了」、「我覺得自己很認真工作」。
  相信大部分公司不會因為上面的理由給你加薪，且通常會給你一些罐頭回覆：「繼續努力，公司不會虧待你的！」
• 準備實際證據
  筆者在 Day 2 的文章中有提到履歷要定時整理，因為許多證據是有時效性的，時間過了你就很難取得，如果你要公司為你加薪，要有實際的證據他才會買單。
  而且這些證據的重點要放在你做的事為公司帶來多少利益，而不是你做了多少事，比如幫公司賺了多少錢或省了多少錢。公司的人很多，如果沒有主動說出來，上級根本不知道你有這些貢獻。

1.2 撰寫有說服力的證據

筆者在這邊提供幾個不同面向的範例，內容的結構為：「過去遇到的問題 → 我用了什麼方法解決 → 具體有什麼成效。」

• 減少部署難度、提升系統穩定性、節省公司開銷
  過去專案在新版本部署時都需要小心翼翼，害怕有什麼參數遺漏導致部署失敗；但在導入 k8s 後，我們就能確保專案在測試區跟跟正式區的環境都一樣；並且透過它自動擴展的特性，我們就不用給伺服器預留太高的硬體配置，從近幾期 GCP 的帳單來看，這個工具的導入平均為公司省下了 30% 的費用。
• 推廣工具、強化跨部門溝通、提升公司整體工作效率
  過去各部門在專案溝通上都以郵件為主，如果郵件數量一多就容易有資訊上的遺漏；為了讓部門之間溝通更為順利，我導入了專案管理系統，並負責向各部門做系統的教育訓練、請 Key man 協助推廣；有了它之後，執行專案時可以更有效地掌握任務時程、歷史紀錄、負責人員，從 Issue Ticket 完成的數量來看，公司整體工作效率提升了 40%。
• 學習新技術、解決公司問題、取得良好的數據回饋
  過去系統首頁的載入速度太慢、且導航功能不夠明確，導致使用者的跳出率一直很高；針對這個部分我把首頁改成 SSR 渲染提升載入速度，並且與 UI/UX 設計師一起討論系統流程，透過審視系統的 SiteMap 來重新規劃導航功能的權重；透過這些更新，從 Google Analytics 的報表我們可以得知使用者平均在系統的停留時間上升了 200%，且瀏覽的頁數增加了 320%。
• 讓公司業務理解產品，提升部門產品的銷售業績
  我們部門完成了很多產品，但幾個月前的銷售業績並不理想；在跟業務聊天的過程中發現他們並不了解我們的產品。所以我便舉辦了一場產品說明會，向業務說明我們的產品能幫客戶解決哪些痛點，讓他們了解並對產品有信心；以這個月來說，我們部門產品的銷售業績提升了 300%。

如果你的上級是個有遠見的人，當你說出自己具體貢獻時，他會毫不猶豫地為你加薪，內部調薪 30% 甚至 50% 以上都是有可能的，因為好的人才真的很難找。

1.3 安排談判時間

就算你已經做好了事前準備，也千萬不要臨時起意找上級談加薪，因為你無法確認他晚點是否有會議要開；而且這種做法也不夠正式，會給對方一種我只是提提看，如果不行就算了的感覺。

談判的時間很重要，相同的要求在不同的時間點提出，可能會有完全不一樣的結果。

• 要避免的談判時間點
  • 禮拜一
    通常休假後的隔天大家的心情都不太好，如果在此時進行談判，上級很可能會帶有較多個人情緒。
  • 禮拜五
    薪水談判未必可以在一天之內結束，因為有些公司有複雜的簽核流程要跑；如果選在禮拜五，你的上級可能會因為要跑的流程太多無法當下給你保證，而你還要捱過一個得不到結果的假日。
  • 下班前
    你喜歡在下班前開會嗎？如果你不喜歡，就不要在這個時機點說，因為上級的臉絕對很臭。
• 最佳的談判時間點
  儘管避開上面的時段都可以談判，但下面的時機更為恰當。
  • 專案獲得成功的時候
    此時你已經證明了自己的能耐，這是上級是無法忽視的實際證據。
  • 上級心情好的時候
    只要你給的證據足夠、加薪幅度合理，挑對方心情好的時候談判，成功率會大幅上升。
  • 知道公司營收成長的時候
    如果公司沒賺錢，或是你待的產業走下坡；即便你在努力也很難加薪。
    相反的，如果公司的營收很好，薪水談判的空間就會很大。

2. 薪水談判時的注意事項

2.1 千萬不要使用紙本或是 Email 要求加薪

• 為什麼不要用文字溝通？
  很多人會因為害怕和公司高層或是上級面對面談判而使用文字溝通，但這個方式真的非常愚蠢。
  因為每個人對文字的理解是非常主觀的；所以請你面對面（或至少讓對方聽得到你聲音）的狀態下去談判，這樣對方才能從你的情緒、語調、肢體語言、眼神的溝通中感受到你的自信。
• 如果你感到害怕，那請準備好劇本，並練習到滾瓜爛熟
  有些人口才很好，只要準備好實際證據，就能信心十足地與上級談判。
  如果你沒有這個天賦，那請你為這場談判準備好劇本；在談判前先跟你的朋友、家人、合作伙伴們多練習幾次，模擬一切可能發生的狀況。儘管實際談判時，恐懼不會消失，劇本也不會完全按造你的想像發展，但你的表現肯定比沒準備時從容許多。

2.2 引導談判流程

• 講清楚這次談判目的，直球對決！
  談判需要有明確的目標以及結果，否則就只是一場毫無意義的面談。
  筆者建議一開始就正大光明地說出此時此刻就是要討論薪水的議題；如果你只是暗示，有些上級會假裝聽不懂或是轉移話題。
• 讓對方認同自己的貢獻
  你可以先說說自己過去在公司的貢獻，並在陳述到一個段落時向上級詢問這些貢獻是否對公司有幫助，透過這樣一來一往的過程，對方更能吸收並認同你所提供的訊息。
• 主動提問題，不要只顧著講自己的豐功偉業
  除了表明自己的貢獻外，你同時也要提出問題，請記住提出問題的人才是主導這個會議的人。
  提問是為了獲取更多情報，並試探對方的底線；但請以合作者的角度去做詢問，讓他知道我們是在同一個陣營的，我們要一起讓公司變得更好。

2.3 不要讓對方覺得是你有求於他

不要在對話中出現：「我想要…」、「我需要…」這類的開頭，一但出現有求於人的詞彙，那談判的主動權就可能轉移。

你可以嘗試改用：「這份薪水有彈性嗎？如果我的年薪有 XX 會更合適，你覺得呢？」這類中性的語句，不要參雜多餘的事情來做詢問。

2.4 被拒絕時的應對進退

並不是每次提加薪都會被接受，但如果被婉拒就直接離場，那你在這次的談判中毫無收穫；筆者在這邊提出另一條思路，讓你確定是否要繼續留在公司打拼。

• 如果現在不符資格，那我要怎麼做？
  在提出加薪需求時，上級可能會跟你說：「現在還不是時候」、「你知道現在公司營運狀況」、「共體時艱」…
  遇到這些問題時你可以考慮這樣回答：「我來這間公司的目標是為了成為一個最有價值的成員，而不是成為公司的負擔；我想要為公司創造收入，並讓您理解當公司支付這個薪水時，我會 10 倍、20 倍的回饋給公司，我是為了讓公司成長而進來的，我不是把這裡當成一份工作而是把它當成我的事業。」先說讓上級聽起來舒服的場面話，然後在最後詢問他：「現在我的年薪是 XX，而我的目標是 YY，我知道不可能馬上調整成這個數字，但是可以請您告訴我，要怎麼做才能賺到這個薪水嗎？」
• 直接向上級確認，完成目標後是否就會調整成期待薪資
  相信上面這些話會讓上級對你印象深刻，至少他會知道公司有你這名充滿野心的員工，此時他就會去思考要如何幫助你成為有資格賺到這個薪水的人，並提出他期望你能夠完成的 KPI、milestones…
  接下來就到最後一步了，你直接向上級確認：「如果我真的完成了您所說的這些目標，公司是否願意支付我所提出的年薪？」在得到肯定的答覆後，可以直接跟上級約下一次會面的時間（ex：3 個月後）。
• 完成目標後，向更高的目標發起挑戰！
  等到下一次的會議，再重複一次你今天所做的事情，挑戰更高的目標。
  如果你是待在一間高速成長的公司，那麼你的機會是無限的，能成長多快完全取決於你的意願、野心、能力。

如果在你達成目標後，公司願意給你該有的報酬，那其實留在原本的公司也不錯；假設公司沒有履行承諾，那你也能非常果決的離職，尋找下一間適合自己的公司。

3. 完賽感言

每個人的人生，都是自己選擇而來的。

3.1 趨吉避凶真的很重要

有些話年輕的時候聽不進去，直到經歷了某些事，才會了解它的道理。

• 做人要圓融
  以前覺得圓融就像是示弱，但社會化越深，越能體會圓融的重要性；如果讓對方講話大聲一點就能取得雙贏，為何一定要鬥到其中一方慘勝？
• 做好本分，不要意氣用事
  如果今天領著公司的薪水，就做好自己的本分；筆者看過太多因為對公司制度不爽或是被 PIP 的同事，在離職前努力的給同事製造麻煩，甚至遇過離職當天把公司電腦給格式化的。
  公司對不起你，你有情緒完全合理；但請注意，如果你損壞公司財產，你可能會背上法律責任，真的不要意氣用事。
  如果公司沒犯法，盡可能不要把事情做絕；至少保留檯面上雙方的面子；圈子說小不小、說大也不大，誰知道有沒有再次相會，也不知道是以什麼方式相遇。
• 給人留一條活路
  以前，在局面對自己有利的時候，我會想要獲得全面性的勝利；但現在，我會選擇給對方一個台階下。
  一無所有的人才是最可怕的，人生中有勁敵會讓自己成長；但如果周圍都是仇敵，你連睡覺都不安穩。

3.2 致謝

• 令人感動的朋友群
  這個系列文能完成，首先要感謝我身邊受苦受難的朋友們；沒有你們，我真的沒有這麼多題材可以寫，希望你們早日脫離苦海。
• 給工程師表演舞台的比賽
  感謝 iT 邦幫忙舉辦鐵人賽，讓我趁這個比賽逼自己去完成一件有意義的事情；並且很幸運的認識一群對技術充滿熱誠的自虐狂戰友們，並成功在各自的主題中完成了連續 30 天發表技術文章的里程碑。
• 使我有勇氣繼續奮戰的後盾
  家人與女友在比賽期間一直給我加油打氣，有你們當我的後盾真的很安心。

後記

這是一系列個人風格強烈的筆記，筆者將自己這些年累積的技術與經驗用最短的篇幅呈現出來；但每個人都有自己的人生要走，文中的應對進退未必適合每一個人。

即便你覺得哪句話說得再有道理，也要經過自己的思考再去實踐。

如果這個系列文對你們有幫助，那是我最大的榮幸。

最後想跟讀者們分享「熔爐」這部電影中，一句讓我印象深刻的台詞：「我們一路奮戰，不是為了改變世界，而是為了不讓世界改變我們。」

雖然鐵人賽在這裡告一段落，但對我來說：「技術分享的旅途才剛開始呢！」

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

參考資源

1. 薪水談判-Salary Negotiation(筆者部落格)
2. Salary Negotiation: 7 Tips On How To Negotiate A Higher Salary

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

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

如果在過往的工作中只遇過 1、2 次不愉快的經驗，那應該是主管偏心、公司制度有問題；但如果你過去的每間公司都遇到類似的狀況，那問題可能出在自己身上。

如果你覺得現在過得不好，不妨參考文章中的方法，也許裡面有些觀點能給你的職涯帶來不一樣的啟發。

1. 做好份內的事
   • 1.1 勇敢拒絕非本職工作，持續加強自己的專業
   • 1.2 不要什麼事情都攬下來，學習當溝通的橋樑
   • 1.3 拒絕承擔與職位不符的責任
2. 讓自己獲得好的工作狀態
   • 2.1 提升工作品質的小技巧
   • 2.2 下班後好好休息
3. 職場禮儀
   • 3.1 避免當個讓人討厭的主管
   • 3.2 詢問別人問題時不要犯的禁忌
   • 3.3 詢問別人問題時該有的禮儀
   • 3.4 給出具體時間，避免使用模糊用語
4. 建立友善的溝通環境
   • 4.1 面對想法意見不同的人，不要先入為主
   • 4.2 不是所有人都跟你有相同的知識背景

1. 做好份內的事

筆者過去非常認真工作，面對主管交代的事從不拒絕，同事需要幫忙時也傾力協助；就算下班時間同事都走光了，我還是獨自加班完成工作。

當時我覺得應該是自己的能力受到肯定，才會被分配到這麼多工作；但過了一段時間後，身體漸漸無法承受這麼高強度的工作，對公司不滿的情緒也越來越多：「為什麼主管只把困難的任務丟給我做？為什麼其他同事都能準時下班？為什麼我要一個人處理這麼多的事情？」然後不久後我就離職了。

直到現在回頭看當年的這段故事，才了解原來「能者過勞」最大的元兇是自己。

1.1 勇敢拒絕非本職工作，持續加強自己的專業

如果你是後端工程師，那就請把自己後端的能力鑽研到頂尖的水準；如果指派給你非本職工作的任務時，盡可能地拒絕。

如果你不懂得拒絕，你就會變成「全包」工程師，同事有事情第一個都先想到你；這容易導致你原本的專業技能停止成長，甚至每天都有做不完的事。

就算你擔任的是全端工程師的職位，我相信一定還是有偏重前端或是後端；筆者建議要認真鑽研偏重的部分，因為絕大多數人都做不到全能，謹記主武器負責殺敵，副武器用來輔助；如果你的主武器已經生鏽，那副武器再多也沒有任何意義。

從高手變成庸才的故事

筆者有個朋友曾經是業界非常優秀的後端工程師，但他在入職新公司兩年後卻變得很平庸；因為除了後端開發外，他還要負責前端網頁開發、公司內部 Server 管理、專案管理系統架設、程式碼版控系統架設、雲端 Server 部署、專案管理、內部教育訓練、Android APP 撰寫…；這些瑣事不僅填滿了上班時間，也讓他下班後沒有體力繼續提升自己，導致技術停留在兩年前毫無進步，而當年落後的人已經可以跟他並駕齊驅，甚至比他更優秀了。

備註：如果在自己手上有事情忙的狀態下，還被強制分配非本職工作的任務；可以趁這個時候跟上級交易，畢竟大家上班都是來賺錢的，如果要我多負擔一份壓力，那也要付出相應的代價。

1.2 不要什麼事情都攬下來，學習當溝通的橋樑

• 將對話窗口轉移
  在非純軟的公司裡面，大部分的部門都搞不清楚前端、後端的差別，因此遇到問題他們不是找主管就是找「全端」工程師；就算你真的能幫他們解決問題，但只要你當了一次的窗口，他們之後遇到問題都會來找你；為了避免日後工作時被其他部門頻繁打擾，筆者的處理方式為：

  • 如果不是本職工作，我會用 Email 告訴其他部門的同事，遇到問題時可以找哪些對應的窗口（ex：如果要提需求可以跟產品經理討論、想知道專案進度請去找專案經理）。
  • 如果是本職工作，但手上工作滿檔；我會將 Email 轉發給其他工程師並描述事情經過，請他協助處理。

  如果你接到問題就處理，那只會是「能者過勞」；你要學習將任務分給同事。

• 不要把別人的問題變成自己的問題
  能力越強，責任越大；當你擔任 Senior Engineer 或是 Tech Lead 時，時常會有同事請你幫忙解決 Bug；如果時間允許，忙當然是要幫的，但請謹記你是幫人，不是攬過來做。
  有些工程師問完問題看到有人幫忙後，就會回到座位一副事不關己的樣子；所以幫忙時請注意界線，以引導為主，不然最後出包，對方可能會把責任直接推到你的頭上。

1.3 拒絕承擔與職位不符的責任

• 背高價、沒看過的資產
  個人資產應該是公司配給你的電腦、螢幕；但有些爛主管會把一些自己不敢背的高價資產掛到下屬身上，如果主管要你在資產轉移單上面簽名，一定要堅定的拒絕。
  大部分的高價資產，只有該領域的工程師才知道如何檢測；所以資產轉移這件事通常有鬼，如果你沒搞清楚就簽下去，很可能成為主管的替死鬼。

• 要你幫忙做不符職權的重要決策
  有些爛主管會將做決策的任務推給下屬，如果你發現這個決策的影響範圍已經超過了你的職權，甚至涉及到多個部門、公司預算；筆者強烈建議你要裝傻推掉。
  他把決策的任務交給你，通常不是為了重用你；只是單純的想要逃避責任跟栽贓嫁禍而已。

  小提醒：假設 1 個決策的失敗率是 20%，你幫忙做了 5 次決策；主管會獲得那 4 次決策正確的獎勵，而你則會承受那 1 次決策失敗的後果。

當然也是有善良的主管，但社會上陰險的人太多，遇到不合理的事你要想辦法拒絕才能保護自己；有的時候不是你比較倒霉，而是因為你沒有拒絕不該由你承擔的責任。

2. 讓自己獲得好的工作狀態

讓我們還回想一下，同樣是工作一整天；有時你回到家時感到沮喪，而有時卻覺得非常充實。

如果你仔細觀察，會發現會造成這兩者差異的主要原因，是因為前者做了太多的雜事，而後者則是去完成有挑戰性的事。

在上個小節已經分享了許多避免雜事的技巧，這個小節就讓我們來了解，如何讓自己有能量去完成有挑戰性的事情。

2.1 提升工作品質的小技巧

你是否曾經工作到一半突然覺得所有事情做起來都非常流暢，在這個狀態下遇到的難題都能迎刃而解、而且能在短時間完成非常多的事，更神奇的是這段時間你的注意力完全不會渙散，甚至會忘記時間的流逝。

筆者周圍有蠻多朋友都體會過這個狀態，它有一個專有名詞 ──「心流」；雖然可遇不可求，但能透過一些小技巧增加它出現的頻率，這些技巧就算無法讓你進入心流，也能提升不少工作品質：

• 給自己一個完整的工作區間，在這個區間內拒絕一切外界聲音；這樣做可以避免你的注意力被打來的電話、訊息的提示音所干擾。

• 給任務設定一個期限，必須在時間內完成某件事；讓大腦把所有精力只投入到一件事情上面。

• 在開始前用一個儀式，暗示自己就要進入無敵模式；透過這個儀式把自己從混亂的思緒中抽離，切斷大腦之前的思緒。

  筆者的儀式是在開始做事前，聽 Victory 這個激昂的音樂。

2.2 下班後好好休息

很多人的下班不是下班，讀者可以回想一下，自己是不是下班後大腦還在思考著剛剛會議的事項，今天尚未完成的工作？

這樣的過度努力，有時會導致你隔天早上到公司的時候昏昏沈沈，做事沒有動力；過去筆者一直以為會這樣是因為工作倦怠、前一晚沒睡好；但後來發現主要是因為在下班後並未將大腦抽離工作環境。

筆者建議在下班前把尚未完成的工作記錄下來，現在有許多筆記軟體都可以幫助你完成這件事，完成後就讓大腦關機，給它喘息的時間；如果讀者願意嘗試看看這個方法，在幾天後你會發現這個細微的調整，竟然能讓隔天上班的時候更有精神、做事效率更高。

3. 職場禮儀

與其說是禮儀，不如說是同事間的互相尊重；如果你有給長官、同事、下屬該有的尊重，彼此的合作會輕鬆許多。

這個小節筆者主要分享不要去踩的地雷，讀者可以從範例中看看自己是否有需要調整的地方；很多時候我們一直在犯錯卻又毫不自覺。

3.1 避免當個讓人討厭的主管

朋友的故事很經典，又符合這個主題，所以就直接拿他來當範例了。

朋友公司的 MIS 部門離職率很高，有多高呢？10 個人的 MIS 部門，一個月可以走 2 個！招募的速度都趕不上離職的速度，部門內除了主管外，最資深的員工還沒待滿一年。

所以時常會找其他 IT 部門來支援業務，而我朋友很不幸的被抓去支援，進去後他瞬間理解為何會有如此高的離職率，簡單幾個例子：

• 在錯誤的時間點發布任務
  除了上班時間會指派任務外，他在禮拜五下午、下班前一小時、下班後還會指派任務給下屬；讓部門每個人的工時超長。

• 光說不練
  一直說自己超級強，但從來沒有看過他自己動手操作，連機房都不太敢走進去；讓下屬對他的能力充滿質疑。

• 推卸責任，陷害同仁
  朋友進去支援，在做交接時身上還要背一堆公司資產；但交接時間只有半小時，資產根本不可能在這麼短的時間內盤點完（當時朋友菜逼巴，不知道一個人背這麼多資產根本不合理），當時他就非常不安；果然隔天就出事了，公司在做資產盤點時發現有些東西不見了，這個主管立馬把鍋甩到我朋友身上要他賠償；一台伺服器就要 20 萬，我朋友現場崩潰大哭。

  如果你只是支援，千萬不要在身上掛賬；就算對方階級比你高，直接請主管幫你擋掉，這是上司應該對下屬的保護。

• 分不清輕重緩急
  凌晨 12 點突然打電話給我朋友，我朋友當時還以為發生了什麼重大事故；結果只是要我朋友幫忙把防火牆重新啟動。因為主管怕自己做出事，所以連小事都要在凌晨打擾下屬。

• 用考績來威脅做事
  在打考績的時期，這名主管在下班時間是這麼交代事情的：「XXX 你幫忙處理一下這個問題，我現在要打考績沒時間處理。」

• 不管團隊承受能力狂接需求，甚至未經討論直接壓任務死線
  這位主管好大喜功，為了討好各個部門，只要有需求就先接再說，完全不考慮團隊的承受能力；為了達成自己的績效，他甚至直接壓死線，要求做不完就全部留下來加班。

看完上面的敘述後，有沒有覺得這個部門根本是地獄？每個人在未來都有可能擔任主管，當你覺得這個故事荒謬的同時，請謹記：「不要變成自己曾經討厭的樣子。」

3.2 詢問別人問題時不要犯的禁忌

如果你問問題的方式讓同事感到不舒服，他們可能之後就不想再幫你了。

• 訊息太過零散
  現在普遍是用通訊軟體來問問題的，如果你沒有把問題整理好再發送，會導致對方電腦一直跳彈窗，非常干擾工作。筆者建議詢問別人問題前，要先整理好訊息且內容要包含：

  • 在哪個地方遇到問題
  • 我搜尋了哪些相關資源
  • 過去有沒有可以參考的範例

• 對方沒馬上回，就一直發訊息
  有些人認為在上班時，同事的訊息應該要秒回，如果超過 5 分鐘沒回就一直敲他。
  我相信會這樣做是因為事情很緊急，但這個做法非常討人厭；對方沒有立刻回訊息，可能是手上也有緊急的事情在處理，如果真的有時間壓力，筆者會建議直接打電話。

• 在下班時間或假日打擾對方
  如果是你個人在專案遇到的問題，建議上班時間處理。

• 訊息只有：「請問你現在有時間嗎？」
  很多人的訊息只有：「請問你現在有時間嗎？」這樣的詢問方式讓收到問題的人沒有辦法預估這個問題將會佔用他多少時間，所以有些人就當成沒看到這則訊息。

• 在開頭說打擾 3 分鐘，結果打擾了 30 分鐘
  如果你的問題其實不小，千萬不要騙對方說只打擾 3 分鐘；這樣很容易打亂他這一天的計畫。

  很多業務開頭的話術就是：「請問可以打擾您 3 分鐘的時間嗎？」如果你有停下來聽他們講解過，就會知道 3 分鐘都是騙人的。

• 拖到最後一刻才問人
  如果最後一刻才求救，不但你緊張，被你求救的人也很緊張；在雙方壓力都很大的狀態下，工作效率實際上是更低的。

• 問重複的問題
  如果詢問重複的問題，除了造成同事的困擾外，還會被質疑你的能力是不是有問題。

• 對方不知道你什麼時候會過來詢問
  如果問問題時對方正好在忙，千萬別說：「我晚點來問你。」因為不明確的時間會給對方帶來更多壓力，應該問：「我什麼時候方便來請教？或是等您有空的時候跟我說一聲？我再過來這邊。」這樣會讓對方比較舒服。

3.3 詢問別人問題時該有的禮儀

有時同事會說：「你幹嘛這麼客氣，直接問就好了啊！」筆者建議你就算聽到這段話，還是要保持該有禮貌，畢竟禮多人不怪。

• 無論是否得到你想要的解答，記得感謝對方
  對方願意幫你，是他人很好而不是義務，就算沒有得到解答也要記得感謝對方，有禮貌對方下一次才會幫你。
• 在打電話給對方前，請先用文字簡述要討論的問題，並確認方便詢問的時間
  如果你直接打電話過去，對方可能在洗手間、會議中…無法及時接電話，並且也不知道接了這通電話要處理什麼事情，而且未經詢問直接打電話有點沒禮貌。
  筆者建議先用文字說明問題，讓對方有思考的時間，這樣可以有效提升討論品質。
• 如果真的有緊急事件需要用通話
  有時會開到一半發現需要某個成員的參與，所以臨時把他拉到會議室。
  若有這種突發狀況，請記得開頭要先說一聲抱歉，並說明要找他討論的主旨，讓他知道突然被加入的會議要討論哪些內容。
• 不要問：「這個要怎麼做？」而是詢問：「這樣做的方向對嗎？」
  第一種詢問方式就像是自己沒有做過功課，第二種詢問方式則是讓對方做修正；大家都很討厭沒做功課就來問問題的人。

3.4 給出具體時間，避免使用模糊用語

當同事問你：「什麼時候東西才會完成？」請不要回答：「等一下就好！」而是說再等 30 分鐘這類具體的時間，因為每個人對「一下」是多少時間的認定是不同的；如果回答的人認為是 1 小時，而發問的人認為是 5 分鐘，就會造成不必要的摩擦。

有些主管在找下屬討論問題時會說：「下午幫我空出一個時間，要找你討論前端設計的問題。」此時千萬不要回答：「好！」你應該要直接提出一個具體時間詢問主管是否方便，如果沒有明確的時間，會導致你無法安排需要高度專注力或是長時間作業的任務。

4. 建立友善的溝通環境

不要說新手，就算是職場上的老鳥，在與同事溝通這塊也經常碰壁；這種情形在跨團隊溝通時遇到的頻率更高，總覺得其他團隊的人在針對我們。

這邊先排除辦公室政治那種拒絕溝通的情境，而是去思考：「如果我們的共同目標是希望讓公司更好，有什麼方法能創造出共贏的局面呢？」

4.1 面對想法意見不同的人，不要先入為主

如果想透過說服對方達成共識，那很容易就把彼此拉到了對立面；即使你成功說服對方，他也未必會真心一起共事。

很多時候在談判前，我們會很自以為是的覺得自己已經了解對方在想什麼了，然後很急迫地把自己的想法加諸到對方身上，不給對方開口的機會。

也許你曾經透過這個方法獲得談判的勝利，但你勝利的原因可能只是因為你的口才比較好；過去的經驗告訴我，這個方法是在封閉彼此溝通的橋樑。

與其一直表達自己的想法，不如嘗試另一條路，詢問對方為何會這麼想，讓對方描述更多想法的細節；在了解對方完整的想法後，用討論的方式詢問對方是否有思考到完整的情境；也許深入探討後你會發現自己的想法是有漏洞的，討論的目的是做出更好的決定，在討論後選擇對方的意見不是認輸，而是達成彼此的共識。

4.2 不是所有人都跟你有相同的知識背景

有時你會在心裡 OS：「這東西這麼簡單，為什麼跟其他部門解釋了好幾次他們還是聽不懂？」會這樣是因為你認為簡單的東西，對其他領域的人而言可能是天書。

每個行業都有自己的專業術語、不同的部門對同一個名詞也會有不同的解釋；如果你今天擔任的角色需要協調各部門的資源，你就要像是個翻譯員，把資訊轉換成他們可以迅速理解與吸收的語言；有時不是其他部門不想配合，而是因為他們真的聽不懂，所以無從配合，資訊轉換也絕對不是一門簡單的功夫，因為你需要對合作部門的業務有一定程度的理解。

備註：筆者認為資深員工最大的價值並不是他擁有的技術，而是他在這間公司的影響力、人脈，以及對各部門業務的熟悉與理解，有能力串連各部門共同完成任務的員工，是公司寶貴的資產。

後記

不會永遠都會有人給你合適的職場建議。

工程師剛進入職場時，能夠在帶你的前輩身上學到很多的技術與經驗。

在你成為老鳥後，你可能要獨自負責一個專案，此時主管能給你一些戰略上面的建議。

但當你成為主管後，你需要同時處理多個專案；到了這個階段，比你更高階的長官因為不了解這些專案的細節，所以很難給出有效的建議。

職涯的前期你會獲得解決問題的標準答案；但隨著你的成長，在未來無論是專案的決策、還是做事的方法，都不會有一個標準答案。

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

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

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

我一定要把你帶好，如果我不把你拉上來，那誰把我推上去。

每間公司在新人教育訓練上，願意投資的資源落差很大；有些有完整的制度與流程，讓新人一步步走上軌道；而有些則是放牛吃草，讓他自行摸索。

筆者這幾年觀察下來，除非新人天賦異稟、經驗豐富，不然讓他自行摸索其實是跟自生自滅一樣的。作為公司的前輩，也許我們可以換位思考：「如果今天到了一個新的工作環境，我希望可以得到哪些幫助？」

大綱

1. 新人報到前的準備工作
   • 1.1 申請 VPN 連線
   • 1.2 註冊公司內部協作平台
   • 1.3 設定內部 Server 登入權限
   • 1.4 整理技術相關文件
   • 1.5 整理工作相關文件
2. 新人入職後的協助
   • 2.1 讓新人對公司有好感
   • 2.2 了解新人的能力，用合適的方式做教育訓練
   • 2.3 最終目標是讓新人有獨立作業的能力

1. 新人報到前的準備工作

隨著公司的擴張，會有越來越多人加入團隊來分擔你的工作，此時你需要準備交接文件，以保證他們會成為團隊中的神隊友；而不是增加你工作份量的豬隊友，這篇文章我會列出自己在交接時準備的東西。

1.1 申請 VPN 連線

因為疫情關係，越來越多公司的 IT 部門採取遠端工作，但許多工作上的資料以及開發環境都在公司內網。

所以在新人報到前，你要先幫忙申請 VPN 帳號，常見的 VPN 連線方式有 PPTP、L2TP。

這邊筆者要特別提醒一下，因為安全性問題，Mac 從 Catalina 這個版本開始就不支援 PPTP 的連線；建議還在使用 PPTP 來做 VPN 連線的公司，可以考慮換一個更安全的連線方式。

1.2 註冊公司內部協作平台

如果公司內部有專案管理系統（ex：Jira、Zentao、Redmine）或是軟體開發平台（ex：GitLab），請先幫新人註冊好帳號，並列成清單讓他們知道不同協作平台的功能。

1.3 設定內部 Server 登入權限

通常會根據專案的測試進度部署到不同環境：

• DEV 開發環境
  工程師內部開發與測試使用，功能穩定性不高，但版本都是最新。
• QA 測試環境
  工程師開發完成，並通過自己 Unit Test 的驗證後，會交給公司的測試團隊在這個環境做各式各樣的測試。
• PROD 正式環境
  測試部門確認功能穩定且通過壓力測試後，就能部署到正式環境。

這三個情境會對應到不同的 Server，筆者建議一開始只給新人登入 DEV Server 的權限，等到熟悉環境後再慢慢把 QA、PROD 的操作權限給他；避免新人在不熟悉環境的狀態下操作，導致不可挽回的後果。

備註 1：建議設定 alias name 來登入 Server，用 ip 登入只要一時眼花手滑就可能導致悲劇。

備註 2：如果公司有導入 CI/CD來做部署，或是由專人負責部署作業，就能大幅降低錯誤操作的可能性（通常 QA、PROD 除了環境變數外，其他設定都是一樣的，以此保證部署的穩定性）。

1.4 整理技術相關文件

• Coding Style（程式碼風格）
  一樣米養百樣人，工程師來自五湖四海自然風格迥異，公司可以使用 ESLint 這類工具來約束風格，但程式碼的效能、長度、分類…很多事情還是需要有前輩跟新人說明。

• Deploy 的方式
  如果團隊有導入 CI/CD，你就要跟對方解釋清楚哪些 branch 在 merge 時會自動 Deploy 到對應的 Server。

  警告：如果有設計這種依照 branch 更新做自動部署的功能，建議將新人的權限設定為 Developer；避免他推送更新到受保護的 branch。

• 專案文件
  大概可以分成：專案架構文件、API 功能說明文件、過去開發的需求規格這 3 種；基本上這些文件是為了讓對方快速了解專案的結構，而不是讓他了解每一行程式碼的意義。

• 會用到的相關技能
  假設公司今天來了一個後端工程師，他過去的工作經驗是用 PHP 開發，但現在公司的專案是用 Node.js 開發；儘管都是後端工程師，但兩者的技能樹存在一定的差距。
  如果知道新人有這種狀況，除了「相關技能」外，我還會準備「基礎知識」的學習連結，讓他可以快速上手，舉例來說：

  • 基礎知識

    • Node.js 的 iT 邦幫忙鐵人賽系列文。

      由有經驗的人來挑選學習素材，較能分辨誰寫的文章更適合新手入門。

  • 相關技能
    • 如何用 POSTMAN 測試 API、切換執行環境、建立 Mock Server，連結。
    • API 文件的撰寫格式，以及產生的方式。
    • 團隊 Git Flow 規則。

• Debug 的基礎知識
  筆者發現有些新人缺乏 Debug 的基礎能力，講解了好幾次他還是跑來問你類似的問題；我相信這個問題不只發生在筆者身上，所以建議大家可以寫了一份文件說明 Debug 的基礎知識，內容包含：

  • 如何印出錯誤訊息。
  • 設計程式斷點，縮小錯誤範圍。
  • 理解錯誤訊息。
  • 判斷是因為程式邏輯造成的錯誤，還是運行環境導致的問題。
  • 解決問題的方向，可以參考的資源。

1.5 整理工作相關文件

• 列出例行公事清單
  列出團隊、部門、公司的例會時間點，並簡述參與人員、討論內容；讓新人日後參與會議時能搞清楚狀況。
  如果有要繳交週報、月報，會說明繳交的時間點並提供撰寫格式。
• 列出待辦事項
  新人會協助或接替你的工作，因此你可以先將手中待完成的任務做一個難易度排序，先將簡單的任務交給新人，觀察他的完成度及適應性。
• 提點行政庶務
  新人剛入職時誰都不認識，印表機不知道怎麼操作、專案管理系統不會用、電腦不會設定開發環境；你可以撰寫「秘笈」讓他了解遇到問題時可以向哪個窗口提問。
• 了解團隊中每個人的職權
  以一個雲端開發團隊來說，你需要讓新人知道遇到前端、後端、資料庫、伺服器…的問題時要找誰，讓他了解團隊每個人的職權，才能讓新人更快的融入團隊。
• 保密協議
  如果公司開發的專案有其機密性，記得提醒新進人員不可洩露專案內容。

2. 新人入職後的協助

如果沒辦法讓新人成為戰力，那當初根本沒有招募的必要。

很多人會以手上工作太多為藉口，不幫忙帶新人以及做教育訓練，但新人來公司就是為了分擔你過多的工作，如果不教他怎麼做事，你不是活該自己做到死？

2.1 讓新人對公司有好感

• 不要讓新人一入職，就感受到沈重的壓力
  有些公司會準備好一系列的新人教育課程，期待他可以快速上工；但如果這些課程排得太過密集、要記住的事項太多，坐在台下的新人可能聽到一半就魂遊太虛了，不要期待新人可以在短短的一天、一週就學會所有事情。

• 與新人建立連結，帶他熟悉周圍還境
  最輕鬆簡單的方式就是中午帶新人一起吃飯，在前往餐廳的路上，可以向新人介紹周圍的環境，像是餐廳、停車場、大眾交通工具等。
  到了餐廳坐下來後，大家可以在較為輕鬆的環境下再次自我介紹，可以多聊聊興趣、休閒活動，如果有共同興趣愛好可以更快建立連結。

  備註：有些人會自己帶便當，或是有午休的習慣；千萬不要把帶新人吃午餐當成 SOP，請先詢問對方的意願，搞不好新人更想自己一個人靜靜的午休，一起吃飯反而給他帶來更大的壓力。

• 安排資深員工協助新人
  無論有在完善的教育訓練、交接文件；新人總是會遇到一些「基礎、非專業」的問題，比如：「看不懂群組的特殊用詞、不知道適合向主管匯報的時間、不清楚辦公室的特殊禮節…」與其讓新人與公司的文化碰撞，不如安排一個資深員工在初期帶領他。

2.2 了解新人的能力，用合適的方式做教育訓練

請依據每個新人的狀況去調整教育訓練的內容，就像應屆畢業生跟有 5 年經驗的工程師；就算同為新人，但你肯定對這兩個人的能力期待有所不同，下面是筆者公司過去安排教育訓練的步驟：

• 應屆畢業生
  • SETP 1：熟悉工作會用到的技術
    應屆畢業生的技術通常跟工作會用到的技術有一定的差距，因此在入職後的 1~2 個禮拜，我會先讓他熟悉工作會用到的技術。
  • SETP 2：能使用工作的技術做出簡單的 Side Project
    在掌握基礎技術後，我會請他們花 2 週的時間寫一個 Side Project，主題不限。
    主要是藉由這個機會了解他們程式的撰寫風格，對技術理解的深度，這樣比較方便評估日後要安排的工作。
  • SETP 3：實作 Senior 工程師分配的小 Feature
    大約入職一個月後，才會請 Senior 工程師分配小 Feature 給新人，讓他們真正參與開發。
• 5 年工作經驗的工程師
  • SETP 1：有專人一對一帶他了解專案架構
    我們期待有經驗的工程師可以快速上手成為團隊即戰力，所以會帶他了解整個專案的架構；並期許他可以在 2 週的時間內對專案有基礎的認知，到達可以開發的地步。（熟悉的時間會依照專案大小而有所不同）
  • SETP 2：指派一些簡單的 Feature 觀察實作能力
    在對專案有基礎的掌握後，就會開始指派一些不影響系統主功能的簡單 Feature （ex：開發新功能、維護舊程式）。
    以此觀察新人對開發時程的掌控度、程式碼的自我要求、團隊的溝通能力，確認他的能力是否符合職位要求。

2.3 最終目標是讓新人有獨立作業的能力

• 用 Code Review 讓新人的程式能力提升
  在新人完成 Feature 發出 merge request 後，由團隊的資深工程師做 Code Review，告訴新人哪裡可以再做改善；這個步驟的好處有：
  • 新人日後寫程式時會特別注意這些問題。
  • 維護專案程式碼的水平。
• 透過 Scrum 機制讓新人融入團隊
  儘管新人主要是做被指派的任務，但透過 Scrum 的機制他可以：
  • 更清楚專案全貌，知道自己負責的 Feature 能幫上什麼忙。
  • 了解同事各自負責的領域、實作進度。
  • 透過報告工作進度，讓其他同事對自己的能力有更清晰的認知。
• 讓新人能自己解決問題，不要養成依賴的習慣
  在前期，有人協助新人可以讓他更快的適應環境；但這個幫助是有限度的，過度的幫助只會讓人養成依賴的壞習慣。
  如果遇到問題找前輩就能解決，那長期下來他就會放棄思考；因此在新人結束適應期後（大約 2~3 個月），筆者會有意識的讓新人知道：
  • 每個人的工作都很忙，遇到問題要先想辦法靠自己解決。
  • 在我有空的時候，你還是可以問我問題；但我只會給你解題的方向，不會直接告訴你答案。

後記

有些人喜歡在新人面前留一手，在教育訓練時故意漏講一些技術重點，害怕新人成長太快超越自己。

如果在 20 年前，這樣做或許能保留身為前輩的尊嚴；但現在時代不同了，即便你不教，網路上也有一堆免費資源供他學習；所以筆者建議不如做個順水人情，在教育訓練時盡心盡力，我相信新人也會對你更加尊敬。

幫企業培養人才，幫自己培養人脈；筆者認為這才是職場的正向循環。

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

參考資源

1. 新工程師報到，我該準備哪些東西來加快交接進度呢？(筆者部落格)

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

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

但如果在 Demo 時發生意外，不但會影響發表的成效，嚴重點甚至會影響到整個團隊的考績與年終。

為了避免憾事發生，筆者將在這篇文章講解專案 Demo 時的種種細節與技巧，並分享過往遇到的問題及解決方案，希望大家日後在 Demo 時都可以展現專案最好的一面。

大綱

1. 保證現場 Demo 穩定度，不打沒把握的仗
   • 1.1 Demo 前要盡可能的測試
   • 1.2 同事間的預演
   • 1.3 只用一台電腦做 Demo
   • 1.4 穿著得體、統一
2. 邀請「對」的人，不是「多」的人
3. 選擇合適的會議室
   • 3.1 會議室的座位只能多不能少
   • 3.2 將觀看 Demo 的最佳座位安排給 Key man
   • 3.3 測試現場投影機，並確認網路環境
   • 3.4 讓每個要上台 Demo 的人在講台試講一小段
   • 3.5 預定會議室
4. 在 Demo 過程中要注意的事項
   • 4.1 記得關閉會干擾 Demo 的軟體、網頁
   • 4.2 現場燈光控制
   • 4.3 讓每段 Demo 的時間都在掌控之內
   • 4.4 記得帶筆記本上台
   • 4.5 安排中場休息時間
5. 遠端 Demo 前要確認的清單
   • 5.1 確認雙方的畫面與聲音穩定性
   • 5.2 確認自己的網速是否足夠

1. 保證現場 Demo 穩定度，不打沒把握的仗

穩定比表現的突出更重要。

1.1 Demo 前要盡可能的測試

如果在 Demo 現場專案出包，你講的內容再好都無力回天了。

• 尋找可能存在的錯誤
  就算專案已經通過測試部門的審核，我還是強烈建議正式 Demo 前要窮盡各種可能來測試專案；萬一你真的發現錯誤，就算無法及時修正，至少可以避免 Demo 時操作到這個部分。
• 只 Demo 絕對不會出錯的內容
  重點：全部都要按造 SOP，絕對不要即興發揮！
  功能越多的專案，在 Demo 時就越要謹慎；如果你每次操作的路線都不一樣，萬一你在 Demo 現場把 Bug 測出來就真的完蛋了。
  不要認為自己沒有這麼衰，筆者已經親眼見證過好幾次地獄倒霉鬼的誕生了；所以建議：「乖乖的按照 SOP 來做 Demo，並且至少跑 3 輪，確認專案在這個流程絕對不會發生意外。」

1.2 同事間的預演

有時專案 Demo 會讓同事輪流上台演示自己負責的 Feature；這邊說一下預演的重要性：

• 預估每個人 Demo 所需的時間
  Demo 都是有時間限制的，如果某個人 Demo 的時間太長，會壓縮到其他人的時間。

  在大約了解每個人 Demo 需要的時間後，也比較好制定議程。

• 知道彼此會講的內容
  預演能讓其他同事知道你 Demo 時要講的內容，如果當天不幸發生了什麼變故還能協助支援。

• 微調內容
  基本上第一次預演會發現很多問題（ex：口條不流暢、內容不連貫…），需要彼此互相提醒才能在當天有好的表現。

1.3 只用一台電腦做 Demo

如果需要輪流上台請將資料都存到一台電腦上面，下面列舉在 Demo 過程中換電腦的缺點：

• 壓縮 Demo 的時間長度
  換一次電腦在快也要 30 秒，如果有 5 個人要上台就浪費了 2 分 30 秒。
• 打斷會議流暢程度
  每換一次電腦，投影幕畫面就會跳掉一次，這容易導致台下觀眾思緒抽離。
• 未知的風險
  換電腦可能導致投影幕有色偏、斷訊、閃爍的問題，雖然這不是專案本身的問題；但也容易遭到台下觀眾質疑團隊的專業能力。

1.4 穿著得體、統一

• 第一印象很重要
  建議男生襯衫西褲、女生職業套裝；千萬不要因為邋遢的打扮讓自己的專業被扣分。

• 穿著盡量統一
  如果每個人上台的穿著差異太大，可能導致觀眾把焦點轉移到人，而非在 Demo 的專案；所以這塊請事先溝通，最常見的是黑白搭配。

• 不要有異味
  有些人的汗腺較為發達，在夏天及緊張的環境更容易出汗；筆者建議隨身攜帶香水，讓觀眾在舒服的狀態下參與專案 Demo。

  在空氣不流通的會議室，這個問題更加明顯。

2. 邀請「對」的人，不是「多」的人

事半功倍 VS 事倍功半

• 重要的長官一定要出席
  Demo 的日期以 Key man 能參與的時間為主，如果最關鍵的 Key man 無法出席，你這次的 Demo 可以說有一半以上的意義都沒有了；因為就算有代理人出席，他也只能做到轉述，而轉述的效果就跟你分享電影情節給朋友的感覺差不多。
• 不要邀請一堆無關的閒雜人等
  有些會議為了要做排場給長官看，就邀請了一堆跟專案無關的人參與；這樣的做法除了會引起他人的反感外，甚至會造成台下一堆人在滑手機、做自己的事。

3. 選擇合適的會議室

如果可以絕對要提前場勘，不然很容易死得不明不白。

3.1 會議室的座位只能多不能少

• 確認參與會議的實際人數
  確認 Key man 可以參與的日期與時間後，再邀請與專案相關的人員一起參與會議；切記會議通知並不是發出去就沒事了，在會議開始的前 2 天，你要再次確認實際參與人數。
• 到現場確認有效座位
  有些會議室的結構比較特殊，部分的位置是看不到講台的，這塊在場勘的時候要特別注意。
• 保留 20% 的座位
  除了收到會議通知的人會來參加外，有時會有不在你邀請名單的長官或是同事出席；因此建議預留 20% 的空位給臨時參與的人。

3.2 將觀看 Demo 的最佳座位安排給 Key man

• 了解哪些座位擁有黃金視角
  因為大部分的會議室都是平面的，基本上只有前幾排可以看得清楚投影幕與 Demo 成員；你需要在場勘時就掌握會議室的座位圖，並了解哪些座位擁有黃金視角。

• 在入口處有專人引導
  為了保證 Key man 是坐在觀看 Demo 的黃金視角，筆者會建議安排專人負責引導 Key man 到座位上。

  也可以放座位名牌避免同仁誤坐。

3.3 測試現場投影機，並確認網路環境

• 測試投影機注意事項
  • 一定要用當天 Demo 的電腦測試，確認是否可以順利投影，以及投影的畫面是否有模糊、字體太小、色偏…等問題。
  • 同時記得確認投影機轉接頭是 HDMI 還是 RS232，現場是否有提供轉接頭還是要自己準備。
• 網路環境注意事項

  • 是否有穩定的 Wi-Fi 或是網路線連接口，建議拿當天會用的電腦直接測速會比較安全。

    有些公司的網路只能連接內網，如果你 Demo 會用到外網也須特別注意。

  • 有些會議室的收訊不佳，建議也要測試自己手機熱點的網速是否穩定。

3.4 讓每個要上台 Demo 的人在講台試講一小段

• 確認聲音大小
  每個人說話的聲音大小不同，同一個場地有人需要麥克風有人不需要，所以可以藉由試講來確認。
  另外如果場地較大，就算你的音量足夠也建議使用麥克風，因為很多場地有回音的問題。
• 熟悉講台的視角與站位
  如果有機會，建議要先上去熟悉講台的視角，這個動作可以消除部分恐慌的情緒。
  有些 Demo 會需要多人站在講台上，這部分一定要在現場走位過，不然很容易擋到投影幕以及要 Demo 的產品。

3.5 預定會議室

這邊筆者分享一些定會議室的注意事項：

• 一定要提早訂
  這種重要會議筆者一般會提前兩個禮拜預定會議室，因為公司通常沒有太多合適的大會議室。
• 確認會議時間沒有與公司例會衝突
  如果你專案的 Demo 時間與公司例會衝突，有可能導致部分原本會來的長官缺席，所以記得把時間排開。
• 保留緩衝時間
  除了 Demo 的時間外，前後都至少要留 1 小時來做緩衝。
  • 如果會議室上一批人剛使用完，可能需要進行場復作業。
  • 提早到可以再次確認與熟悉場地環境。
  • 後面多留一小時，是因為通常專案 Demo 都會 Delay 一點；並且讓會後交流的時間更充裕。

4. 在 Demo 過程中要注意的事項

這塊 PM 需要適時的去協助

4.1 記得關閉會干擾 Demo 的軟體、網頁

如果在 Demo 過程中跳出奇怪的訊息是非常尷尬的，而且訊息不斷跳出的提示音也很吵；Demo 時千萬不要犯下如此低級的錯誤。

下面列出幾個常用的的軟體、網頁：

• 通訊軟體
  LINE、Messager、WeChat…
  只要你的好朋友剛好在這個時間點傳送奇怪的訊息，你的個人隱私就會直接顯示在大螢幕上。
• 郵件
  我發現很多人都會忘記關閉郵件，筆者之前就曾看過同事 Demo 到一半，螢幕右上角跳出信件通知，主旨是：「XXX 公司錄取通知」；當時台下還有總經理，畫面有多尷尬我就不說了。
• 社群網頁
  Facebook、LinkedIn、Twitter…
  千萬不要忘記關閉社群網頁，他們的提示音也是很吵的。

4.2 現場燈光控制

在 Demo 過程中，你可以透過燈控引導觀眾的注意力，筆者大概分成 3 種：

• 只開講台燈（舞台燈）
  需要觀眾將注意力放在講者或是產品身上的時候，通常是講者剛上台做自我介紹，或是要展示產品的時候。
• 只開最後一排的燈
  希望觀眾仔細聆聽簡報的時候，在這樣的燈光下，有需要做筆記的人還是可以記錄。
  筆者不選擇將燈全關是因為：
  • 有些人的眼睛在全暗的狀態下看發光物體會有不適感。
  • 如果講者的表達能力不佳，在全暗的環境中台下會睡成一片。
• 全亮
  簡報結束與觀眾互動的環節，這樣講者與觀眾的互動比較友善。

4.3 讓每段 Demo 的時間都在掌控之內

有些與會者會不停拋出問題或意見來打斷 Demo 的過程，如果沒有阻止，會導致 Demo 時間脫離掌控。

這邊筆者建議引導他們等 Demo 結束後再發問，比如：「不好意思，我這邊先完成專案的 Demo，讓大家對專案有一個整體的概念；也許接下來的操作就能解釋您心中的疑惑，如果沒有，在 Demo 結束後我再回答您的問題。」

4.4 記得帶筆記本上台

通常在 Demo 的過程都是使用鏡像螢幕，因此在遇到發問時，你不方便使用電腦來記錄問題。

如果你在講台上用手機來紀錄問題，畫面也不太好看；所以筆者建議帶一本筆記本上台，好處有：

• 快速筆記
  有些人一次會拋出 4、5 個問題，如果沒有筆記本輔助，容易有問題遺漏沒回答到。

• 記錄需求
  Demo 結束後通常會得到很多反饋，如果沒有筆記本，光憑記憶是很難把這些全部記下來的。

  通常會安排一個同事來做會議記錄，雙重保險。

• 忘詞提示
  如果你對今天 Demo 的內容不夠熟悉，或是擔心自己緊張忘詞，你可以在上台前將重點記錄在筆記本上。

4.5 安排中場休息時間

如果議程超過 1.5 小時，絕對要安排休息時間！

無論在精彩的 Demo，觀眾的注意力還是有限的；建議 40~50 分鐘就需要休息一下，先讓大家喝杯水，5~10 分鐘後繼續。

這樣可以讓觀眾整理大腦新接收到的資訊，而會議主辦方也能利用這個空檔討論下面的議程是否需要調整。

如果主辦方沒有安排休息時間，一口氣給他講 2 個小時；相信我，這絕對是一場失敗的專案 Demo，因為幾乎沒有人可以維持長時間的注意力，通常這麼做的後果就是觀眾後半段的記憶接近空白。

5. 遠端 Demo 前要確認的清單

如果要向國外的客戶 Demo，又或是因為疫情影響需要在家 Demo。

5.1 確認雙方的畫面與聲音穩定性

因為是遠端，所以非常吃雙方的網路速度；有時畫面及聲音的延遲會造成溝通上的問題，筆者在正式 Demo 前會用以下方法維護會議品質。

• 主講者自我介紹
  讓每位主講者先簡單自我介紹，確認聲音的大小，避免有些人超大聲有些人超小聲。
• 只有主講者開麥克風
  遠端開會時除了主講者外其他人都要靜音，不然很容易會有雜訊。
• 建議購買麥克風，不要靠電腦收音
  如果有遠端 Demo 的需求，建議購買專業的麥克風收音，這樣可以大幅降低周遭環境音（ex：咖啡廳背景音樂、小孩哭鬧聲、鄰居吵架聲…）的干擾。

5.2 確認自己的網速是否足夠

• 使用 Wi-Fi 時注意不要互搶流量
  在家中通常是連接 Wi-Fi，但如果很多人共用這個 Wi-Fi 可能會導致Demo 品質不穩定；如果可以，建議大家在 Demo 時請其他人暫停使用 Wi-Fi。
• 確認自己的頻寬能否 Demo 需要高網速的頁面
  在載入圖片、影片資源時，會消耗很多的網路流量，這很可能造成你畫面卡頓甚至靜止，因此建議你先找朋友測試看看，以保證當天勤務萬全。

筆者碎碎念

Demo 過程發生的意外，對台下的觀眾而言是一種必然，因為他們只會聽一次而已；請不要讓這些可以控管的風險毀掉團隊努力的成果，每次 Demo 前都按照這份清單檢核一次吧！

如果大家還有遇到什麼狀況想補充的，請在底下留言告訴我，你無私的分享可以減少 Demo 時悲劇的發生～

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

參考資源

1. 專案 Demo 前的準備、細節、技巧(筆者部落格)

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

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

如果不會表達，那麼你的功勞不是你的功勞。

我想很多人跟筆者一樣，從小就被教導謙虛是美德、不要去邀功；相信皇天不負苦心人，默默地做總有一天會被看見的。

我們在電影中看到反派搶功勞會被主角教訓；但在現實生活中，搶走你功勞的人只會活得更好。

當然這篇文章不是教你搶功勞，而是分享幾個，讓你的努力效益最大化的方法。

大綱

1. 做重要的事
   • 1.1 了解公司目標
   • 1.2 你完成的 Feature 重要嗎？
   • 1.3 主管分配任務給你，跟你主動去要任務是不同的
   • 1.4 如果公司願意把一個高難度的專案交給你
2. 讓自己的努力被看到
   • 2.1 即時匯報進度
   • 2.2 不只完成專案，還要宣傳專案
   • 2.3 專案結束後，要主動去拿獎勵
3. 提升在團隊內的影響力
   • 3.1 主動幫助同事
   • 3.2 讓團隊成員有更好的獨立作業能力
   • 3.3 不要只想著表現自己，分功勞未必是個零和遊戲
4. 增加在公司的影響力
   • 4.1 開會時，你代表的是部門
   • 4.2 如何在沒有權力的狀態下創造影響力
   • 4.3 把握上台機會

1. 做重要的事

花一樣的力氣做事，當然選效益最高的。

很多人天天加班，覺得自己為公司賣命應該要獲得對應的報酬；但這一切往往事與願違。

很多人都會把矛頭指向「個人能力」或是「慣老闆」身上；儘管這兩點也是原因之一，但筆者想從「做事」的角度跟讀者分享，也許我們過去所認為的努力，對公司來說毫無意義。

1.1 了解公司目標

有些人埋頭苦幹做了一堆專案，認為自己績效斐然值得嘉獎；但是否值得嘉獎是由專案帶來的效益所決定的。

你的專案要跟公司的商業目標一致，不然你做的專案再多、再好，公司裡面沒有業務幫你推，你再怎麼加班也是白忙。

相反的，如果你做的專案可以讓業務更輕鬆的銷售產品，提升公司業績；就算你只做一個專案，也能讓你在公司有更高的地位。

1.2 你完成的 Feature 重要嗎？

也許你的技術很頂尖，特別喜歡攻克專案裡面困難的 Feature；但幾年之後卻發現周圍技術能力普普的同事都升官加薪，而自己卻還在原地打轉。

此時請不要抱怨職場不公平，你應該要先審視自己完成的 Feature 為公司或是團隊帶來多少利益；無論你攻克的 Feature 有多難，如果它只有 1% 的使用者會用到，從公司的角度而言你是沒有多少影響力的。

反觀你周圍技術普普的同事，他們用框架快速完成系統的主功能，又用簡單的技術完成了很多實用的 Feature；即便難度不高，但從公司的角度來看，是這些人撐起了系統的運轉。

如果你是老闆，在升職加薪的時候，你會選擇誰？這是一個資本主義的社會，並不是你選擇困難的道路就會獲得更多回報。

1.3 主管分配任務給你，跟你主動要到任務是不同的

如果你不主動爭取，通常最後被分到的都是低價值任務；要嘛難度很高，要嘛毫無價值。

• 為什麼要主動爭取任務？
  每個人的時間都是有限的，如果你長期接手低價值任務，你與周圍同事的差距會越來越大；大部分的人上班都是為了錢，為什麼不去主動爭取高價值任務？
  就算任務的內容完全一樣，但你完成被分配任務只能說是合格；而你完成主動要到任務卻是達成目標，被動跟主動給人完全不同的觀感。
• 如果始終無法獲得高價值任務
  如果主管明顯特別照顧某個同事，即使你主動要求也無法獲得高價值任務；筆者建議直接跟主管敞開了聊，不要在那邊用猜測的方式揣摩上意。
  假使聊完後你還是被分配低價值任務，那你也可以心無罣礙的離開；人生很短，不需要堅持在不合適的環境中成長。

1.4 如果公司把一個高難度的專案交給你

先判斷這個高難度的專案能否給你帶來成長，再去思考這個專案對公司而言的重要程度。

如果評估後是有價值的，請勇敢的接下來；有價值的任務，你不接還是會有人接的。

也不要過度擔心自己做不來失敗的後果，老實說就算真的失敗了，損失最大的是公司，你最慘就是換一間公司；既然公司願意冒這個風險把任務交給你，那就放手一搏吧。

如果你不打算庸庸碌碌過一生，機會來的時候就必須冒險；如果你把握住了，它們是升職加薪非常重要的談判籌碼。

突破舒適圈未必會獲得物質上的獎勵，但肯定能讓你的視野上升一個台階。

2. 讓自己的努力被看到

大部分工程師的思考都是線性的，就像是遊戲關卡一樣，我們覺得完成了手上的專案就會獲得回報；但現實生活不是遊戲，絕大多數的時候你完成專案只會被當作理所當然；你不說，沒人會知道你付出了多少心血。

2.1 即時匯報進度

每做到一個里程碑，你一定要即時匯報進度，不要總是等別人來問你。

• 為什麼要匯報進度？
  • 讓主管方便評估時程
    職場與學校不同，學校有交功課就完事了；但職場會有 30% 進度、70％ 進度，你要讓主管掌握你的進度，他才能評估要安排多少任務給你做。
  • 讓同事掌握進度
    有些合作的任務是有順序性的，你完成了如果不吭聲，很可能壓縮到後面接手同事的工作時間。
    像是做網頁時，如果後端完成後拖到最後一刻才跟前端說，就會壓縮到前端串接後端 API 及確認功能穩定性的時間。
• 匯報的內容要有哪些？
  • 目前進度
    說明你的進度是按照預想的、超前的，還是落後的。
  • 這次你做了什麼
    要強調最終的結果，而不是努力的過程；大家時間有限，不要模糊焦點。
  • 接下來的任務
    說明接下來任務的時程規劃。
• 主動匯報進度的好處

  • 讓你擁有安排進度的主控權
    如果你每次都能按時完成任務，那主管在問你需要多少時間完成任務時，你報出來的工作天數通常都會被接受。

    假使你常常無法準時完成，或是浮報太多工作天數；這些破壞合作信用的行為，會換來主管每天緊迫盯人。

  • 讓自己的存在感強烈
    公司人太多，就算是直屬主管也未必知道你所做的事情；不要等到加薪前才刷存在感，只要有成果便要匯報，讓主管覺得你持續有產出。

2.2 不只完成專案，還要宣傳專案

筆者身旁有朋友明明是專案的主力開發工程師，但在專案取得成功後升官拿獎金的都不是他；一開始他在跟我抱怨的時候，我覺得這應該是公司制度的問題，但每隔幾個月他就會約我出來借酒消愁痛罵公司。

幾次之後我也感到很納悶，以我對朋友的了解，他的技術能力肯定沒問題，不然不會每次都擔任專案的主力開發工程師；但為什麼他都沒有得到應得的報酬？

後來跟朋友細聊專案流程才發現，儘管程式大部分都是他寫的；但在專案完成後都是由主管或同事向高層匯報，向業務做 Demo 的時候他也只是坐在台下讓同事講，因為他認為自己負責開發已經夠辛苦了，這些雜事交給其他同事處理就好。

原本這種各司其職的想法也沒錯，但是有些公司只看得到在做宣傳的人，看不到在做事的人；如果你主管匯報時沒有向高層提及你的功勞、同事在 Demo 時沒有放上你的名字，那你所有的努力都是在做白工。

寫專案固然辛苦，但這個專案是否能帶來收益，要看公司是否採納，業務是否願意推廣；公司的專案那麼多，如果不主動宣傳自己的專案，就算做得再好也沒有意義，因此下次完成專案後，請爭取宣傳專案的機會。

2.3 專案結束後，要主動去拿獎勵

不管你的程式寫得再好、功能多麼穩定；你在主管眼中只是一個合格的工程師而已，況且主管未必會去看你寫的 Code。

• 把自己跟專案的成功綁在一起
  一個人的成功，是需要其他同事的肯定、主管的提拔；如果你沒有適時向他們展示你的成果，那你的努力也會隨著專案結束一起消失；至於要如何表現自己，可以參考以下方案：
  • 技術分享會
    如果你在這個專案中用了新的技術，你可以舉辦一個技術分享會向同事以及長官分享。
    • 這個技術的優點
    • 它解決了哪些問題
    • 你遇到問題有多難，如何克服
    • 它幫公司賺了/節省多少錢
  • 提醒主管不要忘記你的好處
    跟主管聊天時，主動提起自己自己的貢獻與影響力；千萬不要怕邀功，你不說，就算別人都看在眼裡也不會給你應得的獎勵。
  • 爭取向高層匯報、向業務簡報的機會
    如同上個小節所說，專案做完後是需要宣傳的，如果你獲得宣傳者的角色，並成功讓高層與業務採納，你將是這個專案最大的受益者。

3. 提升在團隊內的影響力

你有可能因為工作績效而獲得加薪；但如果想要升官，跟同事打好關係、提升團隊績效也是重要的條件之一。

拍馬屁、玩政治、當聽話的狗也是有效的升官的方式；但這些實際操作起來非常依賴個人特質，並不適用於每個人，因此本文不討論這塊。

3.1 主動幫助同事

公司要提拔一個人，除了專業能力的評估外，也會看他跟同事相處如何；你總不會想提拔一個經常跟周圍同事鬧不合的獨行俠吧？

如果你所處的組織比較龐大，主管並不會知道你每天在做什麼，但周圍跟你合作的同事都很清楚；當有合適的缺空出來，而主管無法準確判斷要將誰升官時，就會詢問同事日常跟誰合作較為愉快；所以是否能被提拔，周圍同事的評分也是重要的參考意見。

3.2 讓團隊成員有更好的獨立作業能力

應該很多由技術轉管理職的新手 Leader 都面臨過以下問題：

• 把任務指派下去後，成員不停再追問細節。
• 成員把任務做到一半就停下來了，他們不知道接下來要做什麼。

遇到這類狀況時，有時不禁會想：「這些問題這麼簡單，為什麼這點小事都要我來做決定？你們沒有基礎的判斷能力嗎？」

除了成員經驗不足容易有這些問題外，也有可能是你在分配任務時只說有哪些任務要做，而沒說明為什麼這麼做、這個任務的目標是什麼；如果願意花多一點的時間說明與撰寫完善的需求規格，成員在了解來龍去脈後，很多細節與流程他們就能夠自己決定了。

3.3 不要只想著表現自己，分功勞未必是個零和遊戲

從短期來看，在團隊中搶功勞的人可以快速升職加薪；但同事也不是傻子，有誰願意跟愛搶功勞的人合作？

如果你願意在彰顯自己功勞的同時也把其他同事帶上，你在同事裡面會獲得更多的聲望；功勞就像是一塊蛋糕，但分功勞也未必只是一個零和遊戲，把蛋糕做大，所有人都能獲得回報。

每個人的性格都不同，有些人在做事上面是一把手，但如果你要他上台跟要了他的命一樣；因此這類有生產力的人容易被組織所忽略，假使你願意在專案宣傳的時候，於簡報的最後一頁放上團隊名單，並說出感謝的話，也許你會獲得意想不到的回報。

筆者感謝結語範例：「很榮幸今天可以跟各位長官分享我們團隊完成的專案，在這裡要先感謝 XXX 經理在這段時間四處奔波，在他的領導下專案才能進行的如此順利；在開發的過程中，XXX 資深工程師也花了很多心力在攻克幾項技術難題，以保證我們系統的穩定性…謝謝大家，我是 XXX，再次感謝各位長官的蒞臨。」

• 感謝結語建議結構
  • 先感謝主管，稱讚領導有方。
  • 接著提到專案中的靈魂人物。
  • 最後再說一次自己的名字，增加長官們對你的印象。

4. 增加在公司的影響力

讓公司更多人記住你的名字、知道你在做的專案；之後在跨團隊合作的時候會輕鬆許多。

4.1 開會時，你代表的是部門

組織一大，辦公室政治幾乎無法避免；每個部門都想要爭取話語權與資源。

如果你只需要面對工程師團隊，大部分的時候還可以就事論事；但如果你的位置會需要接觸業務單位，面對這群非常擅長嘴砲溝通的人，工程師在開會的時候非常容易處於被動狀態。畢竟業務單位每天的工作就是溝通與談判，雙方的經驗值差距太大。

但請不要忘記，出來開會你代表的是部門；假設今天這場會議其中一個環節是由你來做專案的 Demo，你就要有被業務單位 Challenge 的心理預期，對方可能在你 Demo 到一半的時候就直接打斷你、對專案指手畫腳。此時筆者建議你要掌握會議的主導權，如果你在 Demo 時頻繁回答對方的提問，會造成其他與會者無法連貫吸收專案內容。因此筆者會說：「不好意思，我這邊先完成專案的 Demo，讓大家對專案有一個整體的概念；也許接下來的操作就能解釋您心中的疑惑，如果沒有，在 Demo 結束後我再回答您的問題。」

在 Demo 結束時，往往會收到很多的回饋；你可以記錄需求，但千萬不要隨便承諾，你在開會所說的話都是代表部門，如果沒有經過內部的討論就亂給承諾，你在團隊內部會被排擠，在其他團隊也會失去信任。

話語的主導權並非看一兩本書就能夠學會，需要經過多場實戰才能有所提升；筆者認為開會時的心態最為重要，不要一被質疑氣勢就落入下風，謹記出來開會，自己是代表部門！你希望別人怎麼看待自己的部門，你就要表現出什麼態度。

備註：你要搞清楚自己代表的角色，是公司、部門、團隊還是自己；代表不同角色時，說話的份量差異會很大，因為對方還需要顧及你身後的人。

4.2 如何在沒有權力的狀態下創造影響力

• 每個人都曾在沒有權力的狀態下影響過別人的決定
  回想進入公司前的面試，你要在短短 1 小時的時間內取得陌生人的肯定，最終獲得 Offer；此時你在這間公司是毫無權力的，卻能夠影響長官的決定。

• 你成為了主管，但並沒有對其他部門發布命令的權力
  在成為主管後，你能夠組織團隊成員做事；但很多時候一個專案需要跟多個部門合作，你可能會接觸到：「市場部門、行銷部門、品管部門…」而這些部門你都是沒有權力下達命令的。
  對你來說是主任務，但對其他部門可能而言可能只是次要任務；你需要創造一個讓對方獲利的理由，他才有可能配合你，共贏的完成這個專案。

• 有影響力的是人，不是強而有力的數據
  假設你收到公司指令，要負責推行一個專案管理系統，通常情況下，除了自己的部門外，其他部門在推的時候會遇到非常大的阻礙。

  很多人會覺得這是公司高層下的指令，各部門應該會配合；但以筆者的經驗來說，願意在初期配合的幾乎不存在…

  • 不要用產品說服對方
    為了要增加使用人數，筆者曾像推銷員一樣到各個部門說這個產品有多好用、幫自己部門提升了多少工作效率；但成效很差，因為大家現在事情都做得好好的，根本沒理由去學一個要重新熟悉的產品。

  • 由對方創造需求
    後來筆者在推這個專案管理系統前，改成先用聊天的方式跟其他的部門的 Leader 了解：

    • 部門現在面對的挑戰是什麼？
    • 未來 1~3 年的戰略目標

    先用同理心去傾聽對方的回答，適時地引導對方來詢問你有什麼好的建議；此時你再說出自己部門目前有在用這套專案管理系統，且透過它提升了不少工作效率，如果對方想更近一步了解再跟他做介紹；談話重點就是先用問題引導對方去思考，而不是直接告訴對方你覺得這樣做更有效。

4.3 爭取上台機會

害怕上台是人性，但當你走上台從聽眾變成講者時，你所擁有的是更多的機會。

• 增加自己在公司的存在感
  很多工程師對上台報告很抗拒，害怕自己報告的不好會拖團隊的後腿；但這樣長久下來，你在組織中會變成一個隱形人，幾乎沒有影響力；不過如果你願意上台報告，就算你表現得不夠好，至少也讓公司更多的人記住你。

  很多時候，你比自己想像的還要更厲害。

• 從觀眾的角度出發，準備對方感興趣的內容
  有些人站到台上後，會瘋狂的向台下輸出自己的專案有多好、產品的功能有多強；台上講的激情四射，但台下睡眼朦朧，會發生這種狀況是因為你一直在講你想講的，而不是台下觀眾想聽的。
  以筆者要跟業務單位宣傳團隊的專案來做舉例，我會重點描述下面 3 點：

  • 專案能幫客戶解決哪些問題
  • 這個專案預計的定價與目標市場
  • 業務要如何向客戶介紹我們的專案

  想要讓業務願意推銷團隊的專案，筆者認為重點是產品有用、利潤足夠、介紹輕鬆；把一條龍的服務做好，他們要做的事越少，專案推得越好。

後記

你想要當參賽者還是觀眾？

如果你想要在一間公司往上爬，無論人際關係處理得多好，都肯定會受到其他人的嫉妒；公司中想升官的絕對不只你一個，如果決定進入這場鬥爭，你就要有受傷的心理準備。

當參賽者還是觀眾都是自己的選擇，每個人在不同人生階段所能承受的壓力不同、職涯規劃也不同；並不存在選擇哪一個一定比較好，筆者只是建議你選一個 10 年之後自己不會後悔的選擇。

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

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

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

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

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

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

白板題跟系統設計問題的相同點，就是重視釐清問題與溝通。

相比於系統設計，白板題往往需要寫出能夠運行的程式，或者提供面試官認為可行性高的演算法；大部分的白板題難度會落在 LeeCode Easy 的等級，有程式基礎的人基本上都能夠給出答案，但除了給出答案外，程式的正確率與執行效率也會列入評分。

本篇文章筆主要是分享答題思路以及完善程式，演算法並非筆者所擅長；如果想提升演算法的能力，除了買一本書好好閱讀外，同時也要去 LeetCode 刷題累積實戰經驗。

有些公司是考 LeeCode Medium/Hard 等級的題目，除非天賦異稟；否則這個難度需要花大量時間（可能半年以上）練習，才能在現場穩定發揮。

大綱

1. 初探白板題
   • 1.1 白板題的類型
   • 1.2 過程有時比解答更重要
2. 設計一個簡易的抽獎程式
   • 2.1 問題敘述
   • 2.2 面試官為什麼會問？
   • 2.3 面試官想從答案確認什麼？
   • 2.4 筆者提供的簡答
3. 衍伸問題
   • 3.1 如果使用者輸入的機率有小數點呢？
   • 3.2 你有考慮到使用者可能輸入不合理的機率嗎？
   • 3.3 你會用什麼方式來驗證程式的正確性？
   • 3.4 留給讀者優化與思考的問題

1. 初探白板題

1.1 白板題的類型

白板題大概分成以下幾種形式：

• 在白板回答
  通常用白板回答的只要寫出演算法跟架構就好。

  相較於其他形式，更注重與面試官的「溝通」與「確認問題」。

• 紙上作業
  用來觀察求職者在沒有 IDE 輔助下，是否具備寫程式的能力。

  現在的 IDE 實在太方便了，函式會自動補全、錯誤會直接 Highlight，很多工程師脫離 IDE 後真的是武功全廢。

• 上機考
  通常會給你一個時間限制，要求你在時間內寫出一個可以 Run 的 MVP；大多數的面試官會看著你寫 Code 的過程。

  有些人會因為不適應有人盯著寫程式，導致現場發揮失常。

1.2 解題過程比解答更重要

也許你已經非常熟悉 LeeCode 的解題模式；但白板題跟 LeeCode 不同的地方在於通常沒有測資、題目相對模糊。

如果你接到題目就直接解題，可能會忽略一些隱性條件；在了解題目時如果發現模糊地帶，請與面試官釐清問題，有時自己想像出來的條件反而會增加題目的複雜度。

通常在你給出第一版的解答後，面試官會以你的解答為基礎循序漸進問一些延伸性的問題，這部分除了考核程式能力外，也是判斷求職者在開發過程中能否與團隊成員溝通；畢竟隨著專案規模的擴增，單打獨鬥的情境已不多見。

如果遇上你無法解決的白板題，請以積極的態度與面試官溝通你想到的解題方式和卡住的點；相比於求職者的程式能力，有些面試官更加看重求職者的人格特質；有些人也許程式能力不足，但能理解面試官的問題，並在討論過程中作出改善；若能在解題過程中被面試官視為有潛力的人才，也是有機會獲得 Offer 的。

備註 1：解題過程中並不是所有面試官都是以「討論」的形式與你溝通，有些是以「質問」的態度面對求職者；遇到用「質問」態度的面試官，你也要思考自己是否能夠與這樣的同事一起共事。

備註 2：白板題需要有良好的程式基礎與抗壓性，才可能在面試現場表現優良。

2. 設計一個簡易的抽獎程式

為了方便讀者閱讀與驗證，本篇文章以上機考的形式向大家分享。

2.1 問題敘述

請你設計一個抽獎系統，獎品有「一獎、二獎、三獎」，其餘都是感謝獎。

一獎、二獎、三獎的中獎機率可以自由輸入，若沒輸入則默認一獎（1%）、二獎（2%）、三獎（3%）。

時間限制：5 分鐘

2.2 面試官為什麼會問？

這個題目雖然簡單，卻有很多延伸的議題可以討論；是一個瞭解求職者基本功的經典題目。

2.3 面試官想從答案確認什麼？

• 你的程式是否保留擴充空間
• 你會用什麼演算法解決這個問題
• 是否有驗證使用者輸入的參數
• 如何驗證你的程式是符合需求的

2.4 筆者提供的簡答

在面對白板題時，筆者是先求有再求好；如果一昧追求高效但自己不熟悉的演算法，有時會有意想不到的錯誤。

筆者的邏輯是先把籤放入籤筒，再透過亂數抽獎印出結果，以符合題目的基礎要求為目標：

• 使用者可以透過調整參數變更中獎機率。
• 有默認的中獎機率：一獎（1%）、二獎（2%）、三獎（3%）。
• 用 Math.random() 函式模擬亂數抽獎。
• 會印出中獎結果。

// 寫一個函式，有默認的抽獎機率：一獎(1%)、二獎(2%)、三獎(3%)
function lottery(first_prize = 1, second_prize = 2, third_prize = 3) {
  let lickbox = [];
  // 放入籤筒
  for (var i = 0; i < 100; i++) {
    if (first_prize !== 0) {
      lickbox.push("一獎");
      first_prize--;
    } else if (second_prize !== 0) {
      lickbox.push("二獎");
      second_prize--;
    } else if (third_prize !== 0) {
      lickbox.push("三獎");
      third_prize--;
    } else {
      lickbox.push("感謝獎");
    }
  }
  // 抽獎
  console.log(lickbox[Math.floor(Math.random() * 99)]);
}
lottery();

上面的程式先不論演算法優劣，還有許多細節是沒有被考慮到的；在完成 MVP 後有些面試官會先問你：「之前有寫過類似的程式嗎？」如果沒有相關經驗就老實說沒有吧；接下來面試官會以這個程式為基礎，跟你討論哪裡還可以做改善。

3. 衍伸問題

3.1 如果使用者輸入的機率有小數點呢？

考點：求職者對浮點數的處理

很顯然，如果使用者輸入的機率包含小數點，現在的函式無法應付，下面是筆者的處理方式：

• 取得輸入得獎機率中最長的小數點有幾位（N）。
• 將所有得獎機率乘以 10 的 N 次方，這樣機率就沒有小數點了。
• 將 10 的 N 次方再乘以 100，以此為籤筒的總數量。

function lottery(first_prize = 1, second_prize = 2, third_prize = 3) {
  // 取得最長小數點
  let tmp = [first_prize, second_prize, third_prize];
  let longest = 0;
  tmp.forEach((prize) => {
    let after_point = prize.toString().split(".")[1];
    if (after_point) {
      if (after_point.length > longest) {
        longest = after_point.length;
      }
    }
  });

  // 讓機率變整數
  let multiple = Math.pow(10, longest);
  // 沒有用 Math.floor 會出現 js 小數點結尾的 bug，ex:11100.000000000002
  first_prize = Math.floor(first_prize * multiple);
  second_prize = Math.floor(second_prize * multiple);
  third_prize = Math.floor(third_prize * multiple);
  // 籤筒的總數量
  let max = multiple * 100;

  let lickbox = [];
  // 放入籤筒
  for (var i = 0; i < max; i++) {
    if (first_prize !== 0) {
      lickbox.push("一獎");
      first_prize--;
    } else if (second_prize !== 0) {
      lickbox.push("二獎");
      second_prize--;
    } else if (third_prize !== 0) {
      lickbox.push("三獎");
      third_prize--;
    } else {
      lickbox.push("感謝獎");
    }
  }
  // 抽獎
  console.log(lickbox[Math.floor(Math.random() * (max - 1))]);
}
lottery(1.11, 2.34, 3.567);

3.2 你有考慮到使用者可能輸入不合理的機率嗎？

考點：能舉例會發生錯誤的情境，並設計程式來驗證傳入的參數

如果沒有對輸入參數做驗證，程式的穩定性真的是極低，下面列舉幾個要做的基礎驗證：

• 中獎機率不可能超過 100%，如果一獎、二獎、三獎加起來超過 100 是不合理的。
• 中獎機率要是正數，輸入負的機率也是不合理。
• 如果參數輸入文字或是符號就一定是錯的。

這邊筆者透過撰寫一個函式（validate_input）來驗證輸入的參數，如果不符規則就會跳出錯誤訊息。

function validate_input(first_prize, second_prize, third_prize) {
  // 確認是否為正數
  var reg = /^(?=.+)(?:[1-9]\d*|0)?(?:\.\d+)?$/;
  if (!(reg.test(first_prize) && reg.test(second_prize) && reg.test(third_prize))) {
    console.log("請確認輸入參數皆為正數！");
    return false;
  }

  // 確認沒爆表
  if (first_prize + second_prize + third_prize > 100) {
    console.log("中獎機率超過 100 %，爆表了！");
    return false;
  }
  return true;
}
const argsArray = [
  [100, 2.34, 3.567], //中獎率不可能超過100
  [-1, 2.34, 3.567], //機率不可為負
  [1, "錯誤", 3.567], //含有文字
  [1, 2.34, 3.567],
];
argsArray.forEach((args) => {
  console.log("驗證: " + args);
  validate_input.apply(this, args);
});

3.3 你會用什麼方式來驗證程式的正確性？

考點：是否有自動化的測試方案來驗證程式

程式的正確性並不是用嘴說的，面試官想了解你會用什麼方法驗證程式的正確性。

筆者這邊會寫一個測試函式來蒐集抽獎結果，並對原本程式做如下調整：

• 籤筒會反覆使用，所以把它獨立成函式（initLickbox）。
• lottery 函式改為純粹抽籤用。
• 建立測試函式（qa），可調整測試次數，在執行時會印出實際機率與期望機率的比對。

這裡附上調整過的完整程式：

function initLickbox(first_prize = 1, second_prize = 2, third_prize = 3) {
  // 先驗證輸入參數
  if (!validate_input(first_prize, second_prize, third_prize)) {
    return;
  }
  // 取得最長小數點
  let tmp = [first_prize, second_prize, third_prize];
  let longest = 0;
  tmp.forEach((prize) => {
    let after_point = prize.toString().split(".")[1];
    if (after_point) {
      if (after_point.length > longest) {
        longest = after_point.length;
      }
    }
  });

  // 讓機率變整數
  let multiple = Math.pow(10, longest);
  // 沒有用 Math.floor 會出現 js 小數點結尾的 bug，ex:11100.000000000002
  first_prize = Math.floor(first_prize * multiple);
  second_prize = Math.floor(second_prize * multiple);
  third_prize = Math.floor(third_prize * multiple);
  // 籤筒的總數量
  let max = multiple * 100;

  let lickbox = [];
  // 放入籤筒
  for (var i = 0; i < max; i++) {
    if (first_prize !== 0) {
      lickbox.push("一獎");
      first_prize--;
    } else if (second_prize !== 0) {
      lickbox.push("二獎");
      second_prize--;
    } else if (third_prize !== 0) {
      lickbox.push("三獎");
      third_prize--;
    } else {
      lickbox.push("感謝獎");
    }
  }
  return lickbox;
}

function lottery(lickbox = []) {
  let max = lickbox.length;
  // 抽獎
  let result = lickbox[Math.floor(Math.random() * (max - 1))];
  return result;
}
function validate_input(first_prize, second_prize, third_prize) {
  // 確認是否為正數
  var reg = /^(?=.+)(?:[1-9]\d*|0)?(?:\.\d+)?$/;
  if (!(reg.test(first_prize) && reg.test(second_prize) && reg.test(third_prize))) {
    console.log("請確認輸入參數皆為正數！");
    return false;
  }

  // 確認沒爆表
  if (first_prize + second_prize + third_prize > 100) {
    console.log("中獎機率超過 100 %，爆表了！");
    return false;
  }
  return true;
}
function qa(test_times = 10000) {
  // 設定中獎機率
  let first_prize = 1.5,
    second_prize = 2.33,
    third_prize = 3.98;
  let thanks_prize = 100 - first_prize - second_prize - third_prize;
  let lickbox = initLickbox(first_prize, second_prize, third_prize);
  let first = 0,
    second = 0,
    third = 0,
    thanks = 0;
  for (var i = 0; i < test_times; i++) {
    let result = lottery(lickbox);
    if (result == "一獎") {
      first++;
    } else if (result == "二獎") {
      second++;
    } else if (result == "三獎") {
      third++;
    } else {
      thanks++;
    }
  }
  console.log("一獎:" + ((first / test_times) * 100).toFixed(2) + "% (" + first_prize + "%)");
  console.log("二獎:" + ((second / test_times) * 100).toFixed(2) + "% (" + second_prize + "%)");
  console.log("三獎:" + ((third / test_times) * 100).toFixed(2) + "% (" + third_prize + "%)");
  console.log("感謝獎:" + ((thanks / test_times) * 100).toFixed(2) + "% (" + thanks_prize + "%)");
}
qa();

// console.log(lottery(initLickbox()))

圖片為程式測試的結果：

3.4 留給讀者優化與思考的問題

上面只是筆者在面對白板題時的簡單發想，這邊還有一些問題留給讀者思考：

• 需不需要限制浮點數在小數點後的位數？
• 筆者的解決方案超級土法煉鋼，有沒有更好的演算法可以優化？
• 如果改成抽籤不放回的機制，程式要如何調整？
• 假使有四獎、五獎、六獎…程式架構要如何優化？

即使是抽獎系統這種看似簡單的題目，如果深入探討還是有許多的細節需要完善。

筆者上面所提出的衍伸問題，其實是求職者一開始要跟面試官釐清的細節，如果能夠在開始作業前就定義好需求，在開發的過程中就能避免不合適的設計。

不過有些面試官會傾向等求職者完成 MVP 後再做細節討論，筆者就曾遇過面試官出完白板題後就離開 15 分鐘讓求職者作答；所以實際狀況還是需要讀者在現場隨機應變。

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

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

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

擅長嘴砲溝通的人在這個環節有較多優勢。

其實前面 10 幾篇文章的內容都是系統設計的一環，只是問題的方向是從你過往的履歷、技術或是面試公司的需求出發，透過詢問細節來評核你技術的硬實力。

再確認求職者的硬實力過關後，有些面試官會給你一個情境來做系統設計；然後依據你在這道題目上的應對進退，決定要給你 Junior 還是 Senior 的職稱。

如果你面試的職缺是 Tech Lead，這題回答得不好有高機率直接出局。

大綱

1. 初探系統設計
   • 1.1 Junior 跟 Senior 工程師的差異
   • 1.2 系統設計的題目來源
   • 1.3 面試官在找的是同事
2. 如何設計一個像 Facebook 的社交平台
   • 2.1 縮小問題範圍，確認具體需求
   • 2.2 先提出一個簡單的解決方案
   • 2.3 提出減少耗能的解決方案
   • 2.4 從自己擅長的面向切入
   • 2.5 不要有預設立場
   • 2.6 主動提出不同設計的優缺點
3. 衍伸問題
   • 3.1 你有使用過 Mind Map 跟 Sitemap 嗎？它們的使用時機是？

1. 初探系統設計

筆者在第一次遇到系統設計的問題時表現得很差，因為我把它當成一個技術性的問題，所以不停的在輸出自己的想法及觀點，面試完的當下還覺得自己表現的超棒，肯定會拿到 Offer。

果然在兩天後收到 Offer Get 的信件，但核薪結果沒有到達自己的期待；當時我並不了解自己在哪個環節犯了錯，於是向人資詢問主管對我的評價，我收到的評價是：「技術完全沒問題、經驗豐富、自我學習能力高；但在系統架構的設計上能力稍顯不足，主觀思維太多。」

在這之後我才知道面試有「系統設計」這個類型的題目，也明白當時的回答並不是面試官期待的答案。

1.1 Junior 跟 Senior 工程師的差異

Junior 工程師在看到問題後會想直接提出解決方案；而 Senior 工程師則會先釐清問題，從整體架構去思考。

會有這樣的差異是很正常的，因為 Junior 工程師在入職後，往往是接受任務分配的一方，所以他們已經習慣「收到問題 → 解決問題」的作業模式；很少人會去思考為什麼要這樣做、能不能這樣做，以至於可以完成交辦的任務，卻缺乏對整體架構的思維。

而 Senior 工程師除了要寫程式外，有時還要跟 PM 討論需求、規劃系統架構、分配工作給 Junior 工程師、幫 Junior 工程師 Debug；有些工程師討厭做這些事情，因為會耽誤到自己寫程式的時間，但正因為這些事情讓他有更完整的架構思維與溝通能力。

1.2 系統設計的題目來源

雖然系統設計的範圍很廣，但面試官愛考的就大概就是以下幾種：

• 經典面試題
  很多面試官都是去題庫裡面找題目，我這裡也是建議讀者先熟悉題庫；透過反覆練習題庫，除了掌握基本盤外；在面對沒有接觸過的系統也能做到基本的應對進退。
• 面試公司的系統
  有些知名企業喜歡向求職者詢問：「如果是你，會如何設計我們公司的系統？」
  這個問題除了考系統設計外，其實也是想知道求職者對面試公司的系統了解有多深。
• 你履歷上的技能
  像是筆者在履歷上有網頁爬蟲的經歷，面試官就會以此詢問筆者：「如何設計一個網頁爬蟲的系統？」

備註：

每個面試官在意的細節都不一樣；有些題目除了要系統設計外，他還要你提供不同方案的人力資源配置、功能時程預估、所需硬體資源…，要你設計一套可以讓組織運轉的流程。

如果沒有一定的實務基礎，面對這些延伸的問題基本沒有招架之力。

1.3 面試官在找的是同事

問題走向完全看面試官的喜好，因為沒有固定的解答，所以回答是否被接受也是看你跟面試官頻率是否契合。

今天面試官要找的是同事，在確認技術過關後；他想透過這個關卡更進一步了解求職者：

• 是否具備分析問題的能力。
• 會經過討論再做出設計，而不是一開始就有許多預設立場。
• 能夠清晰闡述自己的策略。
• 溝通時雙方在同一個頻率，不會出現雞同鴨講的狀況。
• 能評估自己提出方案的優缺點，並提出可行的優化方案。

與其說是考試，更像是同事間在討論一個議題；有時也會遇到你認為自己的方案沒問題，但面試官就是覺得不可行的狀況；此時你可以先了解面試官顧慮的點，可能真的有自己忽略的細節。

有時面試官的技術能力未必高於求職者，也許你提出的方案更好，但因為已經超過面試官知識範圍所以不被採納；此時並不建議堅持己見，你可以說：「也許有我忽略的細節，您的考慮應該是對的。」然後轉移到下一個話題。

如果你遇到一個自己完全不熟悉的領域，連回答的頭緒都沒有，請跟面試官討論你想解決的問題，並說明為什麼會卡住，千萬不要不懂裝懂瞎掰答案；多跟面試官互相分享彼此的想法，面試官自己也很清楚求職者是不可能在短時間內給出完美的答案，面對自己不熟悉的議題，就算有不會知識也是很正常的。

• 系統設計不只是單純的考試，而是評估你在工作上會如何討論問題。
• 雙方有來有往聊得越開心，就算你的回答有犯錯也容易被忽略。

會錄取的求職者未必技術能力最好，但絕對是在面試過程中溝通流暢的。

2. 如何設計一個像 Facebook 的社交平台

2.1 縮小問題範圍，確認具體需求

大部分主管在交代事情時，只會給一個方向，並不會把細節說清楚；所以面試官也是想透過這個問題來了解在未來交辦工作時，你會如何面對。

• 縮小問題範圍
  Facebook 是一個經歷十幾年改版、無數菁英灌注青春與熱血的系統，它所提供的服務實在是太多了，所以要先確認問題回答的方向，比如說：「Facebook 有提供蠻多種服務的，像是發文動態、Messager、廣告系統；我們要先從哪一塊來做討論？」

• 不要急著提出解決方案
  當年筆者沒搞清楚狀況，把它當成高流量架構設計的問題；直接丟出一堆像是 Load Balance、Repliaction、DB Sharding…的技術方案；我當時說的很開心，但回答的內容完全偏離了面試官想要了解的方向。

  使用什麼技術可以等需求確定後再討論，如果一開始在分析問題時就走偏了，那後面再多的努力也沒有用。

2.2 先提出一個簡單的解決方案

假設面試官把問題縮小到打造一個 Messager 的系統，那核心功能就非常明確；此時你只要簡單敘述設計概念就好；不要急著說出使用 Node.js + Socket.io + MongoDB 這些工具來打造系統。

• 簡述基礎解決方案
  我們會需要一個聊天伺服器來處理訊息間的溝通，當用戶發送訊息時，訊息會先傳送到伺服器並儲存；如果接收方在線上就直接傳送訊息給他，如果不在線就透過推播通知。
  在 UI 介面上，使用者發送訊息成功時會有時間戳記；當接收方點開訊息時也會有已讀的標記。

通常考題都會涵蓋「前端、後端、資料庫」的設計；這樣面試官才能依照自己在意的點深入詢問。

2.3 提出可以減少耗能的可行方案

資源永遠是有限的，更高的硬體規格代表更多的預算，此時就需要 trade-off（權衡）。

接著讓我們從資源消耗的角度來探討 Messager 這個系統中，好友上線顯示綠燈的功能要如何設計。

最簡單的做法是當用戶一上線，就向所有好友發送上線通知；但這個設計在系統成長到百萬用戶，且特定時段上線的活躍用戶數量高達 30 萬時，這種發送通知的方法對資源的消耗極大。

• 有什麼方式可以減輕資源消耗？
  很多人打開 Messager 只是簡單回覆訊息就關掉，所以系統其實沒必要爲剛上線的用戶立刻發送通知；我會建議把發送上線通知的策略改為顯示活躍用戶，可能要在線 5 分鐘以上再發送通知；透過減少請求的次數來降低對系統資源的消耗。

2.4 從自己擅長的面向切入

在提出基礎的解決方案後，題目就會往細節發展，此時你可以主動向面試官確認一些系統需求，假設你擅長大流量高併發的議題，你就故意問面試官：「這個系統在設計上要考量到大流量以及高併發的問題嗎？」

主動引導面試官將話題轉向自己擅長的領域是很重要的；但如果面試官對這個議題沒有興趣，千萬不要自顧自的一直講。

如果你對某個領域不擅長就不要挖坑給自己跳，假如你主動提及資料庫相關問題，面試官可能就因為你履歷上有 MySQL 跟 PostgreSQL 的經驗，而詢問你兩者的優缺點及使用時機，如果你答不出來反而會被扣分。

2.5 不要有預設立場

Messager 系統除了傳送訊息這個基礎功能外，還有建立聊天群組、回覆特定訊息、移除訊息、對訊息傳送表情符號…等眾多功能。

如果你打算在這些功能上開闢戰場，請先詢問面試官是否需要這些功能；而不是沒有經過溝通，自己覺得理所當然就直接開始設計。

經驗分享

在系統開發上，如果你要做的功能在需求規格以外，一定要先跟 PM 溝通；你認為必要的功能對客戶來說可能根本不需要，甚至系統有可能因為多出來的功能而產生無法預期的 Bug；千萬不要自作聰明。

2.6 主動提出不同設計的優缺點

如果面試官把話題帶到 DB Sharding 上面，比如：「隨著用戶成長，儲存用戶的 Table 資料量太大，效率越來越低，有什麼解決方案嗎？」

筆者會用下面的角度來回答：

考慮到用戶數量會持續成長，為了減輕資料庫的負擔，我會將這個 Table 切分到多個資料庫來分散壓力，這邊提供兩種切分策略：

• Range-based partitioning
  第一種是挑選一個合適的欄位作為切分條件，像是以用戶的「年齡」做為切分條件；不過使用這種方式可能會造成不均勻的 Server load，因為每個年齡段的用戶數量不同。

• Hash partitioning
  為了解決 Server load 不均勻的問題，第二種方案則是挑選一個欄位用 Hash Function 計算出一個值，用這個值來決定資料要放到哪個資料庫。

  可以採用 Consistent Hashing 讓資料均勻分布在不同 DB；這個方案在 DB 數量有增減時，也能盡量避免原有的 Key 被重新分配。

系統設計沒有標準答案，如果你有能力提出多種解決方案，並能說出各自的利弊是非常加分的。

3. 衍伸問題

3.1 你有使用過 Mind Map 跟 Sitemap 嗎？它們的使用時機是？

考點：設計系統架構時的輔助工具

• Mind-Map
  在專案做需求訪談時，我會先透過 Mind Map 來幫助發想與記錄想法，透過這張圖即使開會偏離重點也可以快速拉回；在會後我會透過它向同事說明需求的關聯性、以及一些功能的限制條件，讓他們快速理解這個專案的目標。
• Sitemap
  在需求明確後，我會用 Sitemap 規劃系統架構，設計頁面之間的關聯性與階層，完成流程上的模擬；並檢視規劃是否有下列問題：

  • 如果需要 SEO 的頁面被埋得太深就要重新規劃，避免 Google 爬蟲不到。

  • 檢查是否有規劃不良導致的孤兒網頁。

    孤兒網頁：系統沒有連結可以抵達的網頁。

筆者碎碎念

即使經驗豐富，面對一個從未思考過的問題，也很難提出合適的設計；這邊建議讀者可以透過以下方式，有意識地培養自己系統設計的能力：

• 上網找題庫，吸收他人在系統設計上的經驗。
• 找 Mentor 做模擬面試，熟悉答題方向。
• 在閒暇時思考知名的系統是如何設計出來的（ex：Youtube、Google、Twitter…）。

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

參考資源

1. 系統設計面試 6 個技巧｜我面 Google 前的準備方法
2. 軟體工程師系統設計面試準備指南
3. 系統設計面試（第一部分）
4. donnemartin/system-design-primer
5. 從 Sitemap 的應用，談 SEO 的學習

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

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

在功能穩定後，你對程式碼還有要求嗎？

「沒有最好的程式，只有更好的程式。」在完成功能後 Code Review 是非常重要的事情；不只看自己的程式碼，也要多觀摩其他人的程式碼，這個動作除了可以優化程式碼品質外，還可以幫助團隊了解彼此的工作進度。

人無完人，很多時候第一時間想到的解法未必是最好的；解決問題的方法不只一種，可能有更簡潔的寫法或是更好的 Pattern 可以套用，只是開發者不具備這塊的知識儲備；此時 Code Review 就是提升團隊程式水平的方式。

找到需要改善的問題後，Refactoring（重構）就是另一個開始；如果為了盡快完成功能而埋頭狂寫，容易導致日後維護以及交接的困難性；專案越大這個問題會越明顯，所以在完成功能後對程式做 Refactoring 是必要的任務，它能提升你日後解決 Bug、需求變更時的工作效率。

大綱

1. Code Review 會注意哪些事？會依照什麼原則對程式做 Refactoring？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 SOLID 原則
   • 2.2 Design Pattern 是什麼？解決了什麼問題？
3. 衍伸問題
   • 3.1 有處理 Legacy Code 的經驗嗎？
   • 3.2 有用什麼工具讓團隊有一致的 Coding Style

1. Code Review 會注意哪些事？會依照什麼原則對程式做 Refactoring？

1.1 面試官為什麼會問？

只要是軟體工程師的職位，這題可以說是超級常見面試題；因為它能問得很淺也能夠問得很深，如果是相對資淺的職位，求職者只要能說出關鍵字並給出基本解釋就能過關；如果是資深的位置，除了關鍵字外，面試官會繼續詢問你在專案中是否有實踐。

1.2 面試官想從答案確認什麼？

• 瞭解求職者 Code Review 會在意的點
• 有使用哪些方法對程式做 Refactoring
• 對 SOLID 原則有基礎認知
• 知道 Design Pattern 且能舉出實務上的應用
• 有用過什麼工具讓團隊有一致的 Coding Style

1.3 筆者提供的簡答

我會先觀察變數與函式的命名是否符合團隊規範、變數的宣告是否合理（var/let/const 的使用時機）；然後看程式在設計上是否有符合 SOLID 原則；在功能完成後如果發現有合適的 Pattern 可以更好地解決問題，就會再對程式做 Refactoring。

2. 回答問題所需具備的知識

其他章節的知識，可能換一個時空背景就用不到了；但今天這個章節的內容，是每位開發人員都需要將其內化成為本能的。

2.1 SOLID 原則

SOLID 是一個物件導向的設計原則，核心目標是為了讓程式碼更乾淨、易讀、好維護，讓程式朝著 Clean Code（無瑕的程式碼）的方向前進。

• S（Single Responsibility Principle）單一責任原則
  一次只做好一件事；如果把系統比喻成樂高，那單一責任原則就是樂高的每一塊積木。

• O（Open-Closed Principle）開放封閉原則
  程式的架構要容易擴充功能；而這個功能的擴充是新增程式，而非修改過去的程式，這麼做可以維持原有程式的穩定性。

• L（Liskov Substitution Principle）里氏替換原則
  在繼承中衍生的子類別，要能完全繼承父類別的功能；實作時還需顧慮到單一責任原則，避免日後功能拆分或刪減時的困擾。
  以軟體的角度來說，使用者期待版本從 1.0 ➞ 1.1 時行為是一致的，不會更新完舊功能就壞掉。

  子類別 Override 時要注意

  • 不可改變父類別先決條件
    假設籃球比賽的參與者年齡限制在 15~80 歲；裡面可能區分為青年組、中年組、老年組，青年組的年齡「可以是 15~30」；但「不可以是 14~30」。
  • 子類別的後置條件不該被削弱
    籃球的得分有「2」分球、「3」分球，都是數字；如果某個比賽改用「三分球」這個字串紀錄得分就是不可以的。

• I（Interface Segregation Principles）介面隔離原則
  設計程式時不應該預設使用者一定會使用到介面中的多個功能，我們應該盡量讓介面的功能單一；以後端 API 來舉例，我們不要讓一個 API 可以做好多事情，但做每件事情時只用到其中幾個參數。

• D（Dependency Inversion Principle）依賴反轉原則
  子類別一定會依賴父類別，這樣單向的關係是乾淨的；如果是雙向的依賴就會導致程式碼邏輯難以追蹤。

2.2 Design Pattern 是什麼？解決了什麼問題？

Pattern 是指在不同場景下的解釋，包含 Context（情境敘述）、Problem（問題）、Solution（解決方案）。

而 Design Pattern 就是過去人們發現解決問題的套路；學習越多 Design Pattern 在遇到問題時可以有更多的思路，並縮短與其他工程師討論的時間，因爲 Pattern 本身就包含了對問題的基礎解決方案，可以省下說明的時間。

下面分享一些常見的 Design Pattern 幫大家建立基礎概念，在看完後讀者也許會恍然大悟，原來我一直都有在使用 Pattern！

• Factory Method 工廠方法
  簡述：工廠負責生產客戶需要的產品
  假設今天有一個飲料工廠，他會生產很多種類的產品，像是「紅茶、綠茶、烏龍茶」；也許這些飲料的製作過程很複雜，但對客戶來講只要說出自己想要什麼口味的飲料就好了。

• Strategy 策略
  簡述：一個策略介面底下有很多靈活的方法供選擇
  把計算機的計算當成一個介面，這個介面提供加減乘除的方法；如果想加入次方、開根號的功能也能夠輕鬆擴充。

• Factory Method 與 Strategy 混合運用
  簡述：有時解決方案是多個 Pattern 的組合
  假設今天開一間飲料店，飲料會分成茶類、咖啡；每杯飲料又有冰量、甜度的選擇，這裡我們可以用 Factory Method 來建立產品；而飲料在販售時，不同組合有對應的折扣，這裡就可以用 Strategy 提供對應的方法來計算總金額。

• Singleton 單例
  簡述：希望在程式每個位置都能呼叫統一的 Instance
  在寫程式時會希望某些資源可以重複利用，並且在不同檔案引用時這些資料是一致的，像是共用的計時器、資料庫等物件。

• Decorator 裝飾
  簡述：將需求獨立，依據實際需求取得動態的結果
  假設一間餐廳提供三種餐點

  • 商業午餐（主餐）
  • 簡餐（主餐 + 飲料）
  • 套餐（主餐 + 飲料 + 甜點）

  我們發現上面餐點是有疊加性的，所以可以用繼承的方式來撰寫餐點間的關係；但如果今天老闆想要更換簡餐的內容組合（ex：贈送水果），而不想改變套餐的內容，就會導致程式必須改寫。
  面對這個問題，我們可以用 Decorator 作為解決方案，將主餐、飲料、甜點、水果各自獨立，依據商業午餐、簡餐、套餐實際的內容來做組合；這樣就能減少耦合性的問題。

• Observer 觀察者
  簡述：觀察者要能掌握被觀察者的狀態改變，較常用於 GUI 的設計
  像是 Vue.js 的 watch 就是用來監聽一個「值」的變化去做一系列的事情（ex：UI 上的調整）。

• Command 命令
  簡述：將請求的物件和執行的物件分開
  路邊攤的老闆通常是一個人負責備料、點餐、料理、清潔…等到生意做起來有店面了，他才會考慮雇用一些人手來幫忙內場、外場，如果把這個解決方案用 Command 來舉例：

  • 客人（Client）：跟服務生說自己想點什麼餐（Concrete Command）。
  • 服務生（Invoker）：紀錄客人的餐點（Concrete Command），並呼叫命令。
  • 廚師（Receiver）：收到命令後，開始料理餐點（Concrete Command）。

• Builder 建造者
  簡述：依照自己的需求客製化產品
  一台筆電是由許多零件組裝而成，你可以選擇標配也能夠用選配來客製化它；為了讓選配的零件規格有彈性，Builder 就是一個很棒的解決方案；它讓你先選完自己所需的零件後，再產生最後的產品。

備註：如果你熟悉的 Pattern 剛好能解決目前遇到的問題那是皆大歡喜；萬一沒有合適的 Pattern 可以套用，千萬不要為了設計而設計；開發人員的目標應該是想透過 Pattern 解決問題，而不是從 Pattern 出發去設計問題。

3. 衍伸問題

3.1 有處理 Legacy Code 的經驗嗎？

除非是新創團隊或是接案類型的公司；不然絕大多數新人入職後都要接手前人遺留的程式碼（Legacy Code），如果求職者只有從零開始的經驗，在一開始會有陣痛期。

考點：了解求職者是否接觸過 Legacy Code、碰到時如何快速掌握

之前有因為專案擴編而去支援的經驗，因為當時有時程上的壓力；所以我在加入團隊後除了重點了解自己要負責的 Feature、團隊的 Coding Style 外，會主動向定下這些需求的 PM 討論，以此了解因果關係並快速融入團隊。

也曾接手過要維護及擴充的專案，因為當時沒有相關文件可以參考，為了快速掌握專案，我一邊操作系統一邊畫心智圖幫助自己釐清功能；了解系統架構後再去找合作窗口確認需求，避免實作方向與客戶需求不同。

在修改 Legacy Code 時，我會特別注意前人是否有撰寫測試案例，在程式能有效測試的狀態下才能安心的修改與擴充。

以正在運行的專案來說，我會希望建立團隊 Code Review 機制，讓每個人熟悉彼此的程式、使用共同的 Coding Style，當知識共享與風格統一後，就能減少 Legacy Code 的產生。

3.2 有用什麼工具讓團隊有一致的 Coding Style

考點：是否有善用工具解決問題

我在 VSCode 有安裝一個 Prettier 的外掛，靠它就能非常有效的將程式碼格式化；不過有時為了保證團隊的 Coding Style 會導入 ESLint 來統一風格，但 Prettier 與 ESLint 一起使用時會遇到衝突，所以我有再安裝一個 Prettier ESLint 的外掛來解決這個問題；讓程式不僅符合團隊的 Coding Style，還可以透過快速鍵將程式碼格式化。

寫完這篇文章時，我的心裡突然冒出一段話：「一開始我們在追求問題的解答；到後來，我們在學習解決問題的方法。」

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

參考資源

1. 【翻譯】JavaScript 設計模式
2. 什麼是 Design Pattern?
3. 我為什麼想學設計模式 ( Design Pattern )
4. 設計模式五大基本原則 SOLID

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

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

不過面對這個情境，Redis 表示終於輪到我了！今天這篇文章會以 Node.js + Redis 為範例，帶讀者一起解決這個問題。

大綱

1. 如何解決高併發情境的商品秒殺問題
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 先了解 Redis 的基礎知識
   • 2.2 使用 Node.js + Redis 解決高併發秒殺問題
   • 2.3 模擬秒殺情境確認商品沒有超賣
3. 衍伸問題
   • 3.1 如果有數萬用戶同時查看 TOP100 的點數排行榜，資料庫如何設計？
   • 3.2 Redis 跟 Memcached 的差異

1. 如何解決高併發商品秒殺問題

1.1 面試官為什麼會問？

這算是資料庫的常見面試題，除了金融、電商喜歡考這題外；社交平台、新創公司、遊戲產業也會換個形式考類似的題目。

因為這算是職缺所需具備的技術，如果求職者沒有相關經驗可能就會止步於這個關卡。

如果有去以上產業的打算，最好有一定的 NoSQL（ex：Redis、MongoDB） 基礎再去面試；因為在面試官的眼中有基礎跟完全不會的差距很大，求職者可以沒有實務經驗，但明知產業會碰到這些技術還不去學習就是態度問題了。

1.2 面試官想從答案確認什麼？

• 能提出高併發情境商品秒殺的解決方案
• 如果解決方案為 NoSQL，對它的認知有多少
• 是否接觸過同類型的 NoSQL

1.3 筆者提供的簡答

通常這類型的秒殺活動都有固定檔期，我會先將活動用的商品及庫存數量同步到 Redis 資料庫；為了避免超賣，在 Client 端下單時會執行 Lua 腳本，當秒殺到指定數量或是時間結束後就不再接受請求，活動結束後將 Redis 的資料同步到關聯式資料庫。

2. 回答問題所需具備的知識

2.1 先了解 Redis 的基礎知識

如果有短時間大量訪問、需要性能提升的需求，往往會先想到 Redis 這個記憶體資料庫。

• Redis 為什麼快？

  • 記憶體資料庫
    記憶體讀寫本來就快。

  • 單執行緒（single-threaded）
    如果使用多執行緒會耗費時間在上下文的切換以及加鎖上面；而單執行緒會依照請求順序執行，不需考慮同步以及加鎖帶來的效能問題。
    Redis 是基於記憶體操作，所以效能的瓶頸不在 CPU 而在記憶體、網路頻寬；因為 CPU 不是瓶頸，所以可以開多個 Redis 建立 Cluster 分散壓力。

  • I/O 多路複用（multiplexing）
    Redis 使用了 epoll IO 多路複用，可以用一條執行緒處理併發的網路請求。

    這個有點抽象，我用繳交作業為情境說明：
    假設你是一個老師，採用多路復用的原則批改作業，那你批改的順序就是看誰先繳交作業，而不是按照學號順序批改（此作法中間有人沒交作業就會卡住）；這樣就能避免大量無用操作，為非阻塞模式的實現。

• Redis 資料保存方案
  可以使用 RDB 、AOF 來做持久化。

  • RDB 持久化（Redis Database）
    在指定的時間間隔內將資料 dump 到硬碟；因為是定期操作，如果 Redis 當機會遺失部分資料，此方案適合大規模資料恢復。
  • AOF 持久化（Append Only File）
    這個方案可以完整紀錄所有資料的變化，因為採用日誌追加的方式，所以就算當機也不會影響已經儲存的日誌，災難復原的完成度高；缺點是檔案比 RDB 大、大規模資料恢復速度較 RDB 慢。

• Redis 資料淘汰機制
  Redis 主要保存的都是熱點資訊，在儲存資料有限的狀態下（記憶體不足，無法寫入新資料）；就要合理的設定淘汰機制：

  • 選擇性移除有設定過期時間的資料
    • volatile-lru：挑選最近較少使用的資料淘汰。
    • volatile-ttl：挑選即將過期的資料淘汰。
    • volatile-random：挑選隨機資料淘汰。
  • allkeys-lru：挑選最近較少使用的資料淘汰。
  • allkeys-random：挑選隨機資料淘汰。
  • no-enviction：禁止淘汰；若選用這個設定，當數據到達 maxmemory 時會回傳 OOM 錯誤。

  原則上淘汰策略以「volatile-lru、allkeys-lru」為主（淘汰較少使用的資料）。

2.2 使用 Node.js + Redis 解決高併發秒殺問題

• 目標
  • 產生秒殺商品基礎資訊（商品名稱、庫存）
  • 模擬秒殺情境，確認是否會超賣
  • 確認有保存購買人資訊
• 使用技術

  • Redis
    本篇文章使用 Redis 的 Hash、List type 來儲存資訊。

    如果完全沒有相關基礎，建議先參考這篇文章來安裝 Redis 以及它的 GUI 工具。

  • Lua 腳本
    為了避免超賣，這裡採用 Lua 腳本；在 Redis Server 執行 EVAL 指令時，在結果回傳前只會執行當下 Lua 腳本的邏輯，其他 Client 端的命令須等待直到 EVAL 執行完為止。

    Lua 腳本的邏輯應盡量簡單以保證執行效率，否則會影響 Client 端的體驗。

• 程式架構

  • 主程式：redisSecKill.js

    • 先啟用 Redis Client 端（如未安裝相關套件，請在專案資料夾下輸入 yarn add ioredis）。
    • 用 prepare 函式，以 Hash type 建立參加秒殺的產品庫存。
    • 用 secKill 函式模擬使用者購買行為，緩存並執行 Lua 腳本。

    const fs = require("fs");
    const Redis = require("ioredis");
    const redis = new Redis({
      host: "127.0.0.1",
      port: 6379,
      password: "",
    });
    
    redis.on("error", function (error) {
      console.error(error);
    });
    
    async function prepare(item_name) {
      // 參加秒殺活動的商品庫存
      await redis.hmset(item_name, "Total", 100, "Booked", 0);
    }
    
    const secKillScript = fs.readFileSync("./secKill.lua");
    
    async function secKill(item_name, user_name) {
      // 1. 緩存腳本取得 sha1 值
      const sha1 = await redis.script("load", secKillScript);
      // console.log(sha1);
    
      // 2. 透過 evalsha 執行腳本
      // redis Evalsha 命令基本語法如下
      // EVALSHA sha1 numkeys key [key ...] arg [arg ...]
      redis.evalsha(sha1, 1, item_name, 1, "order_list", user_name);
    }
    
    function main() {
      console.time("secKill");
      const item_name = "item_name";
      prepare(item_name);
      for (var i = 1; i < 10000; i++) {
        const user_name = "baobao" + i;
        secKill(item_name, user_name);
      }
      console.timeEnd("secKill");
    }
    main();
    

  • Lua 腳本：secKill.lua
    在 Lua 腳本執行邏輯：「確認下單數量」➜「取得商品庫存」➜「如果庫存足夠就下單」➜「儲存購買者資訊（List type）」。

    local item_name = KEYS[1]
    local n = tonumber(ARGV[1])
    local order_list = ARGV[2]
    local user_name = ARGV[3]
    if not n  or n == 0 then
      return 0
    end
    local vals = redis.call("HMGET", item_name, "Total", "Booked");
    local total = tonumber(vals[1])
    local booked = tonumber(vals[2])
    if not total or not booked then
      return 0
    end
    if booked + n <= total then
      redis.call("HINCRBY", item_name, "Booked", n)
      redis.call("LPUSH", order_list, user_name)
      return n
    end
    return 0
    

2.3 模擬秒殺情境確認商品沒有超賣

• SETP 1：在專案資料夾下輸入 node redisSecKill.js 模擬秒殺

  

• SETP 2：待執行完後，用 Redis GUI 程式確認商品沒有超賣

  

• SETP 3：確認訂單都有對應的買家

  

補充

文章程式只是 MVP，現實狀況還有很多要設計的：

• 哪些商品被列為秒殺，如何紀錄。
• 設定秒殺開始、結束時間。
• 如何將 Redis 資料存入關聯式資料庫中。

3. 衍伸問題

3.1 如果有數萬用戶同時查看 TOP100 的點數排行榜，資料庫如何設計？

考點：對 Redis Zset 這個資料型態的認知與應用

我會使用 Redis 這個記憶體資料庫，建立一個有序集合（Zset）來儲存用戶的資訊。

在設計上，用戶（member）是唯一值，且每個用戶都會關聯一個點數（score），這樣用戶就可以按照分數來排序。

功能實現上會透過 zrevrange Leaderboard 0 99 withscores 這段指令來顯示 TOP100 的點數排行榜。

• zrevrange：依照點數（score）檢視排行榜
• Leaderboard：排行榜名稱（可以自行定義）
• 0 99：TOP100 的意思
• withscores：連點數（score）一起顯示

3.2 Redis 跟 Memcached 的差異

考點：是否了解過同類型的技術以及差異

• Memcached 只支援簡單的資料型態，而 Redis 支援多種資料型態（String、Hash、List、Set、Zset、Stream）。
• Memcached 不支援資料持久化，而 Redis 提供 RDB 跟 AOF 兩種方案。

同樣身為記憶體資料庫，Memcached 提供簡單的使用方式，而 Redis 提供豐富的功能。

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

參考資源

1. 手把手帶你在 MacOS 安裝 Redis ＆Another Redis Desktop Manager(筆者部落格)
2. 用 Node.js + Redis 解決高併發秒殺問題(筆者部落格)
3. redis 之 sorted sets 類型及操作
4. 使用 redis 的有序集合實現排行榜功能

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

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

庫存只剩 1 件，但卻有 10 個人買到？

網路商城特賣會常常會推出特定商品限量 1 組的搶購活動，在搶購過程除了會產生高併發的問題外，同時也需要考慮到「商品會不會超賣」，在現實生活中聽起來很不可思議；但在網路的世界裡，如果SQL邏輯沒有設計好，真的可能發生明明只限 1 組卻賣了 10 組商品的超賣事件。

大綱

1. 關聯式資料庫要如何設計避免超賣？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 什麼是悲觀鎖（Pessimistic Lock）？
   • 2.2 什麼是樂觀鎖（Optimistic Lock）？
   • 2.3 在 MySQL DB 實作悲觀鎖
   • 2.4 在 MySQL DB 實作樂觀鎖
3. 衍伸問題
   • 3.1 悲觀鎖、樂觀鎖優缺點

1. 關聯式資料庫要如何設計避免超賣？

1.1 面試官為什麼會問？

這算是資料庫的常見面試題，對金融、電商相關產業來說都快要變成必考題了。

通常問完這題後會緊接著詢問：「如果是用 noSQL 有什麼處理方案？」這部分會在明天的文章跟大家講解。

1.2 面試官想從答案確認什麼？

• 是否有資料庫 Transaction 的概念
• 了解悲觀鎖（Pessimistic Lock）、樂觀鎖（Optimistic Lock）的概念
• 知道悲觀鎖（Pessimistic Lock）、樂觀鎖（Optimistic Lock）優缺點、使用情境

1.3 筆者提供的簡答

我會依照不同的情境來做設計，如果寫入需求較高，我會選擇使用悲觀鎖（Pessimistic Lock）；因為它是直接使用資料庫 Transaction 的機制，保證了資料的穩定性。

如果讀取需求較高，我會選擇使用樂觀鎖（Optimistic Lock）；因為它可以承受較高的吞吐量，不過它鎖的特性會導致購買順序未必是先到先得，只是保證不會超賣。

2. 回答問題所需具備的知識

2.1 什麼是悲觀鎖（Pessimistic Lock）？

就跟字面上的意思一樣，非常的悲觀；它認為 Table 裡面的 data 非常不安全，無時無刻都在變動，當一個 SQL command（可以理解為搶購的用戶）獲得悲觀鎖後，其他的 SQL command 無法對這個 data 進行修改，直到悲觀鎖被釋放後才能執行。

資料表中用 Synchronized 實現的鎖均為悲觀鎖（ex：行鎖，表鎖，讀鎖，寫鎖）。

2.2 什麼是樂觀鎖（Optimistic Lock）？

相比悲觀鎖，它認為 Table 裡面的 data 變動頻率不會太頻繁，因此他會允許多個 SQL command 來操作 Table；但樂觀並不代表不負責，通常會在 Table 中增加一個 version 的欄位來做更新的確認。因此當 SQL command 想要變更欄位 data 時，會把之前取出的 version 跟現在的 version 做對比，如果相同就代表這段期間沒人修改可以執行；如果不同這次的操作就不會生效。

2.3 在 MySQL DB 實作悲觀鎖

情境描述：

假設 A 跟 B 都想要買 iphone 手機，但商城的 iphone 庫存只剩下一隻，在不加鎖的狀況下同時下單會導致庫存變成負號；請問如何用悲觀鎖解決這個問題呢？

只要安裝好 MySQL，跟著步驟操作即可模擬 A、B 客戶搶購。

• STEP 1：建立模擬資料

  • 先用 SQL command 建立一個簡單的 Table 並新增 data。

    CREATE TABLE `your_DB`.`items` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(45) NOT NULL,
    `num` INT NOT NULL,
    PRIMARY KEY (`id`));
    INSERT INTO `your_DB`.`items` (`name`,`num`)
    VALUES ("iphone",1);
    

  • 確認資料是否建立成功。

    SELECT * FROM `your_DB`.`items`;
    

    

• STEP 2：開一個視窗模擬 A 客戶搶購行為

  • Transaction 的開始要用 begin;，不然 MySQL 會自動提交。

    

  • 在 A 購買前先將 id=1 的 data 加上悲觀鎖，此時這行 data 只有 A 可以操作。

    select num from `your_DB`.`items` where id = 1 for update;
    

    

• STEP 3：開另一個視窗模擬 B 客戶搶購行為

  • 一樣將 id=1 的 data 加上悲觀鎖，下完指令後便會進入等待的模式，要等 A 執行 commit 完成交易或是指令逾時才能繼續。

    

• STEP 4：回到 A 客戶的視窗完成交易

  • 讓 A 執行購買的動作，將 data 的 num 減一。

    update `your_DB`.`items` set num = num -1 where id = 1;
    

  • 然後檢視修改後的 data 是否符合預期。

    select num from `your_DB`.`items` where id = 1;
    

  • 最後下 commit; 結束這次交易。

    

• STEP 5：當 A 完成交易後回到 B 的視窗
  你會發現因為 A 釋放了悲觀鎖，所以 B 結束等待並且獲得鎖；但 data 的 num 已經變成 0 了，只能放棄購買。

  

  7.89 秒是等待獲得鎖的時間。

2.4 在 MySQL DB 實作樂觀鎖

情境描述：

假設 A 跟 B 都想要買 iphone 手機，但商城的 iphone 庫存只剩下一隻，在不加鎖的狀況下同時下單會導致庫存變成負號；請問如何用樂觀鎖解決這個問題呢？

觀察兩者實作上的邏輯差異。

• STEP 1：建立模擬資料

  • 先用 SQL command 建立一個簡單的 Table 並插入 data，比起悲觀鎖的 Table，我們多了一個 version 的欄位。

    CREATE TABLE `your_DB`.`happy_items` (
    `id` INT NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(45) NOT NULL,
    `num` INT NOT NULL,
    `version` INT NOT NULL,
    PRIMARY KEY (`id`));
    INSERT INTO `your_DB`.`happy_items` (`name`,`num`,`version`)
    VALUES ("iphone",1,0);
    

  • 確認資料是否建立成功。

    SELECT * FROM `your_DB`.`happy_items`;
    

    

• STEP 2：規劃實作邏輯思路
  • A 跟 B 客戶在購買前會先將 id=1 的 data 找出來。
  • A 先購買，此時會以 id=1 和 version=0 作為 where 條件來更新 data，更新後 num -1、version +1 變成 id=1、num=0、version=1。
  • B 購買時會因為同樣是用 id=1 和 version=0 為 where 條件，所以會因為找不到 data 而無法更新。
• STEP 3：模擬搶購情境，A 跟 B 客戶購買前先查詢庫存

  • A 及 B 執行查詢的 SQL command 會取得相同的 iphone 庫存資訊。

    SELECT num,version FROM `your_DB`.`happy_items` where id = 1;
    

    

• STEP 4：A 先執行購買的 SQL command

  • A 先購買 iphone 並更新 data。

    update `your_DB`.`happy_items` set num = num -1 , version = version + 1 where id = 1 and version = 0;
    

  • 檢視修改後的 data 是否符合預期。

    SELECT num,version FROM `your_DB`.`happy_items` where id = 1;
    

    

• STEP 5：B 再執行購買的 SQL command

  • 此時 B 的購買就會失敗，在執行購買的 SQL command 後你會發現沒有 Row 被更新，因為庫存資訊已更新，但 SQL command 還是舊的。

    

3. 衍伸問題

3.1 悲觀鎖、樂觀鎖優缺點

考點：對於關聯式資料庫「鎖」的認知程度

• 悲觀鎖（Pessimistic Lock）
  • 優點
    使用資料庫 Transaction 的機制來強迫執行的順序。
  • 缺點
    一但加入 Transaction 的機制，會導致其他的 SQL command 針對這個 data 除了查詢功能外全部卡死，如果這段 Transaction 執行時間較長，會給使用者不良的體驗並造成系統吞吐量下降。
• 樂觀鎖（Optimistic Lock）
  • 優點
    因為沒有在資料庫加鎖，所以 SQL command 都會對 data 進行操作，只有在更新 data 時才會做驗證；這樣做就能避免因使用悲觀鎖而導致吞吐量下降的問題。
  • 缺點
    因為樂觀鎖是我們人為實現的，所以如果換一個業務場景可能會不適用，甚至可能因為其他的 SQL command 導致錯誤。

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

參考資源

1. 理解資料庫『悲觀鎖』和『樂觀鎖』的觀念(筆者部落格)

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

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

經驗不夠，讀書來湊。

除非你的實戰經驗超級豐富，不然在面試時一定會遇到不熟悉的議題；面對無法回答的問題，我個人會老實向面試官表明自己沒有這方面的經驗，會持續學習，瞎掰答案容易讓對方覺得你以後進來公司也會這樣做事。

不過有些議題雖然實際碰過的人不多，但網路上有很多資源可以學習；如果剛好有研究過相關資料，筆者會回答：「雖然沒有在工作上使用過，但在下班後我有特別研究這個議題，如果思路上有不對的部分還請各位面試官批評指教。」

大綱

1. 面對高流量的的系統，會採取哪些措施？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 負載平衡（Load Balance）
   • 2.2 主從式架構（Master Slave Repliaction）
   • 2.3 資料庫讀寫分離（read/write splitting）
   • 2.4 垂直切分（vertical-partition）
   • 2.5 水平切分（horizontal-partition）
   • 2.6 分表（Partition Table）
3. 衍伸問題
   • 3.1 有遇過主從複製延遲問題嗎？怎麼解決？
   • 3.2 分散式資料庫（Distributed Database）有哪些優點跟缺點？

1. 面對高流量的的系統，會採取哪些措施？

1.1 面試官為什麼會問？

如果面試的公司在做金融、電商、社交、媒體的系統，那這題算是該職缺所需具備的技術；儘管也可以透過後天培養，但如果有現成的人才，誰會想要花時間做訓練。

1.2 面試官想從答案確認什麼？

• 要如何設計才能讓前後端伺服器承受大流量情境
• 資料庫為了處理大流量，可以做哪些調整
• 這些處理的方式在實務上是否有遇到問題，如何去驗證你的想法是否正確

1.3 筆者提供的簡答

前後端我會用 Load Balance 緩解 Server 的壓力；在資料庫方面則採取主從式架構、讀寫分離來降低壓力。

如果經過上面的設計後，資料庫還是無法負荷，可以先用業務種類作為切分條件；以電商系統來說我會先做垂直切分（vertical-partition），像是將商品、訂單、明細拆成 3 個資料庫，以此大幅降低單一資料庫被存取的流量。

如果垂直切分後還是在某個資料庫遇到瓶頸，像是訂單的的資料庫內容遠大於其他資料庫；此時會再做水平切分（horizontal-partition），可能會依照訂單的地區再切分成幾個資料庫。

2. 回答問題所需具備的知識

2.1 負載平衡（Load Balance）

無論是電商還是媒體的系統，幾乎長時間都要面臨大流量的議題，想當然一台伺服器是無法承受高流量的。

而負載平衡（Load Balance）就是為了解決這個問題而誕生的，既然 1 台 Server 無法承受 10 萬流量；那我們就用 100 台 Server 來分散流量吧！

早期做法是先預估流量，然後開啟對應數量的 Server 來作分流；這樣的做法多開頂多浪費錢，但如果估計錯誤少開就可能導致系統當機。

所以像是 GCP、AWS 這類雲端廠商所提供的負載平衡（Load Balance），就有依照伺服器健康程度來做自動擴展（auto-scaling）的服務，讓大家不需要去猜要開多少台才合適；如果有使用 Kubernetes 並設定好相關參數，在遇到大流量時也會自動擴展 Pod 來應付。

有時會被問到你的系統過去遇到最高的 QPS 是多少，QPS 指的是每秒查詢率（Queries Per Second）。

2.2 主從式架構（Master Slave Replication）

上面提到的負載平衡只能做到讓網頁成功打開，如果資料庫 Server 沒有做對應的設計，這樣的大流量跟 DDOS 根本沒兩樣，足以讓資料庫 Server 陣亡；所以有時會發現進入某個網站後可以看到 UI 佈局，卻沒有資料顯示。

下面我們先探討主從式架構，目標是先讓資料庫 Server 能承受大流量的檢索，接著再來考慮寫入問題。

• 為什麼需要 Master Slave Replication 的架構？

  • 網站需要面對大流量
    有些網站無論哪個時段都會被大量檢索，如果資料庫只用一個 Server 來處理會無法負荷高流量。
  • 資料庫內容需要被分析
    公司如果有資料分析部門，他們也會隨時監控資料庫的變化來產生報表，但如果跟一般使用者一樣 query 同一台 Server，會使這台 Server 增加不必要的負荷，甚至導致使用者體驗下降。

• Master Slave Replication 為什麼能夠解決這些問題？

  • 主從式架構
    將資料庫的 Server 區分成 Master(1 台) 與 Slave(N 台) 兩種，Master 負責資料寫入，Slave 提供資料檢索；這樣就把壓力分散到幾台 Server 上面。
  • 資料庫同步
    Slave 會同步 Master 的資料，這樣除了分散 Server 壓力外，資料也獲得了備份。

• Master Slave Replication 的架構

  • 在 Master 的 Server 執行的 SQL command 會被記錄在 Binary Log 裡面。
  • Master 將 Binary Log 傳送到 Slave 的 Relay Log。
  • Slave 依據 Relay Log 做資料的變更。

  

  Relay Log 與 Binary Log 檔案格式、內容都一樣，不同在於 Slave 在執行完 Relay Log 的 SQL 之後，會自己刪除當前的 Relay Log。

2.3 資料庫讀寫分離（read/write splitting）

我們知道 Master Server 是用來更新資料，Slave Server 是用來檢索資料；但它們都是獨立的 ip，使用者在存取資料庫的時候並不知道要使用哪一台 Server ，除非你的 Slave Server 只用來做資料分析。

因此我們要在中間設計一台 Proxy Server，準確地將 SQL 指令分流到正確的 Server。

媒體類型的平台在讀的需求很高，寫的需求相對低；因此多會採用主從式架構做讀寫分離。

2.4 垂直切分（vertical-partition）

在讀寫分離後，儘管讀的部分沒有問題；但把寫入的工作交給一個資料庫負責還是會遇到瓶頸。

此時資料庫的垂直切分（vertical-partition）就派上用場了；以商城舉例，商品、訂單、付款明細各自的業務量都很大，所以我們可以先依照業務性質把它拆分成 3 個資料庫，如此設計可以分散資料庫被存取的流量，來提升系統穩定度。

2.5 水平切分（horizontal-partition）

在垂直切分後，有些資料庫還是會遇到瓶頸，像是訂單的資料庫可能遠遠大於其他資料庫。

這時我們就會需要做水平切分（horizontal-partition），將 DB 中同一類型的資料依據特定邏輯拆分成多個 DB；像是訂單可能來自於世界各地，所以我們可能就以地區（ex：亞洲、歐洲、美洲…）做切分的邏輯。

2.6 分區表（Partition Table）

資料庫在經歷了垂直切分與水平切分後，寫入遇到的瓶頸就差不多解決了。

但接下來會遇到另外一個問題，Table 中的資料會隨著時間會不斷增長，如果資料量龐大到就算建立 Index 都無法提升效能；此時就要考慮將 Table 依照特定邏輯做切割，通常會選擇自動產生的 id、日期這類的欄位作為切割依據，在 Table 被切割後因為資料量變少，所以搜尋效能隨之提升。

特別提醒：如果這個 Table 有 Primary key 或是 Unique key，分區鍵（Partition Key）必須是 Primary key 或是 Unique key 組成的一個部分。

3. 衍伸問題

3.1 有遇過主從複製延遲問題嗎？怎麼解決？

考點：瞭解求職者的實務經驗

當時我使用的是 MySQL 資料庫，用 sysbench 這個測試工具模擬短時間執行大量的 SQL command（ex：Table 內容大量更新、Index 建立）；但去 Slave 的資料庫確認同步狀況時，卻發現並沒有完全同步 Master 的資料。

經過研究後發現 MySQL 預設的 Process 只有一個，因此累積了很多尚未同步的 SQL Command；將 MySQL 調整成多 Process後，Slave同步的效率就大幅提升了。

可透過修改「slave_parallel_type、slave_parallel_workers」這兩個變數來調整 Process數量。

3.2 分散式資料庫（Distributed Database）有哪些優點跟缺點？

考點：對分散式資料庫的認知程度

• 優點
  • 穩定度與可用性提升
    過去靠一個資料庫打天下，如果這個資料庫掛了一切都涼了；但建立 Replication 制度後，Slave 資料庫除了可以分擔流量，在 Master 資料庫發生問題也可以讓其他 Slave 資料庫轉成 Master，不影響整體系統。
  • 擴充性
    因為資料分散儲存在多個資料庫，如果有更多的需求只要增加伺服器時設定即可。
• 缺點
  • 開發困難度
    因為資料分散在各個資料庫，所以對開發人員的經驗以及技術要求更高；如果設計不良反而會影響到資料安全性。

紙上得來終覺淺，絕知此事要躬行。 ── 陸游

如果大家想要親手實作今天的面試題，在參考資源中有分享一些實作流程喔！

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

參考資源

1. MySQL Master Slave Replication 主從式架構設定教學(筆者部落格)
2. Ubuntu 用 Atlas 實現 MySQL Proxy 讀寫分離(筆者部落格)
3. 用 sysbench 測試 MySQL 性能(筆者部落格)
4. 解決 MySQL 主從複製的延遲問題(筆者部落格)
5. 30-26 之資料庫層的擴展 - 分庫分表架構
6. MySQL 分區

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

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

好的設計讓你上天堂，爛的設計讓你下地獄。

如果公司有專門的 DBA，後端工程師就可以把心力放在資料邏輯的處理上；但筆者詢問周圍的朋友，似乎有不少公司都是讓後端工程師兼任 DBA…

筆者在這塊也並非專家，主要是分享自己實作中會注意的基礎細節，避免犯下一些原則性錯誤。

大綱

1. 設計資料庫時會考量哪些點？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 在 Table 建立有效的 Index
   • 2.2 資料庫設計與優化
   • 2.3 MySQL 與 PostgreSQL 的區別及應用場景
3. 衍伸問題
   • 3.1 為什麼 Index 不能建立太多？
   • 3.2 寫 DB SQL 時會注意什麼？
   • 3.3 有用過 NoSQL 嗎？什麼應用情境下會使用呢？
   • 3.4 你會用哪些點來評估要使用關聯式資料庫 or 非關聯式資料庫？

1. 設計資料庫時會考量哪些點？

1.1 面試官為什麼會問？

• 因為履歷資訊中表明擅長多種資料庫（Database）
  • MySQL、MSSQL、PostgreSQL
• 且履歷資訊中還表明有優化資料庫的經驗。
  • XXX 資料庫系統
    將 Visual Basic 的單機版程式改寫成網頁系統，整合過去冗贅資料表，優化使用者體驗。

1.2 面試官想從答案確認什麼？

• 選用資料庫前，會思考哪些問題
• 設計資料庫時會注意哪些細節
• 同樣都是關聯式資料庫，你知道他們間的差異嗎？
• 有用過哪些方式優化資料庫效能
• 你對 NoSQL 的認知有多少

1.3 筆者提供的簡答

在決定要使用什麼資料庫前，我會先分析專案的應用場景：

• 像是商城會有金流，所以資料穩定性與 Transaction 機制是很重要的。
• 如果要設計地圖平台，就會選擇對 GIS 支援度高的資料庫。

在設計資料庫時會畫 ER Model 來分析資料間的關聯與屬性；在優化方面，為了要提高搜尋效率會在 Table 建立 Index，同時也會依據實際業務設計欄位適合的長度及 Type。

2. 回答問題所需具備的知識

2.1 在 Table 建立有效的 Index

我們知道在 Table 建立 Index 可以增加搜尋效率，但你知道自己建立的 Index 有沒有派上用場嗎？筆者將在這個小節透過實作，帶大家了解 Coverage Index (覆蓋索引)的意義。

• SETP 1：建立測試用的 tmp_user Table

  • id 為 primary key
  • name 為 index

  create table tmp_user (
      id bigint(20) not null auto_increment ,
      name varchar(255) not null,
      password varchar(255) ,
      index index_name (name),
      primary key (id))
      engine=innodb
      default character set=utf8 collate=utf8_general_ci;
  
  insert into tmp_user (name, password) values ("寶寶不說","123");
  

• SETP 2：下 SQL 指令了解是否使用 Index

  觀察最後「Extra」欄位的資訊有否有 Using index

  • SQL A：explain select id from user_table where name= '寶寶不說';

    

    因為 name 有建立 index，所以在查詢到 name 後可以直接與 id 對應返回結果；因為 name 已經覆蓋了查詢資料的需求，所以稱為 「Coverage Index」。

  • SQL B：explain select password from user_table where name= '寶寶不說';

    

    透過 name 找到「寶寶不說」對應的 id，但接著要透過 id 這個 primary key，在 Table 重新輪詢才能取得這一列的完整資料。

• SETP 3：建立 Coverage Index 優化 SQL B

  • 先將資料庫 drop 掉：drop table tmp_user;

  • 重新建立測試資料以及「Coverage Index」
    為了避免用 primary key 再次從 Table 查詢的耗能，我們可以把 select 與 where 用到的欄位(name、password)做聯合索引，這樣就能夠直接使用索引查詢，而不需用 primary key 重新比對，這就是「Coverage Index」的應用。

    create table tmp_user (
      id bigint(20) not null auto_increment ,
      name varchar(255) not null,
      password varchar(255) ,
      primary key (id))
      engine=innodb
      default character set=utf8 collate=utf8_general_ci;
    
    insert into tmp_user (name, password) values ("寶寶不說","123");
    
    alter table tmp_user add index name_password(name,password);
    

  • 再次執行 SQL B：explain select password from tmp_user where name = '寶寶不說';
    本次的查詢就可以在「Extra」欄位看到 Using index 嚕～

    

2.2 資料庫設計與優化

• 使用 ER Model 做規畫
  在需求規格出來後，我們可以先透過 ER Model 整理資料間的關聯性，然後以此為基礎設計資料庫；向新人說明 Table 間的關聯時，它也是一個非常棒的輔助工具。
• 設計合適的文字欄位
  • 如果不確定該欄位會填入的文字長度，會選擇 VARCHAR 這種依據文字長度來使用儲存空間的 Type。
  • 以時常變更文字的欄位來說，會選擇 CHAR 而非 VARCHAR；因為 VARCHAR 的欄位在儲存時會需要額外的計算。
  • 盡量避免使用 TEXT/BLOB 這類的 Type，它們在查詢時會消耗更多的效能。
  • 根據實際業務需求設計欄位長度，
• 減少 SQL 寫入次數
  以 Insert 來做舉例，假設有 1000 筆資料要寫入 Table；一次插入 1000 筆的執行時間會遠遠小於分 1000 次插入的時間。
• 適當的增加冗餘欄位
  在設計資料庫時要盡量符合三大正規化；但 Table 間的關聯越複雜也會導致查詢效率的下降，因此有時會適當的增加冗餘欄位，用犧牲磁碟空間的方式換取更高的查詢效率。
• 定期審視資料庫的規劃
  如果沒有專門的 DBA，那資料庫通常會有以下問題需要修正：
  • 許多欄位因為不確定實際業務需求，直接把欄位長度開到最大。
  • 因為新需求不斷產生，在思慮不夠周密的狀況下容易新增許多無用欄位。
  • 在系統版本的更迭中，沒有整理不符合實際業務需求的檢視表（View）。
  • 後端存取 Table 的欄位改變，但 Table 的 Index 並沒有一起調整，導致許多 Index 並沒有發揮作用。

2.3 MySQL 與 PostgreSQL 的區別及應用場景

MySQL 是世界上最流行的資料庫之一，世界上有非常多的 Web Application 都採用它作為解決方案；但在被收購後分出了非常多的版本，有免費也有收費的；而 PostgreSQL 基於 BSD/MIT 的 linecense，為完全開源的資料庫。

• PostgreSQL 的優勢
  • 不僅是關聯式資料庫，還支援 jsonb 的格式
    相比於 json，jsonb 以二進位格式儲存且可以使用索引（Index），你可以利用它整合關聯式資料與非關聯式資料。
  • 有 PostGIS 讓他成為很棒的空間資料庫
    相比於 MySQL spatial extension，PostGIS 可以支持「二維、三維、曲線」的空間類型，並有豐富的空間操作函數。
  • 可以輕鬆與外部資料庫關聯
    透過 FDW（Foreign Data Wrapper），你可以把外部資料庫（ex：MySQL、Oracle、CSV）當成自己資料庫中的 Table 查詢，讓 PostgreSQL 成為聯合資料庫。
• MySQL 的優勢
  • 會 MySQL 的工程師更多
    在招募工程師時更容易，遇到問題時也有豐富的社群資源提供解答。
  • MySQL 使用 Thread 而 PostgreSQL 使用 Process

    • Process 比 Thread 要花更多時間建立連線。

    • Process 因為缺失 Thread 實作的「共享」特性，使得每次連線建立時，都需要耗費較高的記憶體空間配置。

      PostgreSQL 可以搭配 Connection Pool 的外掛解決這個問題，但架構上就會變更複雜。

• 應用場景
  • MySQL
    適合業務邏輯相對簡單、較少處理資料一致化問題的網際網路場景。
  • PostgreSQL
    專案資料寫入頻繁，且資料庫龐大而複雜，內容需要高度一致性，有 GIS 需求。

其實在 DB 的選擇上，除了考慮專案適用的場景外，還要考量到團隊內的工程師對哪個比較擅長；思考萬一發生意外時有誰可以救場，不然災難復原是一場惡夢。

3. 衍伸問題

3.1 為什麼 Index 不能建立太多？

考點：了解 Index 對資料庫效能的影響

Index 的數量太多，會影嚮 DML（Insert、Update、Delete）的效能，因為 Table 資料更新時也要連帶更新 Index。

3.2 寫 DB SQL 時會注意什麼？

考點：確認求職者的 SQL 基本功

• 不要回傳大量資料，要有條件的回傳固定筆數（ex：limit）。
• Select 時盡量不要使用「*」，只抓取需要的欄位。
• Select 充分使用 Index 來做搜尋。
• 避免使用不兼容的型態做比較，像是 FLOAT 跟 INT、CHAR 跟 VARCHAR。

3.3 有用過 NoSQL 嗎？什麼應用情境下會使用呢？

考點：確認求職者對 NoSQL 的認知

即便你的履歷中沒有寫自己會 NoSQL，還是會遇到這類考題，所以建議至少有基礎的認知。

• 資料表欄位常常變化
  像是商城這種擁有龐大資料量的系統，在關連式資料庫中如果要 Update 欄位有很多顧慮；因為每個操作都需要重頭到尾輪詢一次 Table，非常消耗時間。
  如果使用 MongoDB 這類的 NoSQL，就可以很靈活的對欄位進行調整。
• 需要高速的讀寫
  像是 Redis 這類記憶體資料庫，單一節點就能應付每秒 10 萬次的讀寫請求。
• 資料量龐大，有擴充需求
  NoSQL 具備水平擴充能力，只要增加新的伺服器節點就能擴充資料庫容量；且對於伺服器的性能要求較低，可使用較便宜的電腦進行擴充。

3.4 你會用哪些點來評估要使用關聯式資料庫 or 非關聯式資料庫？

考點：確認求職者是否有評估的能力與經驗

我會考慮的點有資料量多寡、併發量、實時性、資料一致性、未來擴充性、資料穩定性、維護成本。

以企業內部管理系統來說，因為資料量少、併發數少、未來擴充需求較低，所以會選擇關連式資料庫；如果是遊戲的排行榜頁面，因為資料量大、併發數高、且要求高的更新頻率，所以我會考慮使用記憶體資料庫（ex：Redis）。

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

參考資源

1. MySQL 資料庫面試題
2. 你在 Table 建立的 Index 真的有效嗎？用範例帶你理解 Coverage Index 的意義(筆者部落格)
3. MySQL 與 PostgreSQL 相比哪個更好？

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

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

你設計的 API 除了跑的動以外，它安全穩定嗎？

既然 Junoir 跟 Senior 的後端工程師都能寫出可以運作的 API；那公司為什麼要多花錢請一個比較貴的工程師呢？

不僅面試官會問這個問題，你也要時常反問自己：「我憑什麼可以開出更高的薪水？我跟其他的工程師有哪裡不一樣？」

大綱

1. 設計 API 時會考慮哪些點？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 驗證 Client 端身份
   • 2.2 了解後端驗證的重要性，並認識常見的 Validation Rule
   • 2.3 優化後端的常見方法
   • 2.4 淺談 Unit Test（單元測試）
3. 衍伸問題
   • 3.1 你知道 PUT & PATCH 的差異嗎？
   • 3.2 請舉例 RESTful api 的命名原則
   • 3.3 GraphQL 跟 RESTful API 的差異在哪裡？

1. 設計 API 時會考慮哪些點？

1.1 面試官為什麼會問？

能依照需求規格書寫好 API 只是對後端工程師的基礎要求；但這個 API 考慮的是否周全就看每個工程師的經驗了。

這算是常見面試題，面試官想從回答中了解你後端的實作經驗與基本功，並判斷你在進入團隊後是否需要花更多時間訓練才能成為有效戰力。

1.2 面試官想從答案確認什麼？

• 你設計的 API 是否有防護的機制
• 當 Client 端傳入不符規範的參數及型態時，你的 API 是否有成為防線
• 你有用什麼方法保證 API 的穩定性
• 是否有思考過 API 的優化

1.3 筆者提供的簡答

以過去設計的內部管理系統來說，Client 端在登入後會取得 JWT，之後在存取 API 前會用這個 JWT 來驗證是否有存取的權限；為了避免 Client 端使用不符規範的參數，我會先驗證每個傳入參數的格式，並撰寫 Unit Test 確保這隻 API 在不同情境下的 Response 都符合期待；再確認 API 的穩定性後，我會去思考還有什麼地方可以優化，讓 Client 端有更好的體驗。

2. 回答問題所需具備的知識

2.1 驗證 Client 端身份

這邊帶讀者瞭解兩種主流驗證機制，大部分的框架都有提供對應的方案供開發人員使用。

• Session 與 Cookie
  當 Client 端登入後，Server 會產生一筆 Session 並記錄（可能存在資料庫或記憶體），同時將可以識別身份的 SessionID 送回 Client 端儲存於 Cookie；此後 Client 端的請求，Server 只需要根據 Cookie 中的 SessionID 尋找 Session 來驗證使用者即可。
  • 使用 Session 要考量的問題
    1. 因為 Session 的資料存在 Server 中，需考慮同時有很多使用者上線時要面對的效能或是記憶體問題。
       • 解決方案：定期清理過期 Session。
    2. 如果採取 Cluster 部署，就要考慮不同 Server 的 Session 共享問題。
       • 解決方案：Server 需設計 Session 同步機制（Replication）。
• JSON Web Token（JWT）
  當 Client 端登入成功後，Server 會回傳一個 JWT，Client 端通常會將 JWT 儲存於 localstorage；當 Client 端打算訪問受保護的資源時，需要在 Header 的 Authorization 使用 Bearer 模式添加 JWT，如果驗證通過即可存取相關資源。
  • 使用 JWT 要考量的問題
    1. 在 Client 端取得 JWT 後，在 JWT 有效期內他都能夠使用；即使我們直接把使用者帳號刪除，這個 JWT 依舊可以訪問受保護的資源。
       • 解決方案：設計黑名單機制，使用記憶體資料庫維護一份黑名單，如果想讓某個 JWT 失效，把它加入黑名單就好了。
    2. 不要為了方便把 JWT 的有效期限設定太長，不然這個 JWT 洩露出去後，任何人都可以拿它來幹大事。
       • 解決方案：JWT 有效期限不要太長，同時使用 HTTPS 來減少盜用。

2.2 了解後端驗證的重要性，並認識常見的 Validation Rule

無論前端驗證做得多完美，後端驗證都是必須存在的；因為想攻擊系統的人不一定會從前端執行，直接 Call API 嘗試所有可能性的效率快多了；前端驗證可以大幅減少不必要的 Request 產生，後端驗證則是保護資料的最終防線。

• 為什麼要了解 Validation Rule？
  • 你可以節省非常多親手撰寫 Function 的時間（自己寫的效能跟穩定度未必好，還很佔版面）。
  • 這些不符規範的資料並不會進入後端運算的邏輯層面。
  • 驗證發現錯誤就 Response Error，減少 Client 端等待時間。

接下來用情境來介紹幾個常見的 Validation Rule，不同框架的名字可能略有不同，我這邊以 Laravel 的為主。

• 驗證使用者註冊系統時填寫的參數

  • 此為 Laravel 驗證傳入參數的程式，下方依據參數進行解說。

    $validator = Validator::make($request->all(), [
      'email' =>  ['required', 'email', 'string', 'max:255', 'unique:users'],
      'name' =>  ['required', 'string', 'max:50'],
      'password' => ['required', 'string', 'max:255', 'min:8', 'regex:/^.*(?=.{8,})(?=.*?[a-zA-Z])(?=.*?[0-9]).*$/', 'confirmed']
    ]);
    

    • email
      為必填 required 欄位，同時檢查傳入的字串是否符合 email 格式以及長度 max 是否超過限制，並確認這個 email 並沒有被註冊過 unique。
    • name
      為必填 required 欄位，同時檢查傳入的字串長度 max 是否超過限制。
    • password
      為必填 required 欄位，除了檢查傳入的字串長度 max 是否超過限制外，通常會限制最小長度 min；再嚴謹一點會要求 password 複雜度需包含英數字 regex，且內容與 password_confirmation 欄位相同 confirmed。

2.3 優化後端的常見方法

這邊先不討論程式語言和資料庫選擇帶來的影響，專注在共同可行性方案上。

• 操作資料庫時加入限制條件
  就算前端 Request 的參數沒有限制條件（ex：分頁、筆數、種類…），後端也要有意識的設定預設值，不然當資料量大的時候除了會跑很久浪費效能外，前端也不適合接收/呈現這麼多資訊。
• 回傳前端的資料盡量是已經計算過的
  Client 端使用的機器效能未知，如果把太多的邏輯運算交給前端可能導致不好的使用者體驗；我這邊建議後端最好回傳計算後的資料，前端負責顯示為主，不過這塊也要看實際的業務量以及情境來 trade-off 。
• 加入 CDN Cache
  如果遇到國外客戶抱怨連線速度很慢，就可以考慮採用 CDN 來解決這個問題；CDN 服務商的做法是將 Server 建置在世界各地，將網站上的靜態內容（圖片、影音、檔案）與動態內容（資料庫查詢）Cache 到 Server，根據訪客的地理位置，從最近的 Server 提供資料；好處如下：
  • 提升網站的穩定度（如果某個 CDN Server 掛了也有替身）。
  • 節省原本 Server 的頻寬（因為流量被分散了）。
  • 改善使用者體驗（過去會卡住的都是大檔案，有了 CDN Cache 後瀏覽會更流暢）。
• 提升硬體水平
  江湖傳言：「效能不夠，機器來湊！」雖然聽起來好像是在開玩笑；但實際業務上如果真的遇到效能瓶頸，許多公司的做法就是先靠硬體讓服務穩定；服務穩定了，你才有心力去 Refactor 程式。

2.4 淺談 Unit Test（單元測試）

• 為什麼 Unit Test 很重要？
  • 有它保證程式碼的穩定性，發生錯誤時可以快速找到源頭，因此開發人員可以更大膽的開發。
  • 減少手動測試的時間，大幅降低相關維運成本。
  • API 版本更新時（ex：v2 升級到 v3），確保舊版 API 可以正常運行。
• Unit Test 使用時機
  • 開發人員要先在本機 Run 過一遍，確認所有 Unit Test 都通過。
  • 如果有使用 Git 做版本控制，在特定 branch 合併時 CI/CD 應該要有某個 Stage 來做測試，確保合併分支的程式正確性。
• 撰寫 Unit Test 基礎概念
  • 測試時使用（或自動建立）Mock data，不要動到 Server 資料
    Unit Test 著重在測試程式邏輯，建議測試時使用 Mock data，不然可能導致正式環境發生意外。
  • 測試要涵蓋你程式中的所有邏輯
    • 假設一個 API 有 12 種回傳邏輯，你的 Unit Test 就要有 12 個；根據莫非定律，少寫的測試往往上線後就會爆掉。
    • 如果 API 有做 JWT 防護、Request 參數驗證，我建議要把所有錯誤情境都做一次模擬；甚至要模擬 JWT 還在有效期，但實際權限已被移除的邊緣測試。

筆者聽過有些公司在專案正式 Release 時沒有撰寫任何的 Unit Test，直接讓客戶人肉測試，等客戶回報錯誤時再去修復 Bug；嗯…這種公司的離職率通常很高，因為有一堆歷史業障需要修但沒人敢碰。

3. 衍伸問題

3.1 你知道 PUT & PATCH 的差異嗎？

考點：對於 API 基礎操作的掌握程度

「PUT」是替換資源，而「PATCH」則是更新部份資源內容；以使用者舉例，假設他有「姓名、簡介、年齡」這幾個欄位，如果想更新「姓名」的資訊：

• 用 PUT 方法送出更新，除了「姓名」外還要填寫所有的欄位，如果沒填寫會導致其他的欄位更新成預設值。
• 用 PATCH 方法送出更新，只需填寫要更新的「姓名」欄位即可。

3.2 請舉例 RESTful API 的命名原則

考點：確認你寫 API 的習慣是否符合標準

假設今天有一個 users 的 Table。

• 取得 user list
  • 方法：GET
  • API 路徑：/api/users
• 取得 user detail
  • 方法：GET
  • API 路徑：/api/users/{user_id}
• 新增 user
  • 方法：POST
  • API 路徑：/api/users
• 更新 user 資訊
  • 方法：PUT
  • API 路徑：/api/users/{user_id}
• 刪除 user
  • 方法：DELETE
  • API 路徑：/api/users/{user_id}

3.3 GraphQL 跟 RESTful API 的差異在哪裡？

考點：確認你對市場技術的認知程度

過去 RESTful API 需要根據需求規格書給每個 API 設計回傳的資料結構，如果這個 API 在很多頁面被共用就有可能要回傳更多的資訊，但回傳的資訊中有些是只有特定頁面才有需求的，假使拆成多隻 API 也會導致日後維護困難；而 GraphQL 的出現正好解決了這個問題，他能夠由 Client 端來定義 Server 端要回傳的資料結構，不再回傳冗贅資訊。

• 補充：用範例了解兩者差異
  要查詢圖書館中特定書籍，回傳內容須包含：「作者、書名、出版年」。

  • GraphQL

    • Client 端傳送的 query

      query {
        books (id:12) {
          authors {
              firstName
              lastName
          }
          title
          yearPublished
        }
      }
      

    • Server 端 Response 的 result

      {
        "data": {
          "books": {
            "authors": [
              {
                "firstName": "Lin",
                "lastName": "Dean"
              }
            ],
            "title": "全端工程師生存筆記",
            "yearPublished": "2022"
          }
        }
      }
      

  • RESTful API

    • Client 端的 Request
      需要拆成GET api/books/12、GET api/authors/12來分別取得書籍、作者資訊。

    • Server 端 Response 的 result
      GET api/books/12

      {
        "title" : "全端工程師生存筆記",
        "authorID": 12,
        "yearPublished" : 2022,
        "page": 168,
        "tags": ["履歷"、"面試"、"職場"]
      }
      

      GET api/authors/12

      {
        "firstName": "Lin",
        "lastName": "Dean"
      }
      

  在上面的範例中，RESTful API 需要兩個 Request 才能取得完整資料，如果想用一個 Request 取得完整資料就要重新建立一支 API；比較起來GraphQL 對前端工程師來說是更好使用的工具；不過轉換與建立的成本較 RESTful API 高，如果想嘗試 GraphQL 帶來的效益，可以考慮漸進式的遷移。

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

參考資源

1. 進階 RESTful API 討論
2. 透過 JWT 實作驗證機制
3. 認識 Cookie、Session、Token 與 JWT
4. 簡單聊一聊 Cookie、Session、Token、JWT 的區別和作用

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

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

前端工程師心裡 OS：「其實我是想要空等的。」

大綱

1. 在正式 API 完成前，如何讓未來要串接的工程師不要空等？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 Mock Server 是什麼？學它有什麼好處？
   • 2.1 用 Postman 建立 Mock Server
   • 2.3 設計 Mock Server Response
   • 2.4 設定 Environment 讓你快速切換執行環境
   • 2.5 匯出 API documentation 給同事使用指引
   • 2.6 讓 Mock Server 變成私有的

1. 在正式 API 完成前，如何讓要串接的工程師不要空等？

1.1 面試官為什麼會問？

這問題是想了解你現在的工作是如何運行的，因為許多專案都採取前後端分離的架構，前端常常要等後端完成後才能串接，如果後端提供的服務不穩定，又或是沒按造需求規格開發就容易導致前端空等。

1.2 面試官想從答案確認什麼？

• 你現在工作時，前端與後端是如何協作的
• 你有用什麼工具，讓前端不用等你寫完 API 就能提前串接
• 你有提供什麼文檔供前端串接時參考
• 如果回答的是某個工具（ex：Postman），會再詳細詢問有使用到工具的哪些功能

1.3 筆者提供的簡答

我會先依照需求規格整理出一份讓雙方共同遵守的開發文檔，同時使用第三方驗證工具「Postman」建立 Mock Server，並根據 Request 的參數給予對應的 Result 結果，讓前端不需要等後端 API 完成後才能開始串接的作業。

2. 回答問題所需具備的知識

市面上提供 Mock Server 以及產生 API doc 的工具很多，不過「Postman」是筆者用起來最順手的；Postman 除了 API 的基礎測試外，還有許多加速工作效率的功能，就讓我們透過這篇文章讓自己的 Postman 更專業吧！

2.1 Mock Server 是什麼？學它有什麼好處？

在前後端分離的架構下，前端在完成網頁版面佈局後，需等待後端完成 API 才能做後續的開發；為了不讓前端在這段時間偷懶苦等，Mock Server 應運而生！它能回傳自訂的資料結構供前端使用，等後端完成 API 後，前端只需要切換網址就能使用真實資料。

除了上面的原因外，如果你開發環境的後端 Sever 不太穩定常常罷工，Mock Server 也能保證你的工作效率不受影響，畢竟不可能每次都等到 Server 修好後再工作吧？

2.2 用 Postman 建立 Mock Server

Postman 改版非常快速，你看到的畫面可能跟我有些許不同

• STEP 1： 建立 Mock Server

  1. New > Mock Server

     

  2. Create a new Collection > input url > Next
     如果不是選擇已經存在的 API Collection，就需要至少填寫一個 Request URL 讓 Collections 有初始化的 API Request

     

  3. 給 Mock Server 取個名字，並建議你勾選儲存 mock server URL 到環境變數的選項。

     

• STEP 2： 檢查 Mock Server 是否建立成功

  1. 建立成功後便可以在「Mock Servers」的分頁中看到剛剛建立的 Server，點進去後能看到這個 Sever 的網址。

     

  2. 接著我們到「Environments」的分頁確認，mock server URL 是否有儲存到環境變數，

     

2.3 設計 Mock Server Response

在 Mock Server 建立後，我們要設計不同 API Request 回傳的資料結構。

• STEP 1：先用 Request 的 Default example 來了解使用方式

  1. 到「Collections」的分頁找到剛剛初始化的 Request， {{url}}會帶入環境變數所以右上角請選擇剛剛建立的「Mock_User」，按下「Send」後你會發現下面的 Response 一片空白，這是因為我們還沒設定 Mock Server Response。

     

  2. 在左側 Request 下面有一個「Default」，它就是用來自訂 Response 資料結構的 example，這邊我們用 JSON 格式寫個簡單的 Response example 後按「Save」。

     

  3. 回到剛剛的 Request，按下「Send」後會發現 Response 的資料結構跟剛剛填寫的範例相同。

     

• STEP 2：新增其他的 Response example

  1. 除了最初的 Default 外，我們還可以自己新增其他的 Response example。

     

  2. 可以透過加入 Params 讓這個 Request 有不同的 Response，這裡我們新增「error」、「correct」這兩個 example 並加入「control_res」這個 Params 來做示範。

     在「DESCRIPTION」填寫的資訊會顯示在 API 文件上，寫清楚一點不但方便自己記憶，也更容易讓合作者了解。

     

     

  3. 回到剛剛的 Request ，我們在「control_res」填入不同的 VALUE，按下「Send」就會看到對應的 Response 嚕～

     

     

2.4 設定 Environment 讓你快速切換執行環境

這是 Postman 重要的功能之一，它可以加快開發速度，讓你不用為每個環境都建立一個 Request。

• 如果沒設定會發生什麼蠢事？

  

  有沒有覺得上面這張圖片看起來很蠢，在了解 Environment 怎麼設定前，我的 Collections 就是這麼的複雜；因為開發時通常環境會分成：「Local、Dev、QA、Prod」，如果每新增一個環境你就複製一份，到最後你會無法進行妥善管理。

• STEP 1：新增 Environment
  之前在建立 Mock Server 時其實就已經用到了 Environment，這裡我再詳細的跟大家說這個東西的好處。
  請先到「Environments」的分頁按下「＋」的按鈕，接著輸入名稱來新增環境（我用 local_server 做示範）。

  

• STEP 2：設定常用的 Environment variables

  • url
    這個是最實用的環境變數，讓你只需要調整 Request 的 Environment 就快速切換網址做測試。

  • login_user、login_password
    每個環境的使用者登入資訊通常略有不同，且大部分的 API 都需要透過登入取得 token 才能使用，把他們加入環境變數可以加速你的測試。

    警告：不建議把正式機的 password 加入環境變數，且測試機的 password 不要用平常自己會用的密碼，不然資安很危險的，都已經可以偷懶用 Environment，密碼自己去產生一組吧。

  

• STEP 3：在 Request 使用 Environment variables
  想在 Request 中使用 Environment variables 只需要用 {{your_env_var}} 包起來就好，另外右上角記得要切換到正確的 Environment 才會帶入相應的資料喔！

  

2.5 匯出 API documentation 給同事使用指引

相信後端工程師有一個共同經驗，無論你的 API 文件寫得再清楚、功能執行的再穩定；到了同事手中卻常常被說不能 Work，緊張的你檢查很多遍也找不出問題，百思不得其解的抵達同事座位後，才發現他原來漏了某個參數。

如果你有這樣的經驗，Postman 內建的 API documentation 能拯救你，讓你在 Publish 文件後可以跟同事幸福快樂的生活。

• STEP 1：View documentation
  選擇想要產生文檔的 Collection，按下「View documentation」後文檔就會顯示在右側，你可以透過切換右上角的環境變數來檢視文檔。

  

• STEP 2：Publish documentation

  1. 當你確定文檔內容都沒問題後按「Publish」。

     

  2. 接著會要你調整一些參數，調整完後建議先用左側的「Preview Documentation」自己確認看看是否符合。

     

  3. 確認一切都沒問題後按下「Publish Collection」就發布出去嚕～

     

• STEP 4：Share API Doc URL
  你可以將 URL 複製起來分享給你的合作夥伴，如果你想把這份文檔下架，按「Unpublish」即可。

  

2.6 讓 Mock Server 變成私有的

前面在建立 Mock Server 時，不知道有沒有人注意到「Make mock server private」的選項，在做這個設定前 Mock Server 的 URL 都是公開的，如果你想為自己的 Mock Server 多一層防護可以跟著下面步驟操作：

• STEP 1 : 編輯 Mock server

  1. 在「Mock Servers」分頁打開之前創建的 Server，按下「Edit」。

     

  2. 將「Make mock server private」打勾並按下「Save changes」。

     

  3. 回到之前的 Request，你會發現按下「Send」後會回傳錯誤訊息，這是因為現在 Mock Server 都需要添加 API key 到 Request 的 Header 才能使用。

     

• STEP 2 : 產生 Postman API key

  1. 進去這個 網址 ，點擊「Generate API key」。

     

  2. 填上用來識別這個 API key 的名稱後按下「Generate API key」。

     

  3. 接著請複製這個 API key，上面已經警告你這是唯一見到它的機會了。

     

• STEP 3：將 API key 加入 Environment
  因為日後 Mock Server 的所有 Request 都需要這個 API key，所以我們把他加入 Environment，變數名稱為「x-api-key」。

  

• STEP 4：在 Request 的 Header 加上 x-api-key
  最後回到 Request，在 Headers 的分頁下加入「x-api-key」這個參數並將環境變數 {{x-api-key}} 作為值，最後按下「Send」就能看到正確的 Response 回傳嚕！

  

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

參考資源

1. 讓你的 Postman 更專業(筆者部落格)

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

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

熟悉的起手式：「我方便問你一個 Node.js 核心的問題嗎？」

這是一個在了解後，無論面試還是工作，CP 值都很高的題目，建議讀者要真的融會貫通。

大綱

1. 請簡述 Node.js 的 Event Loop
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 Event Loop 執行的邏輯
   • 2.2 用 Node.js 範例程式確認自己是否理解 Event Loop
   • 2.3 解析 Node.js 範例程式執行順序
3. 衍伸問題
   • 3.1 可以簡述 Node.js 跟 JavaScript 的差異嗎？
   • 3.2 readFile 和 createReadStream 函式的差異？
   • 3.3 REPL 是什麼？

1. 請簡述 Node.js 的 Event Loop

1.1 面試官為什麼會問？

只要你的履歷上有 Node.js，10 間公司至少有 3 間會問這個常見面試題；而且問題的起手式出奇的一致：「我方便問你一個 Node.js 核心的問題嗎？」

1.2 面試官想從答案確認什麼？

• 你了解 Event Loop 對 Node.js 的重要性
• 你能大概說明 Event Loop 每個階段的任務
• 如果出白板題要你解釋程式執行的順序，你可以正確回答

1.3 筆者提供的簡答

Node.js 之所以高效，是因為採取單執行緒與 Event Loop 的概念；將所有需要等待結果、請求外部資源的函式，全部丟到 Event Loop 中等待；而 Event Loop 的邏輯是 Node.js 底層用 C 語言撰寫的 libuv 庫來運行的。

2. 回答問題所需具備的知識

2.1 Event Loop 執行的邏輯

• 了解 MacroTask 的 6 個階段
  • Timer
    等計時器（setTimeout、setInterval）的時間一到，會把他們的 callback 放在這裡等待執行。
  • Pending callbacks
    作業系統層級使用（ex：TCP errors、sockets 連線被拒絕）。
  • Idle, Prepare
    內部使用。
  • Polling：
    • 如果 Queue 不為空，依次取出 callback 函數執行，直到 Queue 為空或是抵達系統最大限制。
    • 如果 Queue 為空但有設置「setImmediate」就進入 Check 階段。
    • 如果 Queue 為空但沒有設置「setImmediate」就會在 Polling 階段等待，直到 Queue 有東西或是 Timer 時間抵達。
  • Check
    處理 setImmediate 的 callback。
  • Close callbacks
    處理關閉連線、檔案的 callback。

Macrotask Queue 在 Evevnt Loop 優先層級較低，接下來介紹優先層級更高的兩個 Queue。

• NextTick Queue 優先層級最高
  「process.nextTick()」的 callback 可以隨意插隊；只要這個 Queue 有東西就會優先執行。

• MicroTask Queue 優先層級次高
  「Promise」的狀態從 pending 轉變為 resolve 或 reject 時，執行的 callback 會進入這個 Queue。

  注意：Promise 在創建時是同步的，不會進入 Event Loop。

2.2 用 Node.js 範例程式確認自己是否理解 Event Loop

大家可以先用紙筆模擬看看下面程式的執行順序：

console.log("start");

process.nextTick(function () {
  console.log("nextTick1");
});

setTimeout(function () {
  console.log("setTimeout");
}, 0);

new Promise(function (resolve, reject) {
  console.log("promise");
  resolve("resolve");
}).then(function (result) {
  console.log(result);
});

(async function () {
  console.log("async");
})();

setImmediate(function () {
  console.log("setImmediate");
});

process.nextTick(function () {
  console.log("nextTick2");
});

console.log("end");

如果答案跟下面結果一樣，那代表你很了解 Node.js 的 Event Loop 邏輯：

start
promise
async
end
nextTick1
nextTick2
resolve
setTimeout
setImmediate

2.3 解析 Node.js 範例程式執行順序

• SETP 1： 順序執行，先把同步函式解決。

  1. 因為 Promise 在創建時是同步的，所以會先執行。

  2. 在 function 前面加上 async 宣告為異步函式，執行時會被轉換為 Promise。

     console.log("start");
     
     new Promise(function (resolve, reject) {
       console.log("promise");
       resolve("resolve");
     }).then(function (result) {
       console.log(result);
     });
     
     (async function () {
       console.log("async");
     })();
     
     console.log("end");
     

• STEP 2： 進入 Event Loop。

  1. 如果執行過程中遇到 NextTick Queue 就優先執行。

     process.nextTick(function () {
       console.log("nextTick1");
     });
     
     process.nextTick(function () {
       console.log("nextTick2");
     });
     

  2. 在處理完最高優先層級後，如果執行過程中遇到 MicroTask Queue 就執行。

     new Promise(function (resolve, reject) {
       console.log("promise");
       resolve("resolve");
     }).then(function (result) {
       console.log(result);
     });
     

  3. 在前兩個高優先層級的 Queue 清空後，返回 Event Loop 繼續執行，setTimeout 設定的時間已到先執行。

     setTimeout(function () {
       console.log("setTimeout");
     }, 0);
     

  4. 接著再在「Check」 階段執行 setImmediate

     setImmediate(function () {
       console.log("setImmediate");
     });
     

以上步驟執行完成後就是範例程式的解答啦～希望對大家理解 Event Loop 有幫助。

3. 衍伸問題

3.1 可以簡述 Node.js 跟 JavaScript 的差異嗎？

考點：確認求職者是否理解自己天天使用的工具

JavaScript 是程式語言，可以在合適的瀏覽器中運行；而 Node.js 是一個能執行JavaScript 的環境，它以 Chrome V8 引擎為核心，再加上 C/C++套件，讓 Sever 端也可以執行 JavaScript。

3.2 readFile 和 createReadStream 函式的差異？

考點：判斷求職者過去專案中使否使用過這類函式，並理解差異

readFile 函式會將讀取到的完整內容存在記憶體後傳給使用者，而 createReadStream 函式則是逐塊讀取檔案，不是全部存在記憶體中；因此要讀取較大的檔案時，建議使用 createReadStream ，利用其逐塊讀取的特性能減少使用者等待時間。

3.3 REPL 是什麼？

考點：對專有名詞是否熟悉，能否解釋

REPL（Read Eval Print Loop）是一個用來執行程式語言的虛擬環境。

就像是我們在瀏覽器的 Console 可以執行 JavaScript 程式碼；在安裝完 Node.js 後，新增一個 JavaScript 檔，在終端機輸入node xxx.js便可以執行它。

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

參考資源：

1. Node.js 的 Event Loop (事件輪詢)到底在做什麼？(筆者部落格)
2. 15 個常見的 Node.js 面試問題及答案
3. 你有沒有想過，到底 Server 是如何「同時處理多個 requests」的？ - Node.js 篇

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

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

你是十八般武藝樣樣精通，還是樣樣通樣樣鬆？

工程師真的很難，會得不多會被問為什麼沒學，會得很多還要被質疑專業程度；這種比較類型的問題，除非你有事先做功課，不然就算你都會用也未必能在現場對答如流。

大綱

1. 你會的後端框架不只一個，可以說明一下它們之間的差異嗎？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 PHP VS Node.js
   • 2.2 用 supervisor 讓 Node.js 熱更新
   • 2.3 不一定要拼個誰輸誰贏
3. 衍伸問題
   • 3.1 既然你先學了 Node.js 的框架，為何後來改用 PHP 的框架？
   • 3.2 使用框架有什麼好處跟壞處？

1. 你會的後端框架不只一個，可以說明一下它們之間的差異嗎？

1.1 面試官為什麼會問？

因為履歷資訊中顯示求職者會如下的後端（Backend）框架：

• PHP：Laravel
• Node.js：Express.js、AdonisJS

當你會的東西多，面試官就會想了解你是每個都學一點，還是真的了解它。

1.2 面試官想從答案確認什麼？

• 能否簡單敘述 PHP 與 Node.js 的差異
• 舉例過去用這些框架做過哪些專案或是功能
• 為什麼會學習新的框架

1.3 筆者提供的簡答

之前使用 PHP 的 Laravel 框架開發過內部管理系統，也曾用 Node.js 的 Express.js 框架完成過餐廳點餐系統。

兩者的差異主要因為程式語言而產生的，PHP 是同步語言、多執行緒，Node.js 是一個能執行 JavaScript 的環境，支援非同步，為單執行緒。

如果專案要求穩定一致的效能，我會偏向使用 PHP 框架；而如果要承接高流量，我會選擇 Node.js 框架。

2. 回答問題所需具備的知識

2.1 PHP VS Node.js

如果面對一個問題只有一種解決方案時，面試官會深入詢問這個技術；但如果面對問題有兩個以上的解決方案，他就會問你在不同情境下該使用什麼技術，每個技術都有各自的優勢，這邊我們就從不同的角度來做分析吧～

• 同步的 PHP vs 異步的 Node.js
  • 同步的 PHP 會為每個 Request 建立一個 thread，每個 thread 都會消耗記憶體，也就是說如果想要服務更多的客戶就要花心思在硬體設備上。
  • 異步的 Node.js 是非阻塞 (non-blocking) I/O 設計，搭配上 Event Loop 可以用一句很形象的話說明：「與其人多但好多人閒著；還不如一個人拼命往死裡做。」
• 多執行緒的 PHP VS 單執行緒的 Node.js

  • 多執行緒 (multi-threaded)的 PHP
    使用阻塞 (blocking) I/O 的設計

    PHP 可以為每個 Request 都開一個執行緒；如果你想要實現非阻塞也能透過 reactPHP 來實現。

  • 單執行緒 (single-threaded)的 Node.js
    使用非阻塞 (non-blocking) I/O 設計 + 提供非同步 (asynchronous) 處理

    Node.js 原則上是單執行緒，但可以透過 PM2 的 Cluster Mode 達到多執行緒。

• 應用場景
  從 Client 端與 Server 端的溝通頻率來做分析：
  • 溝通頻率不高
    PHP 是個不錯的選擇（ex：個人部落格，像 WordPress 就是用 PHP 寫的）。
  • 溝通頻率頻繁
    Node.js 更能激發性能（ex：single-page-application、聊天室）；它適合大吞吐量的系統，較不適合需要大量 CPU 運算的系統。
• 可使用的資源

  • PHP 有 Composer
    Composer 的命名方式：「所有者/package 名稱」

  • Node.js 有 NPM
    NPM 的命名方式：「package 名稱」

    因為 NPM 的命名方式太自由，導致上面有很多的資源都是無效資源，關鍵字第一個找到的未必是最合適的。

• 人才市場
  • 人才數量
    PHP 比 Node.js 早了 10 幾年發行，因此市場上使用 PHP 的人比使用 Node.js 的人更多；如果職位流動性高，用 PHP 開發會比較合適。
  • 薪資
    物以稀為貴，同樣都是新人，會 Node.js 的薪水會略高於會 PHP 的求職者。
• 專案容量
  用 Laravel 跟 Express.js 來比較：
  • 專案初期
    一開始 Laravel 因為包山包海所以專案體積較大。
  • 專案後期
    儘管 Express 是 Node.js 輕量級的框架，但因為實作過程往往要擴充一堆 package，而且一個 package 往往會有很多的 dependency；這些原因容易導致最終實作出來的是一個笨重的專案。
• 程式語言轉換
  除非你的運氣逆天，每次都剛好找到符合你技能樹的公司，而且這間公司專案用的技術還很固定；不然肯定要面對程式語言的轉換，這邊分享幾個轉換時要注意的重點。
  • 找類型相似的框架
    從 PHP 跳到 Node.js 一定會面臨諸多不適應；但如果你選擇的是跟 Laravel 很類似的 AdonisJS 框架，這份不適感會下降許多，反之亦然。
  • 語言語法
    如果你已經熟悉了一種程式語言，我覺得轉換到另外一個語言的學習成本不會太高；但許多內建函式都要重新學習、生命週期也要重新熟悉、錯誤處理的經驗也要重新累積。
  • 專案規模
    如果是只需要 CRUD 邏輯的小專案，那我覺得藉此多瞭解一門程式語言是一個很棒的機會；但如果面臨的是業務邏輯複雜的大專案，我強烈建議一定要選自己熟悉的程式語言，或者團隊中的扛霸子熟悉這門語言；不然出事根本沒人可以救得了。
• 效能
  • 響應速度
    Node.js 靠著 V8 引擎加上非同步的特型，擁有較快的響應速度。
• 面對錯誤的處理

  • PHP 遇到某個 Request 錯誤時，它只對這個 Request 產生影響。

  • Node.js 因為所有 Request 都在單執行緒的 Web-server 中，所以某個 Request 導致的未知錯誤就可能影響到整個 Server。

    不過這塊可以透過 PM2 的 Cluster Mode 與自動重啟來補救。

• 熱更新
  • PHP 修改後，只要刷新頁面就能看到。
  • Node.js 預設沒有熱更新，需要關閉專案後重啟。

2.2 用 supervisor 讓 Node.js 熱更新

在開發階段推薦使用 supervisor 這款套件。

• STEP 1：在全域安裝套件npm install supervisor -g

• STEP 2：建立一個myapp.js的檔案，並複製貼上下面程式

  var http = require("http");
  http
    .createServer(function (req, res) {
      res.writeHead(200, { "Content-Type": "text/plain" });
      res.end("Hello World!");
    })
    .listen(3000, "127.0.0.1");
  

• STEP 3：用node myapp.js啟動程式後，修改res.end("Hello World!");的內容；再刷新網頁後內容不變。

• STEP 4：改用supervisor myapp.js啟動程式，修改res.end("Hello World!");的內容；再刷新網頁後內容更新。

supervisor 也可以做專案資料夾的監控，但是要記得排除一些資料夾（ex：儲存 log 檔的）；否則你的專案就無時無刻在重起了。

如果是正式的網站且流量大，建議使用 PM2 來做處理，它也有監控資料夾的功能。

2.3 不一定要拼個誰輸誰贏

存在即合理

• 小專案不用花太多時間在評估框架及程式語言選擇上
  有些公司對專案要用什麼框架以及程式語言保持著非常謹慎的態度，謹慎的態度是對的，但也要考量到專案的規模；如果今天的專案就是 CRUD 的簡單應用，預估使用者數量不多或是主要來自於內部成員，用什麼框架及程式語言其實都差不多。
• 看組織成員擅長的語言
  如果公司高層為了追求潮流而要求開發人員用一個不熟悉的框架去做專案，他最好祈求專案上線後平平安安；不然出事了公司沒有能夠處理的人才，沒有人會在意一個不能用的網站效能有多好。
• 每個程式語言都有自己的擁護者
  在不同的條件下，每個程式語言都有自己的優勢，而且每年都會誕生新的框架與程式語言；筆者覺得與其不停盲目追逐新的技術，不如先深入研究一個成熟的技術，當你有辦法靠它解決各種現實難題時，再去學新的框架跟程式語言也不晚。

3. 衍伸問題

3.1 既然你先學了 Node.js 的框架，為何後來改用 PHP 的框架？

考點：這題其實是想了解求職者的人格特質

這兩個都是為了解決問題的技術，我一開始用 Node.js 的 Express 框架獨立完成了幾份專案；但後來有一個需要 Team work 的大型專案，因為當時的組長比較熟悉 PHP 的 Laravel 框架，所以我便藉由這個機會學習新的技術；也因為這次的技術轉換，讓我了解不同框架在部署以及效能各方面的差異。

我想透過上面的回答給面試官幾個訊息：

• 我能獨立完成專案，也可以團隊合作。
• 我願意學習新技術。
• 學習的同時會分析不同框架的優劣。

3.2 使用框架有什麼好處跟壞處？

考點：確認求職者對框架的認知

• 好處
  框架能夠讓初學者快速入門並開發出有一定水平的專案，因為框架提供了許多常用的函式，因此可以大幅縮短專案時程；在團隊協作上框架優勢更為明顯，能夠讓成員有一致的開發方式。
• 壞處
  因為框架已經幫開發人員做了太多事情，這會導致開發人員並不理解許多功能的原理，這也造成了一但框架無法滿足功能，初學者的生產力會斷崖式下降；如果長期使用，也容易讓自己的開發思維被限制在框架內。

筆者碎碎念

希望讀者不要只把我提出來的問題當成面試會出的考題；當面試官會這樣詢問時，通常是因為實務上也會遇到類似的問題。

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

參考資源：

1. PHP + Apache Stack vs Node.js
2. 服務端 I/O 效能大比拼：Node、PHP、Java、Go
3. 簡析 Node.js 特點與應用場景
4. 詳細版 | 用 Supervisor 守護你的 Node.js 進程
5. 淺談 Node.js 和 PHP 程式管理

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

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

回想當年還是前端菜鳥時，我完全信任後端前輩回傳的資料；記得當年有個產品上線前的測試一切正常，但上線幾天後 PM 就接到客戶回報系統上有頁面顯示不全的 Bug；因為網頁前端是我負責的，所以第一個被抓去興師問罪。

經驗不足的我在收到 Bug 後，先用本機的環境模擬客戶遇到的問題，但弄了老半天始終查不出問題發生的原因；最後到客戶的正式機上查看顯示不全的頁面，才發現原來是後端忘記更新正式機的 API 版本；把狀況跟後端的前輩溝通後，才順利解決這個 Bug。

為了避免這種狀況再次發生；之後在寫前端時，都會先驗證後端回傳的資料是否符合規定的 JSON 資料結構。

大綱

1. 在使用後端的資料前，你有先做驗證嗎？
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 認識「JSON schema」
   • 2.2 安裝「jsonschema」並了解它的優點
   • 2.3 「jsonschema」驗證範例
3. 衍伸問題
   • 3.1 前端開發時會考慮哪些問題

1. 在使用後端的資料前，你有先做驗證嗎？

1.1 面試官為什麼會問？

這算是常見面試題，主要確認你的前端技術力，這類題目範圍非常廣泛；有興趣的朋友可以看我放在參考資源的「前端工程師面試問題集」；因為問題太過廣泛，幾乎無從準備，所以面試時就看個人基本功夠不夠深，經手的專案有沒有用到了。

1.2 面試官想從答案確認什麼？

• 你過去的專案是否有做這塊的基礎驗證
• 你的基本功是否紮實

1.3 筆者提供的簡答

現在的專案採前後端分離的架構，在前端使用後端的資料前，我會先透過「jsonschema」這款套件驗證 JSON 資料結構，確認後端回傳的欄位是否齊全、格式是否正確；以此避免前端顯示有問題的資訊，在遇到問題時也可以快速釐清是前端還是後端造成的。

2. 回答問題所需具備的知識

2.1 認識「JSON schema」

在介紹套件前，先讓大家對「JSON schema」有一個基礎認知；它是一種基於 JSON 格式定義 JSON 資料結構的規範，下面放上一段範例讓大家快速了解：

const person_schema = {
  type: "object",
  properties: {
    name: { type: "string" },
    age: { type: "number", maximum: 150 },
  },
  required: ["name", "age"],
};

我相信上面這個「JSON schema」應該是非常簡單易懂，他要求 JSON 的格式需要符合以下要求：

• name 為 string
• age 為 number 且最大值不得超過 150
• name 與 age 都是必需的

2.2 安裝「jsonschema」並了解它的優點

現在有許多套件提供驗證 JSON 格式的功能，今天筆者用自己熟悉的套件：「jsonschema」來跟讀者們分享，了解使用的邏輯後，想換成其他套件都非常容易。

安裝步驟

• SETP 1：建立一個專案資料夾。
• SETP 2：在終端機輸入 npm init 初始化專案。
• SETP 3：在終端機輸入 npm i jsonschema 安裝套件。

套件優點

如果後端 API 版本變更、 DB 的 Table 欄位變更沒有通知前端，前端頁面就可能發生新資料沒有位置放、舊資料部分欄位為空的狀況；如果沒有這個套件守護前端，工程師可能就要背黑鍋了。

• 可以詳細定義要驗證的 JSON 資料結構，包含內部所有參數的型態（string/number/array/object）。
• 驗證到錯誤格式時，會明確說明錯誤的原因。
• 可客製化錯誤訊息，轉換成好理解的文字。
• 學習及使用非常直覺。

2.3 「jsonschema」驗證範例

• SETP 1：在專案資料夾下建立「simple.js」來了解如何驗證 JSON 資料結構。

• STEP 2：以剛剛的 person_schema 作為範例來跟大家做講解，程式如下：

  var Validator = require("jsonschema").Validator;
  var v = new Validator();
  
  const personSchema = {
    type: "object",
    properties: {
      name: { type: "string" },
      age: { type: "number", maximum: 150 },
    },
    required: ["name", "age"],
  };
  var person = {
    name: "baobao",
    age: 14,
  };
  let result = v.validate(person, personSchema);
  console.log("valid：" + result.valid);
  console.log(result);
  

• STEP 3：在終端機輸入 node simple.js，會看到如下的驗證結果：

  valid：true
  ValidatorResult {
    instance: { name: 'baobao', age: 14 },
    schema: {
        type: 'object',
        properties: { name: [Object], age: [Object] },
        required: [ 'name', 'age' ]
    },
    options: {},
    path: [],
    propertyPath: 'instance',
    errors: [],
    throwError: undefined,
    throwFirst: undefined,
    throwAll: undefined,
    disableFormat: false
  }
  

• STEP 4：了解輸出參數的意義

  • valid：用布林（boolean）型態回傳驗證是否通過（true/false）。
  • instance：這是我們想要驗證的資料，此範例要驗證的資料是person這個變數。
  • schema：我們提供驗證的規則（JSON schema）。
  • errors：會以陣列的形式顯示驗證發現的錯誤，你可以透過這個參數在前端顯示錯誤原因；因此次驗證的資料結構正確，故回傳空陣列。

• STEP 5：將person改為錯誤的資料結構：

  • 將必填參數name移除
  • 把 age 的數字填寫超過最大值

  var person = {
    age: 200,
  };
  

• STEP 6：在終端機輸入 node simple.js，確認驗證結果的 errors 是否捕捉到錯誤。

  errors: [
      ValidationError {
        path: [Array],
        property: 'instance.age',
        message: 'must be less than or equal to 150',
        schema: [Object],
        instance: 200,
        name: 'maximum',
        argument: 150,
        stack: 'instance.age must be less than or equal to 150'
      },
      ValidationError {
        path: [],
        property: 'instance',
        message: 'requires property "name"',
        schema: [Object],
        instance: [Object],
        name: 'required',
        argument: 'name',
        stack: 'instance requires property "name"'
      }
  ],
  

透過以上範例，相信大家都明白「jsonschema」套件的基礎使用方式，有興趣深入研究的朋友請參考官網文件；如果沒接觸過「JSON schema」的朋友建議自己手動實做看看，這算是非常重要的前端概念。

3. 衍伸問題

3.1 前端開發時會考慮哪些問題

這就是個大哉問，每個人都有自己考慮的點，我建議回答自己擅長且真的有導入專案的部分，因為通常後續會有更深入的問題。

考點：透過一個廣泛的問題，了解你開發時最在意的點

為了減少設計變更，在開始前會先請 UI/UX 設計好 Wireframe（Figma），並向使用者說明流程取得共識，直到雙方確認都沒問題後再進入開發階段；為了讓網頁風格一致，前端在設計時會遵循 Material Design。

為了提升開發效率，會先思考哪個 Framework 較適合這個專案；在依照設計提供的 Protype 完成設計後，會先用Responsively這款工具，確認網頁在不同解析度的裝置上是否會跑版。

完成前期開發後，會思考如何優化效能，像是用 lazy loading 提升頁面載入速度、減少頁面 Request 數量及 Response 時間，透過這些設計讓使用者有更好的體驗。

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

參考資源

1. 拒當前端黑鍋俠！用「jsonschema」來驗證後端回傳的 json 資料結構(筆者部落格)
2. ajv-validator/ajv
3. 驗證資料的好幫手 - JSON Schema Validator
4. 前端工程師面試問題集

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

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