這個職位會不會是加班王? 還是通靈王? 未來主管身上是充滿寶藏 know-how 還是只有響鈴報時功能? 那些面試想問又不敢問出口的問題,這集訪談就邀請到有將近 7 年開發經驗的資深前端工程師彥成,來告訴你怎麼透過正式的問題去旁敲側擊你想知道的真實面!
林彥成,資深前端工程師,成大工科所畢業,有將近7年的前端開發經驗。彥成亦有經營個人網站-前端三分鐘,分享前端技術文章與職場經驗。
本篇為精華版,更多實務案例(誠實豆沙包)請收聽 Podcast
問題一: 會不會常改規格?
彥成分享說常改規格的狀況,很多時候可能會成為某個人離職的原因,因此透過這個問題其實主要是想去了解,這家公司的軟體開發流程狀態是不是適合自己。例如,當遇到不斷更改規格的時候,PM、QA、QC 等團隊成員之間是如何協調。
彥成談到如果常改規格,但可以體驗到正確的軟體開發流程,那也沒有什麼不好。但是前端基本上會是最後整合的人,也就算是最後時間壓力最大的人,當規格一直更改的時候,團隊的應對方式會影響到你的工作樣貌。所以可以透過這個問題,了解未來在這家公司的工作樣貌,會不會是你喜歡的狀態。
問題二: 關於 CSS 的撰寫方式,團隊如何處理樣式檔案? 有沒有什麼命名或擺放規則?
某個樣式檔如果有好幾種寫法,會讓人比較無所適從,而且撰寫方式如果不統一的話,也會比較難維護。
彥成也提到他第一個工作主管說過,如果每個人寫出來的東西都像同一個人寫的,長久下來就是大家會比較好維護、也比較好交接。
問題三: 公司有幾位設計師,如果有多位設計師的話,是否有decide guideline?
彥成分享他之前有遇過公司有好幾位設計師,每個設計師出的顏色不一致。比如說紅色跟綠色在每個畫面可能都微差了一些些,這一方面會造成體驗不好,另一方面又會造成工程師寫code的時候,每次都在為了調整顏色困擾。
再來是像檔名的問題,有些設計師設定的檔名,讓人很難判斷說兩個是一樣的檔案還是不同的檔案? 或是只要用同一個就好? 不過現在隨著科技的進步,有出現像Figma 這類型的工具之後,這樣的問題就比較少了。早期沒有這些工具的時候,就蠻常遇到這類的問題。
但其實不一定所有的公司都會一直追求技術更新,或導入相關工具,可能會持續使用比較舊的模式,所以也要看公司的情況而定。
問題四: 需要整合不同的後端嗎?
彥成談到這個問題首先要看自己是一個比較初階的工程師,還是比較資深的工程師。對比較初階的工程師來說,如果要串接比較多的後端,代表工作上要碰到跟解決問題就會變多,例如接不同的後端,就有跨網域的問題等。
再來就是可能因為不同的後端來自不同公司或不同單位,他回覆回來的格式,或者是可能同個格式裡面同個欄位的內容,可能撈出來都不一樣,那要怎麼去整合? 對初階工程師來說,這樣的工作可能難度會稍微高一點。
像是要串金流,然後要串自己的會員,再來會員可能要再串其他的會員集點系統,這樣可能中間要跟很多人接觸、要看很多文件、以及要處理很多格式不一樣的東西。短時間內可能會讓你技術突飛猛進,但也有可能陣亡,就自己需要去多做考量。
問題五: 專案中有用到哪些設計模式嗎?
彥成談到雖然不是說套設計模式就比較好,但是套一些比較基礎,可以解決某些問題的設計模式,可以讓團隊所有的人不用花太多時間,就看得懂這個程式在做什麼。
畢竟有時候有些工程師會把 Google 搜尋到的解法寫進程式碼,或是有問題就補個防呆、或是補上他根本也不知道為什麼這樣寫的程式碼,反正程式跑得動就好了,那下面一位處理的人就會很頭大。
問題六: 時程比較趕的時候,當工程師遇到困難時,主管會如何協助解決?
彥成提到這個問題是看主管遇到問題的時候會怎麼解決,避免主管只剩下跟你壓時程的功能。
而且主管基本上會是這份職務的天花板,所以他在處理問題的方式是不是值得你學習,也是可以透過這個問題來了解。
有些主管可能是好好先生型的,他就比較沒辦法幫你在跨組織的協調上,包含協調人力或是協調資源等等,可以真的幫上忙。再來就是你也不會了解,當有一天,如果你需要他幫你談判的時候,你要準備什麼東西給他,他才有辦法站得住腳,幫你去跟其他部門談。如果主管沒辦法做到這件事,那你也很難從中學習到如何處理這類型的問題。
問題七: 有分測試跟正式機嗎? 上版本遇到 bug 的時候,會在什麼時候修?
彥成說這個問題可以看出主管或是 PM 有沒有把事情分輕重緩急。從有沒有依照 bug 的類型去區分修復的時間,看出這個團隊是否是有制度的做事。
就算時間很趕,團隊是否有一套有制度的流程可以遵循,而不是隨時都要工程師臨時處理。
問題八: 對於 workaround 是怎麼看待跟處理的?
通常趕時間的時候,可能會直接把在 Google 搜尋到的解法寫進程式,但是其實工程師還沒找到問題在哪裡,或是知道問題在哪,但還沒找到解法,只是剛好搜尋到了可以解決當下問題的方法。
所以可以問主管說,遇到這種 workaround 的時候,會怎麼處理? 會不會排一些時間讓大家去重構?
透過這個問題可以避免遇到團隊像是練蠱大隊一樣,每個人都丟自己搞不清楚的東西進去,架構越來越混亂,最後只有百毒不侵的那個人能留在這間公司。
問題九: 如果有十幾個需求同時開發,或是正在轉換框架函式庫會怎麼進行?
彥成提到軟體開發的東西在上線的時候,可以想像是一部車子正開在路上,如果沒有暫時停車,你就要在車子正在開的時候,想辦法把輪胎換下來,而且你必須要讓他繼續前進,不能故障。
所以面試的時候,也可以跟主管聊聊,是不是有一些測試站跟正式站,然後他是怎麼做到 Zero downtime 等,用什麼做法來應對這樣的狀況。
其實也可以從這邊看出這家公司會用到解決方案是什麼,你就可以去評估這是不是你想做的東西。
問題十: 了解會不會過度結構化
彥成說可以問主管會在什麼時候決定,將共用邏輯抽取出來成為 Function 或是常數。這個問題也是可以了解團隊對於寫程式的價值觀。
一般會有人為了炫炮,就加一堆有的沒有的複雜的東西進去,也許這對個人來說是好的,但對整體團隊來說就不一定了。
因為原本可以用一個比較簡單的解決方案來解決,然後好維護,但是加了一些複雜的東西後,後面的人可能會比較辛苦。
除了這十個問題,彥辰也在新創、中小企業跟大企業都待過,他也分享了在這些這些不同型態的公司,他有什麼樣的工作體驗。