這篇其實提到很多重點, 我想在這邊補充一些細節 個人背景: 美國某特愛考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這兩周左右安排 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 71.231.137.225 (美國) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Oversea_Job/M.1657774186.A.02B.html 就是要靠面試官的經驗, 感覺, 以及觀察申請人的各種反應 比如我如果覺得申請人下意識想跳過一些東西, 就會追問技術細節到滿意為止 或是去挑戰candidate回答的內容 ("我覺得XXX會更好, 當初為什麼不採用") 一般沒有實際經驗的人 很難完整又合理的去分析不同方案的優缺點 再來就是綜合 coding 或 system design 去看寫出來的程式有沒有match BQ水準 現在面試基本都是4-5輪, 要同時騙過所有人難度很高 當然萬事都沒有完美的, 如果真的不幸召錯人 (進來沒幾個月就發現能力不足) 就只能怪 hiring manager 看走眼, 要花很多精力送神... 謝謝各位回應~ 用輪盤選出了五位參與者: https://imgur.com/9M5Y2cH taiyaki35 york13468 k900421 Hammurabi jerrywei24 需要研究一下如何安排時間, 會再寄站內信聯絡 ※ 編輯: KeyFSN (71.231.137.225 美國), 07/15/2022 14:02:20