面試問答
之前負責過哪些專案，遇到最難處理的問題？
照實回答
這次面試是採線上面試，一開始進會議室的時候，人資跟面試官都已經在線上了。人資先簡單說明了一下面試流程，大概就是等等會先由
面試官跟我聊，結束之後她會再回來說明後續的程序跟需要補的資料。
這部分其實滿快的，也沒有什麼特別的事情。確認聲音跟畫面都正常之後，人資就先離開會議室，剩下面試官跟我兩個人。
老實說人資一離開的時候，我本來還有稍微進入備戰狀態。
因為面試前其實準備了不少東西，尤其這次應徵的工作跟我原本比較熟悉的開發領域不是完全一樣，所以一些可能會被問到的技術問題、以前做過的專案，甚至哪些地方可能被追問，我都有事先想過要怎麼回答。
結果後來發現好像有點白緊張了。
面試官沒有一開始就丟技術題過來，而是先從我之前的工作經驗開始聊。做過哪些系統、在團隊裡面主要負責什麼、碰到過什麼比較麻煩的問題等等。
這種我反而比較好回答，因為都是自己真的做過的東西，也不用特別去背什麼標準答案。比較有趣的是，有些問題一開始聽起來很普通，但回答之後面試官會順著內容再往下問，所以很容易從原本的一個問題一路岔出去。
例如一開始可能只是在講某個專案做了什麼，後面就會聊到當時為什麼這樣設計、需求是誰決定的、如果需求本身有問題會怎麼處理。
這種問題其實比直接問框架怎麼用還難一點，因為技術題不知道就是不知道，但「你當時為什麼這樣做」就沒辦法只丟一個標準答案出去。
而且實際工作做久了就知道，有些東西事後回頭看，當時的作法也不一定是最漂亮的。很多時候只是受限於時間、舊系統、其他人的程式，甚至客戶突然改需求，最後只能選一個當下可以動的方式先處理。
所以我也沒有特別把以前做過的事情包裝成每一件都很成功，反而有聊到一些「如果現在重新做一次，我大概不會這樣處理」的東西。
這部分面試官倒也沒有一直挑毛病，反而會接著問如果現在碰到類似情況會怎麼做。到這裡之後，我原本那種「正在被面試」的感覺就淡很多了，比較像兩個做系統的人在交換以前踩過哪些坑。
中間也聊到一個我自己工作久了之後越來越有感覺的問題，就是工程師到底應該負責到哪裡。
如果規格都已經寫得非常清楚，工程師照規格把功能完成，當然是最單純的狀況。但實際工作根本沒這麼理想，很多時候真正浪費時間的不是程式寫不出來，而是做到一半才發現大家對需求的理解根本不一樣。
甚至有時候三個人講同一句話，腦袋裡面想的是三件不同的事情。
這種時候如果只是想「反正規格這樣寫，我照做就好」，最後東西真的做出來了也不一定有人敢說它是對的。
這個話題不知道為什麼聊得有點久。
原本好像只是在回答以前怎麼處理需求，後來已經有點變成在討論工程師要不要參與需求跟系統規劃。我自己是覺得，如果完全不讓 RD 碰前面的東西，等規格一路傳到開發手上的時候，有些問題其實已經很難救了。
講到後來我自己都覺得有點好笑，因為已經不像是在回答面試題目，反而有點像平常公司裡幾個 RD 在聊天。
當然也不是整場都在閒聊。
面試官還是有問到我對這個職缺的想法，以及如果真的加入之後，對工作內容有什麼期待。
這部分我沒有只回答「希望學習新技術」這種比較安全的答案，因為到了現在這個階段，我其實比較在意的是工作到底能不能有一定程度的自主性，還有碰到問題的時候，是不是有空間去找比較適合的解法。
畢竟工具跟技術一直在變，如果每件事情都只能照以前的方式做，對我來說反而會比較痛苦。
接下來換我問問題。
我自己面試之前通常會先準備幾個想問的東西，不然最後突然被問「你有沒有什麼問題？」才開始想，通常也只能問出一些官網上就查得到的問題。
所以我主要問了部門現在的工作模式、團隊怎麼分工、這個職缺進去之後大概會負責哪些事情，還有之後部門想往哪個方向發展。
也是聊到這裡之後，我才比較確定這個職缺跟一般想像中的 RD 工作確實有點不一樣。
因為這個團隊本身還算比較新的單位，所以有些事情並不是已經有一套固定流程，然後新人進去照著做就好。
除了開發之外，可能還會碰到需求訪談、系統架構規劃、跟其他部門協調，甚至新系統要怎麼推進這類事情。
聽到這裡我其實有稍微重新想了一下。
如果只是看職缺名稱，很容易把它理解成比較單純的系統開發，但實際聊過之後，感覺比較像是「哪裡需要有人把事情弄起來，就可能要去處理」。
這種工作有好有壞。
壞處當然是事情可能比較雜，而且新團隊很多東西沒有現成答案，真的進去之後應該不會是每天安安穩穩領需求、寫程式、下班。
但換個角度想，也因為很多東西還沒有完全定型，能碰到的範圍反而比較廣。
這點我自己其實不排斥。
以前做系統做到後來，慢慢會發現程式本身有時候反而是最好解決的問題。程式錯了至少還有錯誤訊息，需求錯了可不一定會跳 Exception。
最麻煩的是系統正常運作、程式也完全沒報錯，最後使用的人跑來跟你說：「不是啊，我們不是要這個。」
那才是真的頭大。
所以當面試官提到這個職位可能需要碰需求、規劃跟跨部門溝通的時候，我反而覺得可以理解為什麼前面會花那麼多時間問我以前怎麼處理問題，而不是一直考語法或框架。
如果只是確認會不會寫程式，前面的筆試其實已經做過一次了，面試再把差不多的東西考一次，好像也沒有太大意義。
聊到後面其實我已經完全沒有注意時間。
直到中間看了一下時間，才發現不知不覺已經接近一個小時。本來以為線上面試可能半小時左右就結束，結果前面幾個話題一路岔出去，時間過得比想像中快很多。
最後面試官問我還有沒有其他想了解的地方。
我稍微想了一下，原本準備的問題其實前面聊天的時候已經陸續問得差不多了，再硬問好像也只是為了證明「我有準備問題」，所以就沒有特別再湊。
之後人資重新加入會議室。
人資說明了一下接下來的流程，以及後續還需要補充哪些資料，也確認我這邊還有沒有其他問題。
到這裡整場面試就差不多結束了。
關掉會議之後，我第一個感覺其實是：我面試前到底準備那麼多技術題幹嘛？
當然準備還是有用，至少真的被問到不會完全沒東西講，只是這次真正花最多時間的，反而不是「你會什麼」，而是「你以前怎麼做事」。
這跟我原本預想的面試方式差很多。
如果要說這次面試最大的感想，大概就是沒有什麼很強烈的考試感。面試官當然還是在確認我的經驗適不適合這個職缺，只是方式比較像從聊天裡面慢慢確認，而不是拿著一張題目一條一條問。
對我來說這樣反而比較舒服。
畢竟工作經驗累積到一定程度之後，要用幾題技術問答判斷一個人到底會不會做事，我一直覺得滿困難的。
而且這次聊完之後，我對這個職缺實際要做什麼，也比看職缺說明時清楚很多。
至少知道如果真的進去，應該不會只是每天坐著寫程式。
至於這算優點還是缺點，大概就真的要看人了。
面試問答
之前負責過哪些專案，遇到最難處理的問題？
照實回答
面試建議
這次面試結束之後，我自己的感覺其實還不錯，不過不是那種「面試官很親切、公司環境很好」的制式心得，而是覺得至少這一個小時沒有浪費。
這點對我來說其實滿重要的。
工作做了一段時間之後，現在去面試跟剛出社會時的想法已經差很多。以前可能比較在意自己答得好不好、技術題有沒有答對，現在反而會花不少時間觀察另外一件事：如果真的進了這家公司，我每天到底會在做什麼？
因為職缺說明畢竟只是職缺說明。
尤其工程師的工作，網站上寫「系統開發、需求分析、系統維護、跨部門溝通」，老實說每家公司都可以這樣寫，看完還是不知道進去以後到底在幹嘛。
這次至少聊完之後，我對這個問題有比較具體的答案。
這個部門本身算是比較新的團隊，所以很多東西還在發展，也不是已經有一套非常固定的工作模式等新人進去照著跑。換句話說，工作範圍可能比一般 RD 更廣，除了開發，也會碰到需求、規劃、架構甚至跨部門協調。
這種職缺我覺得不一定適合每個人。
如果比較喜歡需求跟規格都整理好，拿到手之後專心開發，做完交付，這種工作可能會覺得有點雜。因為很可能程式還沒開始寫，就要先處理一堆「到底要做什麼」的問題。
但如果本來就不排斥碰前面的東西，甚至會想知道這個需求為什麼要做、系統以後準備怎麼走，那應該就會比較有發揮空間。
我自己是後者。
以前做開發時就碰過不少這類事情，有時候真正麻煩的甚至完全不是技術問題，而是需求講不清楚，或是不同單位各自理解了一個版本。這種東西最後通常還是會一路往 RD 身上掉，所以久了以後，我已經不太相信「工程師只要把程式寫好就可以」這件事。
程式有 bug 還比較單純，至少通常找得到是哪裡壞掉。
需求本身有 bug 就精彩多了。
這也是為什麼這次面試官花不少時間問以前碰到事情怎麼處理，我反而覺得滿合理的。因為如果這個職缺真的需要碰這麼多不同的事情，只知道會不會寫某個 framework，好像也判斷不了太多東西。
當然，技術還是要準備。
而且如果真的要講這次整個面試流程，我反而覺得前面的筆試比較硬。
我自己原本主要是 PHP 的開發背景，但這次職缺會碰到的技術並不完全侷限在 PHP，Java、Python，甚至 AI 相關的東西都有可能遇到。所以準備的時候，我也有刻意去看一些不是自己平常天天在用的東西。
這裡我覺得有一個地方滿值得提醒後面要面試的人：不熟的東西真的不用硬裝熟。
因為如果只是第一題問「會不會」，硬著頭皮說會可能還混得過去，第二題、第三題一路往下追，很快就會出事。
反而自己真的做過什麼、做到什麼程度、哪些東西只是接觸過，直接講清楚比較省事。
尤其現在技術範圍這麼大，我也不太相信有哪個工程師什麼都熟。
以我自己來說，我會比較傾向把「我怎麼解決不知道的東西」講清楚。因為工作上真的碰到陌生技術時，公司也不會因為我沒學過就自動把需求取消，最後還是得想辦法把它弄出來。
這幾年 AI 工具越來越成熟之後，這件事又更明顯。
以前碰到陌生框架，可能先 Google、翻 Stack Overflow、找官方文件，現在則多了 AI 可以一起用。但我覺得工具本身不是重點，真正的問題還是你能不能判斷它給的東西對不對，以及最後有沒有辦法真的把問題解掉。
所以如果要準備這類面試，我會建議不要只準備「我會 Laravel、我會 MySQL、我會某某框架」這種技能清單。
自己的專案最好真的重新想過一次。
當初為什麼這樣做？
碰到最大的問題是什麼？
如果重做一次還會不會用同樣的方法？
需求改過怎麼辦？
跟其他人意見不一樣的時候怎麼處理？
這些問題看起來不像技術題，但真的聊起來，比背 framework 的功能更容易看出一個人的工作方式。
還有一個我以前其實沒那麼重視，現在反而一定會做的事情，就是面試前準備「我要問對方什麼」。
這不是為了最後面試官問「有沒有問題」時不要冷場。
是真的要問。
因為面試本來就不應該只有公司判斷要不要你，你也要利用這一個小時判斷這家公司到底是不是自己想進去的。
例如實際工作內容是什麼、團隊怎麼合作、需求從哪裡來、技術選擇有多少空間、這個職缺為什麼現在要找人，我覺得都比問一些公司網站上找得到的東西實際很多。
尤其是有工作經驗之後，這件事情我覺得更重要。
畢竟換工作不是換一個 Git repository 而已。
薪水當然重要，但主管怎麼帶人、公司怎麼做事、工具能不能用、遇到問題是一起解決還是先找人背鍋，這些東西真的進去之後，每天都會碰到。
面試反而是少數可以名正言順一直問對方問題的機會，不問白不問。
這次我自己也是因為問了不少，才慢慢拼出這個部門實際上的樣子。不然如果只看原本的職缺說明，我對工作的想像跟面試完之後其實還是有一點差距。
至於面試氣氛，我覺得算是輕鬆。
至少不是那種從頭到尾面無表情考試，答錯一題就開始懷疑人生的類型。
有些問題面試官會順著我的回答繼續問，有些則聊著聊著就變成交換彼此的看法。對已經有一些工作經驗的人來說，我自己滿喜歡這種方式，因為比較有機會把實際做過的事情講出來。
真的要我給後面準備面試的人一個建議，我大概不會叫他去多背五十題面試考古題。
我會叫他把自己的履歷打開。
然後從第一份工作開始，一個專案一個專案想：這東西當初到底是怎麼做出來的？
哪些是你自己做的？
哪些事情你搞砸過？
後來怎麼救？
有沒有哪個設計現在回頭看會覺得「我當初到底為什麼要這樣寫？」
這些如果都講得出來，我覺得比背一堆標準答案有用很多。
因為技術題真的不會，頂多就是不會。
但履歷上寫自己做過的東西，結果被多問兩句就講不下去，那個才真的很難救。
最後就是，不用把面試想得太像考試。
至少這次給我的感覺不是。
公司在看這個人能不能一起工作，面試的人其實也在看這群人是不是自己願意一起工作的人。
雙方都看得順眼，工作內容也談得來，再來談下一步。
大概就是這樣。
