技術面試時間約 50 minutes +- 10 mins
(20 mins Behavior Question, 30 mins Live Coding) 面試官自行調整
最長建議不要超過 90 分鐘
自動化測試經驗該如何驗證
Experienced in Test Automation
如同前言所說，QA身懷各種程式語言，盡量避免設定單一程式語言的題目。
我習慣依照要找的對象設定不同的問題，對象分為 Junior 與 Senior
Junior 定義在，剛出社會或者工作經驗約 1 ~ 3年 QA 經歷
Senior 定義在，工作經驗超過 3 年以上QA經歷
尋找一個合適的QA，除非整個公司體制有明確的分工，將QA的職務劃分成
- SDET : Software Developer in Test
- QA / QAE : Quality Assurance (Engineer / Evaluator)
SDET 經常熟知的比較偏向於開發測試工具的工作，有些公司明確指出他們需要的是 Developer 「 in Test」，意思是，我需要的是開發人員，但該開發人員負責的項目會專注於產品的測試工具開發，因此，一旦公司職務定位為此時，偏好的語言與工具，即可縮小至適合開發生態的領域。
但大多數的公司，則是希望測試工作並不是獨立只撰寫測試工具，還需要跟著產品執行功能性測試，並且有足夠的知識規劃測試策略與項目，因此，多數公司的職稱直接使用 QA 這個頭銜，要的是通才，而非專才。
其實也在招聘上，造成很大的困擾，我們的工作，到底「自動化測試工具比較重要？」還是「產品開發時的功能性測試比較重要？」相信老闆們會說，小孩才做選擇，我全都要…
因此，你可以想像，一家公司的開發工具與模式不同，當一個 QA 經歷過各種公司的文化後，要怎麼期待人選一直專注在同一種開發工具上呢？
所以，技術面試的重點該是什麼？
產品架構 與 系統架構
理解產品架構中使用的特定元件很好，但更好的是理解整個產品技術的架構
其實在製作SaaS這方面的服務，不外乎就是 Server Client , Coordinator Agent or Master Slave 相關的架構，再複雜一點大概就是 Queue 相關的分散式架構，如果團隊要找的 QA 是希望集中火力針對某個 Component 驗證問題，這類型的 QA 比較多屬於從 SDET 中挖掘，但大多數的 QA 多是從整個產品功能面向往回了解系統架構的。
許多 QA 可以說明負責的功能是什麼，針對功能寫寫測試案例，而少有QA理解整個系統架構，甚至用圖說，將整個系統架構還原。
所謂一圖勝千言萬語，透過圖說，是一種觀察人選組織能力與理解力的方式，在工作上QA非常重視溝通能力，圖像化的資訊更能開啟溝通的橋樑，我的習慣會在圖說中，試著理解人選是否明白，系統上的設計對產品與客戶，帶來什麼好處與可能的壞處？
另一個問題，找到你覺得最擔心的元件進行測試，你會選擇什麼測試手法？並分析優劣勢。
圖解系統架構，是一種探查人選的潛能與是否能宏觀的掌握產品資訊的驗證
The Coding
比起刷題演算法、資料結構，最重要的是解題過程與邏輯
如果你希望人選具備有基礎的程式語言能力，我會建議面試官尋找一些各種 Programing Language 的網站，列出該程式語言最基礎的特性考題，例如 Python 系列的 List 、Java 系列的 String Builder、iOS Swift系列的 Delegate / Protocol 。並將這些有固定答案的考題，放在 Phone Screen 階段測試，以確定，人選對於某些語言是否有基礎的認知，避免在技術面試中，雙手一攤，告訴面試官，我不會寫程式…
真的有這樣的狀態，而且還不少哦…
一旦有第一階段的程式基礎，在技術面試階段，如果職位的條件是程式語言必備，那麼我強烈建議 Live Coding，而不是設計回家作業給人選寫， 我關心的有幾個原因
- 面試是雙向的，公司應該尊重人選的時間，設計回家作業也是一種勞力
- 回家作業是死的，事後再來問過程，也都無法得知最真實的反應
- 寧可提前告知人選題目方向，也不要讓題目變死，因為Bug總是出其不意
通常建議提前讓人選做準備，告訴人選涉略的範疇大概是什麼領域，最好的狀況應該是提供一些網站資訊，讓人選多了解相關領域
當然，如果設計的題目是足夠在限定的時間引導人選解題，這是最佳的面試經驗。
為了符合「引導」這個特性，面試題目會有兩種關卡
- 從產出的結果找問題
- 從答案中設計測試工具並實作（Live Coding）
我會建議面試官們，應該思考自己工作崗位上遇到的問題來設計幾個單純的考試題目及可以被自動化工具驗證的範例作為考題，這樣的好處是
- 提早理解人選是否有能力應對日後的工作內容
- 提早「讓」人選理解，未來的工作性質會遇到什麼實際問題
- 理解，從不同人選的答案中，是否有不同的解題方式，作為技術交流
從產出的結果找問題
設定一些情境，告知人選一些情境下的結果，而且結果中有一些可能錯誤的地方，請人選嘗試分析哪些錯誤？
設定這個題目有幾個重點
- 錯誤的地方，盡可能的多樣化（從很淺到深）
- 題目的內容（Spec or Acceptance Criteria），不要太精確
- 題目可以相互有 Dependencies
錯誤的地方，盡可能的多樣化（從很淺到深）
原因是要觀察人選對於發生問題的敏銳度與細心程度，如果一道題目只有一種解，這個測驗過程，就會變成二分法，解的出來就是合格，解不出就是不合格這樣的評論應該要模糊化，我們的目的是要了解人選在過程中發現多少不尋常的事情，而不是用一道我們熟悉的情境，斷言人選的能力，這不公平
題目的內容（Spec or Acceptance Criteria），不要太精確
產品的 Spec or AC 永遠不會是無懈可擊的！這個目的是要驗證人選的好奇心，嘗試詢問在Spec 上，是不是有漏洞，或沒說明清楚的地方，面試官也建議不要一開始就給予過多的解釋，多讓人選提問，並嘗試引導人選進入對的方向，這個好奇心的考驗，是一種潛力與加分，有些條件因為人選問了以後，答案可能有不一樣的變化。
題目可以相互有 Dependencies
考驗人選是否能解決複雜問題的能力，有時候，當問題發生了，並不是單一狀態造成這個結果，而是由很多原因綜合表現而造成的，這個複雜問題的能力也能順道驗證人選對於 Toubleshooting 的考驗。
從答案中設計測試工具並實作（Live Coding）
剛提到人選一旦有能力找到一些問題，那麼理想上應該能夠根據這些問題設計驗證的機制，而這樣的考試題目非常符合應用性。
在大部分的開發時間，我們並不會要求QA一定要將程式寫到完美，而是要有辦法解決問題，並減少人力的浪費在同樣的問題上，而撰寫自動化測試工具，若我們的目標都一致，不如讓人選自己選擇他所發現的問題中，選擇一個答案，並對該答案設計自動化測試的 Validator 吧！
在 Live Coding 時，我們需要觀察以下幾個重點
- 先理解思路與可行性
- 一旦可行性完成，再進行實作
- 觀察程式撰寫的結構，包含 Naming、Structure、Format、Design Pattern
- 觀察 Debug 的習慣
- 觀察如何設定 Check Point 產生有效的測試報告
程式題目，面試官不一定要熟悉所有語言，但應該要能讀懂語言邏輯的能力
以上為技術面試中，我認為較為活用與關鍵的面試技巧，作為觀察人選對於技術上的潛力與應用能力，也很歡迎面試官或人選們提供我更多的經驗，我們可以互相交流，讓 QA 的環境與方向，有更明確的定義與面試基礎。
