還有什麼問題想問嗎 從過往問題、解法,反思前端面試要問的問題

me
林彥成
2020-01-17 | 5 min.

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

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

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

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

面試現象中的常見地雷

  • 面試遲到讓面試者等
  • 問很多跟工作無關的問題,有女朋友? 結婚有小孩了沒?
  • 請我們又多填一份跟 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