字节跳动 后端开发工程师 一面

面试基本信息

• 公司: 字节跳动（互联网大厂）
• 职位: 后端开发工程师（抖音生活服务平台治理）
• 面试轮次: 一面（技术面）
• 面试形式: 线上视频面试
• 面试时长: 约53分钟
• 面试官: 技术leader，负责平台治理业务

面试问题与回答

问题1：自我介绍

面试官问题：

“先简单自我介绍一下”

我的回答：

“你好，我是王宇哲，来自华东师范大学的软件工程硕士。我考研的话是排70人中排名第二，本科的话是专业排名第一，获得过国家奖学金以及蓝桥杯国赛二等奖之类的荣誉。我简历上的话主要的项目都是基于Go语言去构建的分布式应用…”

标准/建议回答：

其实自我介绍可以更简洁有力一些。可以这样回答：

"你好，我是王宇哲，华东师范大学软件工程硕士在读。在校期间成绩优秀，获得过国家奖学金和蓝桥杯国赛二等奖。主要技术栈是Go语言，有丰富的分布式系统开发经验。

我的项目经历包括：

1. 独立开发的分布式缓存系统，单节点性能超过5000QPS
2. 字节跳动青训营的抖音商城微服务项目，担任队长
3. 目前在上海人工智能实验室实习，参与开源项目开发

对分布式系统、缓存机制、微服务架构都有较深的理解。"

总结反思：

• 当时回答比较详细，但可以更结构化
• 面试官耐心听完，没有打断
• 应该突出技术栈和核心项目

问题2：项目经历详细询问

面试官问题：

“能稍微讲一下在人工智能实验室里面做的那个项目是干什么呢？他要解决什么问题，然后我做的是什么呢？”

我的回答：

“这个项目的话，目前它其实也在一个探索场景的阶段。然后它能想到最常见的场景，就是现在很多人需要做自己的RAG向量数据库。但是那个数据库做切片什么的，其实一般来说都是用markdown去做。就是用markdown这个文件去做数据分片什么的会比较好一些。但是大多数人手上的其实都是PDF文件，然后我们的话是可以把PDF转化成markdown…”

标准/建议回答：

这个问题回答可以更清晰一些：

"我们做的是一个PDF转Markdown的工具，主要解决AI时代的文档处理问题。

背景是这样的：现在很多人需要构建自己的向量数据库来做RAG应用，但大多数人的原始文档都是PDF格式。而向量数据库的切片处理，用Markdown格式会更合适。

我们的项目可以：

1. 将PDF转换为Markdown格式
2. 保留完整的图片和表格结构
3. 精准识别LaTeX数学公式
4. 支持复杂表格的跨行跨列识别

我在其中主要负责后端开发，包括模型部署、异步任务调度、性能优化等工作。"

总结反思：

• 当时回答比较口语化，逻辑不够清晰
• 面试官继续追问了技术细节
• 应该先说明背景，再介绍解决方案

问题3：MySQL索引数据结构

面试官问题：

“你这边了解过mysql索引的数据结构吗？”

我的回答：

“MySQL索引的数据结构的话主要就是B+树。然后如果说它的引擎是哈希的话，它的数据结构就是哈希表。”

标准/建议回答：

这个问题可以回答得更全面：

"MySQL的索引数据结构主要有两种：

1. B+树索引：这是InnoDB存储引擎的默认索引结构，也是应用最广泛的。B+树的特点是：

   • 支持范围查询和排序
   • 适合频繁的增删改查操作
   • 查询时间复杂度是O(log n)

2. 哈希索引：主要用于Memory存储引擎，特点是：

   • 查询速度极快，时间复杂度O(1)
   • 只支持等值查询，不支持范围查询
   • 适合只有插入和查询的场景

实际应用中，B+树索引更通用，因为大多数业务都需要支持范围查询和排序操作。"

总结反思：

• 当时回答比较基础，没有深入分析
• 面试官继续追问了优劣势对比
• 应该准备更详细的应用场景分析

问题4：哈希索引的优化

面试官问题：

“那如果说让你优化的话，你觉你会怎么优化这个地方？”

我的回答：

“让我优化的话，我可能会把哈希跟其他数据结构结合在一起。就比如说哈希下面连一棵树，把链表改成树，这种树的话就比较方便定位到数据，就比较好删除。比如说连个什么B+树什么的。但是的话，对哈希跟B+树最大的优缺点在于哈希我感觉它是更适合用于内存型数据库的。”

标准/建议回答：

这个问题可以回答得更具体一些：

"如果要优化哈希索引的删除性能，我考虑几种方案：

1. 哈希+红黑树：将哈希冲突的链表改为红黑树，这样删除的时间复杂度从O(n)降到O(log n)

2. 计数哈希：在哈希表中存储计数器而不是布尔值，这样可以支持删除操作

3. 分层设计：将热点数据放在内存中，冷数据放在磁盘上

但是哈希索引最大的问题是它只适合内存数据库，因为随机访问对磁盘IO不友好。所以实际应用中，B+树索引仍然是主流选择。"

总结反思：

• 当时回答有创新性，但不够系统
• 面试官对优化方案感兴趣
• 应该结合实际应用场景来分析

问题5：跳表数据结构

面试官问题：

“你这边了解过跳表这个数据结构吗？”

我的回答：

“跳表了解过，但是没有那么熟悉。它查询的时间复杂度应该是O(log n)。它的删除的话只要找到了以后，它的删除的时间复杂度我感觉应该是O(1)。”

标准/建议回答：

跳表是一个很重要的数据结构，可以这样回答：

"跳表是一种概率性的数据结构，可以看作是链表的多层版本。

查询时间复杂度：平均O(log n)，最坏O(n)

删除时间复杂度：找到节点后删除是O(1)，但找到节点需要O(log n)，所以总体是O(log n)

插入时间复杂度：O(log n)

跳表的优势是：

1. 实现相对简单
2. 支持范围查询
3. 空间复杂度是O(n)

Redis的Sorted Set就是用跳表实现的，因为它比红黑树更容易实现，而且性能相当。"

总结反思：

• 当时对跳表了解不够深入
• 面试官没有继续追问
• 应该提前准备Redis等实际应用案例

问题6：Redis缓存问题

面试官问题：

“你这边能之前了解过像缓存雪崩、击穿、穿透这些概念”

我的回答：

“这些我是了解的，因为我项目里面就有，比如说缓存雪崩的话就是一大批的数据它可能同时过期，导致大量的请求直接越过缓存，直接打到数据库上面去了，导致数据库可能会宕机。然后缓存击穿的话，缓存击穿的话就是当有一个热点数据，这个热点数据访问的频率非常高，但它突然过期了。然后就导致了一个问题，就导致大量的请求直接打到了数据库上。然后缓存穿透的话，它就是大量的请求打到了不存在缓存的数据上面…”

标准/建议回答：

这个问题回答得比较全面，可以稍微补充一下：

"是的，我了解这三种缓存问题：

缓存穿透：大量请求查询不存在的数据，绕过缓存直接访问数据库

• 解决方案：布隆过滤器、缓存空值

缓存击穿：热点数据过期，大量请求直接访问数据库

• 解决方案：互斥锁、永不过期、提前更新

缓存雪崩：大量缓存同时过期，导致数据库压力激增

• 解决方案：随机过期时间、熔断机制、多级缓存

我在项目中就实现了SingleFlight机制来解决缓存击穿问题。"

总结反思：

• 当时回答比较详细，覆盖了主要概念
• 面试官继续追问了具体解决方案
• 回答质量较好，体现了实践经验

问题7：布隆过滤器

面试官问题：

“你这边能稍微讲一下这个布隆过滤器它是做什么？”

我的回答：

“布隆过滤器的话，它有很多种应用场景。就比如说过滤掉那些不常见的数据，过滤掉系统中不存在的数据，这是刚刚一种解法。还有一种的话，它其实是可以做一些模糊查询，可以对字符串进行模糊查询，这也是一种应用场景。就是说它可以对一个字符串进行N种哈希。如果说它怎么说呢？它有个叫局部敏感哈希，可以对多个字符串进行局部敏感哈希，这样可以匹配到相似的字符串。就是通过哈希关系，我主要了解是这两种应用场景。”

标准/建议回答：

布隆过滤器的回答可以更准确一些：

"布隆过滤器是一种概率性的数据结构，主要用于快速判断一个元素是否在集合中。

工作原理：

1. 使用k个哈希函数对元素进行哈希
2. 将k个位置都标记为1
3. 查询时检查k个位置是否都为1

应用场景：

1. 缓存穿透防护：快速过滤不存在的key
2. 垃圾邮件过滤：判断邮件地址是否在黑名单
3. 网页爬虫去重：判断URL是否已访问
4. 数据库查询优化：减少不必要的数据库查询

特点：

• 空间效率高
• 查询速度快O(k)
• 有假阳性，无假阴性
• 不支持删除（除非使用计数布隆过滤器）"

总结反思：

• 当时回答有些概念混淆
• 面试官追问了删除支持问题
• 应该更准确地描述工作原理

问题8：Go语言垃圾回收

面试官问题：

“那你能稍微讲一下那个Golang的垃圾回收机制吗？”

我的回答：

“Go语言垃圾回收机制的话，我记得它好像有一个演变过程。首先它一开始的垃圾回收的话，它是直接叫stop the world。就是他在垃圾回收之前，他会把整个程序暂停，然后把垃圾全都回收了。就是从根节点出发，然后把它一个个标记那些可以访问到的那些内存，然后把那些访问不到内存直接给它清除掉，这是第一种方式。然后后面的话就发现这种方式的话，它对性能的影响会比较大。于是他就后面衍生出了一个三色标记法的一种垃圾回收机制…”

标准/建议回答：

Go的垃圾回收机制可以这样回答：

"Go语言的垃圾回收经历了几个阶段：

1. Go 1.3之前 - Stop The World

• 暂停整个程序进行垃圾回收
• 对性能影响很大

2. Go 1.5 - 三色标记法

• 白色：未被访问的对象
• 灰色：已被访问但子对象未访问的对象
• 黑色：已被访问且子对象已访问的对象

3. Go 1.8 - 混合写屏障

• 减少并发标记时的写屏障开销

4. Go 1.12 - 标记清除

• 进一步优化标记阶段

5. Go 1.14 - 并发标记清除

• 标记和清除阶段都可以并发执行

现在的Go使用三色标记+并发回收，大大减少了GC对程序性能的影响。"

总结反思：

• 当时回答比较详细，体现了对Go GC的了解
• 面试官没有继续追问
• 回答质量较好，体现了技术深度

问题9：乐观锁和悲观锁

面试官问题：

“你这边了解过乐观锁和悲观锁吗？”

我的回答：

“乐观锁的话，乐观锁的话他认为他是一种很乐观的想法，就是他预先把事情做好了，然后再加锁，这样性能会好一点。然后悲观锁的话就是认为所有的请求它都有可能会失败，所以说它会提前加锁，加锁以后再执行，这样对性能的影响会比较大。”

标准/建议回答：

这个问题可以回答得更具体一些：

"乐观锁和悲观锁是两种不同的并发控制策略：

乐观锁：

• 假设冲突很少发生，先执行操作，再检查冲突
• 实现方式：版本号、时间戳、CAS操作
• 适用场景：读多写少、冲突较少的场景
• 性能：并发性能好，但冲突时重试开销大

悲观锁：

• 假设冲突经常发生，先加锁再执行操作
• 实现方式：数据库行锁、表锁、分布式锁
• 适用场景：写多读少、冲突较多的场景
• 性能：并发性能差，但无重试开销

实际应用中要根据业务特点选择，比如库存扣减用悲观锁，用户信息更新用乐观锁。"

总结反思：

• 当时回答比较抽象，缺乏具体例子
• 面试官追问了应用场景
• 应该准备更多实际应用案例

问题10：TCP报文格式

面试官问题：

“你这边能稍微讲一下就比如说像TCP它的报文格式，你这个之前了解过吗？”

我的回答：

“TCP的报文格式的话，首先第一个就是第一行，它是32字节。然后前32个位，然后前面16位的话是源端口，后面16位的话是目标端口。然后接下来的话好像是序列号。2个32位它分别应该代表的是一个是序列号，还有一个是确认号，然后后面好像就是有一部分空出来的那接下来就是什么ACK、SYN之类的标志位，然后再往后的话应该是一些校验位，但具体的也记不太清楚了。”

标准/建议回答：

TCP报文格式可以这样回答：

"TCP报文格式包含以下字段：

源端口和目的端口：各16位，标识发送和接收的进程

序列号：32位，标识本报文段第一个字节的序号

确认号：32位，期望收到对方下一个报文段的第一个字节序号

数据偏移：4位，指出TCP报文段的数据起始处距离TCP报文段起始处有多远

保留字段：6位，保留为今后使用

控制位：6位，包括URG、ACK、PSH、RST、SYN、FIN

窗口大小：16位，告诉对方本报文段发送方的接收窗口大小

校验和：16位，检验整个TCP报文段

紧急指针：16位，仅在URG=1时有效

选项和填充：可变长度"

总结反思：

• 当时回答比较混乱，记忆不够准确
• 面试官没有继续追问
• 应该提前复习网络协议的基础知识

问题11：算法题 - 链表对折

面试官问题：

“我这边给你准备一道算法题，能看到这个页面变化吗？”

我的回答：

“我想的最简单的解法就是把它给拆成两个链表。先把它按中间拆成两个链表，然后另一个链表它拆的过程中，它是使用头插法，这样就可以把它反转了，然后它时间复杂度也会很低，然后再把这两个链表再拼起来。”

标准/建议回答：

这道链表对折题可以这样解决：

"我的思路是：

1. 使用快慢指针找到链表中间节点
2. 将后半部分链表反转
3. 将两个链表交替合并

具体实现：

func reorderList(head *ListNode) {
    if head == nil || head.Next == nil {
        return
    }
    
    // 找到中间节点
    slow, fast := head, head
    for fast.Next != nil && fast.Next.Next != nil {
        slow = slow.Next
        fast = fast.Next.Next
    }
    
    // 反转后半部分
    second := reverseList(slow.Next)
    slow.Next = nil
    
    // 交替合并
    first := head
    for second != nil {
        temp1, temp2 := first.Next, second.Next
        first.Next = second
        second.Next = temp1
        first, second = temp1, temp2
    }
}

时间复杂度：O(n)，空间复杂度：O(1)"

总结反思：

• 当时思路正确，但表达不够清晰
• 面试官让我现场实现
• 应该提前准备代码实现

问题12：并发编程题

面试官问题：

“另外还有一个是你这边做过，就像比如说是我现在有两个协程，然后想一个打印奇数，一个打印偶数，然后你能做到让他们两个交替输出吗？”

我的回答：

“可以，我上次的面试也是这个，上次字节的面试也是这个题。”

标准/建议回答：

这道并发编程题可以这样解决：

"这道题可以用channel来实现两个goroutine的交替执行：

func alternatePrint() {
    ch1 := make(chan int)
    ch2 := make(chan int)
    
    var wg sync.WaitGroup
    wg.Add(2)
    
    // 打印奇数
    go func() {
        defer wg.Done()
        for i := 1; i <= 99; i += 2 {
            <-ch1
            fmt.Println(i)
            ch2 <- 1
        }
    }()
    
    // 打印偶数
    go func() {
        defer wg.Done()
        for i := 2; i <= 100; i += 2 {
            <-ch2
            fmt.Println(i)
            ch1 <- 1
        }
    }()
    
    ch1 <- 1 // 启动第一个goroutine
    wg.Wait()
}

关键点：

1. 使用两个channel进行同步
2. 用WaitGroup等待两个goroutine完成
3. 通过channel控制执行顺序"

总结反思：

• 当时有经验，但实现时出现了死锁
• 面试官追问了死锁原因
• 应该更仔细地检查channel的使用

面试整体感受

• 难度评价: 适中，主要考察基础知识和实际编程能力
• 面试官风格: 友善专业，会引导思考，不会刻意刁难
• 题目类型: 技术基础（数据库、缓存、网络）+ 算法编程 + 项目经历
• 准备建议: 重点复习Go语言、数据库、缓存机制，准备算法题和并发编程

面试结果

• 当场反馈: 面试官表示会和HR沟通，没有当场给出明确结果
• 后续流程: 技术面一般有三轮，等待HR通知
• 个人感受: 整体表现还可以，基础知识掌握较好，但有些细节需要加强

经验总结

做得好的地方

1. 项目经历丰富：有实际的项目经验，能详细说明技术细节
2. 基础知识扎实：对缓存机制、数据库索引等概念理解较好
3. 学习能力强：能快速理解面试官的问题并给出合理回答

需要改进的地方

1. 表达不够清晰：有些回答比较口语化，逻辑不够清晰
2. 细节掌握不够：对TCP报文格式、跳表等细节了解不够深入
3. 代码实现能力：算法题的代码实现需要更加熟练

准备建议

1. 系统复习基础知识：重点复习网络协议、数据结构、并发编程
2. 准备项目细节：对项目中的技术选型和实现细节要了如指掌
3. 练习算法编程：多练习链表、树、并发编程等常见题型
4. 提升表达能力：练习用更清晰的语言表达技术概念

知识点复习

• 数据库：B+树索引、哈希索引、乐观锁悲观锁
• 缓存机制：缓存穿透、击穿、雪崩及解决方案
• 数据结构：布隆过滤器、跳表、链表操作
• 网络协议：TCP报文格式、三次握手四次挥手
• 并发编程：Go语言GMP模型、垃圾回收、channel使用
• 算法题：链表操作、并发编程题

这次面试让我意识到在技术深度和表达能力上还有提升空间，需要继续加强基础知识的掌握和实际编程能力的训练。