前端面試該反問的 12 個問題 從過往遇到問題和解法反思未來的職涯疑問

me
林彥成
2020-01-17 | 5 min.
文章目錄
  1. 1. 前端面試該反問的 12 個問題
    1. 1.1. 面試現象中的常見地雷
    2. 1.2. 是否常改規格
    3. 1.3. CSS 撰寫方式
    4. 1.4. 設計出圖是否注意命名及大小
    5. 1.5. 多種後端需要串接
    6. 1.6. 共用程式碼方式複雜
    7. 1.7. 傳統寫法轉換到 SPA
    8. 1.8. 時程總是很趕
    9. 1.9. 專案架構及程式混亂
    10. 1.10. 過度結構化
    11. 1.11. 寫那些文件上沒寫的用法
    12. 1.12. 開放式空間吵雜容易受干擾

前端面試該反問的 12 個問題

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

扣掉找新人免洗的狀況,大部分的公司應該?都是遇到了某些問題才會徵才,單純擴編又沒有坑的狀況可能少之又少。

對於個人來說,目標要找到不討厭、別人願意付錢請我們做、我們可能也做得不錯的事情。而企業目前的問題,很可能是造成前一位員工離職的原因之一,所以這篇文章將提到:

  • 過去四年多在不同專案中遇到了什麼問題
  • 可能的解決方法
  • 轉職面試時又該多問些什麼避免再度中槍

面試現象中的常見地雷

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

是否常改規格

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

Q: 有遇到常改規格的時候嗎? 情境大概是怎麼樣? 工程師會需要如何應對?

CSS 撰寫方式

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

Q: 怎麼處理樣式檔,有沒有什麼命名或擺放規則,像是 BEM 或依元件或依照頁面元件開檔案放置

設計出圖是否注意命名及大小

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

Q: 請問跟設計合作時,有使用像是 Zeplin 這樣的工具嗎?

Q: 請問貴公司有幾位設計,如果是多位那方便問設計有 Design Guideline 嗎?

多種後端需要串接

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

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

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

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

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

共用程式碼方式複雜

  • 用 Java 的概念寫 Javascript,有非常多的 Prototype 的寫法,文件不清楚的情況下,導致實作上每次都需要追本溯源的看,考驗搜尋或是編輯器的能力
    • 很久沒這麼寫,但印象中可以用 Closure Library 協助
    • 使用 Component-Base 的函式庫或框架,並建立故事書
    • 善用設計模式,React 常用的就是 HOC 或是 Render Props

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

最近參加面試就有聊到一個 HOF 的概念:

1
2
3
4
5
6
7
8
9
10
11
var xHOF = function (x) {
return function (y) {
return x * y;
};
};

var xFive = xHOF(5);
var xTen = xHOF(10);

xFive(2); // 10
xTen(2); // 20

傳統寫法轉換到 SPA

  • 前後端分離,前端路由與後端路由衝突
    • RESTful API
    • 前端要避免這樣的狀況 (Service Worker、前端路由的 404)
  • bundle 處理
    • HTTP1 對同個網域的 Request 有限會壓成一大包
    • HTTP2 會做 Code Splitting

Q: 目前團隊有幾個前端,主要使用的函式庫或框架為何,有需要處理伺服器渲染嗎?

時程總是很趕

  • 主管可能不懂前端並無解決問題或協調資源的能力,只剩壓時程及提出需要限時解決
    • 提早尋求同事協助,並看價值觀是否願意加班解決
    • 時間給的不夠屬於管理上的問題,無法靠溝通解決就盡快重新找工作

Q: 當工程師遇到困難時,主管會如何協助解決?

Q: 有分測試和正式機嗎? 上版本遇到 bug 會在什麼時候修?

專案架構及程式混亂

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

Q: 專案中像是多國語系或是伺服器渲染的需求在一開始就會考慮好嗎?

Q: 當需求很趕的時候,可能會有一些 Workaround,是怎麼看待跟處理的?

Q: 如果有十幾個需求同時開發或是正在進行框架函式庫的轉換,會怎麼進行?

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

Q: 請問在引入函式庫的時候有什麼流程嗎?

過度結構化

  • 一層又一層的 HOC 封裝
    • HOC 像是一個工廠,把原來的元件變身或加強,所以不建議包太多層
  • 過度或是過早的結構化,很簡單的功能卻太早預想會變成大專案
1
2
3
4
function getSQL(strSQL) {
// 覺得這裡之後會加上資料處理
return strSQL;
}

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

寫那些文件上沒寫的用法

  • 對 Create-React-App 的專案做了特別處理,寫了些文件上沒寫的
    • 看該 Commit 的 PR 是否有說明,原作者還在嗎? 詢問原因後看狀況儘早拿掉
  • 因為發現第三方套件部分不適用,所以 Fork 了一個版本進行更改並引用
    • 尋找替代方案,並隨時看套件是否更新後有解決問題

Q: 如果第三方套件在使用上出現問題且遲遲無法解決要怎麼辦?

開放式空間吵雜容易受干擾

  • 前端通常是在設計、後端都完成後才進行收尾,收尾的同時也在幫規格、設計、後端 Debug,所以大家在大聊一波慶祝工作完成的同時,我們會發現只剩前端還在工作,但並不是所有的團隊都會尊重並理解 RD 是需要稍微安靜的空間進行軟體開發
    • 我之前是跟老闆提出想往前移動上班時間,原因是難以專注效率低且容易出錯
    • 自發性的提早上班,中午延後吃飯時間,至少會有兩段安靜可專注的時段
    • 買抗噪耳機,台北也許因成本關係,與同事處在摩肩接踵的距離,幫助可能有限

Q: 辦公室看起來是開放式的空間,請問平常會很吵雜嗎? 如果對方回答有時候有點,我會建議直接當成 30% ~ 50% 都跟國小下課時間一樣


喜歡這篇文章,請幫忙拍拍手喔 🤣

share