利用Case Interview,提升工程師面試軟實力

Judy Liou
14 min readSep 15, 2024

--

Preface

去年底因緣際會,決定再嘗試一次大學時的dream job — 管理顧問,於是重新開始練個案面試(case interview),共練習約50個個案。雖然最終留在科技業擔任軟體工程師,但在今年市場不景氣、HR提醒標準提高的情況下,還是通過所有面試,練習個案所提升的溝通能力是關鍵之一。因此,想分享如何將個案面試中的技巧運用到軟體工程師面試中。

這篇適用於對工程師面試流程有一定了解,並希望提升面試軟實力的人;不適合希望增強硬實力(如程式設計、系統設計知識),或還不熟悉工程師面試內容的人。

有一輪behavior甚至得到“She is the strongest candidate I’ve seen at this level. Very articulate.” 的肯定,非常驚喜,也要感謝平常工作提供足夠的scope讓我有故事說。

Overview

簡單介紹個案面試,開頭面試官會描述一個公司/政府/組織的問題,請你幫忙解決(有興趣網路上很多資源)。接著可以分為四個部分:

  1. Recap and Clarification: 確認需求、界定問題
  2. Structuring: 拆解問題、建立解決問題的藍圖
  3. Analysis and Brainstorming: 分析驗證、腦力激盪解方
  4. Synthesis: 彙整總結

這篇會分享怎麼把Clarification、Structuring、Synthesis三部分運用在工程師常見的三個面試關卡(Coding, System Design, Behavior),並在最後加上三個心法作為nuanced tips。

If you’re curious, 3 is a magic number in consulting! :D

1. Coding Round

1.1 Clarification

這次遇到的題目都不短,所以看完後可以簡單總結然後釐清問題,比方確認題幹需求、有沒有invalid input、output format and order、time/space complexity重要嗎(有些公司有好幾個follow-up questions,更在意速度)、edge cases、test cases怎麼寫、error handling有沒有特殊要求等。

“Before I dive into the solution, I would like to ask a couple of clarifying questions.”

1.2 Structuring

接下來就是create a framework from high to low level and take it as a map。

如果需要時間想怎麼拆分小步驟,可以說 “Would you mind giving me a few seconds to think about it?”。不同於管顧的1–2分鐘,這裡我不會停超過30秒。一是有回饋提到避免awkward silence;二是邊講邊想可以讓面試官知道我的思路,即時糾正方向;三是和管顧要求嚴謹、全面的架構不同(有興趣可以搜尋「MECE」),coding是相對直覺的step by step。

舉例,假設題目是找出每個產品類別最長連續出現交易的天數,我會說(同時打在螢幕上)

”We can break it down into three steps:

  1. Convert the input to a dictionary {<category>: [<date>, <date>, ...]}
  2. Sort the list + find the largest # of consecutive days with transactions
  3. Format the output”

接著針對每個步驟解釋重要細節,列出1.1, 1.2, …,視情況寫pseudocode。Implementation的時候,這裡的每個步驟可以是一個function(clean code的分數也就拿了一些),然後把pseudocode copy-paste過去改成可執行的程式碼,很快就寫完了。

過程中每解釋完一部分或看到面試官面有些困惑,就問 ”Does it make sense to you?” “Are you with me so far?”。最後進到implementation前, “Okay I think that’s it! Any questions or concerns before I dive into the implementation?”

1.3 Synthesis

總結簡單一句就可以了, “Alright, we’re able to find the longest consecutive days and pass different cases.”。重點我會放在下一步怎麼優化程式碼, 比方docstring, type annotation, modularization, comprehensive test cases等。

“In the real world, to turn this into production code, I would do (a)…, (b)…, and (c)…”

2. System Design Round

2.1 Clarification

一樣讀題後確認需求,functional和non-functional。functional就是use cases,non-functional包括scalability, availability, consistency, latency等等,參考系統設計的書。在問non-functional的時候,可以先有自己的假設,讓面試官覺得你有sense、有在思考,比如相比於直接問是read-heavy or write-heavy,我會說”Based on my experience, …. Can I assume this is a read-heavy system?”

2.2 Structuring

系統設計包含幾個重點主題,capacity estimation, high-level architecture, API design, database design,可以直接把這幾點打在螢幕上,這就是接下來30分鐘的地圖,確保自己不會在鑽進某個細項後,忘了其他部分。同樣的,根據題目和自己的經驗說,“I think we can start with X. What do you think?”,展現drive conversation的能力;如果面試官不同意也沒關係,就照對方要求繼續。

進入下個主題前,我會做簡單的synthesis(下一點討論),然後提議接下來討論什麼,而不是直接問,“What should we do next?”或等面試官提示。

API和DB design,跟平常寫design doc一樣:提供不同方案、討論優缺點、保持整齊清楚(structured)。

Option 1: Two normalized tables in SQL DB
- Pros:
1. xx
2. xx
- Cons:
1. xx
Option 2: One giant table in NoSQL DB
- Pros:
1. xx
- Cons:
1. xx

幾個面試下來,我感覺mid-level對drive conversation要求不高,自己也常常沒想到一些細節,所以討論後期大多是面試官提出問題我回答。重點在於積極的討論,把每個部分想成一個模組,deliver your thoughts piece by piece and drive the conversation if possible。

2.3 Synthesis

不要等到最後才做!每個主題討論結束後,都給一個小結語(我們討論哪些重點、決定用哪個方法),再進入下一個主題。這樣去除中間討論出現的錯誤、偏題,並確保我和面試官有達成共識。

等時間到了或面試官想討論的都結束了,”Okay we can end here”,這時我會再主動總結一次,一方面是讓面試官好做筆記(有時候討論中間方向會偏掉),二方面是沒時間討論的部分,可以展現出「我沒有忘記,只是時間不夠、抓大放小」。

”Alright, so today we’ve covered the high-level system design and dived into the database schema. Based on our discussion, I would choose Option 1 XYZ because reason 1 and reason 2. Regarding the cons of this approach, we can mitigate them by solution 1. If we had more time, I’d also like to cover A and B to ensure …“

3. Behavior Round

3.1 Clarification

Behavior的問題相對直覺,最難的大概是著名的Amazon Leadership Principles(又稱亞麻軍規),因為每個面試官會被分配到特定幾條,如果聽完題目覺的Principle A and B好像都可以,就要問清楚面試官想聽什麼,才不會偏題沒拿分。

另外,為了減少描述故事背景的時間,我這次盡量用同一個大專案回答不同問題,但連續用兩三次後會開玩笑地問:

“In case you think I’ve only worked on one project, would you like me to share an experience from another project?”

“Are you tired of this project? I can share an example from a different one if you’d like.”

3.2 Structuring

常見的STAR就是很好的架構,尤其用在單一情境的問題(e.g. tell me a time you fail)。這裡想分享面對需要10–20 分鐘回答的問題,怎麼保持架構(例如:介紹一個從頭到尾的專案、複雜的系統)。

還是同個概念 — 從high-level到low-level。我自己心中會有個圖,可能是樹狀圖,從大點到分支小點;介紹系統時,會像下面那樣的圖,先說明這個系統的目的、和upstream/downstream什麼關係、input/output是什麼,接著zoom in到這個系統,再討論其中的重要功能、微服務等等。

我希望做到的是,面試官腦海裡同步有跟我一樣的架構,就像地圖一樣,知道「我們」今天要講什麼、現在在哪了、接下來還有什麼(重點是「我們」,不是自己講自己懂!)。

由於這關沒有打字或畫圖的工具,所以我會提醒自己:

  1. 放慢講話速度、跟面試官同頻
  2. 利用手勢比出來
  3. Deliver piece by piece: 結束一點、停頓、明確的說「我們現在進入第二部分」、再進入下一點。

舉例:Can you walk me through an end-to-end project you’ve worked on?

(聊了關於design and coding的部分)

Interviewer: What else did you consider besides coding before deploying to production?
Me: Two things, testing and CI/CD → high-level components + numbering
Me: For testing, there are three types — unit tests, integration tests, manual QA tests (with numbering gesture)

(討論不同的testing) → piece by piece

Interviewer: Okay, now that everything is tested, what’s the next step for deployment?
Me: Yeah, this is a good segue to my second point, the CI/CD pipeline → bring the interviewer back to the structure/map

3.3 Synthesis

這裡想分享兩點,不完全是synthesis,但可以加在開始和結尾的one-line highlight和mic-drop sentence。One-line highlight是讓面試官期待接下來的故事,同時也是跟面試官確認這個故事是不是他想聽的方法;mic-drop sentence可以想成STAR方法的”R”,讓故事有一個的強而有力的結束,如果是偏長的回答而沒有用STAR的話,也別忘了加上它。

Nuanced Tips

面試除了回答的內容,也包括展現出來的風格。從面試官的角度,「你是什麼樣的人、我是否願意與這個人共事?」。下面幾點心得:

1. Build Rapport

在前面5分鐘small talk + self introduction的時候,把場子暖起來,可以聊天氣、聊城市、聊今天已經面了5小時終於要結束啦等等,然後認真的聽對方的自我介紹,給一些quick follow-up,展現熱情。以前覺得非組招的都只是過場,但其實這為接下來的一小時設定基調;通常聊得好的後面都比較友善幫忙,自己也比較放鬆,更容易在面試官提出疑問時,保持「他是在幫我」的開放心態。

作為一個內向又不太愛small talk的人,我都會想像「如果我是X(一個認識的外向人),他會怎麼做」,慢慢就比較習慣了。

2. Make It Conversational

關於conversational可以分為兩點,一是要engage面試官,就不多說了。

第二點是把問題拋回去。可能在面工程師之前,跟顧問業的人networking多了,後來面對科技業的人(比較隨性)放鬆很多,有幾次在還沒到提問環節,就開始問問題。比如,被問到系統經驗時,面試官說他們用非常類似的infra,我就反問「我知道你們X年前換這個infra,為什麼當時做這個決定」,或在系統設計關,問一個相關但不是直接題目的問題,「那你們這邊是用SKU還是productID呢」,面試官都很熱情的介紹,就又讓場子熱起來了,也展現了對公司的興趣。建議面試前多了解產業、看公司blog,問對問題很有幫助。

”I know it’s not time for me to ask questions yet, but if you don’t mind, could I ask a question now?”

3. Be Confident and Enjoy it

自信,超級重要!當鏡頭一開就要有那種我超厲害、”I’ll nail it”的心態。我都會在面試前聽讓自己亢奮的歌或是來個pep talk。

自信的另一個展現就是享受過程,即使中間卡關也能從容應對。我會觀察那些很活潑的case partner和同事,偷偷模仿他們。列出幾個好用的句子,習慣之後明顯感覺氣氛輕鬆很多(當然也要根據面試官的風格隨機應變,我的原則是跟面試官一樣或熱情一點點):

  • 發現自己講錯了 → “You know what? Actually, we should …”
  • 被糾正錯誤 → “Good point! Thanks for calling that out.“ / ”Oh yess you’re correct“
  • 被提醒應該要討論什麼 → “Sure, let’s talk about it!”
  • Test cases fail → ”Ah hah we have more fun here. Let’s take a look at this.”

Final Words

以上是擷取管顧case interview所學,移用到工程師面試上的心得,從Clarification、Structuring、Synthesis,到最後三點心法,希望大家能透過「有效溝通」,把自己的硬實力在面試中最大化展現出來。

給出”strongest candidate”的那輪面試,回想起來就像一個談話節目,覺得那個面試官超適合去當主持人,然後我也發揮的異常好,可以跟上他的快節奏和高能量一來一回。

如果喜歡的話,歡迎給予拍手鼓勵,也歡迎交流指教,不管是從面試者或面試官的角度。

祝大家面試順利,offer多多!

讀case prep material的聖誕節

--

--