他說：「如果面試 Senior 以上的職位，我更看重他過去是否有處理正式環境 Critical issue 的經驗；因為技術可以靠後天學習，但有能力處理正式環境 issue 的人並不多。」

停頓了一下，又補充一句：「技術能力只能用來衡量平時的工作效率，但遇到緊急狀況時，在壓力下是否有足夠的膽量與決策能力就很看人格特質了。」

接著向我分享一個系統升級遇到意外的案例。

為什麼正式環境發生意外時很難處理？

如果公司有一定的制度與規模，系統在升級前往往有完善的單元測試，並通過 QA 團隊在不同情境的模擬測試。

因為事前已經考慮得相當周全，所以當問題發生時，就代表大家根本沒想過這個情境。

加上系統升級會對外公告維護時間，如果沒在期限內解決問題就出包了。

這邊我簡單描述一下問題是怎麼發生的：

A 系統升級時，會需要跑一個一次性的腳本向 B 系統取得資料；但 B 系統的資料不完整，所以 B 系統還要向 C 系統取得部分細節資料。

在測試環境跑腳本時，一切順利，但上到正式環境後，跳出了「timeout（超時）」的錯誤訊息。

如何定位問題？

出現「timeout（超時）」的問題後，大家並沒有很緊張，覺得只要放寬 A 系統呼叫 API 的時間就好。

但時間放寬後，timeout 的問題依舊存在，所以接著把目光轉移到 B 系統與 C 系統上，並將程式與 Nginx 的 timeout 時間拉長。

原本想說這樣問題總能解決了吧？

但結果不如人意，timeout 的錯誤依舊頑強地顯示。

為了更精準定位問題，大家把 A 系統、B 系統、C 系統的 API 分開測試，最終發現根本的問題在 C 系統。

不要讓自己陷入只有一個解決方案的思維

儘管成功定位了問題，但不知道為什麼 C 系統怎麼放寬 timeout 的設定都沒有生效。

而此時系統維護的時間剩不到半小時，想透過優化演算法來加快效率已經來不及了。

經過討論後，大家決定不解決 timeout 的問題，而是想辦法不要讓 API timeout。

最終的方案也非常簡單，只是將 B 系統取得的資料多拆成多份，以 C 系統絕對不會 timeout 的資料量傳送就解決了問題。

這個案例有什麼值得學習與警惕的地方

從結論來看，加 3 行程式碼就解決了問題。

但要做出這個決策並不容易，因為 A、B、C 系統是由不同的團隊進行開發，如果沒有良好的溝通能力，可能連一開始的問題定位都做不到。

找到問題點後，如果沒有人同時對 A、B、C 系統有一定的掌握度，我想大部分的人會把目標放在解決 timeout 問題，而非調整程式邏輯。

以這個案例來說，解決問題的人不一定要程式能力很強，但要具備良好的溝通能力，並對多個系統有一定的掌握度，且擁有靈活的思維，不會只想用一種方法解決問題。

我想，擁有如上特質的人，是市場上真正的稀缺人才。

最後提醒一下大家，雖然解決問題很帥，但以這個案例來說，只要在測試時考量到正式環境與測試環境的資料量差異，並加上對應的限制與分頁設計，就有機會避免問題發生。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

所有想要的一切都要靠自己主動爭取，在職場懂得「包裝」才有更多機會！

上個月受 iThome 邀約，到鐵人講堂分享職涯經驗。

在準備這次分享的過程中，我在想，如果時光能倒流，我會給過去的自己哪些職涯建議。

跟許多工程師朋友討論後，我最後選擇了「履歷」這個主題，因為每個人一定都會用到。

這堂講座並不會要大家馬上做出重大改變，而是給予一些建議，讓大家可以在熟悉的環境中多做一點事來認識、調整自己。

課程大綱

一、準備履歷不只是為了面試！

• 了解履歷對職涯的重要性
• 求職履歷該有哪些元素？
• 撰寫讓別人想認識你的「重點」
• 擴充自己的履歷

二、你要對自己的履歷瞭若指掌

• 工程師履歷範本
• 寫好履歷後要做的功課
• 面試官從履歷中看到了什麼

三、用簡報讓面試官集中注意力

• 準備面試簡報有哪些好處？
• 簡報要有哪些內容
• 提升簡報穩定度的 4 個方法

如果想優化自己的履歷、增加面試時的穩定度，點擊下方連結，現在只要註冊 iThome 會員就可以「免費」觀看嚕：

https://itplus.ithome.com.tw/webinar-page/201

心態上的差異

我們通常是 18 歲上大學，此時的我們還沒有遭受過社會的毒打，並不知道畢業後將要面臨什麼樣的挑戰。

所以大部分的人都是用輕鬆愉快的心情去讀大學，儘管表面上讀了 4 年，但實際上有多少時間在讀書，就真的只有自己才知道了。

而選擇靠補習班轉職的人，大多有一定的社會歷練，他們是認知到目前的職涯並不是自己想要的，所以下定決心轉換跑道。

跟大學生比起來，他們通常是抱持著「改變命運」的想法去上課，因此這兩者的學習積極度是完全不同的。

有些大學生會翹課，或是在上課滑手機；但報名補習班的人通常都會準時出席，上課認真做筆記，下課找老師問問題，假日繼續研究。

補習班報名費是自己的血汗錢，沒理由打混摸魚浪費掉。

面試的表現

許多本科系畢業的學生並沒有認真準備面試，很多都是憑本能在回答問題的；而補習班出來的人，通常都有經歷過模擬面試，知道不同問題該如何應對。

師父領進門，修行在個人；畢業證書只不過是一張入場卷，讓你有機會被更多人看見。

在人才市場上，「人」就是商品，包裝精美的容易溢價，賣相較差的容易折價；不要期待公司主動理解你的內涵，在職場上要懂得「包裝」才有更多機會！

並不是每個人都適合當工程師

筆者是資工系畢業，但身旁有些同學儘管畢業了，但還是不太會寫程式。

也許會有人好奇這樣是要怎麼畢業？不是都有「上機考」測驗嗎？

恩…他們為了畢業，硬生生把幾百行、上千行的程式碼給背下來了。

對！你沒看錯！是「背下來」而不是靠自己對程式的理解寫出來的；其實這也側面說明，就算是本科系畢業，他的天賦也未必適合當一名工程師。

很多人大學選擇科系是憑「直覺」，或是看哪個科系未來比較「賺錢」；但如果發現自己不適合又堅持不轉系，就會白白浪費 4 年光陰。

相比下來，如果你對一個領域一無所知，補習班 3~6 個月的長度是更為合適的，他能讓你先體驗看看自己到底適不適合這個領域

未來發展

人生很長，在長達 30~50 年的職涯面前，是不是本科系就沒有那麼重要了。

也許在職涯初期，本科系出身的人表現更好、知識更全面；但隨著時間推移，如果沒有持續精進自己，那這些領先的優勢將會慢慢消失。

學歷在前兩份工作有參考的作用，但越往後走，越看重你在實務方面的表現，以及與團隊溝通協調的能力。

如果一個人都 40、50 歲了，還只能拿自己的學歷來炫耀，那代表他出社會後混得很差。

😈 錯誤 1：沒有下載桌面版軟體、不熟悉操作

遠端面試常用的軟體有 Zoom、Google Meet、Teams，其中 Zoom 跟 Teams 儘管可以使用「網頁版」，但有時會遇到一些特殊的狀況（ex：螢幕分享一片黑），因此建議下載桌面版會比較穩定。

另外記得在面試前要先熟悉軟體的基礎操作（ex：螢幕分享、開啟攝像頭），並設定好相關權限（ex：允許螢幕分享、允許使用喇叭＆攝像頭），否則在面試過程你可能會需要多次重開軟體，給面試官留下「不專業」的印象。

😈 錯誤 2：直接穿家居服面試（ex：睡衣）

筆者真的遇過穿吊嘎的面試官與穿睡衣的求職者，我尊重每個人的穿衣風格，但印象分數照扣。

除非你真的強到逆天，對方也非你不可，否則印象分數還是相當重要的。

不要因為遠端面試就隨便穿，建議比照現場面試的服裝儀容；當你穿著正裝時，也會給自己一個這是重要會議的心理暗示。

😈 錯誤 3：忘記關閉會干擾面試的軟體、網頁

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

下面筆者列出常見的通訊軟體、網頁：

• 通訊軟體：LINE、Messenger、WeChat
• 社群網頁：Facebook、LinkedIn、Twitter
• 電子郵件（這個超容易忘記）

💪 小技巧 1：在開始時確認雙方的聲音、畫面都是清楚的

如果面試官的聲音模糊或太小聲，一定要即時反應不要怕；如果你聽不清楚題目，怎麼可能有辦法回答得好？

如果你有分享螢幕，一定要先確認對方有看到再繼續說；避免自己分享錯螢幕，或是對方沒看到的窘境。

💪 小技巧 2：盡量找有乾淨背景、合適光源的場地

如果在家進行遠端面試，請盡量找乾淨的背景，或使用軟體內建的虛擬背景（也可以上傳自己喜歡的背景）。

同時注意光源，背光會導致你的臉黑掉。

小提醒：在網路環境不佳的環境下使用糊化背景，你的人也會被糊化。

💪 小技巧 3：盡量找安靜的環境

如果周圍環境音太多會嚴重影響面試品質；如果在家面試，要提醒家人不要在面試時打擾自己。

同時建議不要在咖啡廳面試，因為大多數的咖啡廳都會播放背景音樂，附近的人如果講話太大聲也會影響收聽。

💪 小技巧 4：最好有雙螢幕

這樣你在分享螢幕時較不容易錯亂，同時也方便即時做筆記、看小抄。

如果只有一個螢幕，那在簡報時就只能自己把講稿背下來了；但如果有雙螢幕，你就可以透過備忘錄提醒自己該講什麼。

結語

面試過程發生的意外，對面試官來說是一種必然，因為他們只會聽一次而已。

建議每次面試前，都參考這篇文章檢核一次，不要讓這些可控管的風險，毀掉自己努力的成果！

過去很多人對獵頭的第一印象是「專業」，認為透過他們就能找到一份高薪的工作。

但筆者與多位獵頭溝通合作後，發現並不是每個獵頭都具備「專業」，有些獵頭更像是用碰運氣的方式大量私訊工程師；但這種亂槍打鳥的結果，就是在與工程師溝通時，連他擅長的領域都搞不清楚…

會發生這種亂象，筆者認為是有些獵頭並沒什麼工作經驗，甚至少部分獵頭的第一份工作就是獵頭（聽起來有點荒謬對吧？）

給獵頭的良心建議：

每個人都有自己的專業，如果你今天要幫工程師媒合，至少要對他們的專業有基礎認知；像是媒合網頁工程師，你至少要理解前端、後端的差異，並且對常見的框架有基礎認知（起碼名字跟對應的程式語言要知道）。

筆者遇過最扯的獵頭，是傳送錯誤的面試時間…直接讓那場面試報銷（當天還有請特休…）。

不知道讀者看到這裡會不會覺得有點荒誕？但現在獵頭的專業水平真的落差極大，筆者也是有遇過幾個優秀的獵頭，現在這份工作也是在獵頭的幫助下才找到的。

以筆者與周圍朋友的經驗來說，與獵頭培養好的關係是有必要的，但絕對要「謹慎」選擇合作的對象，我會用以下幾點評估：

1. 他了解你的背景與專業嗎？
   我不想吐槽，但真的有些獵頭連你的履歷都沒看過，就直接打電話聯繫…這簡直在敗壞獵頭名聲；如果不幸遇到這種的，筆者建議直接列入黑名單。
2. 他了解你現在從事的產業嗎？
   同樣是網頁工程師，在硬體廠、金融業、新創公司、政府單位…所擁有的專業技能其實有一定程度的差異，如果推薦不適合的工作機會，可能會讓求職者無法發揮所長（當然有些人是考量到職涯發展，特別選擇自己沒接觸過的產業）。
3. 獵頭過去的工作經驗，在這一行待多久了？
   誰都有是菜鳥的時候，但筆者相信絕大多數人都不太願意把攸關自己人生走向的任務交給經驗不豐富的人。
4. 過去主要推薦哪些產業的人才？
   人無全才，每個獵頭都有自己擅長的產業，你也可以先了解自己感興趣的產業對方是否熟悉，再思考後續的合作可行性。

專業的獵頭能快速找出符合你需求的公司，就算他擅長的產業與你的需求不符，也會介紹其他同事幫你找，這就是我說與獵頭建立合作關係的好處。

一般來說我們不會沒事到處搜集公司資訊，但獵頭每天的工作就是搜集這些資料，把槓桿用在對的地方就能獲得更大的效益。

個人經驗：

獵頭相較於人資，更能帶給求職者公司內部的實際情況；畢竟大部分的人資不會透露自己公司的問題，但獵頭因為手上公司多，相對來說可以更客觀的分享這些資訊。

良心建議：「不要等到要轉職的時候才開始面試。」

筆者知道準備面試很煩很累，在有工作的狀態下面試還要請假很違反人性；但我認為這麼做是值得的，在舒適圈待久了，我們容易忘記外面世界的空氣，相信每場面試都有你能學到的東西。

看見自己的盲點

習慣現在的工作模式後，我們通常會選擇自己最有把握的方式來解決問題。

久而久之，我們成長的只有年資，擁有的只有這間公司所需要的技能、以及公司裡面的人脈；如果沒有足夠的外力刺激，我們是看不到自己問題的。

而面試是一個非常棒的機會，因為對方不認識你，所以沒有預設立場；為了確保你是合適的人選，他們問的問題可不會那麼客氣。

在這一來一往的過程中，你更容易看見自己的盲點。

提升自己的表達能力

有些技術儘管我們每天使用，但並不代表我們了解它，有辦法用對方能夠理解的語言表達它。

下面列幾個常見的問題，螢幕面前的你，有辦法清楚明瞭的回答嗎？

• 可以說明一下最近專案的系統架構嗎？
• 在資料庫設計上，你會注重哪些細節？
• 過去工作上有遇過哪些挫折，你是如何面對與解決的？

也許你知道每個題目的解答，但如果要用嘴巴說出來卻很容易卡住。

因為表達能力是需要訓練的，否則你陳述的內容會斷斷續續缺乏邏輯體系。

保持危機感

了解自己在其他公司眼中的「市場價值」。

很多人認為自己值得更好的薪水，但在離職後才發現是自己「高估」了。

現在市場的輪動速度相當快，技術也是日新月異；也許你現在能領到高薪，是因為「過去」的市場真的需要這門技術，但這並不代表「現在」的市場依舊需要。

當然公司能給多少薪水也會跟「大環境」有關，如果在景氣不好的時候離職，即使有能力也未必能找到更好的工作。

增加自己的談判籌碼

有些公司在明知你有卓越貢獻的狀態下也不願意加薪，如果對這間公司還有留戀；我的建議絕對不是什麼加強向上管理能力，或繼續努力總有一天會被發現的廢話，因為這些做法是否有效完全取決於上級的良心。

與其長期投資一個不確定的未來，又將最終決定權交到對方手上，還不如自己主動獲得談判權；如果你成功在其他公司拿到不錯的 Offer，不僅可以做為跟公司談判的籌碼，也保留了談判破局的後路。

不過在談判時，筆者建議用比較委婉的方式跟上級溝通，比如：「我不是很在意錢，只是最近剛好遇到了 XXX 的機會，他開了 YYY 的薪水讓我了解到自己的市場價值；但比起那些，我更想要留在這間公司跟大家繼續打拼，想了解有沒有調整的空間。」

這是殺手鐧，一間公司用一次就是極限了，即使是暗示也沒有人喜歡被威脅；部分公司會因為這些話給你貼上「不忠」的標籤，絕對要經過謹慎分析與思慮後再使用這招。

結語

有些人認為「面試」是一種對公司不忠的表現，但我認為面試是一種「提醒」自己與市場差距的行為。

如果等到「受夠了」才醒悟，那很多時候一切都已經晚了…

而這篇文章將向您展示如何利用 ChatGPT 快速產出一系列讓您在面試中脫穎而出的有力武器。從自我介紹到推薦信，您將學會如何將自己的面試水平提升到新的高度。

警告：
ChatGPT 在面試過程只是擔任「輔助」的角色，讀者還是要自行把關產出的「品質」，並將這些資訊內化到大腦，這樣才能在面試現場表現出自己最好的一面。

大綱

▋ 用履歷產生不同長度的自我介紹
▋ 針對產業來產生自我介紹
▋ 將經歷用 STAR 的原則呈現
▋ Bonus：產生推薦信草稿，讓教授、長官、同事幫你一把
▋ 結語：如果沒花時間練習，那武器再好也沒用

用履歷產生不同長度的自我介紹

不同公司的面試形式不同，有些公司可以讓你用簡報自我介紹，你就算講個 10 分鐘都沒問題。

但有些公司只給你 3 分鐘，甚至是 1 分鐘的時間。

此時，事先準備好不同長度的自我介紹就非常重要了，你可以嘗試這麼做。

😀 我：「請依照下方提供的履歷，幫我用充滿自信的語氣、專業的詞彙，寫出一份讓現場面試官滿意的自我介紹，講重點就好。

• 在 Node.js 中擁有豐富的開發經驗，能夠開發出穩定且可靠的後端服務。例如，我曾經利用 Node.js 開發一個點餐系統，其處理速度比起傳統的點餐系統快了 30%。
• 能夠設計和實現 RESTful API，我曾經設計和開發了一個測驗系統的 RESTful API，並且能夠讓 1000 個同時的用戶快速地進行測驗。
• 熟悉 MySQL、PostgreSQL 等關聯式資料庫，我曾經優化一個 RMA 系統的資料庫設計，使其在大量的數據處理下能夠維持穩定性。
• 在點餐系統、測驗系統、RMA 系統等專案中擔任領導者的角色，我負責協調團隊成員，制定開發計劃，並能夠有效地解決問題。
• 具備將應用程序部署到 GCP 的經驗，我曾經部署一個測試系統到 GCP 上，能夠最大化地利用雲端資源進行開發。」

🤖 ChatGPT：「非常感謝您給我這次面試的機會，我很高興能夠在這裡介紹一下自己。我是一名後端工程師，對於 Node.js 開發有著豐富的經驗，能夠開發出穩定且可靠的後端服務。例如，我曾經利用 Node.js 開發一個點餐系統，其處理速度比起傳統的點餐系統快了 30%。這是因為我能夠充分發揮 Node.js 的優勢，進行優化和改進，提高了系統的效率和性能。

我也非常擅長設計和實現 RESTful API，我曾經設計和開發了一個測驗系統的 RESTful API，並且能夠讓 1000 個同時的用戶快速地進行測驗。我認為一個好的 API 設計應該是簡潔、清晰、易於理解和使用的，這樣才能滿足用戶的需求。我熟悉 MySQL、PostgreSQL 等關聯式資料庫，並且在一個 RMA 系統的開發中進行了資料庫設計的優化，以便在大量的數據處理下能夠維持穩定性。這些經驗都讓我能夠在開發過程中更好地運用數據庫技術，並且進行數據庫性能優化，以提高系統的效率和穩定性。

在點餐系統、測驗系統、RMA 系統等專案中，我都擔任領導者的角色，我負責協調團隊成員，制定開發計劃，並能夠有效地解決問題。我的領導風格是鼓勵和支持，鼓勵團隊成員發揮創造力和想象力，以創造更好的產品。在我的領導下，團隊可以高效地協同工作，以最短的時間開發出高品質的產品。

最後，我具備將應用程序部署到 GCP 的經驗，我曾經部署一個測試系統到 GCP 上，能夠最大化地利用雲端資源進行開發。我對 GCP 的熟悉程度可以讓我更好地理解 GCP 的特點和優勢，並且能夠快速地部署和管理應用程序。

總的來說，我相信我的技能和經驗可以讓我成為貴公司的一員。我對開發工作充滿熱情，並且總是保持著學習和進步的態度。我期待著和您們的團隊一起工作，共同創造出更好的產品。謝謝您的聆聽。」

上面 ChatGPT 產出的自我介紹大約「600 字」，而人一分鐘大約講 100~200 字，所以這是一份長度約「4 分鐘」的自我介紹；如果你想要讓他更精練、濃縮，可以這麼做。

😀 我：「只要突出我的實戰經驗、領導能力就好，幫我把它濃縮到 150 字。」

🤖 ChatGPT：「您好，非常感謝您給我這次面試的機會。我是一名擁有豐富實戰經驗的後端工程師，尤其擅長使用 Node.js 開發穩定且可靠的後端服務。在我曾經開發的點餐系統中，我成功優化了系統，使其處理速度比起傳統的點餐系統快了 30%。此外，我也負責設計和實現 RESTful API，並在測驗系統中成功地讓 1000 個用戶同時進行測試。

除此之外，我在點餐系統、測驗系統、RMA 系統等專案中擔任領導者的角色，負責協調團隊成員，制定開發計劃，並有效地解決問題。我的領導風格是鼓勵和支持，激勵團隊成員發揮創造力和想象力，以創造更好的產品。我相信我的技能和經驗可以為貴公司帶來價值，期待和貴公司的團隊一起工作，共同成長。謝謝！」

儘管我們的要求是 150 字，但 ChatGPT 最後給出的答案還是有 250 字；剩下的優化還是需要自己微調，以下是筆者優化的版本：

「您好，我是一名擁有豐富實戰經驗的後端工程師，尤其擅長使用 Node.js。在我曾經開發的點餐系統中，我成功優化了系統，使其處理速度比起傳統的點餐系統快了 30%。此外，我設計的測驗系統也成功地讓 1000 個用戶同時進行測試。

我在多個專案中擔任領導者的角色，負責協調團隊成員，制定開發計劃，並有效地解決問題。我相信我的技能和經驗可以為貴公司帶來價值，期待和貴公司的團隊一起工作，共同成長。謝謝！」

好的自我介紹除了可以應用在面試，還能在交流研討會中幫你拓展人脈，讓更多人對你留下深刻的印象。

針對產業來產生自我介紹

我們都知道如果能針對面試的產業、對象，去撰寫自我介紹能提高不少錄取率。

但過去這件事太耗時耗力，只能針對幾間公司特別做客製化；但有了 ChatGPT 後，這一切便不再是問題。

😀 我：「我要面試的是金融產業，對方是技術長。
請依照下方提供的履歷，產生專業性的自我介紹，語氣要充滿自信，在結尾用前面的案例證明自己適合這個產業。

• 在 Node.js 中擁有豐富的開發經驗，能夠開發出穩定且可靠的後端服務。例如，我曾經利用 Node.js 開發一個點餐系統，其處理速度比起傳統的點餐系統快了 30%。
• 能夠設計和實現 RESTful API，我曾經設計和開發了一個測驗系統的 RESTful API，並且能夠讓 1000 個同時的用戶快速地進行測驗。
• 熟悉 MySQL、PostgreSQL 等關聯式資料庫，我曾經優化一個 RMA 系統的資料庫設計，使其在大量的數據處理下能夠維持穩定性。
• 在點餐系統、測驗系統、RMA 系統等專案中擔任領導者的角色，我負責協調團隊成員，制定開發計劃，並能夠有效地解決問題。
• 具備將應用程序部署到 GCP 的經驗，我曾經部署一個測試系統到 GCP 上，能夠最大化地利用雲端資源進行開發。」

🤖 ChatGPT：「尊敬的技術長，您好！感謝您抽出寶貴的時間來面試我，我是一名擅長於 Node.js 後端開發的工程師。我擁有豐富的開發經驗，曾經開發過一個點餐系統，使用 Node.js 能夠快速地處理大量訂單，提高了點餐效率。同時，我也設計和實現過一個能夠讓 1000 個同時用戶快速進行測驗的 RESTful API，並優化過一個 RMA 系統的資料庫設計，確保其能夠在大量數據處理下保持穩定性。

在過去的工作中，我擔任過領導者的角色，負責協調團隊成員，制定開發計劃，並且有效地解決問題。我也具備將應用程序部署到 GCP 的經驗，曾經將測試系統部署到 GCP 上，並能夠最大化地利用雲端資源進行開發。

我對金融行業非常有興趣，我相信我的技能和經驗可以為這個產業做出貢獻。我曾經開發的點餐系統不僅能夠提高效率，也能夠確保交易的安全性；而我設計的測試系統 RESTful API，也能夠確保高可用性和安全性。我相信這些經驗和技能可以幫助我更好地應對金融領域的挑戰，進一步提升金融服務的質量。

再次感謝您抽出寶貴的時間來面試我，我期待有機會加入貴公司的團隊，並為貴公司的發展做出貢獻。」

小提醒：
筆者不是要大家把 ChatGPT 完整的回應給背下來，而是要去了解我們能從什麼角度做切入，讓面試官感受到我們的「誠意」。

將經歷用 STAR 的原則呈現

在自我介紹結束後，面試官會根據自己感興趣的部分做更深入的詢問。

如果你想在經歷被問到時能回答得更有說服力，那你一定要好好利用 STAR 的回答模板：

• Situation （情境）：描述你所面臨的挑戰。
• Task （任務）：在上述情境下你被賦予了什麼任務。
• Action （行動）：為了解決問題，你採取哪些行動。
• Result （結果）：根據你的行動，最終達成的結果。

看完上面的描述後覺得準備起來很麻煩嗎？沒關係！讓 ChatGPT 為您代勞。

😀 我：「我正在準備面試，想請你扮演擅長 STAR 原則的教練，將下面的經歷用 STAR 原則呈現。

專案：全球售後服務系統
職位：Tech Lead
任務：

1. 提供公司內部處理產品保固、維修，以及庫存查詢的平台
2. 客戶可以在平台上查詢產品保固資訊、維修進度
3. 此系統串接泰坦 T100 工廠端資料，以及蓋亞 BPM 簽核系統」

🤖 ChatGPT：「
Situation（情境）：
我擔任全球售後服務系統的 Tech Lead，我的任務是提供公司內部處理產品保固、維修和庫存查詢的平台，以及允許客戶在平台上查詢產品保固資訊和維修進度。此外，我們的系統還需要與泰坦 T100 工廠端資料和蓋亞 BPM 簽核系統進行串接。

Task（任務）：
我的主要任務是負責設計、開發和實施這個全球售後服務系統，並與其他部門進行溝通，以確保系統能夠正確地與泰坦 T100 工廠端資料和蓋亞 BPM 簽核系統進行串接。

Action（行動）：

1. 在設計階段，我們花了很多時間了解公司和客戶的需求，以確保我們的系統能夠滿足所有利益相關者的要求。
2. 為了實現系統的功能，我們選擇了一些先進的技術，例如 REST API 和 AWS Lambda，並使用敏捷開發方法來迭代開發，以確保系統能夠按時交付。
3. 我負責與其他部門和團隊進行緊密的合作，包括銷售和行銷團隊，以確保他們了解系統的功能和優勢。同時，我們還需要與泰坦 T100 工廠端資料和蓋亞 BPM 簽核系統的開發團隊進行合作，以確保系統可以正確地與這些系統進行交互。
4. 在實施階段，我們使用了自動化測試和持續集成的方法，以確保系統的穩定性和可靠性。我們還設置了監視系統，以及故障排除和恢復計劃，以確保系統在發生故障時能夠快速恢復。

Result（結果）：
由於我們的系統能夠提供全面的售後服務，使得公司內部和客戶可以更加方便地處理產品保固、維修和庫存查詢。客戶也可以透過系統輕鬆地查詢產品保固資訊和維修進度，這大大提高了客戶的滿意度和忠誠度。

此外，我們成功地將系統與泰坦 T100 工廠端資料和蓋亞 BPM 簽核系統進行串接，使得系統可以更加高效地處理售後服務相關的事務。系統也能夠快速地進行故障排除和恢復，保證了系統的穩定性和可靠性。

最終，我們的全球售後服務系統成功地提高了客戶滿意度和忠誠度，並大大提高了公司的售後服務效率和效益。」

不得不說，ChatGPT 似乎比我更了解這個專案 😅；這邊還是提醒一下讀者，如果 ChatGPT 所寫出的內容不符合事實，請自行更正！

Bonus：產生推薦信草稿，讓教授、長官、同事幫你一把

有些職位我們會需要以前的教授、長官、同事幫忙寫推薦信，不過這封推薦信「通常」是自己先「擬好」一份草稿給對方參考。

不過筆者很清楚絕大多數人都不擅長寫推薦信，如果要模仿對方的語氣來寫推薦信難度又上升一個台階。

不過現在我們輕鬆多了，只要把自己的履歷餵給 ChatGPT，然後請他用給「學生、下屬、同事」的口吻來寫推薦信就完工嚕！

😀 我：「我要面試的是後端工程師的職位，下面是我的個人履歷，請你使用指導教授的口吻來撰寫一封推薦信。

• 在 Node.js 中擁有豐富的開發經驗，能夠開發出穩定且可靠的後端服務。例如，我曾經利用 Node.js 開發一個點餐系統，其處理速度比起傳統的點餐系統快了 30%。
• 能夠設計和實現 RESTful API，我曾經設計和開發了一個測驗系統的 RESTful API，並且能夠讓 1000 個同時的用戶快速地進行測驗。
• 熟悉 MySQL、PostgreSQL 等關聯式資料庫，我曾經優化一個 RMA 系統的資料庫設計，使其在大量的數據處理下能夠維持穩定性。
• 在點餐系統、測驗系統、RMA 系統等專案中擔任領導者的角色，我負責協調團隊成員，制定開發計劃，並能夠有效地解決問題。
• 具備將應用程序部署到 GCP 的經驗，我曾經部署一個測試系統到 GCP 上，能夠最大化地利用雲端資源進行開發。」

🤖 ChatGPT：「尊敬的招聘委員會：

我很榮幸向您推薦我的學生，他將面試您公司的後端工程師職位。作為他的指導教授，我很自豪地說，他是一位優秀的後端工程師，擁有非常豐富的開發經驗和卓越的技術能力。

在 Node.js 開發方面，他有豐富的經驗，能夠開發出穩定且可靠的後端服務。例如，他曾經利用 Node.js 開發一個點餐系統，其處理速度比起傳統的點餐系統快了 30%。他也能夠設計和實現 RESTful API，過去曾開發了一個測驗系統，並且能夠讓 1000 個同時的用戶快速地進行測驗。

此外，他也非常熟悉 MySQL、PostgreSQL 等關聯式資料庫，曾經優化一個 RMA 系統的資料庫設計，使其在大量的數據處理下能夠維持穩定性。在點餐系統、測驗系統、RMA 系統等專案中擔任領導者的角色，他負責協調團隊成員，制定開發計劃，並能夠有效地解決問題。

他還具備將應用程序部署到 GCP 的經驗，曾經部署一個測試系統到 GCP 上，能夠最大化地利用雲端資源進行開發。

總的來說，他是一位非常優秀的後端工程師，有豐富的開發經驗和卓越的技術能力，擅長解決問題和協調團隊成員。我相信他能夠在您公司為後端開發團隊做出卓越的貢獻。

謝謝您的時間！

真誠地，

[您的名字]」

推薦信中如果有不合理的稱謂、描述，請自行調整。

結語：如果沒花時間練習，那武器再好也沒用

儘管 ChatGPT 能在短時間產出許多輔助面試的素材，但這並不代表求職者不需要付出努力。

如果在對這些素材一知半解，又或是不夠熟練的狀態下去面試；那當面試官細問經歷、技術等問題時，你肯定會出包。

師父領進門，修行在個人。

希望這篇文章能給準備面試的讀者帶來幫助，讓你藉著 AI 工具的輔助在職場更進一步！

小提醒：
筆者了解對許多人來說，英文面試才是最大的難關；所以提醒大家，文中 ChatGPT 所做出的回應，可以請 ChatGPT 扮演翻譯專家，將內容轉換成「英文」喔！

想將 AI 導入自己的職場與生活嗎？歡迎購買筆者出版的新書，幫助您在 AI 的浪潮中站穩腳步，並在未來的職場競爭中佔據優勢！

大綱
一、為什麼有些人這麼重視這份測驗?
二、我要偽造自己的性格來獲取 Offer 嗎？
三、反映性向測驗的現實案例：我就是生來顛覆
四、反映性向測驗的現實案例：每個人都有自己的優點
五、總結

一、為什麼有些人這麼重視這份測驗?

「我以為這個東西大家都是亂填的沒啥參考價值，但在部門物是人非後，發現它根本準到令人心寒。」 ── 一位歷經滄桑的主管悲嘆

通常受過傷的人才會特別重視這項測驗，有朋友就曾表示當組織誕生問題兒童時，他會先回去翻他入職時的性向測驗，此時往往會發現，這些「問題兒童」的誕生並非偶然。

性向測驗並非「玄學」而是「科學」，只要求職者用直覺去選擇答案，他就有相當大的參考價值。

跟用星座決定是否錄取的老闆相比，性向測驗實在科學太多了 XD

二、我要偽造自己的性格來獲取 Offer 嗎？

有部分心理系出身，或是對心理學有所研究的人，他們可以輕易地在性向測驗上偽造自己的性格。（筆者相信大部分的人都是善良且誠實的，這頂多算是潛意識的習慣？）

但除非他們連在面試現場的表現都能偽造的天衣無縫，不然肯定會被面試官、HR 覺得這個人怪怪的，而錄取「怪人」往往會給組織帶來許多未知的風險。

況且每間公司在不同職位上需要的人才不同，你怎麼能肯定自己偽造出來的性格就是該公司需要的？

如果每個求職者都表現出強大的積極性，那想要找穩紮穩打人才的公司就會很困擾。

性向測驗的結果沒有絕對的好壞，就是看你與面試公司的氣場是否合適。

雖然話是這樣講，但大部分公司還是傾向打保守牌，如果受測者的「情緒穩定度、服從性」分數超級低，用人主管還是會好好評估的。

三、反映性向測驗的現實案例：我就是生來顛覆

如果錄取一個不合適的人，影響到的可能是全公司的收益。

在一個適合借酒澆愁的夜晚，擔任部門主管的朋友跟我分享了一個血淋淋的案例。

當時公司有個職位空缺太久，在一直找不到適合人選的狀態下，部門主管挑選了一個勉強堪用的求職者。

原本也沒期待她能夠有多大的輸出，只求能夠完成本分的事情就夠了；但隨著時間推移，組織內部的氣氛越來越奇怪。

直到某一天，她突然無預警的被開除，大家才知道裡面發生了一個怎麼樣的故事，也了解為什麼用錯了一個人會導致整個部門完全失去向心力。

STEP 1：利用人喜歡聽八卦的本性

在公司與人建立聯繫最快的方式就是聊八卦，而八卦的內容儘管無法確認真假，卻能潛移默化的影響一個人看待他人的目光。

最開始她先用無傷大雅的八卦與同事建立聯繫，並且製造各種巧合讓這些八卦一一被印證，讓大家相信她的情報是有價值的。

STEP 2：告訴你無法與本人確認真假的八卦

而下一步，她向團隊成員散播不利於所有人的八卦消息，而這些八卦訊息你是很難跟本人求證的，舉例：

1. 在主管最近無理由的挺她、幫她說話的狀況下；跟你說主管對她有意思，還想要約她出去玩，並附上對話截圖。
2. 如果發現其他女同事跟大家相處愉快，就跟主管打小報告說這個同事作風不檢點，想用不正當手段在職場生存，害她被排擠。
3. 用誘導的提問方式讓你說其他人的壞話，並將其錄音、截圖給本人。

如果你是下屬，會不會懷疑主管跟她有不可告人的秘密？

如果你是主管，會不會用不一樣的角度來解讀這個女同事的所作所為？

如果你收到錄音、截圖，會不會與他人產生猜忌？

上面這些涉及個人隱私的內容，相信大多數人都不可能與本人求證。

STEP 3：用資訊不對等製造內部糾紛

在心態改變後，一句再普通不過的話語都可能被視為挑釁。

經歷了上面的步驟後，已經有許多成員被影響；而那些沒被影響的成員更慘，因為被重點抹黑。

團隊成員不信任彼此的狀態下，只要小小的摩擦，就足以產生燎原的野火。

故事尾聲

點火的人就如開頭所說，事跡敗露後被開除了，但她給部門製造的傷害除了績效上的損失外，間接導致的部門形象受損、人才流失的影響更為深遠。

後來朋友回去看這個人的性向測驗，發現她在「情緒穩定、服從性」的指標接近為 0。

四、反映性向測驗的現實案例：每個人都有自己的優點

上面的案例是鬼故事，接下來這個案例應該就是「天生我材必有用」？

朋友公司有個成員的做事速度較慢，因此他把這個情況向主管匯報，希望主管可以跟他溝通一下，不要拖到大家的進度。

不過主管在了解狀況後並沒有選擇跟做事較慢的組員溝通，而是拿出了性向測驗結果，跟朋友說道：「其實他做事比較慢這點我很早就發現了，也曾經想著有沒有要去跟他溝通；但在發現他性向測驗的敏捷性是 0，可是細緻性是接近滿分後，我思考良久，就沒有多說什麼了；畢竟組織中如果每個人都在往前衝，那也是很危險的一件事情。」

「一個方案的好壞，不要只看激動人心的部分，反而要注意風險的控制。 」— 理想之城

五、總結

在性向測驗時做自己，比較有機會進入與自己契合的工作環境。

技術、知識都可以透過後天教育和學習成長，但人的性格是長期養成出來的。

想要改變一個人的性格極為困難，就算當下勉強改了，也有很高的機率故態復萌（就像渣男劈腿一次的通常會劈腿第二次？）。

與其戴上面具，改變自己的性格去工作，還不如去找一份跟自己性格匹配的工作。

再次提醒，性向測驗的結果沒有絕對的好壞；勉強自己的後果可能會導致被放到不對的位置。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？(本篇)
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！

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

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

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

大綱

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

用工具完成任務 ≠ 了解工具。

隨著時代演進，大部分的公司都採用框架來加速開發效率；自從有了框架，工程師可以更輕鬆，並且在更短的時間完成專案。

儘管做事的效率提高了，但因為許多核心概念已經被框架取代，導致部分開發人員做得出來功能，卻無法解釋怎麼做出來的。

大綱

1. 了解文章結構，快速掌握面試技巧
   • 1.1 文章結構
   • 1.2 為什麼用這種角度分享面試經驗？
2. 請說明你現在專案用到的前端框架
   • 2.1 面試官為什麼會問？
   • 2.2 面試官想從答案確認什麼？
   • 2.3 筆者提供的簡答
   • 2.4 [小提醒]簡答的好處
3. 回答問題所需具備的知識
   • 3.1 Vue.js
   • 3.2 Vuex
   • 3.3 Vuetify
   • 3.4 Nuxt.js
4. 衍伸問題
   • 4.1 在 Vue 框架中，watch 跟 computed 的差異及使用時機
   • 4.2 在 Vue 框架中，computed 跟 method 的差異及使用時機
   • 4.3 有使用過 React 嗎？為什麼會選用 Vue 開發呢？

1. 了解文章結構，快速掌握面試技巧

1.1 文章結構

從今天開始，我會分享面試官常問的問題；文章會以下面的結構呈現：

• 面試官為什麼會問？
  主要分成 5 個方向與讀者分享出題邏輯
  • 履歷資訊
  • 職缺所需具備的技術
  • 常見面試題
  • 工作相關問題
  • 人格特質
• 面試官想從答案確認什麼？
  • 技術面
    用考題判斷你是否真的掌握這門技術。
  • 經歷面
    用追問細節的方式核實你經歷的真實性。
  • 人格特質
    面對各種問題的應對進退是否符合公司需求。
• 筆者提供的簡答
  筆者會附上自己在面對問題時的答覆，這塊僅供參考。
• 回答問題所需具備的知識（技術考題）
  筆者會統整問題涉及的知識面，讓讀者不會知其然而不知其所以然。
• 衍伸問題
  大部分的面試官會根據你的回答，詢問他們想知道的細節；所以我也會分享從這個問題出發的衍伸問題。

1.2 為什麼用這種角度分享面試經驗？

就算同為全端工程師，每個人的技能樹也都略有不同；這個系列文不是為了猜題而寫，而是希望讀者可以透過它了解面試官出題邏輯、自己答題方向；如果可以，你也可以參考筆者的文章架構，做出屬於自己的面試攻略，建議先把知識面整理完，再用自己的口吻整理答案。

網路的解答未必都是正確的，在整理的過程你甚至會發現部分邏輯互相衝突；如果未經思考直接照抄，你會連錯誤的知識一起吸收。

2. 請說明你現在專案用到的前端框架

2.1 面試官為什麼會問？

因為履歷資訊中表明面試者具備前端（Frontend）的技能：

• Nuxt.js：Vue.js & Vuetify & Vuex
• HTML5、CSS、JavaScript

其中Nuxt.js：Vue.js & Vuetify & Vuex都是框架，面試官想知道你對這些框架了解的深度。

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

• 想看你能否解釋這些前端框架的關聯性
• 如果要你單純解釋某個框架的功能，你是否能應對
• 如果能說出這些框架解決了哪些問題更好

2.3 筆者提供的簡答

目前使用 Nuxt.js 這個 Vue.js 的應用框架，並使用 Vuetify 提供的 UI Component 來設計版型；同時利用 Vuex 來管理 Vue 框架下的全域變數讓傳值更加直覺。

2.4 [小提醒]簡答的好處

你的簡答必須包含關鍵字，並盡量控制回答時間最多不超過 1 分鐘。

• 簡答的好處
  • 面試官會依照自己感興趣的技術深入詢問。
  • 因為回答的時間短，如果你的回答面試官不滿意，這也只是一個小橋段。
  • 雙方有來有往，營造出同事間的交流感。
• 詳答可能的壞處
  • 如果超級詳盡的解答每個問題，整場面試會變成只有你在說。
  • 萬一你回答的方向跟面試官期待不符，你就會在錯誤的道路越走越遠還不知道要停下來。

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

3.1 Vue.js

一個優秀的 JavaScript 框架

• 過去只有 JavaScript、HTML、CSS 時有什麼問題？
  • 難以維護
    專案結構龐大時，JavaScript、HTML、CSS 維護難度會成幾何式上升，各式各樣的邏輯都集中在 JavaScript 裡面導致程式可讀性極低。
  • 效能低落
    如果 JavaScript 頻繁操作 DOM 元素，會不斷觸發 Reflow & Repaint 的流程，頁面重複渲染的過程會消耗大量效能。
• 框架的優勢
  • 資料與 UI 分離
    過去 JavaScript 要動態的去更新 DOM 來塞入資料，但框架透過資料雙向綁定，工程師可以專注處理資料的邏輯面。
  • 模組化的 UI
    一個網站會有許多重複出現的元素（按鈕、表單、表格…），在框架中可以將這些常用的元素設計成 Component，要使用時再根據實際需求填入資料及參數即可，大幅提升工程師理解與維護的能力。
  • 更好的效能
    採取 Virtual DOM 概念，當資料變動時先計算好要變動的地方，以此抵銷無意義的變更，並且重複使用已存在的 DOM 元素。

3.2 Vuex

• Vue 過去傳值時面臨什麼問題？
  過去 Vue 裡面 Component 的參數傳遞都是採用 emit 跟 props ，但如果 Component 的關係並非 parent/child 而是像下圖想要將 Component B 的資訊傳到 Component C ，這種操作不但需要很多 emit 跟 props，還會造成程式碼閱讀困難。

  

• 如何解決這個問題？
  根據這個問題，官方推出專門用來「狀態管理」的工具，你可以把它想像成 Vue 裡面的全域變數，將狀態（state）全部放在倉庫（store）來進行管理。

  

  • 更新 state
    在 Vuex 裡面，儲存狀態的為 State，當 Component 需要更動 State 時，需要透過 Actions 發出一個 Commit 去呼叫 Mutations，再由 Mutations 去更改 State。
  • 取得 state
    而 Component 的資料更新，可以在 computed 裡面使用 mapGetters 的 function，或是用 mapState 直接取用 state 的資料。

3.3 Vuetify

• 提供前端工程師豐富的 MD Component
  你可以把 Vuetify 當成 Vue 的 Material Design Framework，他不但省去了你自己手工打造 UI Component 的時間，還為每個 Component 提供許多可以自由定義的 property 讓版型更加靈活。

• 強大的社群支持並穩定更新
  截至今天在 Github 上有高達 30K 的星星，如果你在開發上遇到問題，在他們 discord 社區上發問也能很快得到解答。

  

  官方每個禮拜都會穩定更新版本，相比於其他 Vue 的 Framework 是非常穩定的。

  

• 自由決定導入的 Component
  官方稱為 Auto treeshaking，在使用 Vuetify 時你可能覺得他非常「肥」，裡面包了一堆你專案中用不到的 Component，但因為有 Auto treeshaking 的機制，所以只會導入你有使用的 Component。

3.4 Nuxt.js

• Vue.js 的應用框架
  把 Webpack、Vue loader、Vuex、Router 的設定都集中在一起，減少使用者的配置成本。

• SSR 伺服器端渲染
  由 Server 端組成 HTML 後回傳，這樣的做法讓 Google 在 SEO 解析時可以很好的分析 DOM 元素，藉此提升網站的 SEO 水平。

  備註： Nuxt.js 也是能做 SPA（無 SSR），或產生靜態網頁。

4. 衍伸問題

大部分的面試官在聽完你的簡答後，會以此為基礎做深入的詢問；如果要你深入介紹每個框架的職責，你可以參考「3. 回答問題所需具備的知識」來回答；除此之外，下面筆者再分享幾個常見的衍伸問題。

4.1 在 Vue 框架中，watch 跟 computed 的差異及使用時機

考點：確認是否掌握框架基礎知識

watch 與 computed 都在觀察「值」的變動：

• computed
  有「快取」的特性，根據依賴值的變化去計算一個結果（多對一）。
• watch
  支援「非同步」，監聽一個值的變化去做一系列的事情（一對多）。

4.2 在 Vue 框架中，computed 跟 method 的差異及使用時機

考點：確認是否掌握框架基礎知識

• computed
  有些複雜邏輯的運算會花很多時間；但靠著「快取」的特性，只要依賴的「值」沒有改變，它就不需重新運算，以此節省效能。
• method
  只要被呼叫，它每次都會執行，就算這些執行結果是相同的；適用於「不需要快取」的計算。

4.3 有使用過 React 嗎？為什麼會選用 Vue 開發呢？

考點：你是否了解或是曾經用過同類型的技術，以及現在專案框架選擇的理由

因為前輩先將 Vue 導入公司的專案，所以我是先學習 Vue 來開發網頁前端；對有接觸過 JavaScript 的工程師來說，Vue 算是一個可以快速上手的框架。

我個人在業餘時間有使用 React Native 來撰寫 App，因此覺得如果熟悉 Vue，React 的學習曲線不會太過困難；兩者都是優秀的前端框架，主要還是看團隊成員對哪個比較熟悉。

讀者可以透過以上幾個前端框架的問題，初步了解面試官出題邏輯，以及答題方向。

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

參考資源：

1. 5 分鐘帶你搞懂 Vue、Vuex、Vuetify、Nuxt.js 之間的關係(筆者部落格)
2. Vuex 是什麼? 怎麼用?
3. 前端框架的功能與優點

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

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

打著「吃虧就是佔便宜」的口號，許多人別說去爭取不屬於自己的東西，連屬於自己的東西都沒有開口的勇氣。

我認為面試就是在打一場資訊戰，除了公司要了解你之外，你也要了解公司；很多人在面試的時候不敢提出自己內心真正的問題，深怕問錯一個問題就錯失了工作機會；如果你有這些擔心，可能來自於你對自己的專業沒有自信，又或是過去人生的負面經驗。

但老實說，找工作並不是一件可以隨便的事情，如果你能在沒問清楚的狀況下進入一間好公司，那是你洪福齊天；絕大多數沒搞清楚就進去的都是掉入火坑。

大綱

1. 在接到人資/獵頭邀約時要詢問哪些基礎資訊
   • 1.1 確認公司沒有觸碰到自己的地雷
   • 1.2 了解職缺基礎資訊
   • 1.3 了解面試流程
2. 準備詢問面試官的問題
   • 2.1 使用的技術與團隊工作方式
   • 2.2 職位期許與可能面對的困難
   • 2.3 讓對方有表現機會的問題
3. 面試官種類

1. 在接到人資/獵頭邀約時要詢問哪些基礎資訊

不要一有面試邀約就答應，先確認是否符合自己的期待，並初步確認自己的專業能否勝任該職位。

1.1 確認公司沒有觸碰到自己的地雷

每個人的地雷不一樣，自己零容忍的問題一定要先問，下面只是筆者個人的地雷範例。

• 是否為博弈產業？
  如果是博弈相關我會直接謝謝不聯絡。
• 如果加班，公司會依照勞基法給予補休或是加班費嗎？（或委婉的問：「如果臨時有工作必須加班，請問會有相關補貼嗎？」）
  我相信大部分的求職者都不敢問這個問題，但台灣真的有部分企業完全無視勞基法；如果你沒有在一開始把這些不合法的企業篩選掉，難道要等到入職後再來抱怨沒有加班費？老闆是慣老闆？

1.2 了解職缺基礎資訊

我在聽完人資/獵頭對這份工作的簡介後，會先詢問下面的問題，判斷是否要去面試。

• 實際上班地點

  請注意，你的面試地點不一定是上班地點；JD 裡面的公司地址也未必就是上班地點；這個問題能讓你了解上班的地點是確定還是浮動的；藉此估算通勤時間成本，如果每天通勤時間超過 2 小時，就算薪資不錯也會讓人猶豫。

  • 有些集團類型的公司，你甚至會去很多個地點面試；你最終會被分配到哪個部門，是他們最後開會討論出來的，並不是一開始就確定的。
  • 如果是「駐點工程師」的職缺，就只有面試地點在公司。

• 上班時間

  • 上班時間幾點到幾點，是否有彈性上下班時間
    每個人的生活作息都不太一樣，有些公司要求早上 8 點前就要準時抵達，有些則是中午 12 點；你要了解自己的生理時鐘，不然錄取後天天遲到會給人很差的印象。
  • 午休時間多長
    因為每間公司的午休時間不一樣，從 30 分鐘到 2.5 小時都有，這會影響你的下班時間，如果你希望在下班後有自己的時間也需要考量到這個因素。

「上班地點＋上班時間」是綜合考量條件；如果一間公司距離較遠，又要很早上班，你就要評估自己是否能長期承受這樣的生活。

• 座位是 OA 隔間還是開放式？
  每個人喜好不同，有些人在開放式的環境工作會有壓力、覺得自己沒有隱私；而有些人在隔間的狀態下會覺得溝通上受到阻礙。
• 是否需要出差（國內/國外）？會需要跨日的出差嗎？
  如果家裡有老人小孩需要照顧，是個不能出差的人，一定要問這個問題。
  • 不是只有業務需要出差，再做出產品後，有些公司的業務出差時會帶幾個開發這項產品的工程師，以處理客戶問到的專業問題。
  • 如果是外包類型的公司，也很常帶工程師出去 Demo 產品、跟客戶簡報、討論需求。
• 公司正式員工人數、部門人數
  除了要知道公司的規模外，你更要知道自己面試的部門有多少人；筆者的朋友曾面試過 2000 人的大公司，但入職後卻是這個部門的第 1 人，他需要從零開始自己 Build 一個 Team。
• 職缺預算與薪資結構
  • 職缺預算
    如果你面試的是比較資深的職位，我會建議你在面試前要先了解公司對該職缺的預算，如果你發現自己的期待薪資已經是這個職缺預算的頂，基本我拒絕這個面試機會；我會挑選期待薪資落在職缺預算中間的，以增加薪水談判的空間。
  • 薪資結構
    同樣的年薪，不同的薪資結構也會影響到大家的選擇；如果在年薪相同的狀態下，我個人比較推薦你選擇月薪最高的那個，這樣你一年無論在哪個月份離職都比較不會心痛。

1.3 了解面試流程

這個很重要，如果能提前取得資訊，你就能夠作出相應的準備。

• 面試有幾關，每關大概會面對哪些人、有哪些考試
  因為每間公司的面試關卡差異很大，有些考技術、有些則是看你人格特質；在不同心裡預期的狀態下，會影響到求職者發揮的水平（ex：原本以為這一關要了解你的人格特質，結果一上來就是白板題）。
• 如果順利，從面試到最後 Offer get 需要多少時間
  有些公司的面試流程非常冗長，用人單位跟核薪單位也不同；所以長達 3 個月也是有可能的，因此如果你急迫需要一份工作，最好問清楚這些細節。

2. 準備詢問面試官的問題

面試到一半時，面試官通常都會問你：「有什麼問題想問我們的嗎？」

這個不是客氣話，你有問題真的要發問，不要入職後再來懊惱為何自己當初沒問；而且很多面試官會從你的問題來判斷你是否對公司感興趣。

就算面試官沒有主動提出讓你詢問；你也可以在回答完面試官的問題後進行反問。

警告！筆者下面所列的問題，請挑自己最在意的提問，如果全問可能會讓面試官崩潰！

2.1 使用的技術與團隊工作方式

筆者在下面列舉的問題是向你未來主管詢問的，如果他答不出來；你可能要對這間公司的技術力打上一個問號。

• 工作使用的技術以及專案架構

  • 專案使用的前後端框架、資料庫？
  • 公司是否有使用 GCP、AWS 的雲端服務？

• 了解團隊分工的模式

  • 確認開發團隊大小以及職能分佈（人員配置：Frontend、Backend、Devops、UI/UX、MIS、DBA、SA、PM）
  • 工作是商量過才分配還是直接指派？
  • 會有 Partner 一起完成一個 Feature 還是單獨作業為主？
  • 每個人角色明確還是會有身兼多職的情形？

• 開發流程

  • 收到一個新需求後，專案經理會如何推動開發的進度？
  • 功能完成後，有專門的測試以及部署人員保證產品的品質嗎？
  • 有導入敏捷（Agile）開發嗎？

• 部門資訊

  • 因為公司有很多的產品，想了解貴團隊負責的是哪一塊？
  • 負責的產品有多少活躍用戶？過去平均多久會做一次新版本的 release？

• 工作所需設備

  • 錄取後是否會配筆電以及外接螢幕等工作所需設備？
  • 電腦是否符合開發所需規格？

  這個問題不是廢話，因為筆者的朋友在入職後配的電腦根本不堪使用（i3 / 4G / 500G），他還要自掏腰包買一台 Mac 在工作時使用（大概花了 7 萬）。

2.2 職位期許與可能面對的困難

你要讓面試官體會到，你真心希望加入這間公司，想了解這個職位期待什麼樣的人才、會遇到哪些困難。

• 公司對這個職位的期許
  • 希望擔任這個職位的人有什麼人格特質，在組織中扮演什麼角色？
  • 什麼樣的技術專才、相關經驗是會被肯定或是可以應用在工作上的？
• 未來工作中可能遇到的考驗
  • 什麼樣的人會在貴公司待下來，什麼樣的人不會？
  • 這個職位在未來要面對哪些挑戰？
• 職涯發展
  • 方便詢問貴公司過去在人才培養上有什麼補助或是獎勵嗎？
  • 如果有榮幸加入貴公司，我未來的職涯會有哪些發展方向呢？

2.3 讓對方有表現機會的問題

面試時除了求職者要展現自己的實力，也要讓面試官有炫耀自己工作的機會；如果連面試官自己都對現在的工作毫無熱情，你未來的職涯可想而知。

• 成就感
  • 在做專案的過程中，哪個環節帶來最大的成就感？
  • 這間公司的哪個特色讓您對這份工作感到驕傲？
• 未來展望
  • 公司目前在市場有一些競品，想了解未來發展的方向？

在問完面試官問題後，你可以用這句話做結尾：「謝謝您的回覆，我會問這些問題，是因為想確保自己未來在這間公司是會成功、留得下來、能有貢獻的人。」

我們最初有可能因為薪水選擇了一間公司，但只有在充滿願景的環境，才會全力打拼、持續成長。

3. 面試官的種類

面試官種類很多，雖然面試的感覺不代表一切；但如果你在面試的當下就感覺很不舒服，我認為要相信自己的直覺。

• 從你會的技術出發，確認你對技術認知的深淺
  通常第一關面試你的會是未來的直屬主管以及合作的資深工程師，這一關會著重在你是否具備個職缺的技術力。
• 從你的履歷出發，用聊天的方式互相認識
  在跟公司高層、人資面試的時候，他們更關注你的穩定性、發展潛力、人格特質。
• 連環提出問題，不給你任何思考時間
  有些面試官會連續拋出問題，中間不給你喘息時間；通常這樣做是為了知道求職者在職場上的應對進退，常發生在內部競爭激烈的公司，這類公司你不只要做產品，還要面對其他部門的壓力。
• 專門問刁鑽的問題、冷門的問題
  如果只是其中幾題這樣，那面試官是想看你面對答不出來的問題時會如何應對，是瞎掰一個答案、直接承認自己沒接觸過、還是跟面試官討論；如果接連好幾題都是刻意刁難，那可能是面試官想壓你薪水。
• 不斷攻擊你的履歷，用很差的態度面試
  現在有些公司流行壓力面試，也就是用很差的態度面對求職者，職場如戰場，他們會用這種方式面試也是有道理的；因為有些公司的政治氣味濃厚，如果抗壓力不足、隨機應變能力不夠，真的不適合這樣的環境。

俗話說：「不是一家人，不進一家門」雖然不是絕對，但透過面試官的風格你可以大概了解這間公司的風氣，也對未來的職場環境有一個心理預期。

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

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

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

等到「受夠了」才開始進步，一切都已經晚了…

前言：小明的故事

剛踏入職場時，小明對工作懷抱著憧憬，接手的專案總是格外珍惜且戰戰兢兢，生怕自己哪個地方做不好連試用期都過不了；因此入職的第一年像海綿般瘋狂吸收新的知識，並在錯誤中學習成長。

幾年後，小明成為公司的老鳥；當年需要熬夜才能完成的專案，現在只需要半天就能完成了；剩下的上班時間，他選擇泡杯咖啡犒勞辛苦的自己，一邊跟同事打屁聊天消磨空閒的時光，當然他也養成了躲在廁所滑手機當薪水小偷的習慣。

又過了幾年，小明兩眼無神地看著眼前的電腦，他覺得自己受夠了現在的生活，也不滿意公司給的薪水；於是他打開人力銀行，信心滿滿地認為：「憑藉自己多年的經驗，肯定一堆公司來搶自己！」

一個月過後、兩個月過後…

小明取得了非常多公司的面試機會，但卻始終沒有獲得理想的 Offer；此時的他才驚覺，除了第一年外，剩下這些年自己都在原地踏步。

為什麼寫這個主題？

我相信上面「小明的故事」，大家都不是第一次看到了；但卻很難保證自己不成為故事中的小明，畢竟離開舒適圈是一件很痛苦的事情；所以很多人就算「知道」自己不能再這樣下去，但看到舒適圈外的荊棘之路還是馬上打消了這個念頭。

所以我這個主題並不是想要讓讀者立刻做出重大改變，而是在熟悉的環境中多做一點事來認識、調整自己。

• 了解自己現在工作所使用的技術
  • 很多工程師擅長解決問題；但卻無法說明為什麼選用這門技術，以及為何這樣做能解決問題。
  • 有時我們根本不知為何選用某個技術，只是因為公司裡的前輩選擇了，所以就跟著用了。
• 定期整理自己的履歷
  • 整理履歷是一個很好的習慣，可以審視自己這些日子到底做了些什麼。
  • 很多實力很強的人反而不懂如何表現自己，也不理解自己的價值，導致他在市場被低估。
  • 有些資料都是有時效性的，如果沒有定期整理你可能就會忘記或是找不到。
• 每年定期面試
  • 在面試時，很多人會發現自己其實不太了解每天在使用的工具。
  • 了解自己在不同產業的價碼，以及自己最在意的點（距離、氛圍、產業、薪水）。
  • 透過面試知道自己的盲點。
• 做高價值的任務
  • 選擇影響力大的任務，你做的事被大家看到才算是有在做事。
  • 嘗試主動承擔報告與 Demo 的任務，讓公司更多人對你有印象。

適合哪些人看？

1. 工作遇到瓶頸，想要跳槽的人
2. 覺得自己很有實力，但因為不知道如何表現自己，而沒有得到合適 Offer 的人
3. 想了解面試官是以什麼邏輯出題的人
4. 不知怎麼提問題衡量求職者的新手面試官
5. 想找到自己盲點，在職場不斷進步的人

這個系列文我能學到什麼？

快速檢視自己在職場上所缺少的東西，並教你如何用「技術」及「經歷」來包裝履歷，讓自己在市場上取得應有的價值。

文章大綱

• PART 1 履歷（Day2~Day4）
  • 重新認識履歷對職涯的重要性，以此整理有效履歷
  • 將履歷精華提煉成面試用的簡報，用簡報引導面試官提問的方向
• PART 2 面試（Day5~Day25）
  • 了解通過面試可以獲得的好處，並檢核自己是否做好面試的準備
  • 面試是雙向的，你可以透過詢問公司問題；並透過種種細節判斷適合自己的公司
  • 從履歷分析面試官可能詢問的問題
    • 讓求職者了解為什麼面試官會問這個問題、他想要了解什麼
    • 每個問題會附上簡答範例，同時提供回答問題前所需具備的知識
    • 問題面向包含前端、後端、資料庫、設計模式、系統設計、白板題、職場相關
• PART 3 職場（Day26~Day30）
  • 有哪些方法可以擴增自己在公司的影響力
    • 讓新人成為有效戰力
    • 讓部門在 Demo 專案成果時一切順利
    • 爭取 Presentation 機會表現自己
  • 職場上與同事合作的注意事項
    • 問別人問題時要注意的禮節
    • 你是全端工程師，不是全包工程師
    • 建立友善的溝通環境
  • 與公司薪水談判的秘訣
    • 了解談判前要做哪些準備、如何選擇合適的談判時間
    • 注意談判過程要表達的重點與忌諱
    • 被拒絕時的應對進退

文章的篇幅有限，答案僅是提供讀者一個思路；請依自身情境去思考問題，沒有經過思索就接受的答案是經不起考驗的，你要依據自己的經歷寫出合適的腳本。

筆者碎碎念

儘管這個系列文花了很大的篇幅在「PART 2 面試」上，但我不希望讀者只把答案背下來，而是去思考面試官為什麼會這樣問。

說來諷刺，這些面試題並不應該是特別為了面試而準備的，而是你在掌握這個技能時，本就應該理解的；只是許多工程師誤以為完成任務就等於掌握技術，沒發生意外就不去深入研究。

筆者會寫出這些話，就是因為自己曾經是一個注重開發速度而不深入理解技術的人；當時甚至沾沾自喜覺得自己好棒棒，完成了別人好幾倍的任務；但經歷了幾次專案的更迭後明白，欠下的技術債遲早要還的，時間早晚罷了。

在這個系列文，我會盡其所能把自己知道的都分享出來，讓有緣分看到的人少走一些坑，如果讀者有自己的想法歡迎留言，你的留言或許可以幫助到其他人，希望每個工程師都能夠取得自己應有的價值！

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

參考資源

1. 「沒有人該為你的成長負責」 寫一封信給工作疲憊的你
2. 工作想有「突破性成長」的關鍵：懂得切換執行與學習

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

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