乐趣区

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

jiezi

前言

工夫过得很快，好像 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！

退出移动版