0


2024年前端真实面试题集合(前端面试关注我就够了)

前言:

    从2024年1月初到2月底为止,由本人伪装其他经验段去面试收集的来。面试城市在昆明、贵阳。前后一共差不多20家。其中三家大公司,其他都是中小型公司。拿到的offer薪酬也不是很理想,有几个规模比较大,比较理想的公司也是平薪甚至降薪拿到的offer,当然跟我本人自身的三脚猫功夫有关。

    整体大环境不是很友好,特别卷,各位靓仔靓女简历里的项目尽量不要带有电商系统,后台管理系统的字眼,很多hr,面试官看到3年经验,项目是某某电商系统,某某后台管理系统直接就否了。

面试技巧

** 这方面没有一个非常官方的标准答案,每个公司规模政策都不一样,因地制宜才算经验,才能体现能力。也没有什么一两句话就可以让实力突飞猛进的技巧,所以我也放在了最后。总结了一些要注意的点。**

    1、回答问题时候,思路要清晰,不要扯蛋说了半天说不到重点,这里需要提前准备一两个项目,优缺点,为什么这么做,解决什么问题,达到什么效果等等,然后不断优化文案。

    2、面试(二面,非技术面)的最终目的是进行画像,比如对你入职后能胜任什么工作,积极性,能给团队带来什么贡献,所以这方面回答,根据公司情况表达出你的善于沟通,技术能力,效率高,并且稳定就可以了。不要太浮夸,适当表现出真实情况,可以用想要稳定的工作,买房等拉取亲近感。记住面试官也是人,不要害怕!要自信!
如何在面试中转场,跟面试官聊起来
    可以在回答问题得时候侧面吧要想要传达的点表达出来。常用公式就是:比如我的xxx,举个例子:xxx ,我说个实际项目的例子xxx。比如面试官问你是怎么解决问题的时候,除了阐述如何解决问题还可以衔接比如我做xxx项目时候,我一个人推动的,就遇到了xxx问题,我就通过这种办法解决。(这时候你就可以把你想要表达的执行能力很强等优点给侧面传达出去)
如何更好的表达出积极性很高
  • 可以介绍你项目的时候可以讲,xxx项目是我一手推动的,因为我发现了什么什么问题,这样做可以零代码交付减小开发成本
  • 某某项目立项,需求审批的时候,我会站在用户的使用角度去考虑,而不是100%听从产品,比如xxx例子
  • 谈到未来规划的时候,可以讲管理或者技术方面,这时候主动提及,比如,我在技术,架构支撑是够的,质量监控,自动化测试都是我这边主动推进的(这里就表达出了执行能力,技术能力都可以),在这个过程中我发现挺适合做管理/技术负责人,我发现我小团队更多注重性能、体验、效率,但我深⼊去思考时发现,了解业务,了解商业价值,转换⻆度思考这方面比较缺乏(自身优缺点也可以这么回答的)。
如何表达未来规划
  • 这里我个人推荐你表达出做个小组长,比较灵活,既透露出热爱技术,又可以做小管理。
  • 我想做前端小组长,因为我目前自我觉得我处于优异的执行者,目前所在瓶颈是怎么成为团队核心,比如怎么通过影响和带动他人,帮助团队获取更多成果。然后也想找个稳定的工作,有计划买房,供房(这些就结合实际情况看着回答了)。
判断公司需要什么类型的人
  • 从团队规模人员判断,一般规模越多,真正管理岗位越小,最多是个组长之类。然后问前端,后端,测试,产品数量。比例如果在2:3:2:1左右适合,如果1:3:1:3较忙。然后聘应岗位会做些什么工作内容,如果是日常开发,版本迭代就相对还好,如果是根据业务线,友方项目(理解成外包之类,很多公司不是外包但其实是外包的性质)这种可能较忙。如果是根据项目去安排人手,这公司一般会忙些,一个萝卜一个坑,这时候他们需要是高机动性,高积极性,最简单,比如做完事情会主动上报,并且寻找有没有其他事情做。
  • 如果是分业务线管,并且部门前端3个左右,产品是2个,后端是4个左右,他们需要的是有一定质量的搬砖仔或者需要一个领头人,这种情况可能更适合你
  • 招聘的是否是猎头,如果是猎头,这个岗位大多数情况会比较忙。这种情况公司规模是中偏大型,但管理,项目之类的大多数比较混乱的。最好问清楚先
  • 可以直接问HR,晋升机会,福利这些来判断公司管理是否混乱。如果回答的头头是道,并且语气挺期待自信的,一般是ok的。反之
表达自己优秀的万能回答
    我目前自我觉得我处于优异的执行者,目前所在瓶颈是怎么成为团队核心,比如怎么通过影响和带动他人,帮助团队获取更多成果。一些名词可以根据情况替换,比如团队核心,可以替换成技术支撑等

自我介绍:

需要传达的内容:

  • 基本信息:你叫xxx,xx毕业开始做前端,做了多少年
  • 职业经历:我在xxx、xxx公司(一线互联网大厂)呆过,选择在xx公司担任高阶(前端);

技术特长:

  • 对xx方面特别感兴趣 or 擅长,曾经做过xxx技术项目(轮子、性能优化、解决过复杂问题);
  • 当下在做什么,特别擅长的点
  • 核心:简单明了,把基本情况和核心竞争力传达清楚

怎么突出重点,让自己更有吸引力

  • 一线互联网大公司:字节、阿里、腾讯、shopee等
  • 有技术深度的经历:性能优化、解决疑难杂症、优质开源项目作者、有深度的技术博客/分享
  • 性能、稳定性、开发效率提升
  • 重要业务冲刺 owner

避免

  • 事无巨细,抓不到重点
  • 平淡如水:
  • 逻辑混乱

举例:

    面试官好,我叫汤姆丁,拥有3年前端开发经验,其中有将近2年带团队经验。是实干型开发选手,vue/react等主流前端框架业务开发是完全没有问题的。node,python搭建简单的服务端写接口也是没问题。node的话使用egg,Sequelize(斯Q奶)。python的话用flask这些框架开发服务端。目前工作约20%左右在团队管理上,80%左右还是业务开发。技术上较大的成果就是,把公司业务梳理一遍,使用微前端重构。团队管理上除了技术规范,还有文档沉淀,每月复盘,提测规范等等这些流程的完善。
如何做优化
    除了常规的资源优化,体制压缩,gzip,懒加载这些,让可以在nginx那开通一下http2,还有根据业务做一些缓存,使用indexdp。其实这些难就难在怎么定义指标,进行业务,代码逻辑层面的优化,才是难点。我初步是打算Lighthouse配合 sentry 来指定一个流程。比如首页多少秒打开合格,弱环境下要多少秒等。如果有动画是要多少帧等,因为帧数是关电脑hz的,跟配件有关。
vue双向绑定原理
    Vue采用数据劫持 结合 发布者-订阅者的方式来实现数据的响应式,通过Object.defineProperty来劫持数据的getter、setter,在数据变动时发布消息给订阅者,订阅者收到消息后进行相应的处理,通过原生js提供的监听数据的API,当数据发生变化的时候,在回调函数中修改DOM。 

缺点:

    一次性递归到底开销很大,如果数据很大,大量的递归导致调用栈溢出、 不能监听对象的新增属性和删除属性 无法正确的监听数组的方法。要使用$set
vue2和vue3的区别
    除了语法,api,比如setUp,最大的不一样就是双向绑定从vue2的defineProperty改成了proxy,可以监听数组了,弊端是ie8之类的低版本兼容问题
什么是闭包
    闭包本质还是函数,通俗来讲就是把操作函数暴漏出去,然后细节放在内部。避免污染,增加安全性。简单举个例子,函数a里面定义一个函数B, 外部一个变量引用了函数A,就创建了一个闭包。现在很少用了,因为会占内存,用不好还会造成内存泄漏。比如vue中的数据劫持observer就用到了闭包
原型链
    他的本质还是对象,但是呢有个上下文,是用他来创建私有变量拿数据的,不同地方调用方法,this.xx就拿上一个。继承等等。反正这么处理的根本原因还是不想做全局污染。因为现在mvvc框架原因,业务上很久没有单独处理过这个了。
vue性能优化
    除了常规的懒加载,还有keep-alive缓存组件。更多需要多使用函数式组件,还有不要设计太深的响应式数据。组件的颗粒度不能设计太细.,v-if-for不要同时使用。
vue计算属性和watch
    computed有缓存功能拿不到this,watch主要是监听data里面的定义的量多个属性影响一个属性时,建议使用 computed。 价格,根据订单数量,优惠券等,显示价格当某个值发生变化,引起一系列的业务时,建议使用 watch。 比如input搜索,请求接口(记得做防抖),渲染列表。就可以监听input Value值。
vue3增加了哪些特性
    vue3整体下来感觉更贴进react那种了,比如定义数据使用ref,不再用this.data 还有setpup可以划分逻辑,也支持jsx了
React如何避免重复渲染(如何优化)
    以前用shouldComponentsUpdate里面做判断,return false等。现在基本用hook,useMemo。useCallback。

    useMemo场景:父的state变化,用useMemo可避免子重复渲染
用useCallback这个函数重新生成了的话,子组件会不会重新渲染
    会,让他不会的就用useRef作为useMemo的依赖
UmiJs和dva、roadhog是什么关系?
    roadhog 是基于 webpack 的封装工具,目的是简化 webpack 的配置 umi 可以简单地理解为 roadhog + 路由,思路类似 next.js/nuxt.js,辅以一套插件机制,目的是通过框架的方式简化 React 开发 dva 目前是最纯粹的数据流,和 umi 和 roadhog 之间并没有相互的依赖关系,可以分开使用也可以一起使用。
React 中 keys 的作用是什么?
    住要是避免重复计算,增加性能。因为react用到的是diff算法,吧树形结构按层级分解,只比较同级元素。所以列表,循环时候要给个key。
react diff 原理
    把树形结构按照层级分解,只比较同级元素。所以需要给列表结构的每个单元添加唯一的 key 属性,方便比较,节约性能。基于这个,开发的时候可以重写 shouldComponentUpdate 提高 diff 的性能。当然现在大部分是使用useMemo。useCallback。去优化了。
React.Children.map和js的map有什么区别?
    JavaScript中的map不会对为null或者undefined的数据进行处理,而React.Children.map中的map可以处理React.Children为null或者undefined的情况。
React高阶组件
    高阶组件本质还是组件,只是一个包装了另外一个 React 组件的 组件。可以通俗理解成,一个函数里可能有好几种组件。这种形式通常实现为一个函数,本质上是一个类工厂。运用场景,多个组件都用到同一段逻辑时候,就需要吧共同逻辑提取出来,利用高阶组件的形式将这段逻辑整合到每一个组件中, 从而减少代码的逻辑重复 。

    需要代码重用时, react如果有多个组件都用到了同一段逻辑, 这时,就可以把共同的逻辑部分提取出来,利用高阶组件的形式将这段逻辑整合到每一个组件中, 从而减少代码的逻辑重复 。又或者需要组件增强优化时, 比如我们在项目中使用的组件有些不是自己写的, 而是从网上撸下来的,但是第三方写的组件可能比较复杂, 有时不能完全满足需求, 但第三方组件不易修改, 此时也可以用高阶组件,在不修改原始组件的前提下, 对组件添加满足实际开发需求的功能
哈希和非哈希的区别
    有井号没井号,一个是用window里面的pushState一个是用onpopstate做进退
箭头函数
    好处就是不用管this了,谁调用就是谁的上下文,不能使用new,没有arguments,也没有原型和super等等。
重绘与重排的区别
    重排:渲染树中的元素结构,尺寸、属性这些发生改变时候,浏览器就会重新渲染。

    重绘:页面某些元素发生变化,浏览器就会对元素进行重绘,比如background这些。如果是opacit既出发重排也出发重绘
强缓存和协商缓存
    强缓存就是根据header的字段,Expires和Cache-Control来判断是否过期再请求服务器,坏处就是服务器更新了,如果还没过期就会主动请求。而协商缓存就是从服务器判断是否重新请求。前端你可以在头部meat标签设置,多少秒刷新文档等。作用就是对http请求缓存,减少请求次数,达到优化效果。
防抖/节流
    防抖:让 事件 在触发后 N 秒后执行,如果在 N 秒内重新触发,则 重新计算 时间。input的搜索等

    节流 : 在规范时间内,只能触发一次函数,如果多次触发不会执行。比如支付按钮等。
事件循环Event loop, 宏任务、微任务
    浏览器的事件循环:执行js代码的时候,遇见同步任务,直接推入调用栈中执行,遇到异步任务,将该任务挂起,等到异步任务有返回之后推入任务队列中,当调用栈中的同步任务全部执行完成,将任务队列中的任务按顺序一个个推入执行,重复执行这一系列的行为, 异步任务又分为宏任务和微任务。

宏任务: 任务队列中的任务称为宏任务,每个宏任务都包含一个微任务队列

微任务: 等宏任务中的主要功能都完成后,渲染殷勤不急着去执行下一个宏任务,而是执行当前宏任务中的微任务

宏任务包括:执行script标签内部代码、setTimeout、ajax请求

微任务包括:pormise、MutonObserver、Object.observer

创造promise实例后,它会立即执行,有等待,失败,成功
严格模式的限制
  • 变量必须声明后再使用
  • 函数的参数不能有同名属性,否则报错
  • 不能使用 with 语句
  • 禁止 this 指向全局对象
数组去重
  1. 1.利用双重for循环,再利用数组方法splice方法去重(es5常用)
  2. 2.set去重:准备一个数组,数组解构newset,再准备一个函数存放数组的变量作为函数的判断值,return
  3. Array.from(new set(arr))即可
  4. 3.数组方法indexof
  5. 4.数组方法sort Obj[a]-Obj[b]
跨域
    最稳妥最常见的就是服务器开允许访问。剩下就是jsonp,现在很少了每个接口都需要特定处理,一般都用反向代里,proxy这些。我们目前是采用node中间件进行转发。跟nginx反向代理差不多。当然C端的项目原则上是不允许跨域的。而且生产环境也是全部关闭,安全性问题。真需要跨部门也是通过接口去处理,比如小程序内部打开h5进行下单之类

如何管理团队等

    其实我觉得最大的困难有亮点,第一人才培养,第二就是达成共识。第三文档沉淀。1和3都很好理解,字面意思。第二点达成共识呢,我举个理想的场景。整个团队大家都有明确目标,然后一起使劲往同一个方向前进。又比如领导有需求下来了,大家能明白这个需求的意义,而不是单纯的完成任务。大概就是这种感觉。

我为了完成上面三个几个目标,做了以下几个措施:每月(项目)复盘,多写注释,拆解需求。复盘包获代码量,还有收集遇到的问题,还有一些技术方案收集。当然代码量不是越高越好,越高就证明复用性可能没做好就帮忙深入去看看。因为组员性格情况可能不同,所以这些可以线上进行。然后再整理一下变成文档沉淀下来。踩过很多坑,分享啥的,最后组员都不积极,采用这种,然后偶尔写写文章。当然根据每个人性格采取

然后就是需求拆解了这个,举个最简单的例子,产品那边的需求不单单是怎么做怎么做,整个项目有背景的需要说明,然后我会协助拆解成任务,比如登录页,为什么用短信短信验证码,为什么使用按钮要隐藏起来,因为我们只想要客户买,不想让他用等等。当然是极端例子哈,一些简单常规的肯定不讲了。这样拆分后呢,时间评估就准很多了,因为所有都有个对比,比如登录页一天,商品列表页更简单应该半天就好等等。效率自然就高了。

当然还经历很多,都是一个大前端团队去接任务,后面慢慢改成分成业务组,当然这些我一个人肯定处理不来,需要总监他们协助。反正很深的感悟就是,这些没有标准答案,也没想像中发发任务,故时间,开分享会这么简单。要因人而异,因地适宜

为什么要微前端重构项目

因为之前公司好几个后台管理系统,每个管理系统都有相同的功能,这样维护起来费时费力,所以我重新梳理了业务逻辑,使用react/umi搭建项目,利用git submodule去维护跨项目之间共同的代码方法。使项目更清晰明了,维护成本大大降低。

微前端遇到了什么问题
  1. 图片资源丢失,在子应用部署到服务器后,他的路径是找在基座上面的。所以会丢失,采用,base64,太大就网络图片形式
  2. 路由跳转,子路由跳子路由,后面做了路由的守卫,统一封装了跳转方法,采用了基座那里存起来的history.push 等等
  3. 数据的传递,跨modal之间调用。利用window
做了哪些亮点:

最大得亮点还是在业务梳理,推广微前端这个。遇到

  1. 配合git submode 抽离很多带业务的页面,方法,样式等。跟组件不同,他是带有很多业务的,会有请求后端接口的一些逻辑。
  2. 文档的收集,每周收集便利的,和踩过的坑,有分享会演变而来

如何实现拖拉拽生成活动

核心原理使用react-dnd这个,然后呢一开始的理想是很丰满的,颗粒度非常小,后面越做阻力越大,比如一些层级,如果用定位的话,不好维护。最后是我们跟产品制定好规则,分两一种,一种是页面模板,一种是组件,比如banner,导航栏,可以选择样式类型,然后自己拼成页面,导出来的是一个数组,如果需要后台会生成对应代码,单独部署,就是先去仓库拉去模板代码。然后利用node-fs编写配置文件。再把整体项目打包出来,或者根据钩子,生成到gitlat上。这种场景多半用于需要单独部署维护的项目,比如是某个客户买了我们产品。需要独立部署

工作中最大的瓶颈

其实还是需要回到人才还有达成共识上面,我做的每月复盘,都是曲线救国,如果他本人不愿意或者摆烂的,就需要指定好情况,当他当作单一的生产单位。然后怎么让技术部门逆推去推动商务,就是赚钱。

技术上面的话因为不是开发框架又不是手撕底层原理这种,相对棘手的还是类似指定性能优化这种需要根据业务制定,但市场又没有很完善很开源的产品。这种就比较复杂。

------答案2适用于非管理------

我个人执行力还有业务开发是完全没问题的,目前的瓶颈在于怎么把个人的能力扩散到团队中,影响和带动他人,为团队带来更多结果和更高收益。

低版本的兼容

app: 19还是20年把,setupWebViewJavascriptBridge ios升级,要区分安卓或者ios特殊处理,低版本兼容。

A标签包裹图片,不用A标签的href跳转,点击事加进行window.location.href跳转没出发

前端安全:

一般攻击手段有xss,csrf,DDoS.xss现在较少了。一般就行方等严格项目有要求,我们都是用转义方式来避免xss攻击。csrf得话采用token,DDoS是服务器那边得,一般采取ip禁止

标签: 前端 面试

本文转载自: https://blog.csdn.net/2401_82552544/article/details/141056763
版权归原作者 泛微集团小王 所有, 如有侵权,请联系我们删除。

“2024年前端真实面试题集合(前端面试关注我就够了)”的评论:

还没有评论