金三银四你是否已准备好！这份阿里淘系前端-实习面经助你成功

前言

时间过得很快，仿佛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！