角度清奇

用 edge，插件方面和 chrome 无区别。标签开多了 edge 会自动冻结没用的

候选人太优选，太快就用完了我事先准备的问题的时候。就问一个 hard 看看，答出来加分，答不出也不减分

面试官本宫吐槽一下：首先国内面试没有你们想的那么「规范」。首先是根本不存在一套统一的面试题（也许某些厂的某些部门会有，那也仅限于特定部门），即便拼到同一部门了，面你的人也会随机分配，不会一直是一个人一面。不同人也会用不同的面试题面你

哪怕你们运气好面到同一个人了。拿我自己来说，我确实有一套固定的题，比如 20 题。是会根据面试者具体表现、自己当天的心情各种不可预知的情况出不同的题，不会一股脑全问了

总之就是不同公司的部门之间、组之间区别巨大。都可以认为是不同公司了

网络小说，先看个几十分钟，平静下来之后戴耳机听，一般设置 15~30 分钟后关闭。听着听着就睡着了

副作用是万一看到比较好的剧情会忍不住一直看下去导致睡更晚了，所以别选太好看的书

经历大概有点类似吧。985 建筑学专业毕业，毕业之后没找工作直接转行的前端

中学也搞过竞赛，学的 pascal，所以有一定基础。一开始也是自学，后来发现比较坑

- 学的不成体系
- 不知道该学什么，学到什么程度
- 没法得知自己的横向水平
- 没人交流，容易心慌

所以最后还是花钱报班了
如果 lz 不是那种自控力及其强大的人还是报班比较好，学费啥的后面一两个月工资就回来了

所有靠自觉和口头的风格化都是没有任何价值的。在项目里用 lint 工具限定好就行了，用哪个都无所谓，关键是要统一

一个 bundle.js 加载了 40+ 秒，实现的效果也没看出什么酷炫。无非是一堆线乱飞，简直意义不明。硬要做用 canvas 也不至于这么卡把

特别好，公司以后决定不要前端了。只要产品自己来描述需要的效果，不过描述一个准确又好用的页面不是那么容易，而且还加了好多工作量。

这时候那些描述得又快又好的产品突出了，他们专门研究怎么描述一个页面，其他产品想要页面都得找他们。这个工作慢慢被叫做「描述」

他们开始推动描述和产品分离，独自对接产品经理和后端。成了第一批「描述经理」

你想多了，不告诉你答案是因为如果每个题还给你讲解甚至讨论一下，那一个小时下来都问不了几个题。或者你答了一个非常规答案我自己一时间也判断不了，不能露怯，所以嗯一下当你大概对了

顺便告诉你作为一个面试官的心态

- 最开始面试别人的时候会充满好奇，然后很详细的跟人讲解、讨论，后来发现太耽误时间了

- 中期就是尽量少讲解，多问点。

- 后期就是很烦面试，耽误自己搬砖的时间有，多快面多快。

如果问了一半觉得不太行

- 远程面就直接结束

- 现场面就问个算法题，让丫想个半小时，自己继续搬砖然后到时间结束，

正常吧。头条、快手、百度都是这个流程

看简历感觉不错，作为前端 leetcode 两百题基本面所有厂都不虚了，直接投吧

@yafeilee 太巧了，我们组面人时候刚好用的 showmebug，体验还比较好。最巧的是刚用了一天，第二天就碰到你们推出正式版。还好面的人不是特别多，赠送的次数够用。

提一个不知道是使用方法错误、bug 或者是 feature 的问题，面试过程中添加题目之后，找不到预先设置的题目备注

双 985 硕，工作 1 年。研究生起薪肯定比本科高，假设折半换算，约等于本科毕业 2.5 年工作经验。学历加水平正常的话在北京这个期望确实不算高吧，主要还是楼主现在的 base 太低了。

我经历和楼主某种程度上还挺类似的。非计算机相关专业 985 本、2.5 年，最开始 8k 一个月。两次涨薪加跳槽，现在收入才和楼主期望差不多。

你就亏在当前薪资 9k 太低了，大厂是一定会按照当前 base 来给你涨的，通常最高 30%、特别优秀 50%。你这确实算 base 低过头了，但是给你翻倍也才 18k 。

如果按你的期望想进大厂至少还得跳两次，建议先找个不限制涨幅的中小公司把 base 拉高吧。

不会 vue 和 react 是硬伤。然后应届生的话主要还是加强 js 基础，弄懂跨域、模块化、从输入 url 到展示页面之间发生了什么这几个典型题。

之后能投大公司肯定优先进大公司，不然第一家一定找一个不忙的。进去先把业务弄熟，想尽一切办法提高开发效率，之后节约出来的时间全部由用来研究源码、构建工具、组件库。一边研究一边在业务里实践，有一定成果了之后再疯狂刷面试题、leetcode 。之后再找工作就轻松了，基础一般考不倒你，业务上也能说出亮点。

顺利的话一年多可以进大厂，不顺利就先进二线厂，重复之前的步骤，再进大厂应该没啥问题了。

再之后路就宽了

@chingli 看描述你这应该就是个大屏展示页？首先是「性能大大增强」，假设你写得完全没有一丝性能浪费，我估计有多大呢，应该是首屏速度从 1.1s 提速到 0.8s 的水平。然后为了这足足 0.3s 的性能，开发复杂度、后期维护复杂度，都会疯狂上升。

如果是偶尔写一两次，并且不怎么更新倒也还好。你说会经常遇到，那就更没理由花时间用落后于主流的技术栈去做一套所谓的高性能逻辑。

虚拟 Dom 的比对和更新也根本不是你想的那么消耗性能。只要按照最佳范例，早就能做到最小单位的监听和更新了，更比如更新 Dom 属性、给 Dom 换位置等操作时，你确定自己一个个改的性能比人家高？而且本身框架帮你处理了一堆乱七八糟的边缘问题。构建工具也全是现成的，一行命令就能跑起来。为啥要用 jq 磨练自己

或者说你这么问自己：花时间研究 jq 好还是花时间研究 vue\react 好？

js ≈ 走路、jq ≈ 骑车、vue/react/ng ≈ 开车

- 如果终点很近，当然是随便怎么过去，滚过去都行

- 如果终点很远，当然开车最快。反对开车的理由实在有点搞笑

问：不会开车，等我考完驾照再来开，我单车都可以来回十趟
答：如果只去很少的次数，当然没必要学新的东西了

问：开车效率低，不如我单车可以选最短路
答：路程短，时间不一定短。小路也不怎么安全

问：单车维护成本低，容易修
答：所以选工具最重要的因素是好修么？

问: 开车烧油，消耗大，不环保
答：如果你真的这么在乎这个，那就慢慢骑车吧，还能锻炼身体。只是等你去一个地方的耗时，人家可能已经来回十躺了

当然了，有些极端情况确实没法开车，比如路太窄、道路禁止机动车出行、乘客晕车等

感觉语雀不错