前言

工夫过得很快，好像20年的金九银十就在昨天，21年的金三银四随之而来了，还没有筹备好面试的同学们不要慌，明天和大家聊得的是淘系前端面试，一共是5面+HR面，会问那些问题？又该如何答复？看完这篇，为咱们的面试精益求精！

一面

这一面次要问了根底局部, 一部分题目我会带上提醒
  • TCP 三次握手/四次挥手/期待2MSL意义/建设连贯但客户端故障
  • TCP 慢启动/拥塞管制, 疾速重传/疾速复原
  • TCP UDP QUIC(QUIC是Http3的底层协定)
  • Http2绝对于Http1.1新增了哪些货色, 次要是信道复用之类的
  • 浏览器渲染过程, 留神只是渲染过程, 就是从解析DOM树到展现在屏幕这个过程

    次要是 令牌化/建树/收集样式表/布局渲染树/绘制列表/栅格化/绘制图块/...这些过程, 举荐浏览浏览器的工作原理：旧式网络浏览器幕后揭秘

  • 强缓存与协商缓存, 次要讲了下E-Tag和Last-Modified以及对应的标识, 强缓存计划与协商缓存计划的场景, 比方index.html该用哪个?
  • CSS的程度居中与垂直居中
  • 挪动端1px, 老问题啦.
  • Git操作, 次要是revert与reset, 咱们工作室应用的是Git Flow, 并且辨别Master和Dev分支这种, 小哥说了一个Git Flow无奈handle的场景, 即一个feature还未合并到Master, 然而前面的一个feature曾经通过提测要并进骨干, 这时要如何解决?
  • React: 新旧生命周期的问题, 为什么要废除旧版的(束缚开发者以及Fiber架构可能会将其打断), 新版的有什么特点(getDerivedStateFromProps(nextProps, prevState), 这个办法是静态方法, 也就说你无奈在外面获取到this, 还有就是入参为prevState, 这样就保障state和props之间更隔离). 还有就是我感觉很好玩的getDerivedStateFromErrors和componentDidCatch的合作.

  • React: PureComponent, 浅比拟, 放一下shouldComponentUpdate中shallowEuqal的源码:

      const hasOwn = Object.prototype.hasOwnProperty;  function is(x, y) {    if (x === y) {      return x !== 0 || y !== 0 || 1 / x === 1 / y;    } else {      return x !== x && y !== y;    }  }  export default function shallowEqual(objA, objB) {    if (is(objA, objB)) return true;    if (      typeof objA !== "object" ||      objA === null ||      typeof objB !== "object" ||      objB === null    ) {      return false;    }    const keysA = Object.keys(objA);    const keysB = Object.keys(objB);    if (keysA.length !== keysB.length) return false;    for (let i = 0; i < keysA.length; i++) {      if (!hasOwn.call(objB, keysA[i]) || !is(objA[keysA[i]], objB[keysA[i]])) {        return false;      }    }    return true;  }复制代码
  • React: setState之后产生的.
    屡次setState的合并与获取最新的state, 其实这俩个是同一处代码(如同是particalState), 外部对参数的Object类型和Function类型做了不同的解决, 为函数的状况下, 会在setState调用实现并且组件开始rerender的时候被调用.
  • Node: stream和Buffer, 面试前不久刚写过流式的文件上传所以历历在目, 答复了四种流(可写/可读/可写可读/可转换), 以及罕用的几个pipe办法.

    Buffer的话次要提了一下它是堆外内存(V8的常驻内存由代码区/栈/堆/堆外内存组成)啥的.

  • Node: 内存治理, 这个有看到过通过启动命令更改堆内存下限的文章所以理解的多了一下, 次要关键词有 新生代/老生代假说, Scavenge算法(采纳复制实现内存回收, 典型的就义空间换工夫), From/To空间, 标记革除, 标记整顿, 增量标记(将标记阶段拆分为管制在5ms内的小步骤, 每隔一段时间执行, 进步程序流畅性.)

二面

  • 微信小程序, 这个是二面的重点发问之一, 包含以下几个方面:

    • 生命周期, 包含利用级的和页面级的.
    • 架构, View - Native - JavaScript的层级, 零碎层能力, 如微信凋谢能力/离线存储/网络申请等. 视图层的话, 安卓下是腾讯自主研发的基于Blink的X5内核, IOS的话则是自带的WebKit-Webview
    • 应用async/await, 小程序目前如同并不能原生反对async/await语法, 须要引入FB的Regenerator库. 说到这个, 我很好奇Taro/Remax这些计划中是如何解决async/await的, 降级为Promise吗?
    • 鉴权, code2session这个api, 应用sessionKey生成token, openid作为主键入数据库, 再返回自定义的登录态标识.
    • 与 H5/RN/Flutter/PWA 这些差别, 次要是和 H5/PWA , 我其实不太认同 PWA是小程序祖师爷 这种说法, 甚至认为不是一个性质, 只是他们的目标/玩法是类似的.
    • WXS, 过后小程序也用到了, 次要特点就是运行在View层的逻辑, 并且因为JavaScript在IOS下运行在JSCore, 安卓下运行在V8的起因, 在IOS上WXS能够达到JS数十倍的性能, 但在安卓上和JS持平.
    • setState, 很神奇的一点: 数据扭转同步而视图更新异步, 次要也是因为下面提到的架构的起因. 有趣味的能够再查阅相干材料.
    • 小程序如何做到禁止拜访Dom, 我的了解是小程序压根就没提供DOM/BOM的API, 并且在打包编译的JS里也获取不到Window对象.

  • @Penumbra/cli, 一个思路相似Feflow的脚手架, 也是 脚手架外围+模板插件包+构建器 的一个组合, 模板插件包的话, 前端蕴含 Webpack/Parcel + TypeScript/JavaScript的组合, 后端蕴含Koa/Egg + RESTFul/GraphQL的组合. 次要问了这些问题:

    • 为什么要整这个货色, 解决了哪些问题?
    • 带来了什么益处?
    • 为什么还增加了Parcel
  • Parcel和Webpack
  • 谬误监控, 咱们目前应用的形式是Sentry以及Release时上传Source-Map文件的形式. 本人实现的话, React的思路次要是一个最外层的<ErrorBoundry />组件, 借助getDerivedStateFromError与componentDidCatch来捕捉谬误.
  • Https加密机制
  • Git Rebase 与 Git Merge
  • Flutter 与 React Native底层
  • Serverless, 这一块能够讲FaaS以及BaaS, 还有Serverless对前端意义, 这个问题千人千面, 就不开展来讲了.

三面&四面

三面和四面提问的角度和提出的问题比拟相似, 因而就放在一起讲了.

  • 介绍我的项目, 通常会问面试官是对业务型我的项目还是设施型我的项目比拟感兴趣, 业务型的话就介绍小程序, 设施型就介绍@Penumbra/cli.

    不要东扯一点西扯一点, 以 技术栈 -> 业务场景 -> 亮点 -> 难点 -> 提炼总结 -> 自我晋升 这几个步骤来叙述会更加条理清晰, 其中亮点/难点以STAR法令介绍最佳.

  • @Penumbra/cli这个, 下面曾经介绍过, 就不再赘述. 次要为了体现 新工程目录建设繁琐 -> 该当成员之间对立目录构造 这个意识.

  • GraphQL, 次要介绍了这些:

    • GraphQL的意义, 与RESTFul的差别
    • 对后端的影响
    • Apollo生态, 在这里我想大胆猜想下, 将来的BFF层肯定少不了这三个货色: Apollo-Server & TypeGraphQL & Apollo-Rest-Datasource, 至于它们是什么感兴趣同学能够去查查. Apollo不仅提供了服务端反对, 也提供了客户端反对, 即Apollo-Client, 同时应用Server和Client来构建利用真的能起到1+1>2的成果, 因为二者就像是一体的.
    • 推广阻力, 其实只有一个团队比拟年老就没有什么阻力, 次要是可能有肯定的学习/开发/保护老本~ 嚷嚷着"学不动了"在前端世界里可能真的举步维艰.

  • Webpack性能调优, 从 打包速率 / 打包大小 / 交互敌对 三个方面动手的, 这里能够略微列举一些我感觉比拟好用/乏味的Plugin:

    • friendly-errors-webpack-plugin, 次要是对抛出的谬误做了界面优化, 很多cli都在用.
    • speed-measure-webpack-plugin, 测量各个环节的打包耗时, 也能够找出哪一个loader/plugin耗时最久.
    • terser-webpack-plugin, 压缩JS
    • webpack-bundle-analyzer, 剖析打包产物
    • webpack-visualizer-plugin, 同样是剖析打包产物, 然而更直观
    • webpack-parallel-uglify-plugin, 并行压缩, 如同和terser性能反复了
    • webpackbar, 强烈推荐! 在打包时会有进度条(VuePress就用的这个)
    • preload-webpack-plugin, 预加载
  • 至于从配置动手的话, 次要是缩小查找文件工夫和缩小build代码体积, 前者能够通过resolve字段中配置extension, loader中配置exclude, 后者的话则次要是Tree-Shaking(留神, CSS也能够做摇树优化), 代码宰割(动静加载以及Lodash/Antd这种宏大的模块), Source-Map模式, 压缩代码等等.
  • React函数式组件

  • React Hooks:

    • useState
    • useEffect, 不传dep与传入[], 别离对标类组件的哪个生命周期.
    • useLayoutEffect

    • useRef, 还有useImperativeHandle与forwardRef

      • useRef，使函数式组件也可能享受到获取 DOM 元素或者自定义组件，父组件获取子组件援用而后调用子组件办法，如 focus 等.
      • forwardRef，能够获取父组件的 ref 实例作为子组件的参数（与 props 同级），而后再把这个 ref 绑定到本人外部节点，就能够实现 ref 的透传了！
      • useImperativeHandle，常与 forwardRef 搭配应用，能够管制向父组件裸露的属性以及办法，第一个参数即为 forwardRef 包裹后失去的父组件 ref 实例.
    • useMemo与useCallback
  • Hooks思维, 比方Vue3的新API, 社区React生态也在纷纷拥抱Hooks思维, 比方下面提到的的React-Redux的useSelector和useDispatch, React-Use还有Umi-Hooks等等.
  • Node的Cluster模块, 主从模式, 底层的Libuv.
  • CI/CD.
  • 埋点, 次要是以GA为代表的一键式埋点计划, 以MixAlpha/神策数据为代表的可视化埋点等.
  • 测试, Jest/Enzyme/Puppeteer编写单元/集成/E2E测试.
  • Flutter.

五面

五面的面试官可能比较忙, 因而整个面试过程大略就二十分钟左右. 以本人的经验为主, 如果你是独行侠, 也能够讲一讲本人在社区的奉献等等, 不要间接说你喜爱独来独往一个人全干.

HR面

这一面就是常见的问题啦:

  • 大学问题
  • 兴趣爱好
  • 有没有女朋友 俩人当前的职业规划
  • 集体职业规划
  • 成就感
  • 团队合作经验
  • 从小到大比较顺利还是崎岖(?)
  • 为什么学习前端
  • 手上有别的offer吗
  • 为什么想来阿里, 当然是因为阿里是前端的宝地了

这些问题比拟主观, 为了防止误导我就不讲啦

总结&将来前端瞻望

对将来前端的瞻望是二面问到的问题, 我集体的想法次要分这么三点:

  • 多端计划, 随着5G的倒退, 物联网设施也在逐步成熟, 到时候前端程序员要适配的屏幕可能又多了几种? 我感觉将来可能会呈现真正的多端解决方案, 即更全面的Rax或者Taro, 真正的一次编写处处运行. 当然现实是好的, 在它还未乘着七彩祥云到来前, 还是分心学好每一端吧~
  • 侵入后端, Serverless无疑是前端仔的下一个风口, 它给予了咱们向后端进发的能力, 让咱们"本人和本人联调", 也无需操心本人写的服务被流量打爆掉. 后端同学则可能解放出来, 去做一些更有意义的事件.(真的不是抢饭吃)
  • 智能化, 尽管当初到处都是赋能这个概念, 然而我还是感觉, 前端的终极之一就是赋能其余岗位, 让经营可能本人搭本人想要的流动页, 让产品爸爸本人选要对哪些控件/事件/指标进行埋点, 让不想从零学前端的后端间接拖拖拽拽配一个界面进去, 还有就是前端同学, 间接设计图生成UI代码(梦还是要有的). 尽管当初业界曾经有一些计划, 但都还存在着或多或少的问题. 这也是我最感兴趣的方向之一.

只能说面试真的是很玄学的货色, 如果每一面都能遇见和你相当合得来的面试官, 那整个面试流程真的会很轻松愉快。春招逐步靠近序幕, 也心愿大家都能拿到本人称心的offer！