1. 写在前面：为什么B站社招值得认真准备
后台一直有人催我写面经，拖了快两个月，终于坐下来把这趟B站社招的完整经历捋了一遍。标题写的是“烤面经”，其实就是“考面经”——把自己烤过、考过的经验全部翻出来晒一晒，给准备冲B站或者正在冲大厂的朋友一份能直接抄的作业。这篇稿子不是那种“我朋友说”“我听说”的二手消息，是我自己从投简历到拿offer全流程走下来的真实记录，包括每一轮的面试题、我当时怎么答的、哪些地方答崩了、复盘之后怎么改的，全部摊开来讲。
先交代一下结果：已拿offer，岗位是技术方向的社招，不是校招。整个流程大约三周，一共四轮面试加一轮HR沟通。B站的面试风格给我的整体感觉是：问得很细，但不会故意刁难人。面试官普遍愿意引导，只要你思路在线，哪怕某一题没答完美，也能通过追问把信息挖出来，重点是考察你是不是真的做过事、能不能把事讲清楚。这跟我之前面的某些公司风格差异很大，那类公司喜欢上来就抛一个特别大的场景题，逼你在白板上做架构决策，答不对就直接挂。B站不是这个路数，B站更看重“你过去做过什么，怎么做，为什么这么做，有没有想过更好的做法”。
这篇面经我尽量按时间线走，从投递渠道、简历准备，到每一轮的面试重点、高频题拆解，再到心态调整和开价策略，都覆盖到。你如果是准备社招的人，不管是冲B站还是冲别的中大型互联网公司，这篇内容里的方法论基本通用。
提示：面经永远是“参考”，不是“押题”。行情、部门、面试官风格，甚至同一家公司不同事业部之间的差异都很大。我这篇的价值在于帮你建立一套“怎么准备、怎么应对、怎么复盘”的完整框架，而不是背答案。
2. 整体准备：投递渠道、简历打磨与目标部门判断
2.1 投递渠道怎么选：内推优先，但别只盯着内推
先说结论：B站社招，内推效率明显高于海投，但内推不是万能药。我当时是找了在B站工作的前同事帮忙内推，从简历进系统到约面大概用了4天；同期一个朋友自己走官网投递，简历泡了两周才有动静。这个差异不是绝对的，但内推至少能保证简历被HR看到，而不是躺在简历池里被算法筛掉。
另外有个细节容易被忽略：B站的招聘官网和很多大厂一样，同一个岗位可能挂在不同的部门下面，JD看起来差不多，实际工作内容可能差很多。所以内推的时候一定不要只甩一个简历过去，要跟帮你内推的人问清楚三件事：这个岗位挂在哪个事业部、团队目前主要做什么、面试流程大概几轮。我当时就是问清楚之后才投的，因为B站的业务线很长——主站、直播、电商、游戏、OTT、漫画、音频都有技术团队，不同团队的技术栈和节奏完全不一样。盲投的话，就算拿到了offer，入职之后发现自己对业务不感兴趣，那才是最大的坑。
2.2 简历上写什么：项目经历是绝对核心，技能列表是装饰品
我筛过简历，也帮朋友改过简历，一个深有体会的点是：技术简历上“精通”“熟悉”“了解”这一栏，面试官大概率只是扫一眼，真正会逐字读的是项目经历。所以我准备简历的时候，把大概70%的篇幅给了项目，技能列表反而压缩到了一小块。
项目经历的写法，我推荐一个四段式结构，也是我这次实际采用的写法：
- 背景：一句话说清楚这个项目解决什么问题，服务对象是谁。比如“面向创作者的数据分析平台，帮助百万粉以上UP主实时监控内容表现”。
- 你在里面的角色：是主导者还是核心参与者？负责的模块边界在哪里？这里要写具体，避免“参与了XX系统开发”这种模糊表述。
- 技术方案与关键决策：选型是什么？为什么选它而不是另一个方案？这是面试官最喜欢追问的地方，提前写好，面的时候就不慌。
- 结果数据：上线后带来了什么可量化的变化。QPS提升了多少、耗时降低了多少毫秒、人力成本节省了多少，有数字就写数字。
我这次简历里放了三个项目，一个偏业务架构，一个偏性能优化，一个偏数据链路。三个方向刚好覆盖了B站面试官可能会问的不同角度，实际面试中也确实都被深挖了。第三轮面试官就盯着性能优化那个项目连续问了四十分钟，从排查思路到监控指标再到上线策略，一层一层往下剥，如果没有提前把项目细节吃透，那轮估计就交代了。
2.3 目标部门判断：岗位信息藏着面试方向的关键线索
两段相同的JD，背后可能是完全不同的面试难度和技术侧重。我的做法是把JD里的关键词拆出来，逐个对照自己的经验做匹配。
具体来说，我会新建一个表格，左边列JD里的技术关键词，比如“高并发”“微服务治理”“ClickHouse”“Flink”，右边列我自己对应的项目或技能，能对上就标“强相关”，对不上就标“需要补课”。这个动作看起来很简单，但价值很大：它能很直观地告诉你，这个团队在意什么。如果JD里反复出现“稳定性”“SLA”，那一面大概率会问容灾、限流、降级；如果反复出现“数据分析”“实时计算”，那大概率会问流式计算框架和存储选型。
B站的技术岗JD，通常还会在最后附上“团队介绍”或“业务方向”，比如“负责弹幕系统”“负责推荐链路”“负责创作者服务”，这些信息就是最好的押题来源。我当时投的岗位跟内容中台相关，所以重点复习了缓存设计、消息队列、分布式一致性这些方向，最后一面确实有一道场景题就落在这个范围里。
3. 面试全流程拆解：从一面到HR面的真实记录
3.1 一面：基础功底的“体检”，重点在操作系统、网络与编码
B站的一面给我的感觉很像一次全面体检，不追求某一个领域考到天荒地老，而是快速把计算机基础、编码能力和业务理解都扫一遍。我这一面大约是70分钟，整体节奏是：自我介绍（5分钟）→ 基础题问答（20分钟）→ 手写代码（25分钟）→ 项目深挖（20分钟）。
基础题部分，我记得比较清楚的几个：
- 进程和线程的区别是什么？协程又是什么？这个题我答的时候先给了教科书定义，然后立刻切换到实际场景：进程是资源分配的最小单位，线程是CPU调度的最小单位，协程则由用户态调度，切换成本远低于线程，适合IO密集型任务。面试官接着追问了一句“那Go的goroutine跟协程是什么关系”，这个追问说明他想要的不只是定义，而是你有没有在实际开发中用过。
- TCP四次挥手为什么是四次？我回答的时候画了时间线：主动方发FIN，被动方回ACK，被动方再发FIN，主动方再回ACK。核心原因是被动方收到FIN之后，可能还有数据没发完，所以ACK和FIN不能合并。面试官又问“如果被动方刚好没有数据要发了，可不可以合并成三次”，这个点我当时犹豫了一下，最后回答“理论上可以，但TCP协议栈实现中并不会这么干，因为收到FIN只代表对方不再发数据，不代表对方不再收数据”。这一题算是我答得比较顺的。
- HTTPS的握手过程，以及公钥加密和对称加密在里面的分工。这个几乎是必考题，我建议每个人都能在5分钟内画完整条链路。
手写代码那题是LRU缓存。这题我太熟了，直接写了基于HashMap加双向链表的实现。写完之后面试官问我“如果多线程并发访问，这个实现会不会有问题”，我说会有，最简单是加锁，追求性能可以用分段锁，再激进一点用并发数据结构。他又追问“那Redis的近似LRU跟你手写的这个LRU有什么区别”，这也引导得很好，把一道算法题接到了工程实践上。
项目深挖部分，面试官挑的是简历里那个性能优化项目，问的问题集中在：你怎么定位到瓶颈的？优化前后数据是什么？上线之后有没有出现异常？我提醒一句：简历上写的每一个数字都要能自圆其说。我写“接口耗时从380ms降到120ms”，面试官立刻问“这个数据是怎么测出来的，压测工具是什么，压了多大并发”，如果你只写结果答不上来过程，那这一项不仅不加分，反而会让面试官怀疑简历的水分。
3.2 二面：系统设计与项目细节的“压力测试”
二面通常是交叉面或者技术Leader面，我的二面面试官是另一个团队的资深工程师，整体风格比一面更“松”，但问题更开放。这一面大约80分钟，主体是三块：一道系统设计题、一个线上故障的排查推演、以及对我提到的某个技术选型的极限追问。
系统设计题大概是这样的：设计一个短链服务。这类题很经典，考察点无非是发号器、存储选型、缓存策略、跳转逻辑、过期清理。我回答的时候没有急着写表结构，而是先花了两分钟跟面试官对齐需求：短链的QPS预估多少？过期时间多长？需不需要自定义别名？需不需要统计数据？这些都是“澄清需求”的加分项，因为实际工作中没有人会把需求讲全，能主动定义清楚边界，是高级工程师的基本素养。
之后我给的方案是：发号器用号段模式，每台机器预取一批ID，内存里用完再取；存储用MySQL存映射关系，KV直接存“短链号→原始URL”的映射而不存业务字段；读链路挂Redis缓存，缓存穿透用布隆过滤器挡一下；过期清理用惰性删除加定时任务兜底。
面试官顺着方案追问了几个点，其中有一个我印象很深：“如果Redis缓存和MySQL里的数据不一致，用户会看到什么？”我的回答是：短链数据本身是不可变的，一旦生成就永远指向同一个URL，所以缓存只需要做“读多写少+只增不改”的策略就能规避一致性问题，不需要引入分布式锁之类的重型方案。面试官当场点头，这个追问让我意识到，设计题的回答重点不在于面面俱到，而在于“你的每一步决策都有清晰的依据”。
线上故障排查推演也很有意思，面试官给了一个场景：某个服务某天开始P99延迟从50ms涨到500ms，CPU和内存看起来都正常，你怎么排查。这个问题考察的思路比答案重要。我当时给出的排查路径是：先看调用链，确认延迟是发生在服务内部还是下游依赖；再看GC日志，确认没有频繁FullGC；然后看线程状态，确认有没有线程阻塞；接着看连接池，确认有没有连接泄漏；最后再看网络层和磁盘IO。面试官听完说“这个思路比较完整”，然后补了一句“其实最可疑的是那个被很多人忽略的日志框架，曾经出过磁盘打满导致阻塞的事故”——这算是他分享的经验，也提醒我排查问题时不能只盯着应用层。
3.3 三面：业务理解与跨团队协作的“综合面试”
三面一般是更高的Leader或者总监级别，这一面不再抠技术细节，重点考察的是你有没有大局观。我的三面大概60分钟，面试官是内容中台的技术负责人，开场没有让我自我介绍，直接抛了一个问题：“你觉得B站的弹幕系统跟抖音的评论系统，在技术设计上最大的差异是什么？”
这个问题很妙。表面上在问技术，实际上在问你对B站业务的理解。我的回答是：弹幕是强实时、高并发、内容极短的流式数据，用户在同一个视频上的互动高度同步，所以弹幕系统天然需要低延迟推送和时序一致性；而评论是相对长尾的内容，有楼中楼结构，更强调存储的灵活性和检索能力，它的写入模型没那么集中。两个系统的核心差异来自用户行为模式的不同，技术上就会导向不同的架构选择。
面试官还问了几个偏软实力的问题，比如：“如果产品提了一个需求，你觉得技术上实现不了，你怎么沟通？”“你有没有做过技术方案被别人推翻的瞬间，当时怎么处理的？”“你带过新人或者指导过同事吗？”这类问题没有标准答案，但有一个核心：不能只说“好的没问题”，也不能只说“不可能”。我当时回答第一个问题时用了STAR结构，先描述场景，再说明自己的分析和方案，最后说结果如何。这块建议每个人都提前准备三四个真实小故事，面试的时候比临场编要自然得多。
三面结束后两天，HR打电话过来说“面试评价不错，约HR面”。到这个节点，offer基本已经十拿九稳了，HR面更多是确认意愿和薪资期望。
3.4 HR面与薪资谈判：目标公司、期望值、以及定级参考
B站的HR面不算难，核心就是三类问题：为什么离开上一家公司、为什么选B站、你的薪资期望是多少。这三类问题我建议提前打好腹稿，但不要背稿子，HR经验很丰富，你说得太流利反而像排练过。
“为什么离开上一家”是最容易踩坑的问题。千万别吐槽前司，什么加班多、Leader不行、业务没前景，说出口就是减分项。我的建议是把它翻译成“追求”而不是“逃离”：因为想接触更大规模的用户体量、想做更复杂的业务场景、想要更专业的技术氛围，所以选择离开。同样的事实，换个说法，观感完全不一样。
“为什么选B站”这个问题，最好结合自己的实际体验来答。我是B站深度用户，从大学就开始用，对社区氛围和内容生态有真实的感受，这个答案就很自然，不是那种“我很看好贵公司发展”的空话。
薪资谈判这块，B站跟大多数公司一样，会先问期望薪资，然后根据面试表现和当前薪资综合定级。我的经验是：先说一个比自己底线高15%-20%的数字，再表现出“可以商量”的态度。谈判的本质是信息不对称，你掌握的信息越少，越要给自己留出缓冲空间。另外有一个细节：HR如果问你“手上有其他offer吗”，如果你真的有，可以如实说，这能增加谈判筹码；如果没有，就说“目前还在流程中”，不要编。
4. 核心考察点解析：B站社招面试官到底在筛什么
4.1 技术深度的考察逻辑：不是背得多，而是扎得深
B站面试官很喜欢做的一件事，是抓住你简历里的某个技术点，一个劲往下挖，挖到你答不上来为止。这不是为难你，而是在试探你的“技术下限”——你对一个东西的理解究竟能深入到哪一层。
比如一面的时候，我在项目里提到了Redis，面试官就顺着问了三个递进式的问题：
- Redis的key过期之后是不是立刻删掉？
- 惰性删除和定期删除分别是怎么实现的？
- 为什么不直接全部用定时删除？
这三个问题连续抛出来，就形成了一个“记忆→理解→分析”的梯度。如果你第一层还能答上来，第二层开始含糊，第三层直接卡住，那说明你对Redis的了解停留在“会用API”的层面，没有真正读过底层实现。这个考察方式跟八股文背诵完全不同，它要求你对每一个写进简历的技术名词都至少有源码级的认知，至少要知道原理。
那怎么准备这种深度呢？我的做法是：把简历里每一个技术名词列成一张清单，然后对每个名词问自己三个问题：它解决了什么问题？它的核心原理是什么？它有什么缺陷或者说代价？如果任何一个问题答不上来，就回去查资料整理成一页笔记。这个动作我持续了大概一周，效果非常明显。
4.2 系统设计题的隐藏评分标准：合理性大于炫技
很多人准备系统设计题有个误区，觉得方案越复杂越显水平，于是上来就甩出一套微服务加消息队列加数据湖的宏大架构。但实际上面试官想看到的不是“最先进”，而是“最合理”。
什么叫合理？就是你的方案跟题目给出的前置条件匹配。五分钟能看完的需求文档，你给了一套需要两个团队维护半年的方案，这叫过度设计。百万级别QPS的问题，你用了单机加本地缓存解决，这叫考虑不周。合理的中间地带是：优先给出一个能支撑当前业务量级、又预留了演进空间的最小可行架构。
我在准备系统设计题时找到一个特别实用的方法，在这里分享出来。找一张纸，先把题目里所有限制条件写出来：QPS、数据量、一致性要求、可用性要求、团队规模、工期。然后对着这些条件逐个画架构：流量入口怎么接，服务怎么拆，数据怎么存，缓存怎么放，任务怎么跑。最后问自己两个问题：这套架构在最坏情况下会不会挂？需要几步才能演进出更复杂的方案？如果两个答案都是合理的，这套方案基本就能过关了。
B站的系统设计题里，还经常夹杂一个业务理解题。比如“B站的搜索和电商的搜索有什么不同”“推荐系统冷启动你怎么设计”，这类问题表面考设计，实际是考你对B站业务的熟悉程度。建议在面试前，认认真真把B站的主要功能拆一遍：创作端、消费端、互动端、商业化端各有什么技术挑战，面试的时候会非常加分。
4.3 软实力问题怎么答：用STAR结构说好一个故事
B站面试中软实力问题的占比不小，尤其是三面，这类问题的目的是考察你的协作能力、沟通能力和自我驱动力。技术面里的软实力题，很多候选人回答得特别散，想到哪说到哪，面试官根本没法判断。
我的建议是用STAR结构来组织每一个案例。STAR是四个英文单词的缩写：Situation（背景）、Task（任务）、Action（行动）、Result（结果）。讲一个故事时，用三句话交代背景和任务，然后用五句话讲清楚你具体做了什么，最后用两句话给出结果和数据。
举个例子，面试官问“你有没有一句话说清楚你最近做的最有成就感的项目”。我的回答结构是：Situation——我们团队负责的推荐接口在晚高峰时段经常超时，用户体验问题被投诉很多次；Task——我负责在一个月内降低接口超时率并保证不增加机器成本；Action——我先做了全链路埋点，定位到耗时集中在某个下游服务，然后把这个服务的降级策略从提前熔断改成了超时降级，同时把部分非关键数据的加载从同步改成异步；Result——上线后接口超时率从3%降到0.4%，机器成本没有增加，落地时长只用了三周。这样一个故事，面试官不需要追问细节就能对你的能力形成一个完整判断。
软实力题里面还有一个高频问题：“你最大的缺点是什么？”这个题很多人栽在两处：一是真的说了个硬伤，比如“我脾气不好跟同事处不来”；二是说了个伪缺点，比如“我太追求完美了”，这种答法面试官见得多，会觉得你不真诚。比较好的折中方案是：说一个真实但不致命、而且你已经在努力改善的缺点，比如“我在做技术方案的时候控制不住细节狂的倾向，有时候会过度投入，现在我会有意识地用时间盒来控制”这一类的回答，既展示了自我认知，又展示了改进能力。
5. 高频题目复盘：一套可以“背”进脑子里的真题库
5.1 基础必考题清单与答题框架
以下几类题目，B站三面技术面里都高频出现，而且完全可以提前准备，不需要考场硬想：
并发与线程这类题目，答题框架要覆盖四个层次：定义层面、实际应用场景层面、底层原理层面、选型对比层面。比如“进程和线程的区别”，先给教科书定义，再给实际场景（浏览器多进程为什么比多线程稳定），再讲线程切换的代价来源（内核态到用户态的切换），最后说什么时候用进程、什么时候用线程。
分布式一致性这类题目，要围绕三个关键词讲：一致性模型（强一致、最终一致）、共识算法（Raft、Paxos）、实际工程方案（分布式事务、消息补偿）。B站业务里常见的是最终一致性场景，所以“本地消息表”“事务消息”“TCC”这几个方案的做法和适用场景要能讲清楚。
缓存与存储这类题目，重点在“缓存三兄弟”——缓存穿透、缓存击穿、缓存雪崩。不仅要会描述问题，还要能给出对应的解决方案，并且说明每种方案在什么情况下不适用。比如拦截空值能防穿透，但如果攻击者用大量随机key，布隆过滤器更可靠；热点key过期要靠互斥锁或逻辑过期处理；缓存雪崩要靠过期时间打散加熔断降级。
这类基础题，我备考用的方式是“关键词卡片法”。每个选题写一张卡片，正面写题目，背面写答题框架，然后随机抽自己。抽到之后不看背面先试着答一遍，答完再看哪些点漏了。
5.2 场景题与代码题实战示例
B站的场景题，一个特点是贴近自身业务。比如我遇到的题目：“B站首页信息流，假设每天有1000万用户访问，你会怎么设计推荐服务端的数据链路？”
我当时的分析分了三层。第一层是数据接入：用户行为数据打到消息队列下游做特征计算；第二层是推荐服务：读特征、召回、排序、重排、返回结果；第三层是缓存层：热门内容缓存、用户个性化结果缓存、兜底策略。面试官追问了两个问题：“如果个性化服务挂了，你怎么降级”“用户刷新频率很高，你怎么避免重复计算”，这两个追问都指向推荐系统的核心难点——稳定性和实时性的平衡。能答上来，就说明不是背的方案，而是真做过。
代码题方面，B站考察算法的方式比较常规，基本上集中在：LRU缓存、手写单例、TopK问题、二叉树遍历、字符串处理。考察难度我觉得属于中档偏上，不会出特别偏门的题，但需要你熟悉常见的解题套路。唯一的建议是：写代码前先跟面试官说思路，写的时候注意变量命名和边界条件，写完后主动讲复杂度。这些细节都是加分项。
5.3 反问环节：别浪费这个展示机会
面试最后，面试官大概率会问“你有什么想问我的吗”。很多人直接说“没有”，这是在浪费最后的机会。反问环节是一个展示你思考深度的窗口，也是你反向了解团队的机会。
我的建议是准备三个层次的问题：
- 关于技术方向：“团队目前技术规划上最看重的是什么方向？”这个问题能让面试官觉得你对自己未来的技术发展有规划。
- 关于业务挑战：“这个岗位未来半年最大的挑战是什么？”这个问题能让面试官觉得你关心业务而非只是养家糊口。
- 关于团队氛围：“团队内部的代码评审和架构评审机制是怎么运作的？”这个问题能帮你判断这个团队的技术文化是否适合自己。
不要问“我表现得怎么样”“接下来还有几轮”这类问题，这些问题只会暴露焦虑，而且面试官也不好回答。反问环节全程控制在五分钟左右，问两到三个问题就足够了。
6. 面试中踩过的坑：这几点教训希望你提前看到
6.1 简历与面试实际内容的一致性
第一轮面试结束之后，我的一个强烈感受是：面试官的问题，92%都来自简历本身。我复盘了一下，面试中几乎每一个深挖的问题，都能追溯到简历里的某一句话、某一个数字、某一项技能。所以准备面试最大的一个功课，不是刷题，而是把简历上的每一个字都重新“咀嚼”一遍。
我给自己的要求是：简历里出现的每一个技术名词，都要能说出它的底层原理、应用场景、优缺点；每一个项目数字，都要能说出它的测量方法、采集工具、优化过程。这项工作很琐碎，但回报率极高。你可以找朋友或者同事充当面试官，专门就着简历提问，直到每一个角落都被覆盖到。
有一个特别容易犯的错：简历里写了“熟悉Java并发编程”，面试官问你“volatile和synchronized的区别”，你答上来了，但是追问“volatile能不能保证原子性”，你却犹豫了。这个犹豫不代表你能力不行，但它暴露了简历措辞和实际深度之间的差距。所以写简历的时候，宁可把“精通”改成“熟悉”，把“熟悉”改成“了解”，也要保证写出来的每一项能扛住两轮追问。
6.2 面试节奏失控：回答问题太长其实是减分项
我一面的时候踩了一个坑，就是在回答“Redis缓存穿透怎么解决”的时候，一下子从布隆过滤器讲到缓存击穿，再从缓存击穿讲到缓存雪崩，把三个概念全倒出来了。面试官听完笑了笑说“我知道这三个的区别，你只需要回答穿透的方案就行”。
这个教训是：面试回答问题，先给结论，再给理由，控制在一到两分钟以内。如果你啰啰嗦嗦讲五分钟，面试官不仅抓不住重点，还会觉得你缺乏提炼能力。更好的做法是“金字塔式回答”：先说核心答案，然后展开理由，最后补充细节。面试官对哪个点感兴趣，自然会继续追问，你不需要把所有知道的东西一次性倒出来。
6.3 别在面试中否定上一家公司或前同事
我身边真有朋友在面试B站的时候，因为吐槽前公司“技术老旧”“管理混乱”“同事不配合”而被挂了。虽然B站文化整体偏包容，但这个动作在任何公司的社招面试中都是大忌。
面试官听到的都是“这是你怎么处理问题的方式”的潜在信号。你说前司不行，他会担心你入职之后遇到困难也会用同样方式处理。我的建议是：所有关于前司的描述，都尽量用中性、客观、就事论事的表达。比如“之前的技术栈偏传统，我在那边接触大规模分布式系统的机会比较少”就比“那边技术太落后了”好听一百倍。
7. 个人经验和最终建议
拿到offer之后，我复盘了一下整个流程，有一个特别深的感触：B站社招考察的，本质上不是你的技术广度，而是你做事的完整度。一个候选人哪怕技术栈没那么“新潮”，只要他对自己做过的项目有完整闭环的理解——背景是什么、方案怎么选的、数据怎么验证的、上线后怎么运维的——面试评价通常都不会差。反过来，光会背八股、简历里堆一堆中间件但是经不起追问，基本会被刷得很惨。
另一个建议是：面试前一定给自己留出至少两周的整块时间做针对性的准备。第一周用来重读简历、整理项目细节、做技术深度梳理；第二周用来专门刷高频题、模拟系统设计、找人做模拟面试。临时抱佛脚可以在短时间里记住很多知识点，但应对深挖型面试远远不够。
最后分享一个小技巧：面试前我会把B站的核心功能产品界面都打开用一遍，从首页推荐到弹幕互动到创作中心，边用边在脑子里过“这个功能背后的技术挑战是什么”。这个动作帮我建立了产品直觉和技术直觉的连接，在回答业务类问题时特别有用。你如果也想冲B站，建议从今天开始就养成这个习惯。准备面试的这一个月很辛苦，但拿到了心仪的offer回头看，一切都值。祝你在面经的加持下，也能“可带劲了”一把。
