全端工程师这个词是最近十年才出现的
我的感觉是因为前端技术的发展迅速
导致传统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)