面試前端，你還有什麼問題想問嗎 一起透過發問知己知彼找到理想生活

在新鮮人階段時，通常不太確定面試可以問什麼或該問什麼，當面試到最後被問起:「你還有什麼問題想問嗎?」又該怎麼回答?

隨著職涯的發展，這個問題終究是回到自身想要成為什麼樣的大人?

對於個人來說，面試的目標是要找到不討厭、別人願意付錢請我們做、我們可能也做得不錯的事情。

面試前端，你還有什麼問題想問嗎?

在面試過程除了被面試其實也在面試團隊跟公司，而一個好的問題可以幫助我們從更多面向去了解這間公司工作樣貌，進而去看看公司有沒有符合想要的職涯目標、工作型態。

扣掉找新人免洗的狀況，大部分的公司都是遇到問題才會徵才，單純擴編的狀況可能並不多，而企業目前的問題很可能是造成前一位員工離職的原因之一。

在轉職時，要怎麼知道接下來是不是想要體驗這樣的職涯環境? 或著說工作樣貌是不是自己喜歡的?

之前小編收到 Open Career 的邀請，把這篇文章錄成 Podcast，在這兩集訪談的節目中會提到:

• 過去在不同專案中遇到了哪些問題
• 哪種工作模式可能是讓某個人離職的原因?
• 哪種職務內容需要你有越級打怪的實力?
• 在傳統大企業和新創寫程式會遇到什麼不同的挑戰?
• 避免再度中槍轉職面試時又該多問些什麼?

前端面試可以反問的 8 個問題

致那些年我踩過的坑，也預祝大家在新的一年填坑大吉

小編是前端工程師，決定在工作一年左右轉換的原因可以參考小編談談選擇前端的理由這篇文章。

前端通常是在設計、後端都完成後才進行收尾，收尾的同時也在幫規格、設計、後端 Debug，所以大家在大聊一波慶祝工作完成的同時，我們會發現只剩前端還在工作。

接下來會從小編當前端工程師過往遭遇的問題和解法反思未來職涯疑問，就讓我們一起看下去。

面試現象中的常見地雷

• 面試遲到讓面試者等
• 問很多跟工作無關的問題，有女朋友? 結婚有小孩了沒?
• 請我們又多填一份跟 104 一樣的履歷表
• 面試沒問太多技術問題都在聊天
• 很急著壓報到時間，燙手山芋正在快速拋接中
• 試用期砍薪水，過了還不一定會調整

不過這邊想要特別說明一下，我朋友在面試的時候很誠實跟主管說接下來的目標是交女朋友工作什麼的都是浮雲，而老闆不管在面試時或是面試結束後也給了很多機會，這邊不得不感謝那個問了問題後有協助處理的老闆。

是否有遇過常改規格的情境? 工程師會需要如何應對?

常改規格並沒有不好，要看的是有沒有體驗到好的軟體開發流程，目標是確認公司開發流程是不是下一份工作的目標，像是有分測試和正式環境嗎? 上版本遇到 bug 會在什麼時候修?

• 常依需求修改資料庫 Schema 或 API，每次都要重寫邏輯以及資料庫互動的部分
  • 需要常常顯示不同的統計，可考慮導入 GraphQL 從 Client 決定，減少開 API 的時間
  • 使用 Document-Oriented 的資料庫，POC 階段相對簡單
• 隕石式開發，主事者看到畫面後覺得還想改就又重來一次
  • 出 Mockup 或是設計製作不須切版的假畫面流程
  • 出一個 Demo 用的 Prototype (處理關鍵流程，不須注重美觀) 讓不熟網頁開發的主事者了解目前的狀況和方向，確認後才進行設計切圖、前端切版、後端開 API

通常是怎麼處理樣式檔? 像是 BEM 或依元件或頁面開檔案放置?

是不是可以在這樣的專案架構下學到東西

CSS 選擇器和規則們就像女孩化妝桌上的化妝品們，桌上總是放著各個種類，數也數不清大罐小罐擠的噴的擦的，在沒有預備知識和整理規劃的情況下，若要一個男孩子短時間搞清楚簡直是天方夜譚。

該怎麼透過 CSS 的架構來優化，可以參考之前小編寫的如何 透過 BEM、SMACSS、OOCSS、Atomic CSS 簡化樣式開發流程、減少維護成本。

• 撰寫地圖專用的圖層 SLD 樣式檔 (類似 XML) 超過一萬行
  • 官方有介紹使用 CSS 的寫法，運用 Class 共用的特性可讓行數減少
• 樣式檔沒有寫在元件中，也沒使用預 (後) 處理器，上千行的樣式檔搜尋 .user-photo 也許有十幾個結果
  • 樣式需要有命名規則 (BEM)
  • 導入 SCSS

目前公司有幾位設計，是怎麼合作的?

希望可以看出現在的專案是不是好維護，打聽一下工作流程或是有沒有 Design Guideline 或使用 Zeplin 或 figma 這類工具

• 同樣功能的圖片大小長寬比不一
  • object-fit
  • background-size: cover
  • 重新切圖
• 拿到檔名是 123543.jpg 大小超過 10 MB
  • 請設計壓縮一下
  • 小於 5MB 可使用 TinyPNG
• 設計沒有考慮到字數過多的情境，導致上字詞之後與預期狀況不符
  • overflow: hidden
  • 改設計

請問會需要整合不同的後端嗎?

評估自己的能力有沒有辦法處理

會需要串接不同網域的後端

• 使用 Nginx Proxy
• 改成在後端才打 API
• 後端開放 Domain 解決 CORS

不同 API 的配置大多不太一樣

• Token 都移到 Cookie，這樣相關的 Token 會自動送回相關子網域的 API
• 善用客製化後的 Axios Instance

專案中有用到哪些設計模式?

看現在的老闆或是同事是怎麼看待問題或是歷史遺跡

什麼是 Pattern，Pattern 就是改善如何去架構程式的方法，主要是讓程式碼能夠在元件間共用。

• 用 Java 的概念寫 Javascript，有非常多的 Prototype 的寫法，文件不清楚的情況下，導致實作上每次都需要追本溯源的看，考驗搜尋或是編輯器的能力
  • 使用 Component-Base 的函式庫或框架，並建立故事書
  • 善用設計模式，React 常見的 Component Pattern 就是 HOC 或是 Render Props

專案的時程會很趕嗎? 當工程師遇到困難時，會如何協助解決?

如果老闆只剩下壓時程的功能，那是不是我們用個鬧鐘或是 Google Calendar 就好了

主管可能不懂前端並無解決問題或協調資源的能力，只剩壓時程及提出需要限時解決

• 提早尋求同事協助，並看價值觀是否願意加班解決
• 時間給的不夠屬於管理上的問題，無法靠溝通解決就盡快重新找工作

如果有十幾個需求同時開發或是需要轉換框架函式庫，會怎麼進行?

要看的是與歷史共業的生存法則與態度

不同的產業別都會有歷史的包袱 (Workaround)，可能還是會用一些比較舊的東西。

除了東西較舊也可能遇到專案架構及程式混亂，這有點像是煉蠱的過程，看最後誰會生存下來。

• 專案在後期才考慮要加入 i18n 或伺服器渲染
  • React 本身是一套過於單純的函式庫，容易且戰且走疊床架屋，建議可以參考 Next.js Repo 中的 Example
• 趕時程但又好又快又便宜無法共存，專案中可能滿滿的 Workaround，像資料來源用 Google Sheet
  • 留下 // TODO: 及未來可改善方向
• 同樣一種功能有多種寫法或是 Deprecated 的寫法
  • 討論用哪種方法好，有時間就盡快合併，讓程式碼更好維護
  • 尋找 Deprecated 寫法的替代方案

會在什麼時候決定將共用邏輯抽取出來成為 function 或是常數?

炫技跟過度結構化並不會讓專案變得更健康

• 一層又一層的 HOC 封裝
  • HOC 像是一個工廠，把原來的元件變身或加強，所以不建議包太多層
• 過度或是過早的結構化，很簡單的功能卻太早預想會變成大專案

1
2
3
4

function getSQL(strSQL) {
  // 覺得這裡之後會加上資料處理
  return strSQL;
}

這裡有兩個觀念想要分享給大家，YAGNI 和 RUDT

YAGNI (You Ain’t Gonna Need It.)

• 真的需要使用 XX 模式嗎？
• 真的需要拆分成小元件嗎？
• 真的需要切成一堆小介面和抽象類別嗎？

RUDT

• Read: 最短的時間、最少的檔案
• Update: CRUD features 時可以用最小成本去改
• Debug: 菜鳥工程師也可以很快找到根本問題
• Test: 問題、結果都可以容易被複製被測試 (資料面像是抽獎時該怎麼辦?)

透過問題了解面試官和團隊

同場加映四個問題，來自 Medium 的 what questions should you ask the interviewers。

您的工作上一天大概是怎麼過的?

這題是開放式的問題，目標是希望可以聽到一些工作型態。

有些面試官可能會說公司通常是早上八點半上班到晚上六點，有些面試官可能會說我們公司跑 Scrum 每天早上會有站會，偶而晚上會跟其他國家同事開會。

藉由這個問題，你大概就能夠了解如果進入這間公司，你大概會過怎麼樣的生活。

延伸的問題可能會是趁機問一下加班、出差的頻率，或是任何你對工作型態的好奇。

最喜歡和最不喜歡這個團隊或公司的地方是什麼?

第一個部分通常是簡單的，但其實真正有趣的會是第二個部分。

面試官通常在有 HR 的場合會講不出來，甚至只會模糊的打官腔，可能會有面試官回答說，我不太喜歡頻率太高的會議或是一直在不同的產品中轉換。

最主要的目的是，透過這些回答，我們可以去延伸一些後面的問題，甚至我們可以只是單純再問說哇那到底是有多討厭多不喜歡，即便我們不會得到直接的答案或是他們真的不喜歡的地方，但我們仍舊能從這些回答中得到些蛛絲馬跡和感受，也許這些感受剛好也會是你在意的。

這個團隊接下來的目標是什麼?

這個問題很適合問團隊主管，至少在決定加入這間公司前，可以知道自己未來兩到三年大概能有什麼樣的成長。

這個問題可以幫助我們了解這個團隊是否在成長中，若是正在成長是不是有一個規劃好的計畫藍圖? 如果是的話，就可以評估我們的戰力是否可以協助公司推進。

那如果是一個穩定的團隊，只是做一些日常維護的工作，那該問自己的問題可能會是這是我們這個階段想要追求的嗎?

請問您通常都是怎麼帶領團隊?

主管的帶領風格會對你接下來工作的成就和快樂有非常大的影響，藉由這個問題，你也許可以知道主管的管理程度，也許有些會說他們做微管理，有些也許會說只需要你一周寫一次週報。

從回答中，你可以判斷這個主管的個性是不是適合你，提早了解這些層面會比進去之後後悔要來的更好。

最後，如果有什麼問題或想討論的東西，歡迎寄信到這裡 linyencheng.tw@gmail.com 跟我聊聊，或是到粉專前端三分鐘幫忙按個讚直接訊息我也很歡迎 :)

• ← 上一篇
• 下一篇 →