LinkedIn SDE 的八轮面试前后花了五周，终于走完了。整体感受就是LinkedIn 不是靠刷题速度筛人的公司。前几轮确实有 Coding，但从第四轮开始，技术深度、项目判断、产品思考的权重越来越高。能不能把自己做过的系统说清楚、说深，比能不能秒出最优解重要很多。
Round 1：Recruiter Call
这轮大约 30 分钟，recruiter 有一份准备好的问题清单，逐一确认——不是随意的聊天，更像是在打钩，你有没有资格进下一轮。
开场问了”Tell me about yourself”和”Why LinkedIn”。
“Why LinkedIn”这道我提前准备过。说”我想去大厂”是负分，recruiter 听到会认为你 intent 很低。更好的答法是说具体的技术方向，比如”我想在职业社交这个场景下做 Feed 相关性的工程，LinkedIn 的会员规模和数据密度是这个方向最好的土壤”。我说完 recruiter 明显松了一口气，后面聊得很顺。
然后问了对 LinkedIn 产品的理解——核心 Metrics 是什么、商业模式怎么运转。我说了三块：作为求职平台的职位投递转化率；作为招聘工具（Talent Solutions）的客户续费率；作为内容平台的文章互动率。Recruiter 说”你的理解比较完整”，然后安排了下一步。
提前研究 LinkedIn 的三条产品线（Talent Solutions、Marketing Solutions、Premium Subscriptions）很关键，进去只说”LinkedIn 是找工作的”会直接减分。
Round 2：Phone Screen（项目 + BQ + Coding）
这轮在 CoderPad 上，60 分钟，两个面试官，前 15 分钟聊项目和 BQ，后面直接进 Coding。
BQ 问了一道：讲一次你接受了别人的负面反馈，后来是怎么调整的。这道在 LinkedIn 的后续轮次里也反复出现，他们真的很在意你能不能真实地面对批评，不是让你表演”我非常感谢反馈”，而是要看你实际的判断和行动。
Coding：最少 Worker 数
给定任务的开始和结束时间列表，计算最大并发任务数，也就是至少需要多少 Worker。
把所有时间点拆成”开始 +1、结束 -1″的事件，排序之后扫一遍，维护当前并发数，取全程最大值。时间 O(n log n)，主要开销在排序。
Follow-up 一：结束时间等于开始时间时，能否复用同一个 Worker——取决于题意，要主动 clarify，排序的稳定性会影响结果。
Follow-up 二：一个 Worker 能否同时处理多个任务——这改变了整个问题的模型，面试官说”你能想到这会改变什么就够了”。
Round 3：Coding
这轮纯 Coding，60 分钟。
把货币看成图的节点，汇率看成有向带权边，BFS 搜索路径并把沿途汇率相乘，找不到路径返回 -1。注意双向建边——已知 USD→EUR 的汇率，EUR→USD 就是倒数。
面试官追问了三个优化方向：高频查询场景下缓存已算过的汇率对；用并查集维护连通分量，不连通直接返回 -1 不跑 BFS；浮点连乘误差用对数转换处理（把乘法变成加法再取指数，减少精度损失）。
Round 4：Tech Lead 面——项目深度 + Behavioral
这轮是 Tech Lead，60 分钟，前 20 分钟深挖项目，后 40 分钟全是 BQ，密度最高的一轮。
项目深挖
他盯着我简历上一个分布式系统的模块，连续追问：为什么选这个技术栈、有没有评估过其他方案、遇到了什么性能瓶颈、怎么 profiling、如果重来会改什么。
这轮深挖的坑是只说当初的决策有多好——他要的是你能不能说清楚判断的逻辑，包括当时没考虑到的地方。我有一个点说了”这块我当时没有深入做 profiling，但我的判断是……”，他点头说”OK，继续”。
BQ 五道
第一道是讲一次在工作中处理过冲突的经历，这是 Glassdoor LinkedIn SWE 面试评价里出现频率最高的 BQ。PracHub 指南里特别说了弱答案和强答案的区别：弱答案是”对方不理解系统”，强答案是”我意识到我们在优化不同的风险，所以我把各自的 failure scenario 写下来，比较影响，然后提出了一个小规模验证测试再做决定”。我讲了一次和另一个 team 在 API 设计上的分歧，怎么通过数据驱动的方式收敛了方案。
第二道是讲一个最有挑战的项目，怎么推进的，结果如何。他追问了：如果重来你会改什么——反映出你有没有真正复盘过。
第三道是讲一次快速学习新技术来完成任务的经历。他追问了：讲一个最近学的具体技术以及学的过程。泛泛说”看文档、做项目”不够。
第四道是为什么本地测试通过，线上仍然会出 bug。我说了三个方向：环境差异（配置、依赖版本）、时序问题（本地单线程覆盖不到并发场景）、边界数据（线上真实数据分布和测试数据不一样）。他追问了：你会怎么设计测试减少这类问题——我说了 staging 环境加线上数据 shadow。
第五道是如何处理模糊的需求。先 clarify 成功的定义，拆分成可验证的小目标，对齐之后再动手。
Round 5：LLM 相关 + Coding
这轮前半段考 LLM 基础知识，后半段是算法题。
LLM 部分
面试官先问了 RAG 和 Fine-tuning 的区别。RAG 是检索增强生成，在推理时动态注入外部知识，适合知识库频繁更新的场景，不需要重新训练；Fine-tuning 是在特定数据集上继续训练，适合风格迁移和垂直领域适配，但更新知识库时需要重新训练。
然后问了 Hallucination 的成因和降低方法——成因是模型在训练分布之外生成时缺乏锚定；降低方法：检索增强、降低 temperature、引用约束、RLHF、自洽性检查（多次采样取一致的答案）。
面试官追问了 temperature 降到极端情况的副作用——生成结果会变得重复和保守，对开放性问题效果变差。
Coding：DAG 最长依赖链
在有向无环图中求最长路径。拓扑排序加 DP：维护每个节点的最长入链长度，按拓扑序更新，最后取全局最大值。时间 O(V+E)。
Follow-up 一：带权 DAG——DP 转移时加上边权而不是加一。
Follow-up 二：多个 disconnected components——拓扑排序天然处理了，所有入度为 0 的节点都作为起点，最后取全局最大值即可。
Round 6：System Design
这轮 60 分钟，设计一个类 LinkedIn 的职业社交平台，支持用户资料、好友/关注关系、动态发布和 Feed 流。
先 clarify 了几个问题：DAU 量级、读写比例、Feed 实时性要求、关系链是单向还是双向。面试官说 DAU 一亿、读多写少、Feed 允许秒级延迟、支持单向关注。
数据建模：用户资料用 MySQL（结构化，强一致性）；关系链用 MySQL 关系表按 user_id hash 分片；动态内容用 Cassandra（写多、时序查询）。
Feed 生成：推拉结合——普通用户用推模式（发布时把内容推到关注者的 Feed 队列）；大 V 用拉模式（读取 Feed 时实时拉取，因为推模式下大 V 发一条内容要写几千万份）。Feed 队列用 Redis Sorted Set 按时间戳排序。
面试官追问了热点用户——大 V 的内容被大量并发读取：本地缓存加 CDN，TTL 设短保证实时性。
关系链膨胀的追问——用户关注了十万人，Feed 怎么处理：对关注列表分页，异步预计算，用 Kafka 缓冲写入压力。
Round 7：项目深挖
这轮专门深挖简历上的支付网关项目，60 分钟，基本全程追问。
面试官先让我讲整体架构，然后往下钻：渠道接入怎么做抽象（统一 Adapter 层，每个支付渠道实现相同的接口）、状态机怎么设计（PENDING→PROCESSING→SUCCESS/FAILED/REFUNDED，每次状态流转要有幂等保证）、对账流程怎么跑（每日定时拉取渠道账单文件，和系统内记录逐笔比对，差异进人工复核队列）。
然后问了最难的一块：支付回调重复或丢失怎么处理。
重复回调——收到回调先查幂等表（以渠道的 transaction_id 为 key），已经处理过的直接返回成功，幂等表用数据库唯一索引保证并发安全。
回调丢失——定时轮询任务，对所有 PROCESSING 超过一定时间的订单主动查询渠道状态做补偿。
面试官追问：查询渠道状态时渠道也返回了 PROCESSING 怎么办——继续等待，设置最大重试次数，超过次数后进人工处理队列，不能无限轮询。
Round 8：HM 面
最后一轮是 HM，45 分钟，前半段技术追问，后半段 culture fit。
技术追问
延续前几轮的方向——性能瓶颈在哪里、怎么定位、用了什么工具。我说了用 Flame Graph 定位热点函数，用 async-profiler 在 Java 服务上做 profiling，他点头。
然后问了一道真实题目变体：”假设你加入 LinkedIn，接手了一个遗留系统——测试不完善、监控缺失、响应时间慢，你会怎么做？”
我说了：先做可观测性建设（加 metrics、traces、alerts），用数据定位最高影响的瓶颈，用小步快跑的方式做改进，每次改动都有可测量的结果，而不是一次性大重构。他说”这个方向是对的”。
Culture Fit
又一次问了处理冲突的经历——他的追问方向是：冲突的根源是什么，你当时的判断依据是什么。我讲了一次架构选型分歧，怎么把双方的顾虑都显式化，通过数据验证而不是说服对方来收敛决策。
最后他问了对 LinkedIn 产品的看法：如果你是 LinkedIn 的工程师，最值得投入的技术方向是什么。
我说了推荐系统的冷启动问题（新用户 Feed 质量直接影响留存）和内容审核的实时性。他说”这两块确实是我们在做的事情”，气氛很好。
高频题型总结
综合多份 LinkedIn SWE 面经，按考察频率整理：
Coding 高频方向
区间调度类——最少 Worker 数、会议室分配、区间合并，这类题在 Phone Screen 和 Onsite 都多次出现。
图论——汇率转换（BFS 带权图）、课程表（DAG 拓扑排序）、单词接龙（BFS 最短路），LinkedIn 的 Coding 题里图论出现频率明显高于很多其他大厂。
Top-K 问题——堆维护 K 个最大值、LRU Cache（O(1) 读写）。
数组和字符串——最大子数组（Kadane’s Algorithm）、滑动窗口变体，Phone Screen 热身题常见方向。
System Design 高频方向
Feed 流系统（Push/Pull/Hybrid）、键值存储（Key-Value Store）、通知系统、搜索系统——Glassdoor 真实记录里”design a social media platform”和”design a key-value store”出现了多次。
BQ 高频方向
冲突处理在多轮都出现；接受负面反馈；快速学习新技术；处理模糊需求；项目失败的教训。LinkedIn 的 BQ 不是走过场，每道都会往下追问两三层。
备考 Timeline
第 1-2 周：基础补全
每天 2 到 3 道 LC Medium，重点覆盖区间调度、图论（BFS/DFS/拓扑排序）、Top-K 堆、滑动窗口这四个方向。同时把 LinkedIn 的三条产品线研究透彻，了解每条线的核心 Metrics。
第 3 周：系统设计专项
每天一道系统设计题，重点准备 Feed 流（推拉结合的权衡是 LinkedIn 面试的核心考点）、键值存储、通知系统。每道题要能把 clarify、数据建模、核心架构、追问处理四块都说清楚。
第 4 周：项目深挖准备
把简历上最复杂的 1 到 2 个项目从以下维度全部想透：为什么选这个技术栈、遇到过什么瓶颈、做过什么 profiling、如果重来会改什么、并发量翻十倍系统会在哪里先挂。能回答到这个深度，Tech Lead 面和 HM 面就不会被问倒。
第 5 周：BQ 打磨
准备 5 到 6 个真实的项目故事，覆盖冲突处理、接受负面反馈、快速学习新技术、处理模糊需求这四个方向。每个故事要准备到第三四层追问的深度——你当时为什么这么判断、有没有考虑过别的选项、事后复盘了什么。
FAQ
LinkedIn 八轮是标准配置吗？
不是，NG 岗通常 4 到 5 轮，资深岗位才会到 6 到 8 轮。提前问 recruiter 确认这次 loop 包含哪些环节。
BQ 里”冲突处理”为什么在这家反复被问？
LinkedIn 在真实工作里会碰到大量跨 org 的合作和分歧，冲突处理能力是真实的工作技能。准备一个有具体行动和结果的真实故事，比背一套完美答案重要。
System Design 那轮需要画图吗？
通常用共享白板，但不强制。更重要的是把每个设计决策背后的 tradeoff 说清楚，画图只是辅助。
LLM 那轮需要很深的 ML 背景吗？
不需要，考的是 LLM 应用层的基础概念——RAG 和 Fine-tuning 的区别、Hallucination 的成因和缓解、temperature 的作用，理解业务层的应用场景就够了。
Team Matching 是什么，会影响结果吗？
VO 通过之后还有 Team Matching 阶段，候选人通过了但没有团队有 headcount 时会被 delay，可以主动问 recruiter 进度，这不是你的问题。
LinkedIn 这套面试，信息差是真实存在的
有在准备 LinkedIn 或其他大厂的同学，可以来找我们聊聊。InterviewShow 做过 LinkedIn、Google、Meta 这些公司的面试，项目深挖的打磨、汇率图论题、Feed 系统设计、支付幂等这几块都有专门覆盖，一对一跟着走。有需要的来聊。