iT邦幫忙

2021 iThome 鐵人賽

DAY 15
0
自我挑戰組

不會講幹話的工程師大冒險系列 第 15

身為面試官,如何在面試時聊技術?

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

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

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

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

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

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

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

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

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

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


上一篇
好的履歷是面試的入門票
下一篇
身為面試官,在面試中如何在有限了時間解應徵者
系列文
不會講幹話的工程師大冒險36

尚未有邦友留言

立即登入留言