全端工程師這個詞是最近十年才出現的
我的感覺是因為前端技術的發展迅速
導致傳統web開發技能樹在前端大幅增加
在SPA流行之前，web開發技能很單純就是後段語言
加上HTML & 基本CSS
JS在那個年代差不多只是用jquery跑簡單的UI
一個專案可能數萬行後段程式碼
前端的JS只有幾百行
在這樣的時空中，web工程師實際上重心放在後端語言
隨著SPA興起，前端框架與技術的進步
現在的前端開發已經不再是簡單的事情
需要專精的人才去處理
前端工程的複雜度早就不亞於後端工程
而全端工程師的誕生我認為與相關工具的進步直接關聯
由於各種工具的輔助，大量節省工程師的時間成本
才可能會有全端工程師這樣的職位
我個人認為全端工程師真正的價值
不是一個人可以同時做兩件事
而是由於對兩端都有涉獵
因此可以從系統整體面相規劃設計
例如在實現功能的時候可以設計出彈性的API 規格
此外在中小型團隊中，可以依照任務目標靈活調派人手
目前在我工作的團隊中，每個人都是全端工程師
最基本的門檻是
前端技術方面，了解JS基礎特性
後端技術則是著重於基本演算法
系統設計方面要能夠考慮到大型系統的運作及延展度
我自己面試別人的時候都還會問一個 JS 題
意外的是大概2/3的人答不出來，但是這個題目
是我覺得全端工程師在前端技術上的最低門檻
題目是
for(var i = 0; i < 5; i ++) {
setTimeout( function () {
console.log(i);
}, 0);
}
問：輸出為何？
再問：如何輸出0到4
至於後端問題我通常找leetcode medium 問
此外我們面試絕對不會問框架問題
因為我們認為優秀的工程師不應該受框架限制
而是能夠快速學會任何框架
而且我們用的框架是內部設計
問了三大框架問題也沒用

let?

樓上答對了

IIFE

輸出4 4 4 4，var改成let

[0,1,2,3,4].forEach(n => console.log(n))

DOM基本操作呢？CSS呢？資料庫基本觀念呢？全端最囧的地方就是面試方可以拿任何一方面的”基本觀念”來考被面試者 因為那是基本觀念呀你拿資料庫優化的基本觀念來考後段強前端弱的求職者當然可以電他*前端強後端弱你拿javascript closures跟event loop來考CSS強者也可以電他你拿leetcode medium/hard搞不好也可以電Tyler mcginnis之類的JS大法師 (我是不知道他演算法多強啦)考來考去不如大家回歸前端vs後端 至少範圍清楚一點

請問為啥是4444呢

google js closure就知道為什麼

Godbye45你已經死了 XD

不是55555嗎

我是覺得養成好習慣先寫個變數不好嗎？

這是 function scope 跟 EC 的問題吧

不是5566嗎

i 宣告在global 時間到之後 event loop 執行 callback 印出 i 。中間有用到包閉嗎要包閉才能拿到 i sor

也有些人認為前端的重點在 CSS 切版啊，這個要寫的優雅也不是件容易事，我覺得就像 cloud 說的那樣，因為東西太多了，

放棄js 改用 c# 同事表示兩個蠻像的

很容易被電。這題也很多可以深入的啊，比如 callback 時間不要設 0 改成i，問你為什麼輸出不是 0 5 5 5 5 而是 5 5 5 5 5？這樣就是一個小陷阱了。五樓說的解答也滿足題意，可是大概不是面試官想要的答案

面試最重要的不是考倒對方，基礎的確是重點就是個性比一切都重要，一個會背答案，實戰力＋態度超弱也遇過一個太強融不進團隊的也不適合

這種考題雖然考到爛了 但平常沒在用還是答不出來XD

(function(i){console.info(i);})(i)

只能推max

寫了n年js還沒踩過closure的坑，這種觀念題已經過時了吧？最近看到一題有趣的題目[1, 7, 11].map(parseInt)

3樓害我思考了一下為什麼是4，這題我不會踩到closure不過會在12345和55555猶豫，原因是我會忘記javascript是單線程加上setTimeout(0)我會誤以為是立即執行但看題型我又會懷疑故意考closure，剛去查才發現setTimeout(0)是立即排進序列，而非立即執行...所以因為單線程，所以不會是隨機由小到大的1~5setTimeout(0)非立即執行，所以會等for結束才執行再加上var i被hosting，所以全部都是5，1題3個細節...

don't use var

.map(parseInt) -> .map(Number) 這是考平常沒在用的細節

這是在考平常不會去踩的坑 跟台灣馬路一樣

樓上 是的 完全是平常根本避免踩的坑

坑就在var 不過現在平常都用let或const了

問題是大家都得為這種坑做準備 因為面試官就喜歡這個 不然我團隊上有人寫這種鬼東西一定被我罵

還是不懂為何不同經驗出身的工程師為什麼必須要符合全端工程師的標準 還有當他已經是專業前端或後端那還會來應徵全端工程師嗎?

parseInt那個類型的坑踩過一次就不會那樣寫了QQ但是let的支援度實在是....https://caniuse.com/#feat=let

不是啊，瀏覽器端的支援度差，開發時你照樣可以寫 let，再透過 webpack 配合 babel 去打包...不然 TypeScript 怎麼辦？這篇給問題其實也是 TS 寫在文件裡說為什麼會有 TP 出現，因為 JS ES2015 之前的 xxx 會有那些問題，那個問題就是其中一個例子…

我都不習慣用編譯的，Javascript 就是要寫了直接在瀏覽器跑所以還是用 var，這些問題寫久了知道就會避開了它也不是沒有邏輯或規則可言，也有很多解決這問題的寫法

如果說 TS, CoffeeScript 這種方言就算了，ES 算是 JS 最常見也通行的規範了，我覺得 let, var 的爭議只是要不要學新東西而已，瀏覽器為了市場也會漸漸支援，不然很容易被淘汰像是 class 的語法糖出來了，還要繼續用舊的方式寫類別嗎？還是用推出的 class 語法糖，然後也知道 JS 的繼承實作和其他語言不同就足夠了？

不 babel還是有團隊或公司是不接受的 理由就是不能保穩我自己也認為他們莫名其妙...另一個babel會被打槍的狀況是包出來很大一包XD

很大包可以試試polyfill.io之類動態引入的解決方案

這種題目 基本前端沒稍微摸的(就不是UI套套的等級)應該會答的很亂...另外let var 和 array function 等 這種常用的ES6應該跟前端有關的工程師都該習慣.(打太快是arrow function)