TikTok 在线测评面试实录 2026：真实面经完整复盘

公司：TikTok 岗位：在线测评 (Online Assessment) 面试形式：Virtual Onsite 结果：Pass → Offer

1. Timeline

我在 8月底申请 TikTok 的 SDE New Grad 岗位，通过官网直投。大约 10 天后收到了 OA 邀请。提交 OA 后大概一个月，收到了 HR 邮件安排 VO 面试。VO 分为三轮，分三天完成，结构是：第一轮纯技术，两道 coding + 大量followup；第二轮 senior engineer，半小时简历 deep dive + 半小时 coding；第三轮是 hiring manager，全程围绕项目经历和过往行为展开。每轮时长 60 分钟，整体节奏比较紧凑，技术细节问得深入。（注意TT的面试结构和内容并没有统一的标准，因组而已，有的组甚至会给ng安排系统设计面试）

2. VO 面经

第一轮全程都是算法题，没有BQ或简历拷打。

面试官节奏很快，第一道是字符串处理题，类似于 Group Anagrams，我用了 hashmap 结合排序构建 key，先讲了基本思路，再一步步实现，注意了空输入、大小写和特殊字符的处理。第二题是偏dp的题型：“给定一组整数，找出是否能分成两组，使得它们的和相等”，这是经典的Subset Sum，我用记忆化搜索写了一个 top-down DP。面试官重点看我怎么解释状态定义和剪枝逻辑，并让我说出时间和空间复杂度。整体体验偏硬核，对代码准确性和思路结构要求很高。

第二轮是一位senior，风格更像技术一线的 tech lead，沟通清晰但追问非常深。

前 30 分钟是简历 deep dive，我讲了一个全栈项目：使用 React + Node + Dynamo 实现的权限管理平台。他问得非常细，包括前后端接口如何协作、权限校验是否做在前端、分页和索引设计、如果用户量从几百到几万有没有瓶颈，以及部署方式等。后半小时是一道系统类 coding 题：实现一个简化版的 LRU 缓存。我用 hashmap + 双向链表结构实现，代码完成后他继续问，如果这个结构需要在多线程环境中使用，应该怎么改。我补充了加锁方式，并说明了性能影响。

第三轮是 hiring manager 面试，全程围绕简历展开，更偏BQ，也更关注沟通（前两轮都是纯中文，这一轮是纯英文）。

面试官先让我自我介绍，接着逐个项目提问。他重点问了我最有挑战性的项目、如何与队友协作、有没有处理突发问题的经历、自己在哪些地方做得不够好并是怎么反思的。我分享了一个实习中因为接口变更导致部署失败，最后写回滚脚本+自动验证工具避免再次出错的经验。他还特别关心我在团队中是否主动take ownership，是否愿意 mentor 别人，是否愿意快速学习新系统，能不能 adapt to fast pace environment。他没有问算法题，但会从经历中判断你是不是适合 TikTok 工程文化的人。

3. 注意事项

TikTok 的 New Grad 面试整体偏工程导向，对项目理解深度和系统设计意识要求比很多传统 tech company 更高。第一轮是纯技术题，题目难度接近 LeetCode 中等偏上，细节处理必须到位。第二轮则体现出他们对实战能力的重视，项目要讲清楚来龙去脉、技术选型理由、性能优化方案，还要能从架构、扩展、并发、稳定性等角度接受推敲。代码题偏实用型，比如 LRU、rate limiter、cache system，是非常典型的 backend-oriented 题目。

Hiring Manager 面试是另一种考察纬度，他们不关心你算法有多强，而是看你是否具备独立思考、主动承担责任、持续成长的潜力。他们也很看重沟通能力。

准备时一定要对自己的简历项目进行彻底复盘，能画出架构图、解释每一个决策点；同时练习能手写的工程类题目，掌握核心数据结构在实际应用中的组合使用。整体风格相比 Google 更工程化，相比 Amazon 更灵活但深度更高。

1. Top K Frequent Elements（高频出现）

经典题，LeetCode 347 原题，题目是：给一个整数数组 nums 和一个整数 k，返回出现频率前 k 高的元素。

常规思路：先用 HashMap 统计频率，再用 min-heap（优先队列）维护 size 为 k 的 top-k 结构，时间复杂度 O(n log k)。

TikTok 面试点 - 我这轮遇到的是变种：如果有多个元素频率一样怎么办？是否可以任意返回？我问清楚了之后面试官说：只需要保证返回任意 top-k 即可，不要求排序。但他后面又追问：“你能不能只用 O(n) time？”我立刻说可以用 bucket sort 优化，把频率当作 index 存到数组里，最后从后往前扫 bucket，时间复杂度 O(n)。然后我们讨论了HashMap + Bucket 的 trade-off 场景。

建议：刷这个题的时候，不要只会 min-heap，最好也把 bucket sort 的优化版本掌握一下，TikTok 特别爱 follow-up “Can we do better”

2. Longest Substring Without Repeating Characters（变种高频）

看似简单，但 TikTok 爱考变种形式。

原题版本： LeetCode 3，双指针 + HashSet，找最长无重复子串。

tt 面我的是变种：返回最长子串的实际内容，而不是长度，并且不区分大小写（即 ‘A’ 和 ‘a’ 视为同一个字符）。

思路：要处理大小写，可以先把所有字符 lowercase，然后再做 sliding window。过程中注意存字符时要映射为统一形式（我用的是 char.lower()）。实现上没什么新难度，但TikTok 很在意你的 test case 是否覆盖到了大小写混合的情况。面试官明确说 Can you walk me through edge cases，我准备了 “AaBbCc” 这种 case，他说 that’s exactly the one I expected。

建议：这类 substring 题，TikTok 特别在意 corner cases，比如空串、全重复、边界条件、字符编码。别只写核心逻辑，要自己补几个 edge case 解释清楚。

3. Merge Intervals（地里也提到过很多次的题目）

他们特别偏爱各种 interval 操作，包括 merge、insert、find overlap、判断是否冲突。

我遇到的一题是 Merge Intervals，但是输入无序的版本。原题是 LeetCode 56：合并所有重叠区间。

TikTok 版本 twist：输入 intervals 没有排序，你要先 sort，然后 merge；而且他会 follow-up 问 “what if intervals are massive and don’t fit into memory?” 思路：第一步：sort intervals by start time，然后遍历合并。

Follow-up：我提了 external sorting + chunking 的思路，他继续问 “So what’s the complexity of your sort step?” 我答 O(n log n)，他说有没有更好的办法，如果我只能顺序读取数据。我说可以用 map-reduce 方式来分布式 sort，但代码层面写不出来。他说 ok，但希望我能 identify 出“sort 是瓶颈”。

建议： tt 面试官往往不要求你写特别长的代码，而是希望你能快速 spot 出瓶颈，并给出高层设计的解法。这在 infra 组尤为常见。

4. Decode String（栈模拟）

这个是我听到好几个人在 TikTok 面试时遇到的题，LeetCode 394 原题。题目是：输入 “3[a2[c]]“，返回 “accaccacc”。

核心考点：要实现嵌套解码，必须用 stack 模拟。过程就是遇到 [ 把当前 prefix 和 repeat 数都压栈，遇到 ] 就弹出来展开。

TikTok twist：可能会要求你支持更复杂的语法，比如支持变量名、支持 unicode、支持自定义分隔符（比如括号改成 {} 或 <>）。有一次面试官甚至问了：“If this becomes a part of a mini language interpreter, how would you generalize it?” 建议：栈模拟题 TikTok 特别爱延伸问系统设计，比如你这个 parser 能不能模块化？能不能适配更多语法？不是考你设计 AST，但思路要清楚。

5. Sliding Window Maximum（难度偏上）

LeetCode 239，给一个数组和一个窗口大小 k，输出每个滑窗里的最大值。

常规思路：单调队列（deque），维持窗口中元素的 index，确保队首是最大值。

tt follow-up：面试官问：“Can you make it concurrent-safe if the input array is a stream of data?” 我说可以封装一个线程安全的 max window processor，用锁 + condition variable 控制 sliding window 的推进。他又问：“So what’s the latency of your update operation?” 建议：对于 stream、window、heap 类问题，TikTok 偶尔会加一点 infra flavor，特别是如果你投的是 infra/backend 的岗位。这类题要准备一些并发 / 多线程的延伸讨论。

1. 灯光照射的最大重叠点

题目给定 N 盏灯，每盏灯的照明范围是 [pos - r, pos + r]，要求找出被最多灯照亮的坐标，如果有多个并列则取最小的坐标。这是一道典型的区间重叠统计题，可以用扫描线高效解决。做法是将每个区间的起点记为亮度 +1，区间的终点+1 位置记为亮度 -1，然后将这些事件按照坐标排序，从左到右扫描并维护当前亮度。当亮度超过历史最大值时，更新最大值和当前坐标；当亮度等于最大值时，比较坐标大小来满足 tie-break 条件。由于需要排序，整体复杂度是 O(N log N)。实现细节上要注意区间是闭区间，所以终点处理时需要用 end+1 来标记减少亮度，否则会多算最后一个点；另外 tie-break 条件必须在亮度相等时单独判断，否则结果可能错误。

2. 包裹分发系统

有多个分发中心，每个中心有固定容量，包裹按顺序分配。当输入 CLOSURE x 时，表示关闭中心 x 直到下一轮。在每轮结束时，除了关闭的中心外，其他中心的容量会恢复到初始值。题目要求找出处理包裹最多的中心，如果有并列则取最大 index。这道题本质是一次较长的模拟过程，可以用两个数组分别维护每个中心的当前剩余容量和累计处理包裹数。在分配包裹时，如果遇到关闭中心或容量不足则跳过，否则分配并减少容量。每轮结束时需要恢复容量，但要注意关闭的中心在下一轮前不能恢复。复杂度是 O(N * M)，其中 N 是中心数量，M 是包裹总数。实现时最大的坑是 tie-break 条件和关闭中心的恢复逻辑，如果恢复处理不当会导致统计错误，另外输入的处理顺序也要完全按照题意执行，不能跳步优化，否则可能丢掉模拟的精确性。

3. 字符串逐位相加

给定两个数字字符串，从右到左逐位相加但不进位，如果一个字符串较短，剩下的部分直接取另一个字符串的数字，最后拼接成结果输出。这题看起来简单，但要求实现细节正确且性能合理。标准做法是用双指针从两个字符串末尾向前移动，每一位直接相加，将结果（个位值）追加到一个临时列表中，直到两个字符串都遍历完成。最后将结果列表反转再拼接成字符串输出。复杂度是 O(max(lenA, lenB))。实现时要注意不能直接用字符串累加结果，因为那样会导致 O(n²) 的性能退化；同时，由于不进位，所以每位的和不需要拆分十位，只保留相加结果本身，这一点和常规的大整数加法不同，很多人在第一次写的时候会习惯性加上进位处理，这是不必要的。

第一轮

第一轮一上来是经典的 “Tell me the project you are most proud of”，面试官从项目细节一路深挖到底，问得非常细，从架构设计、性能优化到算法复杂度都涉及到了。可以感觉到 TikTok 的面试风格和其他大厂不同，他们很在意候选人对自己写过的系统是否真的理解，而不是背一堆 buzzwords。算法题部分是权重随机选择题，给定一个数组 w 表示权重，实现 pickIndex()，要求返回的下标按照权重比例随机选取。标准思路是先对权重做前缀和，然后在 [1, total] 范围内生成随机数，再用二分查找确定随机数落在哪个区间，对应的下标就是答案。这道题考察的其实是思维清晰度和实现能力，而不是复杂算法。写完后面试官没有深入追问 follow-up，看得出他更关注我的项目经验。剩下十分钟我反而问了几个关于 AI infra 的问题，比如模型推理延迟、分布式缓存、特征管线等话题，对方聊得很深入，气氛也挺轻松。

第二轮

第二轮开始得更快，对方没有再重复问简历，而是从业务层面闲聊起，刚好我们的研究方向有些重合，所以前半段更多是交流式的探讨。算法题换成了一个偏系统设计方向的问题：实现一个日志存储系统，支持 put(id, timestamp) 存储日志，以及 retrieve(start, end, granularity) 按时间范围和粒度查询日志。思路上可以用字符串前缀匹配或者时间分桶，把日志按粒度分类存储，再用二分查找定位区间。代码部分不难，但面试官的 follow-up 把题目一下子拉到真实系统层面，他问如果这是生产级别的 infra，要怎么水平扩展。这个问题实际上在考分布式系统思维，比如如何做分片存储、如何按照时间或 ID 进行 partitioning、如何在多个节点之间保持一致性，以及如何提升查询效率。我们聊到了 Kafka、HBase、ClickHouse 这些真实世界的实现方式，从一个算法题一路延伸到生产架构的讨论。面试官明显对这些话题非常感兴趣，最后五分钟几乎变成了技术茶话会，从日志检索聊到流式分析，整个过程很顺畅。

什么是八股

很多人会把这种面试里出现的开放性问题或项目追问称为八股文，但实际上 TikTok 的问题并不是那种死记硬背式的模板化提问。他们更看重候选人对基础概念和系统原理的理解，比如时间复杂度为什么是 log n、分布式检索的索引怎么设计、延迟瓶颈如何优化。这类问题确实属于 computer science fundamentals，但它们不会以“请背出定义”的方式出现，而是让你在一个具体的工程情境中去推理。也正因为如此，TikTok 的面试整体节奏看起来轻松，但实际上信息密度极高，非常考察思维深度。

Part 1：Resume Deep Dive

面试一开始是简历deep dive。这一部分总体以candidate的输出为主，没有特定的考点，只要你的项目和data engineering相关，并且足够熟悉就没啥问题。面试官让我从项目中挑一个最能体现数据工程能力的例子，我选择讲一个基于 Kinesis + Flink 的实时用户行为分析系统。我主要介绍了从数据采集、实时计算到下游入库的整体链路。他问到如何应对 Flink 的 checkpoint 延迟或状态膨胀问题，我解释说可以通过调整 RocksDB state backend、控制 checkpoint 频率，以及给状态数据设置 TTL 来避免积压。他还问当流处理任务出现 back pressure 时该如何排查。

Part 2：SQL 实战（HackerRank）

第二部分是两道 SQL 题，在 HackerRank 平台上完成。第一题考的是用户活跃度增长分析，要求根据用户注册与事件表计算每日活跃用户数，并统计相较前一天的增长率。面试官进一步追问如何在大规模数据下优化查询，我提到可以按日期字段进行表分区，配合日期范围过滤避免full table scan。第二题是关于content creator内容互动的分析，需要从多张表中进行 JOIN，计算过去一段时间内 engagement 得分最高的creator。面试官继续问如果事件表规模达到亿级，如何优化大表 JOIN。我回答可以通过 broadcast join 或预聚合 summary 表降低计算量；在分布式环境下，也可以使用窗口函数与 CTE 优化查询逻辑。这部分总体难度中等，更注重分析清晰度与优化思路。

面试总结

成功经验

充分准备高频题：TikTok 的面试题目集中在经典算法和数据结构上，提前准备 LeetCode 高频题非常有必要。
Behavioral 故事要准备充分：使用 STAR 框架准备 5-8 个核心故事，覆盖 Leadership、Conflict、Innovation 等场景。
沟通表达要清晰：解题过程中要主动与面试官沟通思路，不要闷头写代码。
边界条件要主动讨论：面试官很看重候选人对 edge cases 的考虑。

面试注意事项

时间管理：每轮 45-60 分钟，需要合理分配时间给题目、讨论和 follow-up 问题。

技术深度：TikTok 的面试官对技术细节要求很高，边界条件、性能优化、系统设计能力都是考察重点。

💡 需要面试辅导？

如果你对准备技术面试感到迷茫，或者想要个性化的面试指导和简历优化，欢迎联系 Interview Coach Pro 获取一对一辅导服务。