這篇其實提到很多重點, 我想在這邊補充一些細節
個人背景: 美國某特愛考BQ大廠面試官, 面試數十人, 跨各種level&role
※ 引述《yschen25 (卡)》之銘言：
: 我自己在準備 behavior questions 的時候，
: 會把題目按照不同類型分類，
: 這樣你在回答的時候，知道某種情況的問題大致是可以回答哪一種答案。
: 再來列下各別問題的答案，但這裡要注意的是
: 面試官問的問題，其實是隱含他想知道的事情，比如說這題 :
: "Tell me about a time you failed. How did you deal with the situation?"
: 面試官其實是想知道 :
: * 你是否願意承擔責任，不是找藉口或是責怪別人，而是從錯誤中學習，
: 並且利用此經驗在下一次處理事情上。
所有的面試過程 (phone interview, on-site, BQ, coding) 其實都是為了回答一個
終極問題: 這個申請人到底能不能勝認這份工作?
所以回答的重點應該是 "以實際的例子去佐證你具有某些能力"
: 這邊回答的技巧是 :
: * 不要說自己從沒失敗過
: * 簡短的舉出實例說明
: * 但不能是頻繁發生的問題 (會顯示你很粗心，沒學到教訓)，或是很嚴重比如損失好幾萬
: 的訂單 (講了應該會不敢用你)
: * 不要找藉口，不要抱怨，不要把錯怪在別人身上
: * 顯示出你從這件事學到什麼，怎麼避免下次再發生
: 回答範例可以按照 Situation, Action, Result 去回答
: Situation (情況): I was managing a project for one of our biggest clients in
: my previous company, and I was so eager to please them that I told them we
: could finish the project within 2 weeks. I thought this was doable, but it
: ended up taking 3 weeks and they were not happy. Looking back, I realized I
: should have been more conservative in my estimate to the client. I realized
: that a client isn't going to be upset if you're clear about the timeline in
: advance, but they are going to be disappointed if you promise something and
: then don't deliver.
: Action (行動): So I took this experience and used it to become much better at
: managing the expectations of clients during projects I oversee
: Result (結果): on the next project with a different client, I told them it'd
: take 4 weeks and we finished in 3. They were very happy about this.
這個範例很有意思, 可以很清楚的說明面試官跟申請者在意的不同點在哪裡
你心中想的:
S: 團隊承諾2周deliver, 結果花了3周, 客戶很不高興
A: 你學到下次估計要估得更好
R: 下次專案超前完成
面試官的筆記:
S: 團隊承諾2周deliver, 途中遇上困難, 可能無法如期完成
A: candidate沒有採取任何行動 (no data)
R: 專案延遲, 客戶非常不高興
Debrief: 介於 no hire 跟 strong no hire 之間, 取決於其他 follow-up question
那麼這個回答有什麼問題呢?
首先, scope 太小, 但凡工作超過 2 年以上的人都不該給出這麼 "淺" 的範例
再來, 細節含糊不清, 你中間提到 "become much better at managing the
expectations", 但是卻完全沒有解釋 "how", 說服力很低
最後, 估計4周但3周做完未必是好事, 這種行為有個專業術語叫 "sandbagging",
意指故意估一個比預期長的時間, 面試中給這種回答風險很高
如果我是面試官, 我期待的理想回答會是這樣的:
S: 團隊承諾2周deliver, 途中遇上困難, 可能無法如期完成
A: 我採取以下行動
1. 首先嘗試排除障礙, 爭取如期完成
2. 發現#1不可能, 立刻對目前及剩餘的工作reprioritize
3. 跟stakeholder溝通, 重新定義 minimum viable product (MVP)
4. 跟leadership溝通, 設法爭取額外資源/人力
5. 發起 daily standup 加速團隊溝通, 可以第一時間排除困難
R: 雖然2周無法完成所有功能, 但是最核心的 MVP 有交出去, 團隊額外花一周
補齊所有功能, 事後我主動召開檢討會, 制定下次的預防措施及流程
這樣就是一個最標準的答案了, 但實際上在我經歷過的所有面試裡面, 大約只有不到
30% 的人可以完整回答
換句話說, 如果能說到這種程度, 基本上就贏過一半以上的人了
: 別人問問題的時候，也不一定要直接回答，可以先反問對方，
: 釐清說對方想問這個問題的用意，而且這樣也有更多互動，
: 顯示出你是會去思考問題的人，而不是只會回答。
: 比如說對方問 : Do you think you are a good developer?
: 你可以反問說 : How do you define the definition of good?
: The developer who can write the good code? Or they have good communication
: skills?
這個例子也蠻微妙的, 如果說面試官是我, 就會反問你 "What do you think?"
通常面試的問題都是有設計過的, 像這種很直接的反問很吃面試官的脾氣
(但如果你是真的不知道何謂 "good", 又恰好說明你經驗不足)
如果真的要反問, 可以這樣說: "Yes, I do consider myself as a good developer,
I can expand on this topic in two areas: coding competency and soft skills.
Which one do you prefer me to explain first?"
=====
如果有人需要的話, 我可以幫忙提供 1-1 的 mock interview
流程大概是: 花20-30分鐘按on-site標準問BQ, 10-20分鐘討論反饋, 回答問題
雖然是杯水車薪, 但還是希望可以多少幫助最近要面試的人
有需要的麻煩在這篇文章推文, 我會亂數選出3-5名, 預計7/25-8/5這兩周左右安排