自我介绍+项目

自我介绍

1.自我介绍
2.快手实习
- 难点：上锁函数 + 防抖函数结合
- 亮点：技术选型
Uber实习
- auth0 原理

1.自我介绍

（乖巧，听话的声音）
好的，面试官你好。我是一名前端开发工程师，叫李小菲，目前是英国诺丁汉大学计算机科学专业的研究生，也是快手商业化部门品牌广告小组的前端开发实习生。

在前端领域我有幸获得3段前端开发实习机会，在实习的过程中，我经历了完整的开发流程（技术方案评审、排期、开发、联调、测试、上线），做过技术选型、第三方库的调研、封装hooks、写组件供同事用、页面开发等工作，我深入了解浏览的工作原理、事件循环、Dom事件流、存储与缓存、知道如何做前端性能优化、以及前端安全性相关知识，我最近经常使用的技术是react与TS，Vue也会使用，但是很久没用了。

在当实习生的这段时间，我经历了很大的心态转变，从学生转变成能独立承担企业项目开发的职场人，也明白了在职场大家不太关注把事做成的过程，大家更关注事情的结果。

除了我的技术能力，我也非常注重自己的沟通能力和团队协作能力。我在团队中很乐于分享我的想法和经验，我也曾担任过项目组长的角色，第一次是2020年做了一个基于计算机视觉的智能无人机项目，获得了中国大学生计算机设计大赛的国家级二等奖，第二次是我2021年与我的小组成员一起完成了基于Echarts与Vue的疫情数据可视化平台，也拿到了中国大学生计算机设计大赛的国家级三等奖。拿到了专利申请。

最后，我非常感谢您抽出时间来面试我。我希望能够有机会加入xxx公司\团队，把我学习到的这些知识应用在实际企业项目中。

2.快手实习

难点：上锁函数 + 防抖函数结合

Situation (情境)：
你被分配到一个任务，需要在品广平台的售前系统中实现一个营销案例卡片组件和详情页。这个功能目的是为潜在的广告主提供优秀的营销案例展示，推动销售并缩短广告主的犹豫时间。
Task (任务)：
你需要设计和实现一个响应式的营销案例卡片组件，这个组件应该能够展示图片、文字、链接、视频、文档等多种内容。同时，还需要一个详情页，用户可以点击卡片查看具体的营销案例详情，其中包括图片、视频和PDF预览。你只有11天的开发时间，并需要确保最终的组件可以在移动端和桌面端都有良好的展示效果。
Action (行动)：

响应式设计：你利用@media、flex和%的组合来实现了响应式设计，确保了组件在各种屏幕大小上都可以良好地展示。
上锁函数实现：为了避免用户在PDF下载过程中频繁点击下载按钮，你首先尝试使用了防抖函数，但发现这并不适用于当前的问题。于是，你参考了小组成员的建议，设计并实现了一个上锁函数。这个函数能够确保在异步函数（如PDF下载）执行期间，用户不能再次触发这个函数，直到异步函数执行完毕。状态管理优化：在实现上锁函数时，你选择使用useRef而不是useState来管理函数的执行状态，因为useRef的状态改变不会引起组件的重新渲染，从而提高了性能。

Result (结果)：
在规定的时间内，你成功完成了这个需求，并且成功上线。最终的组件在移动端和桌面端都表现良好，稳定运行，没有出现bug。截止9.20，售前工具pc+移动端总 PV访问7130，UV访问3927。这个项目最后的质效指标：前端投入5人力，合计54PD，冒烟通过率100%，线下bug数 16个，千行bug率 PC端 0.16%=27/17130，移动端 0.1%=16/16428

亮点：技术选型

Situation（情境）:
我的需求是，在品广平台（品牌广告平台，帮助广告主在快手客户端app 上投放广告）上，我们需要一个营销案例组件，展示广告的预览效果和优秀的营销案例，能够同时预览图片和视频。并且要确保这个组件在各种设备和浏览器上都有良好的表现，特别是在移动端。

Objective（目标）:
主要目标是找到一个解决方案，使得我们能够同时展示视频和图片，并且在移动端有出色的触摸响应效果。同时，我们还需要扩展该组件，添加显示图片介绍的功能。

Action（行动）:

对多个流行的开源库（如 Lightbox、FancyBox 和 Viewer.js 等）进行了深入研究和对比。
考虑到移动端的特殊要求，尤其是触摸事件响应和图片双指缩放功能。
最终选择了react-photo-view，并使用了高阶组件（HOC）来对其进行扩展，添加了显示图片介绍的功能。

Result（结果）:
成功完成了PC端的需求，后面移动端的开发在图片视频预览这块也相当顺利，PC并且已经上线并稳定运行了一个月，移动端稳定运行半个月。在整个开发过程中，我只出现了两个bug，并且在组内是少数。这得益于我们对技术选型的仔细考虑以及对代码的自测和调试工作。这是我的成绩与亮点

Uber实习

刚进入Uber进行实习，在新人培训期间接触了PWA技术，我实现了一个TodoList PWA应用，PWA应用是一个类似原生APP的浏览器应用，它可以实现离线访问、系统级别的消息推送、后台数据同步等功能

它在第一次加载后可以实现离线访问、提供系统级别的消息推送(定时提醒功能)、后台数据同步功能

实现离线访问使用了，缓存Cache、IndexDB、service worker请求拦截
系统级别的消息推送：Notification API
后台数据同步功能：使用了Service Worker的Background Sync功能进行后台数据同步

在实现这些功能的过程中，我遇到了一些难点：

我在实现后台数据同步功能的时候，使用了service worker和Background Sync来实现

Background Sync 是一个允许在网络恢复后进行延迟操作的Web API。这意味着当用户处于离线状态或网络连接不稳定时，应用程序仍然可以完成某些操作（例如发送数据：存储在本地数据库中），然后等待网络连接恢复后再实际执行这些操作。这种技术通常与 Service Worker 一起使用，以实现更复杂的离线功能和性能优化。

在实现后台数据同步功能的时候，可能会遇到网络不稳定导致的同步失败，需要等到下一次 sync 事件自然触发来尝试重新进行数据同步。这种情况下，如果用户或应用没有再次触发 sync 事件，那么数据同步可能会长时间得不到处理。

为了解决这个问题，我需要去实现一个重试机制在操作失败时自动尝试重试操作。

首先，我在service worker文件中，配置了一些重传机制的基础变量，比如已经重试了多少次、最大重试次数、两次重试之间的时间间隔默认2秒，定义一个异步函数，使用try catch，向服务器发送同步数据的请求，如果成功则重制已经重试了0次。失败则使用setTimeout定时器重新发送同步数据的请求，使用默认时间间隔。我这样做是为了在短时间内尝试多次，如果问题是暂时的，那么很快就能恢复。

但是，在实际情况中，并没有这么简单，用户发送数据同步请求失败经常是在网络不稳定的时候或服务器过载的时候，高频率的重试可能加重服务端的负担和网络拥塞，这个时候如果单纯将默认间隔时间设置得更长，那就会造成等待时间过长，同样影响数据同步的速度。

最后我是使用了指数退避策略来优化了重传机制指数退避策略在每次失败后都会增加等待时间。这通常是通过将等待时间与2的重试次数次方（或其他基数）相乘来实现的。

const delay = Math.pow(2, retryCount) * 1000;

在这个例子中，第一次失败后，程序会等待 2^0 * 1000 = 1000 毫秒，然后是 2^1 * 1000 = 2000 毫秒，2^2 * 1000 = 4000 毫秒，以此类推，直到达到 maxRetry。指数退避通常更适用于网络不稳定或服务器过载的情况，因为它给系统更多的时间来恢复。

，因为它给系统更多的时间来恢复。而普通的重试机制则更简单和直接。

指数退避策略（Exponential Backoff）是一种错误恢复机制，用于自适应地调整两次重试操作之间的等待时间。该策略的核心思想是：在遇到失败时，不立即进行下一次尝试，而是等待一段时间后再重试，并且每次失败后都会增加等待时间。等待时间通常是指数增长的，例如2的n次方乘以一个基础的延迟时间。
样做有几个好处：

减少网络拥堵：如果服务暂时不可用或网络状况不好，立即进行下一次尝试可能会加剧问题。指数退避通过增加延迟来减少网络请求，降低了进一步拥堵网络或压垮服务的风险。

自适应：如果第一次重试失败，那么可能需要更多的时间来解决问题。指数退避通过延长等待时间来给系统更多的自我恢复时间。

提高成功率：通过给系统更多的时间来恢复和减少网络负担，指数退避策略可以提高重试请求的成功率。