原標：Blog 5 — 軟體業PM常見面試問題整理與解題分享 (上)
(圖/文由朱騏提供)
我曾在《2020 軟體業PM面試問題，3個月的面試經驗分享》分享了自己在2020年找工作時，各家公司面試官當時所問的問題。後來發現其實每一間公司的問題其實都大同小異，且在每次面試後我都感覺經歷了一次「產品迭代」，在後續介紹經驗或是回答技巧上可以有更好的說法。
此主題由於內容太多，預計寫3篇文章來分享面試常見的15道問題，同時附上面試完畢後可以詢問面試官什麼問題，幫助自己對這家公司、合作同事、入職後要做的工作…等，能夠更清楚的了解。
此篇文章先分享5道問題，請留意下方的某些問題是比較PM職能導向的問題，若不是申請相關職位的朋友可以當參考就好。
每場面試的標準起手式，如果面試官不知道要問什麼通常也會用這個問題當開頭，所以準備上也是相對容易。
▶︎ 解題思維
網路上許多文章會建議要準備「1分鐘」與「3分鐘」的版本，我認為這個思路是好的，但在回答內容上可以安排有「彈性」的回答方式。
▶︎ 回答邏輯
會這樣做的原因是，我發現如果面試官已經將眼神對到你的時候還在介紹，其實場面會變得有點 “尷尬”，面試其實跟雙方聊天很像，任何一方講太多話而另一方缺乏互動時，會變得像是唱獨角戲，缺乏彼此互動的氛圍。
參考說法 (以下是我近期面試介紹自己的內容)：
你好，我是朱騏，共有4年多的軟體產品開發與管理相關的經驗，分別是2年在旅遊新創、2年在金融科技產業。
我的能力專長、工作經驗歸類為四點：
1.產品企劃與開發：主要工作是將使用者需求轉換為適合公司的產品功能，包含初期的使用者訪談、競爭產品研究，將需求撰寫PRD、使用工具來規劃產品原型，例如Axure, Adobe XD, Balsamiq;中期帶領開發團隊開發; 後期產品功能上線後的營運流程與觀察指標
2.溝通協調：對內我擔任商業端(BD、OP)與技術端(RD)的溝通橋樑 ; 對外則是擔任API技術窗口。
3.問題分析：我認為可以分成3個步驟，觀察、假設與驗證驗證、行動。我會使用可觀測數據的工具，可以分為商業端與工程端。商業端包含Tableau或是直接用SQL從資料庫中撈取數據觀察 ; 工程端則是使用如ELK KIbana，也就是API Log追蹤工具。驗證則是要建立一個假設原因，並且用數據去驗證是否如自己所想的一樣 ; 最後採取行動可能是擬定產品功能來解決問題、或是透過營運手段來進行處理。
4.專案管理：我使用過Trello、Gitlab來管理team的開發流程，team是採取Kanban跟Scrum的開發方式
我會投遞貴公司的PM職缺原因主要是：
(投遞原因)
許多產品職缺都會要求應試PM能了解完整產品的開發流程，新創公司的面試官更是對應徵者過去如何帶領產品團隊開發、跑完整個開發週期(不論是Kanban, Scrum, 甚至是隕石流開發…)的細節有興趣。
下面分享過去我在和團隊成員合作時，整個產品功能從發想->上線的流程，由於各家公司與團隊都有不一樣的工作流程，大家可當作參考即可。
I、第一階段
✅ 第一步、收集需求
需求可以簡單分成兩類：被動需求 與 積極探索需求。
被動需求指的是其他團隊成員，如CEO, BD, Marketing, Operation, CS…等成員，以日常工作為契機所發現的問題、新市場機會…等 ; 積極探索需求則是PM藉由研究方法，例如競爭產品研究、產業研究…等挖掘得到的洞察，再將其轉換成適合公司的產品功能。
▶︎ 解題思維
針對「積極探索需求」，可以補充過去做過的研究來埋下伏筆，有些面試官會針對伏筆做進一步提問，接下來就可以將以做過的研究、研究過程分享給面試官。
✅ 第二步、需求訪談與定義
此階段主要是在明確需求的詳細內容，並將需求轉化成公司產品功能，最後定義此功能的示意畫面與執行邏輯。
▶︎ 解題思維
此階段我認為是應徵者很好展現邏輯的地方，因為產品功能從「Idea(想法)」落地到「Spec(規格)」，需要許多實際文件的產出。
此時產出的 Spec 可能包含：使用者訪談研究結果 與 Definition of Done(簡稱DOD) [1]。DOD 包含
老實說 Spec 的寫法每家公司、每位PM都不相同，上方所列的是我自己過往工作時會產出的文件，有可能某些公司會需要更多更細緻的文件、有些公司則需要其中1–2兩樣就開工，這些都是依公司可有所調整。
✅第三步：產品團隊的內部討論
此階段PM會和產品團隊的成員 (QA, Developer, Designer)，共同瀏覽需求的整份 Spec，此時請準備好被問題不斷轟炸的準備。
這階段PM需要不斷調整 Spec，並和產品團隊成員溝通與解答疑惑。
▶︎ 解題思維
此階段主要展現自己的領導力，讓面試官看到自己是有能力可以領導整個團隊討論並推動開發進度。
✅第四步：技術團隊、QA團隊內部討論
此階段主要由工程師、QA人員針對 Spec 討論在實際執行工作時，需要派多少人手、要注意哪些技術/測試問題、有沒有PM規劃時沒考慮到的點…等。
✅第五步：Kick off meeting
此階段是團隊內的所有成員都對 Spec 達成一致共識，正式開始開發此功能的里程碑會議。
▶︎ 解題思維
可以在這裡向面試官強調，之所以會有流程，是希望能將後續開發過程中「因規格不清楚而成員來回討論」的時間與機率降到最低，也就是將風險放到開發前先提前討論。
II、第二階段：開發/測試流程
進入此階段後對PM的工作上相對單純。主要工作有：
(1) 主持每日站立會議 (Standup Meeting)
(2) 協助排除團隊問題
每日站立會議 (Standup Meeting)的目的是讓團隊成員快速分享資訊，會請成員分享三項資訊：
若成員碰到困難，PM要第一時間幫助協調問題，不論是功能需要更詳細的確認、開發人力不夠、技術問題卡關…等，找到對的人(Key Man)來幫助成員，是PM最大的價值所在。
當工程師將程式碼部署到測試環境後，QA就會開始對功能進行測試，測試種類其實非常多種，詳細內容可以參考《一次搞懂單元測試、整合測試、端對端測試之間的差異》。
III、第三階段：上線與營運
當QA測試完畢後，產品開發也即將進入尾聲，此時除了PM自己也必須走一次功能流程之外，還必須寫 “Release Note (功能發佈紀錄)” 給公司內部其他人員，通知大家即將上線什麼功能、對哪些團隊會產生什麼影響。
有些大型專案由於功能複雜，PM也可以製作教學手冊/簡報給內部人員，讓大家知道新功能、新產品應該怎麼操作，並以此教學手冊/簡報為基礎來教導客戶，客戶若有反饋也可以回來優惠手冊內容。
這張圖片濃縮上方提到的流程內容：
新多台灣新創公司的職缺其實無法很好的拆分 Product Manager 與 Project Manager 的工作，導致一家公司的PM其實是兩個職位的工作通包。
我個人覺得 Product Manager 如果多懂一些時程管理相關的知識，可以很好幫助自己去拆分功能開發的大小，並將工作拆分成一個個的 Action，最後按照 Action 將該做的任務逐步完成。
以我來說，我在回答此問題會以「OKR」當作回答切入點。雖然不一定每家公司都會導入這樣的管理制度，但「OKR」的精神非常適合專案的任務優先序管理。
我的回答是：
在安排專案上我會以「OKR」當作核心精神安排專案。我會先了解公司在這一季、這一年想要達成的Objective，並將產品團隊想開發的功能分類到不同的目標下，這些產品功能成為Key Result。
接著去了解每一個功能(Key Result)實際會帶來的商業影響有什麼，例如會直接增加營收、提高轉換率...等，以跟目標最直接相關、且能產生最大商業影響的功能，為開發優先考量。
此問題通常會被面試官以「你最近有專注在找什麼樣的產業、你找工作有什麼條件」等這些問題一起被問。
▶︎ 解題思維
這個問題反而是面試每一家公司需要最最最被認真思考的問題，可以分成「真實動機」與「回答技巧」兩類。
(1)真實動機
有可能自己在投遞時根本沒想這麼多，也可能自己是用刪去法，結果這家公司沒有被踢除掉。
不論是哪個原因，在真的要去公司面試之前，要好好的瀏覽公司的官網、看看104的職缺介紹，甚至思考看看產品與公司的未來性，找到1–3個能 “強烈support” 投遞原因的理由。
(2)回答技巧
我相信每個面試者一定都同時在看許多機會，不是每家公司的應徵動機強度都相同。
但去每家公司面試的時候，最好都能夠把這家公司當作是自己 “強烈想要加入” 的公司，如此才能讓公司面試官感受到面試的誠意。回答上盡量都要以「自己對這家公司、這個產業有非常高度興趣」才選擇投遞。
有些人會說這樣不是就「不老實」嗎？
我的想法是：如果你不去思考投遞理由，隨便掰一個原因來回答，那的確是不老實。因此在「真實動機」上才需要自己準備 1–3個 “強烈support”投遞的理由，這些理由是真的有觸動、吸引到我們內心，我認為這樣就不算「不老實」了。
舉例來說，如果我對某間公司的商業模式興趣度是中等，那我可以回答在產業、公司產品、公司文化上自己有強烈的興趣。想清楚自己的投遞理由是一種尊重的態度，除了尊重對方面試自己的時間，也讓自己準備這場面試的時間有意義與價值。
如果只是去練功的話，我建議也是要準備啦…要不然面試時回答不出來，其實也只是讓氣氛更尷尬而已…
這是一個很弔詭的問題，如果面試是要盡量表現自己，那回答關於自己弱點的答案不是在降低自己的錄取率嗎！
查詢了網路上 Head Hunter, 其他面試者的回答後，建議方式如下。
▶︎ 解題思維
回答一個缺點的同時，要對此缺點提出改進方案，以及自己改進後的樣子。
人無完人，說自己沒什麼缺點其實是很不實際的。因此我們反而要從 「想強調自己什麼樣的特質」出發，去反向思考這個特質的缺點是什麼。
舉例來說，我希望強調的特質是「我對專案的 Deadline 非常在意」，因此我可以這樣回答缺點：
我的缺點當專案期限快要到期時會顯得不耐煩，我對deadline這件事情很在意，當專案無法如期完成時我會覺得很煩躁。
為了避免這件事情發生，我變得更加主動關心團隊工作狀況，並且專心在幫助他人可以更有效率的完成工作。
將缺點轉換成強調自己人格特質的跳板，記得別傻傻的只回答一個缺點就停止不說了。
[¹]:Definition of Done是定義一個功能應該做到什麼樣的程度，才能被認定為完成的文件。 更多資訊可參考：
DONE Understanding Of The Definition Of "Done”
(圖/文由朱騏提供)
職務百科
薪資範圍
成功履歷
轉職推薦
