身为面试官，如何在面试时聊技术？

一开始加入面试会议时，心里不知道要问些什麽，但与同事们不断讨论过後，才慢慢摸索出要如何开口提问。与其用文字落落长地说明，不如举一个常见在面试的时候会提问的：你遇过最难的解决的问题是什麽？在这段经验里学到什麽经验？又怎麽去解决这个问题。

以 Android 工程师应徵者举例回答，曾经在 Android 看到一些闪退回报 OOM 问题，然後我们查看了页面上读图的做法有效能上问题，所以我们做了修正後就没有再发生。

身为面试官听到这样的回应，是不是听了意犹未尽？那就可以接下来深入询问细节，效能问题是使用套件处理吗？还是前端做了什麽啊？怎麽确定问题之後没有再发生？

为什麽要抛这些问题？面试过程中主角是应徵者，所以尽可能给他们发挥的舞台，这样才能从他过去的经验当中去挖出这个人适不适合。

在抛出这些问题後，应徵者再继续补充：我们在 Firebase 上看到 Crash Free Rate 降到 95% 的告警，然後这些手机大都发生在记忆体比较小的装置上面，所以在画面上显示的优先权是让最大张图片先显示，不重要的图片就重新缩小尺寸显示。之後与後端讨论其他可以改善的空间，以防万一将画面上一些缩图的 URL 改读後端处理的小图，而不由前端再读原始大小图片。在 App 修正後，发现 Crash Free Rate 就逐渐回升至稳定的 98% 左右。

从这样的回答可以得到什麽讯息：

1. 有使用 Firebase Crashlistics 观察闪退回报
2. 检视目前画面可能造成的问题外，还与後端进行合作降低未来再发生 OOM 的机率

是不是比最先一开始获得的资讯多少更多呢？这也提醒在询问问题的时候，应徵者做了很多的事情，只是如果不经挖掘是看不到宝藏在哪里的。而到这边也是提醒，如果你的应徵者的话，尽可能地要展现自己过去做的事情，就像後来这位应徵者的补充内容，毕竟也不是遇到的每一个面试官，都很会做提问让你有表现的机会。

如果以往公司有规定或者是必问的题目的话，就依公司规定吧。毕竟考虑公司过去的背景，必定这些题目有他们的历史存在。当然考题内容取决於工程师们在意加入的夥伴要解决什麽问题，注重演算法那就把经典题目列出来；想问情境题，那就开一个白板题；想要了解问题的思考逻辑，就请他列出可以解决的方向有哪些。

每间公司已经有既存的一个范本，一开始就是照抄问，之後可以慢慢做调整，或是与参与面试的同事做交流。如果只有你一人，那麽在面试的最後问问应徵者，你对这一场面试有什麽想法？通常应徵者会觉得这是一环很重要的人格特质测试，所以得到的回答有时候很真诚。