字节-抖音短视频-社招-5年 on Last Stand

字节-抖音短视频-社招-5年 · 第 1 轮 · HR面

Sun, 27 Jul 2025 11:49:10 +0000

← 第 1 轮 · 返回本次面经 · 已是最后一轮 →

本轮共 10 道题。答案默认折叠，便于先自行作答。

1. 为什么选择前端，你是怎么学前端的，自学前端觉得比较困难的点

题目要点

真实表达学习动机和行业认知
清晰描述学习路径与方法，体现自驱力
主动总结自学难点及解决方案，展示解决问题能力
表现对未来成长的规划和期待

参考答案

考察点

● 面试官希望了解候选人的学习动机和成长路径

● 关注候选人对前端行业的认知及自学能力

● 探索自学过程中的困难及解决方案，反映抗压和问题解决能力

参考答案

一、选择前端的原因

技术的即时反馈与可视化强：前端开发可以快速看到效果，工作成果直观，满足感强。
行业发展迅速，应用广泛：随着互联网和移动端普及，前端技术需求旺盛，职业前景广阔。
结合设计与开发的跨界魅力：前端融合设计、用户体验和工程实现，工作内容丰富多样。
学习曲线友好，入门门槛相对较低：相比后端复杂环境，前端技术栈更容易起步。

二、学习前端的路径与方法

基础知识打牢：从HTML、CSS、JavaScript开始，系统学习语言和浏览器原理。
项目驱动实践：通过小项目练习知识点，逐步积累实战经验。
系统化学习框架和工具：深入学习 Vue、React、Webpack 等主流框架和构建工具。
参与开源和社区：通过阅读源码、提问和答疑，加深理解和扩展视野。
持续跟进新技术：保持学习态度，关注生态变化和新兴技术趋势。

三、自学过程中的困难及应对

1. 知识点多且零散

前端涉及面广（浏览器机制、网络、安全、UI等），容易迷失方向。
解决方法：制定阶段性学习计划，系统化梳理知识体系。

2. 理论与实践脱节

单纯看文档和教程，缺少动手操作，难以消化。
解决方法：边学边做项目，遇到问题及时查阅和总结。

3. 框架与工具更新快

框架迭代频繁，工具链复杂，学习压力大。
解决方法：关注核心原理，不盲目追新，重点掌握主流稳定技术。

4. 调试与性能优化难度高

浏览器兼容、异步机制、性能调优等问题复杂。
解决方法：借助调试工具，多阅读源码和案例，积累经验。

四、总结观点

选择前端，是因为它能快速实现创意、应用广泛且持续发展。自学过程中遇到知识面广、实践难和技术更新快等挑战，但通过系统规划和项目实践克服。未来希望通过不断积累，深入理解前端底层原理和工程化实践，成为一名全栈且有深度的前端工程师。

2. 对工作的期望

题目要点

略

参考答案

略

3. 成就感的点

题目要点

略

参考答案

略

4. 一二三面面试官给你的感觉

题目要点

略

参考答案

略

5. 看到你面试比较曲折，转了三个部门，你有什么感受，事后有复盘吗

题目要点

略

字节-抖音短视频-社招-5年 · 第 1 轮 · 三面

Sun, 27 Jul 2025 11:46:08 +0000

← 第 1 轮 · 返回本次面经 · 第 1 轮 →

本轮共 10 道题。答案默认折叠，便于先自行作答。

1. 自我介绍（注意与一、二面的差异化）

题目要点

略

参考答案

略

2. 请重点介绍一个你主导或深度参与的技术项目（非业务需求），如何从0到1推动落地

题目要点

明确项目是“自主发起”，解决了实际“工程难题”
描述了“目标-方案-过程-成果”四个完整阶段
有实际的“技术亮点”可以展开讲解（如 monorepo、适配抽象、构建工具链）
表达出清晰的“主人翁意识”与技术领导力

参考答案

考察点

● 面试官希望了解候选人是否具备“技术主导力”或“技术项目 owner”思维

● 重点考察项目选题是否合理、推进过程是否专业、技术方案是否有深度

● 了解候选人在“从问题识别、调研方案、攻克难点、团队协作、成果评估”全过程中的角色与能力

参考答案

一、项目背景与问题识别

在我负责的公司前端平台中，随着业务的扩展，多个产品线逐渐发展出自己的前端应用，形成了大量重复代码、组件风格不一致、工程维护困难等问题。尤其是在多端部署（H5、微信小程序、企业微信等）场景下，重复建设、逻辑差异、样式割裂等问题尤为突出。

于是我提出建设一套前端基础能力平台化方案，目标是实现：

通用组件与工具库的沉淀与统一
多端适配与平台差异抽象
支持微前端/模块加载的架构演进

该项目在初期并非“业务需求”推动，而是从开发痛点中主动识别问题、提出技术方向并推动落地。

二、方案设计与关键落点

✅ 技术目标拆解

组件与样式平台化
- 设计统一的 UI 规范（基于现有设计稿抽象）
- 使用 monorepo + lerna 管理组件库
- 使用 Storybook + VitePress 建立文档与调试系统
工具函数抽离
- 构建 @common/utils 包，提供统一的日期处理、加密、验证、网络库封装等工具
- 用 TypeScript + 单元测试保障稳定性
构建通用模板/脚手架
- 抽象常用项目模板：H5、小程序、纯组件库
- 提供一键初始化、CI/CD 脚本、lint规范、GitHook 校验等预设
模块注册系统设计

字节-抖音短视频-社招-5年 · 第 1 轮 · 二面

Sun, 27 Jul 2025 10:01:22 +0000

← 第 1 轮 · 返回本次面经 · 第 1 轮 →

本轮要点： CSRF攻击、https、浏览器的同源策略、浏览器的缓存机制、盒子模型、全方位解读this、call、apply和bind

本轮共 23 道题。答案默认折叠，便于先自行作答。

1. 自我介绍与项目介绍

题目要点

略

参考答案

略

2. 你在项目中如何优化首屏加载时间

题目要点

清晰解释首屏加载构成和评估指标
梳理优化方向：资源优化、加载顺序、渲染提前
结合实际项目列举优化措施及效果
提醒常见误区，展示对细节的把控能力

参考答案

考察点

● 首屏加载性能优化的全链路能力

考察对加载过程、资源调度、渲染流程等多维度的理解与掌握。

● 实际优化手段的选型和落地能力

考察对首屏加载优化策略在项目中的实际应用和效果反馈。

参考答案

一、首屏加载时间的定义与构成

首屏加载时间指的是从用户发起访问请求到页面关键内容（尤其是首屏可视区域）可交互的时间。
它包括以下几个阶段：

DNS 解析、TCP/TLS 连接
HTML 下载与解析
CSS/JS 加载、阻塞与执行
首屏组件渲染、资源加载与图片显示
浏览器首次 Paint 与可交互（First Contentful Paint / TTI）

二、常见优化策略与实战举例

1. 资源加载优化

Gzip / Brotli 压缩：减少资源体积
使用 HTTP/2 / QUIC：提升多资源并发加载能力
开启 CDN 加速：靠近用户，提高请求速度
精简依赖包：如 tree-shaking、移除未用依赖（如 moment → dayjs）

2. 首屏关键资源优先加载

Critical CSS 提取与内联：减少 CSS 阻塞渲染
示例：使用 webpack 的 critical-css 插件提取首屏样式并内联到 HTML

预加载首屏图片和组件

<link rel="preload" href="/assets/banner.jpg" as="image">


* **合理使用 `async` / `defer` 加载 JS**：避免阻塞 HTML 解析

#### 3. **首屏代码最小化（关键代码提取）**

* **路由懒加载**：非首屏模块按需加载

 ```js
 const About = React.lazy(() => import('./About'));
 ```
* **组件级拆分（如 webpack 的 SplitChunks）**：减少主包体积
* **SSR / SSG / 静态渲染**：预渲染首屏内容，降低白屏时间

#### 4. **骨架屏 + 占位图**

* 使用骨架屏组件在主内容加载前展示占位 UI

 ```html
 <div class="skeleton-loader">...</div>
 ```
* 提高用户感知速度，避免白屏

#### 5. **缓存策略**

* 使用强缓存（Cache-Control）与协商缓存（ETag）
* 使用 Service Worker 做离线缓存，提升重复访问性能

#### 6. **图片优化**

* 使用 WebP、AVIF 等新格式
* 小图 base64 内嵌、大图懒加载
* 多倍图压缩（如用 tinypng 等工具）控制首屏图体积 <200KB

---

### 三、项目实战效果举例（性能指标前后对比）

| 优化项 | 优化前 | 优化后 |
| ------------ | ----- | ----- |
| 首屏加载时间（TTFB） | 1.8s | 0.9s |
| JS包大小 | 1.2MB | 450KB |
| 首屏渲染（FCP） | 3.5s | 1.2s |
| 可交互时间（TTI） | 5.2s | 1.9s |

---

### 四、常见误区与陷阱

* **盲目使用懒加载**：过度懒加载会导致首屏核心内容延迟
* **未合理拆分 vendor 包**：导致主包过大
* **骨架屏布局不一致或闪烁**：影响用户体验

---

### 五、总结

* 首屏优化是系统性工程，涵盖网络传输、资源管理、组件拆分、渲染路径等多环节。
* 应结合业务场景按阶段优化，配合 Lighthouse/Chrome DevTools 实时评估效果。
* 目标是压缩关键资源、减少阻塞、加快首屏渲染并保障体验一致性。

</details>

## 3. 如何识别首屏关键资源 {#question-subjective-9bbab0275c1b}

### 题目要点

* 明确首屏关键资源的定义与分类
* 能列出识别方法：Performance、Lighthouse、Network、Coverage
* 能结合项目给出识别+优化的实际策略
* 有资源优先级调度、渲染阻塞等知识支撑

<details>
<summary>参考答案</summary>

### 考察点

#### ● 识别影响首屏渲染的关键资源<br>
考察候选人对渲染链路和性能瓶颈的理解。

#### ● 熟悉浏览器加载机制与资源优先级调度<br>
考察对 Chrome DevTools、Performance 面板等性能工具的使用能力。

---

### 参考答案

### 一、首屏关键资源的定义

> **首屏关键资源**是指那些**必须在首屏渲染前加载完成**，否则会**阻塞页面首屏展示**的资源。常见类型包括：

- **HTML 入口文件**：解析整个页面结构的根文档
- **CSS 样式表**：CSS 是阻塞渲染的，必须加载后才能绘制页面
- **首屏 JS 脚本**：用于首屏交互或组件逻辑初始化的 JS（例如 React/Vue 渲染逻辑）
- **首屏图片**：Banner、大图等占据首屏核心位置的可见资源
- **字体文件（可选）**：若首屏需展示特殊字体（注意 FOUT 问题）

---

### 二、识别关键资源的方法

#### 1. 使用 Chrome DevTools → Performance 面板

1. 打开页面，F12 → Performance → 开始录制
2. 观察：
 - **Loading 阶段的资源瀑布图**（Network Timing）
 - **Longest Frame Before First Paint**
 - 标出首屏时间点前加载完成的资源，即为关键资源

#### 2. 使用 Chrome DevTools → Coverage 面板

- 识别“实际使用的 CSS/JS”
- 可以看出哪些资源在首屏期间被真正用到，哪些是冗余代码

#### 3. 使用 Lighthouse 报告

- Lighthouse 中的“Diagnostics”项会指出：
 - 阻塞渲染的资源（Render Blocking Resources）
 - Critical Request Chains
 - Unused JS/CSS 提示，帮助精简非关键资源

#### 4. 查看 Chrome DevTools → Network 面板排序

- 按时间排序，查看首屏渲染前加载的资源
- 关注 `Initiator` 列，了解加载来源（HTML、JS 引入、CSS @import）

---

### 三、首屏关键资源识别的原则

| 资源类型 | 是否为关键资源 | 原因说明 |
|--------------|----------------|-----------|
| `index.html` | ✅ | HTML 是渲染入口 |
| `main.css` | ✅ | 阻塞渲染，必须先加载 |
| `main.js` | ✅ | 驱动页面逻辑，渲染主视图 |
| 首页大图 | ✅ | 首屏可见，未加载即白屏 |
| lazy.js | ❌ | 延迟加载，非首屏资源 |
| 用户点击后加载的组件 | ❌ | 用户交互后才需要，不影响首屏 |

---

### 四、如何标记与优化首屏资源加载

#### ✅ 使用 `&lt;link rel="preload"&gt;` 预加载关键资源

```html
<link rel="preload" href="/styles/main.css" as="style">
<link rel="preload" href="/scripts/main.js" as="script">

✅ 合理设置优先级（优先样式、关键 JS）

样式应优先加载，JS 使用 defer 避免阻塞渲染
图片使用 priority 或手动 preload，避免首屏懒加载

✅ 拆分资源、按需加载，非关键资源延后

使用 webpack 拆包、code splitting
配合路由懒加载、图片懒加载，剥离非首屏资源

五、总结

首屏关键资源识别关键在于时机和影响：只看首屏时间前对渲染有影响的资源
工具使用（DevTools Performance / Coverage / Lighthouse）是识别的重要手段
识别后需通过优先加载、资源压缩、预加载、懒加载等手段进行优化

4. 具体通过哪些手段减少关键资源体积

题目要点

清晰分类 JS / CSS / 图片 / 字体 / HTML 各自的体积优化方式
能结合具体工具（Webpack、插件、工具链）给出实操方案
表达对“精简资源体积 = 提升性能体验”逻辑的理解
给出优化前后定量结果更有说服力

参考答案

考察点

● 资源优化能力（代码压缩、依赖精简、图片优化等）

考察候选人对性能优化的掌握是否落到实处。

字节-抖音短视频-社招-5年 · 第 1 轮 · 一面

Sun, 27 Jul 2025 09:47:52 +0000

← 已是第一轮 · 返回本次面经 · 第 1 轮 →

本轮要点： 事件循环、前端存储、React 生命周期、列表和key、react 事件机制、react 渲染机制、浏览器的同源策略、CSRF攻击、 XSS防御、跨域资源共享（CORS）

本轮共 23 道题。答案默认折叠，便于先自行作答。

1. 介绍一下你觉的比较有成就感的项目

题目要点

STAR法则

参考答案

老传统了，基于简历挖掘一个最有亮点的项目

2. 遇到的最有挑战的技术是什么

题目要点

略

参考答案

略

3. 项目技术选型是如何衡量的

题目要点

列举技术选型的核心衡量标准
说明评估流程和实操方法
强调综合权衡，避免片面判断
结合项目需求和团队实际展开

参考答案

考察点

● 理解技术选型的核心因素及其权衡原则

考察对项目需求、团队能力与技术趋势的综合分析能力。

● 掌握技术选型中性能、开发效率、维护性等多维度考虑

考察系统架构设计和项目管理思维。

参考答案

一、技术选型的衡量维度

1. 业务需求匹配度

技术是否满足项目的功能需求、性能要求和扩展性。
是否支持项目特有的场景或复杂逻辑。

2. 团队技术栈和能力

团队是否熟悉该技术，学习成本及培训投入。
技术社区活跃度，文档完善程度，易用性。

3. 性能表现

技术的响应速度、负载能力、资源消耗。
是否支持性能优化方案（如 SSR、缓存策略等）。

4. 生态和兼容性

技术生态是否丰富，有无成熟的第三方库和工具支持。
与现有系统和平台的兼容性。

5. 维护成本与长期可持续性

技术的稳定性和升级频率。
社区支持和企业采用情况，避免技术孤岛。

6. 开发效率

开发周期和上线速度。
工具链和开发体验是否高效。

7. 安全性和合规性

技术在安全防护、隐私保护方面的能力。
是否满足行业合规标准。

二、技术选型的评估流程

需求调研：明确项目功能和非功能需求。
方案调研：收集备选技术方案及案例。
技术预研和验证：通过小型原型测试技术可行性。
成本评估：综合考量开发、维护、培训等成本。
风险分析：识别潜在风险，如社区活跃度、技术稳定性。
决策和方案确定：结合以上评估，选择最优技术方案。

三、总结

技术选型是一个多维度权衡过程，既要满足业务需求，也需考虑团队与生态。
注重长期维护和性能表现，避免盲目追新或仅凭个人偏好。
通过科学的评估流程和数据支撑，做出理性选择。

4. 项目中的性能监控和错误上报讲一下

题目要点

列举关键性能指标及监控方法
说明错误类型、捕获机制和上报流程
强调数据分析与持续优化的重要性
结合实际项目实践进行阐述

参考答案

考察点

● 理解前端性能监控的关键指标和监控手段

考察对用户体验优化和实时监控的认知。