一開始加入面試會議時，心裡不知道要問些什麼，但與同事們不斷討論過後，才慢慢摸索出要如何開口提問。與其用文字落落長地說明，不如舉一個常見在面試的時候會提問的：你遇過最難的解決的問題是什麼？在這段經驗裡學到什麼經驗？又怎麼去解決這個問題。

以 Android 工程師應徵者舉例回答，曾經在 Android 看到一些閃退回報 OOM 問題，然後我們查看了頁面上讀圖的做法有效能上問題，所以我們做了修正後就沒有再發生。

身為面試官聽到這樣的回應，是不是聽了意猶未盡？那就可以接下來深入詢問細節，效能問題是使用套件處理嗎？還是前端做了什麼啊？怎麼確定問題之後沒有再發生？

為什麼要拋這些問題？面試過程中主角是應徵者，所以盡可能給他們發揮的舞台，這樣才能從他過去的經驗當中去挖出這個人適不適合。

在拋出這些問題後，應徵者再繼續補充：我們在 Firebase 上看到 Crash Free Rate 降到 95% 的告警，然後這些手機大都發生在記憶體比較小的裝置上面，所以在畫面上顯示的優先權是讓最大張圖片先顯示，不重要的圖片就重新縮小尺寸顯示。之後與後端討論其他可以改善的空間，以防萬一將畫面上一些縮圖的 URL 改讀後端處理的小圖，而不由前端再讀原始大小圖片。在 App 修正後，發現 Crash Free Rate 就逐漸回升至穩定的 98% 左右。

從這樣的回答可以得到什麼訊息：

1. 有使用 Firebase Crashlistics 觀察閃退回報
2. 檢視目前畫面可能造成的問題外，還與後端進行合作降低未來再發生 OOM 的機率

是不是比最先一開始獲得的資訊多少更多呢？這也提醒在詢問問題的時候，應徵者做了很多的事情，只是如果不經挖掘是看不到寶藏在哪裡的。而到這邊也是提醒，如果你的應徵者的話，盡可能地要展現自己過去做的事情，就像後來這位應徵者的補充內容，畢竟也不是遇到的每一個面試官，都很會做提問讓你有表現的機會。

如果以往公司有規定或者是必問的題目的話，就依公司規定吧。畢竟考慮公司過去的背景，必定這些題目有他們的歷史存在。當然考題內容取決於工程師們在意加入的夥伴要解決什麼問題，注重演算法那就把經典題目列出來；想問情境題，那就開一個白板題；想要了解問題的思考邏輯，就請他列出可以解決的方向有哪些。

每間公司已經有既存的一個範本，一開始就是照抄問，之後可以慢慢做調整，或是與參與面試的同事做交流。如果只有你一人，那麼在面試的最後問問應徵者，你對這一場面試有什麼想法？通常應徵者會覺得這是一環很重要的人格特質測試，所以得到的回答有時候很真誠。