常见的前端面试提问方式和题目

前端面试的时候，有些面试官其实并不是特别注重面试题目的答案，更多的是以平时开发的一些方方面面去延升，既能确定对方的工作经验是否真实，同时又可延伸去询问一些技术方面的问题，还能确定面试人员是否有自主探索学习的习惯。我接下来举几个常见的切入点去模拟

一、生态方面

这里设定两个角色 a:一线开发  b:开发兼小组长

1.你在工作中扮演什么样的一个角色？

a:纯业务开发

b:前端小组长

2.你平时的工作中是否涉及发布和部署？

设计或者不涉及

3.你们部署一般用的什么工具？

静态资源:ares

node服务:captain

4.能大概讲解一下这些工具的原理吗？

ares:

打包:git接入pipelines之后,在captain上设置流水线job,具体job内容是内置的,使用者只需要提供以下参数:group、aresName、verson就行,流水线执行到ares时,ares平台就会在对应的项目版本的测试环境生成静态资源包,并且托管在ares平台

接入:ares有个ares-agent包,提供初始化api,可以根据group、aresName、verson去返回对应的静态资源列表,均为src链接,可以使用script标签去拉取静态资源.

captain

常规的部署平台,包含集群镜像等管理

5.如果你们平时发布之后出现了一些线上问题一般会怎么解决？

高优紧急的问题,先回滚再定位,尽早修复.低优的初步定位,再决定是否回滚,后续安排修复.

6.这类环境问题你们大概得排查方向是什么？会使用哪些工具或者网站

部署是否符合期望:看captain平台发布的是否最新镜像

静态资源版本是否正确:看ares的版本是否上生产,和release代码上的版本是否匹配.进一步确认页面上的静态资源是否在ares静态资源列表里.

接口数据是否符合期望:确认前端代码符合期望,再看看接口返回是否正确,确认后端代码发布完成了.

堡垒复现:堡垒环境尝试复现.

测试环境复现

代码分析

 

二、开发习惯方面

1.你们平时开发中有哪些代码规范？

接入了公共的eslint组件,大致的规范有

a:如果变量未被重新赋值,必须使用const而非let

b:未使用变量必须删除声明

c:声明必须在使用之前,不可先使用再声明

d:map函数必须所有分支都有返回

e:不允许空函数存在

等等

2.你们开发过程中有哪些为了提升性能做的优化？

a:图案能使用ico就不使用图片

b:图片使用会进行压缩,具体压缩方案有公共的方法

c:静态资源能分开拉取就分开,比如shark等

d:减少页面刷新,尽量使用局部刷新

3.你们平时如如何关注自己项目的性能？如何判断性能是否优越？

最主要的方式是tti监控面板,前端开发过程中会进行tti埋点,具体的方案也是由公共提供,大致原理就是在路由加载时给window添加一个renderTime,记录当前页面的几个关键节点,关键接口调用开始,关键接口调用结束等,然后根据时间差计算ttis的数据.这些埋点会记录在ck表中,再通过hickwall平台通过配置去获取表中的数据生成一个可视化的表.简单通过图表的表现就可判断出,初始化复杂的页面时间可以稍长,简单的稍短.

4.如果工期比较紧张的情况下，如何做到兼顾性能和需求？

优先需求,但是会跟产品同步一下隐患,考虑折中的方案,代码设计的时候可以为未来留一点槽口.比如有个列表页面,接口方的接口并不支持分页,而且支持分页需要超出需求的时间,那结合实际需求,数据并不会太高,用户体验不会太糟糕,那可以先不分页.但是前端开发过程中可以考虑时间是否充足,如果时间充足,可以考虑前端分页(js分页或者第三方工具,比如table),时间不足的情况下可以按分页的方式来,只不过pageSize为99,这样后续只需要修改pageSize就行

5.如果我们这边对一个文件的代码量有要求，你会怎么去设计自己开发的代码？

从大到小的拆分,这个页面能分几个模块,每个模块能拆几个组件.哪些组件可以拆成纯ui组件和业务高阶组件,哪些方法可以拆成公共的.通过这些细分,可以将原本一个文件的代码拆成多个,同时提高了代码的复原性.

 

三、具体的案例

1.你在工作做你觉得遇到的最棘手的问题是哪个？

app内,A页面跳转到B页面之后,B页面再跳转C页面,C页面再通过头部的自定义返回键返回B页面,B页面再通过手势返回返回时还是B页面.

2.能讲讲你是怎么一步步排查和解决这个问题的吗？

1)结合mpass用户足迹查询,查看用户的每一步访问的页面,符合用户的描述

2)尝试复现,通过尝试,发现只有app内有这个问题,h5页面没有这个问题.

3)结合mpass中记录的埋点分析,B页面的返回确确实实得执行了,而且区分了h5页面和app内的埋点,发现主要区别在于app内的手势返回的触发

4)向app的对应开发请教,一同排查.得知app内手势返回会有不同的逻辑,手势返回会优先判断当前webview是否有上一页,有就返回上一页,没有就关闭当前webview

5)基于手势返回的逻辑,开始梳理整个流程的跳转方式已经webview和页面的场景得出了最终结论.C是独立的webview并且返回B并非返回而是replace,所以app内手势返回会关闭当前webview回到上一个B的webview

6)解决方案:app的开发加一个地址拦截,因为b页面是一个聚合页面,很多页面最终都有返回该页面的操作,所以app内加了拦截,凡是跳转到B页面的操作均被拦截,并且app会关闭所有B页面之后的所有webview,返回最早的那个B页面的webview.

 

3.遇到这类问题后你们有后续的预防方案吗？

1)加强与app开发和公共组的沟通,相关的api或者功能的实现,先初步与他们沟通再决定方案.

2)遇到的case会被记录下来,后续开发会结合之前的case进行预检.

 

四、组织与架构

1.你们团队一般多少人？多少前端多少后端

 

2.你们是怎么安排联调的？假如后端的时间与前端错开了，怎么联调更合理？

前后端开发时间分开安排,但会约定联调时间.同步建相同时间的联调任务.

3.如果测试同学因为某个bug与你产生了冲突，你该怎么解决？

先结合prd和设计稿确认是否有被提及,如果该部分内容没有提及,则需要和产品明确该bug归属,如果明确为开发bug,则开发与产品和测试一起明确优先级,优先级高则建bugfix优先解决.低则跟随迭代一起修复.后续和测试约定按该流程去讨论.

4.如果产品在验收过程中觉得实际上的内容并不能达到他的期望，该怎么解决？

需要明确是功能上还是视觉上,如果是视觉上,则提议与设计同事一起提一些需要优先修复的视觉bug,可以紧急修复这些bug,直到产品满意.如果是功能的bug,则需要拉上测试前后端开发一起,讨论到底是哪部分不符合期望,再评估紧急修复的成本,最终由产品拍板是紧急修复还是新建优化需求处理.无论哪种不满意都需要复盘其原因.

5.怎么减少自身开发过程中的bug量？

1)需求和设计稿的确认要精细,不想当然

2)代码拆分要细化解耦,避免冲突,方便理清思路

3)重难点的实现方案最好能先有demo,避免中途换方案,压缩开发时间

4)评估代码影响范围,做足自测

 

大体上就是这些方向，有些时候，这些内容不会放在技术面中，一般是项目主管的终面，但也有些是在技术面中，以某个话题为切入点。当你回答的过程中冷不丁的问一个知识点，比如当你回答代码优化的时候，会问你一句，你知道哪些设计方案吗？工厂模式知道吗等等。最好还是能把自己可能会提到的点对应的知识点都复习一下。