我去年暑期通过校招流程拿到了腾讯IEG后台开发的实习offer整个面试周期大概三周一共经历了五次面试。面完后最大的感受是IEG的面试风格和市面上流传的很多面经不太一样它特别看重你对高并发、海量数据、线上稳定性这三件事的真实理解而不是单纯背书。这篇面经我拖了很久才写就是想把自己踩过的坑、复盘出来的经验整理得完整一点给准备投IEG后台开发方向的同学做个参考。先交代一下我自己的情况某211硕士实验室方向是分布式存储实习过一家中型互联网公司做的是用户增长后台的接口开发。技术栈以C和Go为主会用MySQL、Redis、Kafka对容器化部署有一定了解但不算深入。下面所有内容都是我真实的面试回忆加复盘总结部分细节做了脱敏处理但考察角度和答题思路绝对原汁原味。1. 面试前的准备搞清楚IEG后台开发到底在招什么人1.1 岗位定位与考察侧重点解析IEG是腾讯互动娱乐事业群旗下有王者荣耀、和平精英、英雄联盟、穿越火线等核心产品线。所以IEG后台开发的技术场景基本可以概括为四个关键词超大流量、极端峰值、实时性要求高、稳定性优先级极高。具体来说游戏后台和普通互联网后台有本质区别游戏玩家在线状态需要实时维护对局匹配要毫秒级响应战斗数据同步不能有肉眼可见的延迟。这意味着面试官考察的重点会集中在高并发架构设计、缓存与数据库一致性、分布式系统的可用性保障上而不是简单问几个八股题。我在准备阶段梳理了IEG后台开发的核心技术栈清单C或Go语言大部分团队用C写核心战斗逻辑Go写接入层和微服务、MySQL和Redis必考而且是深挖级别的考、Kafka或CMQ消息队列、分布式一致性协议Raft、Paxos概念要懂、网络编程epoll、Reactor模式几乎是必问。这里要提醒一点IEG的面试官非常看重研究课题或实习项目与岗位的匹配度。如果你的项目经历和游戏后台完全没有关系一定要提前找到两者之间的关联点。比如我实习做的用户增长后台虽然和游戏无关但涉及了618大促的流量峰值这和游戏开服时的瞬间流量冲击是非常相似的场景面试时我就反复强调这个共通性。1.2 简历项目怎么讲才不会被追问到翻车IEG的面试官追问项目的能力很强基本是顺着你的回答一层层往下挖。我自己总结了一个三层讲述法第一层讲项目背景和整体架构30秒内说清楚第二层讲自己负责的模块和核心难点重点展开第三层讲攻坚过程和数据效果这是加分项也是追问最多的地方。以我实习做的那个用户增长项目为例我的讲述框架是这样的项目背景是活动大促期间接口QPS峰值会从日常的5万冲到30万导致数据库连接池被打满接口RT从20ms飙升到800ms。我负责的模块是做一层本地缓存加分布式缓存的多级缓存方案把核心查询接口从直接查DB改为先查本地缓存Caffeine再查Redis最后回源DB。攻坚点是缓存击穿和穿透的防护我用互斥锁加布隆过滤器解决了。最终效果是接口RT稳定在15ms以内数据库QPS从3万降到3000以下。这套讲法在面试中非常管用因为面试官可以顺着缓存击穿怎么解决布隆过滤器误判率怎么控制缓存的key怎么设计才能避免热点集中这些点继续追问而你因为确实做过每个点都能接得住。1.3 基础知识的复习范围与重点取舍基础知识的复习范围我在前面已经列过这里重点说取舍策略。我的复习优先级是Redis源码级理解SDS、跳表、字典扩容、持久化机制大于操作系统进程线程、内存管理、文件系统、IO多路复用大于MySQL索引结构、事务隔离级别、MVCC、锁机制大于计算机网络TCP四次挥手、TIME_WAIT、HTTP/HTTPS、HTTP2.0大于分布式理论一致性算法、分布式事务、服务治理。为什么Redis优先级最高因为我后来复盘IEG面试中Redis几乎是每轮都会出现的角色一面问基础、二面问场景、三面直接给一个游戏业务场景问你怎么用Redis去设计。而且Redis的问题最容易拉开差距多数人能说出八股定义但只有深入理解源码的人才能在场景题和压测问题中给出有说服力的答案。2. 面试全流程实录从简历筛选到HR面共五轮2.1 一面电话初筛与基础问答我的第一面是电话面试时长约40分钟。这一面相对基础面试官主要确认三件事你的基础功底够不够扎实、你在实习中承担的角色是不是核心开发、你的表达能力和沟通能力是否合格。具体问题统计如下自我介绍要求结合项目经历不要复述简历C中智能指针的实现原理、引用计数是原子操作吗vector扩容机制、为什么是1.5倍或2倍、扩容时迭代器为什么失效TCP和UDP的区别、为什么游戏对战一般用UDP而直播用TCP进程间通信方式有哪些、共享内存为什么最快、多线程下如何保证共享内存数据安全MySQL的聚簇索引和非聚簇索引区别、为什么InnoDB必须有主键Redis持久化机制比较RDB和AOF的优缺点、混合持久化是怎么设计的一面的问题虽然基础但面试官会追问细节。比如问我vector扩容我答完扩容倍数后面试官接着问为什么标准库不采用固定1.5倍而是不同编译器实现不同这其实考察你是否真正理解扩容的内存分配策略和时间复杂度权衡。我当时答到了1.5倍可以实现内存复用空间换时间2倍虽然均摊复杂度一样但无法利用之前的空闲内存面试官比较满意。这里想说的核心经验是基础知识复习不要只背结论一定把为什么搞清楚。计算机基础的东西很多时候不是非黑即白的判断题而是权衡取舍的工程决策你能讲清楚决策背后的依据面试官才会觉得你是真的懂。2.2 二面核心技术面与手撕代码二面是视频面试时长约1小时是整轮面试中最硬核的一轮。面试官先问了一个多小时的技术问题然后出了一道中等偏上的算法题。技术问题的考察覆盖了操作系统、网络、数据库和Redis最让我记忆深刻的是下面这几个在操作系统方面面试官问了进程和线程的本质区别这个问题看起来是送分题但面试官要求从内核视角回答。我当时从task_struct、地址空间、文件描述符表、内核栈这几个维度展开特别强调了线程的创建和切换并不总是比进程更轻量因为涉及mm_struct的共享和私有VMAs处理面试官追问了协程是否更轻量以及为什么我给到了协程切换与线程切换的本质区别是用户态栈和内核态栈的切换差异。在网络方面面试官详细追问了TFOTCP Fast Open、拥塞控制的演进Reno、Cubic、BBR的区别、TIME_WAIT过多对高并发服务器的影响以及如何优化。其中TIME_WAIT这个点我印象很深因为这是实战项目里真实遇到的问题我详细讲述了实习时线上服务器因为TIME_WAIT导致端口耗尽的事故案例以及用tcp_tw_reuse加长连接池的方式处理的经验。在MySQL方面面试官给了一个具体的SQLSELECT * FROM t WHERE a 1 AND b 10 ORDER BY c LIMIT 100问如何建立联合索引。这题考察的是最左前缀原则、排序字段如何利用索引、范围查询对索引使用的影响。我给出的思路是(a, b, c)或(a, c, b)两种方案的选择取决于b的范围查询选择性如果b的选择性高可以用(a, b, c)如果c排序的需求更强烈可以用(a, c, b)。手撕代码题目是LRU缓存要求实现get和put操作时间复杂度O(1)。这个题我专门准备过使用HashMap加双向链表实现HashMap记录key到链表节点的映射链表按访问时间从新到旧排列。考虑到页面加载时的稳定性和无状态要求我选择了用C实现手动构造链表节点结构体不借助STL容器。面试官看完代码后追问了两个问题为什么不用vector或deque实现因为中间插入删除是O(n)不符合要求如果考虑并发场景如何保证线程安全我回答可以在HashMap的get加读锁、put加写锁的基础上再用细粒度锁优化热点key。2.3 三面技术终面与场景设计题三面通常是由更高职级的面试官或部门负责人进行时长约50分钟。这一轮的风格和二面完全不同不太纠缠基础知识而是直接扔给你一个业务场景让你完整地设计一套技术方案。我的场景题大致是这样某个节假日晚上八点一款游戏的抽卡活动准时开启用户同时在线峰值预计会达到500万请设计一套后台架构支撑这次活动重点关注充值、抽卡、物品入账三个环节的稳定性和一致性。这个问题考察的是你有没有全局架构能力而不只是某个点的技术深度。我当时面试的回答较成体系后来复盘又做了优化核心的答题思路是流量接入层用API网关做限流令牌桶和灰度染色把请求打散到接入层集群业务逻辑层按用户维度进行哈希路由保证同一个用户的请求落到同一台业务节点上减少分布式缓存和数据层的并发冲突存储层采用主从MySQL加Redis热数据缓存充值订单写入时用本地消息表加异步MQ保证最终一致性抽卡概率计算放到独立的抽奖服务中基于用户ID加时间戳做种子进行伪随机计算物品入账通过消息队列削峰由消费端异步幂等写库。面试官针对这个方案追问了很多细节其中几个关键问题值得分享抽卡服务的原子性怎么保证用户A在一秒钟内并发发送十次抽卡请求如何避免超买超发我的回答是用Redis的Lua脚本把扣减次数和发放结果原子化通过在脚本内部先判断用户剩余抽卡次数再执行扣减逻辑最后把抽卡结果写入记录整个操作不存在竞态条件因为Lua脚本在Redis中是单线程执行的。关于如何保证物品入账不丢失我提到了消息队列的ack机制和本地消息表的最终状态机比对以及引入对账任务作为兜底每天凌晨扫描异常的入账流水自动重放或者人工介入。三面结束后面试官说了一句话让我至今记忆深刻好的架构不是堆砌中间件而是想清楚每个环节出问题时的降级方案。这句话真的值得所有想做后台开发的同学反复琢磨。2.4 四面/五面交叉面与HR面四面实际上是交叉面面试官不是目标部门的主要考察候选人的基础广度和深度有没有明显短板。这一轮会随机提问基本就是你简历里写了什么他就问什么而且专门挑你不经常准备的地方问。我简历里写了一个基于OpenResty和Redis实现分布式限流网关的小项目。面试官没有问我熟悉的漏桶和令牌桶算法而是问网关是多实例部署的你的分布式限流依赖了Redis如果Redis集群出现网络分区网关该怎么处理才能不影响正常业务说实话这个问题我当时答得不太好只想到降级成本地限流但没有考虑到降级后多实例限流阈值需要相应调低否则会产生流量超限的连锁反应。这个经历给我的教训是写在简历上的每一项内容都要站在面试官角度推测至少五个追问问题并且把每个追问的答案都想清楚。交叉面问的恰恰是你最不设防的角落。HR面相对轻松主要考察稳定性、团队协作能力、工作意愿。但有几个点还是值得注意HR会问你实习时间、能实习多久、对工作地点有没有要求也会问你有没有在面别的公司、目前的offer情况。这些问题的回答策略是真诚但不失技巧实习时间建议表达出稳定性和充足性其他offer的情况可以如实说但不要显得在压价尽量让HR觉得你是经过慎重考虑后对腾讯IEG有明确意向的。3. 高频考点深度拆解每一道题背后的考察逻辑3.1 操作系统与网络面试官最爱深挖的几个点操作系统和网络是后台开发面试的基石IEG的面试官尤其中意这几个点进程内存布局的区别尤其是堆和栈从高地址向低地址增长的方向、栈溢出和堆溢出的不同表现、栈上分配和堆上分配的性能差异。如果被问到建议画图说明最好能把代码段、数据段、BSS段、堆、栈、内核空间这个完整布局讲出来然后说清为什么栈从高地址向下生长而堆从低地址向上生长栈和堆相向扩展最大化利用有限的地址空间。多线程编程中的内存序问题这个问题是C后台岗位的高频考点。面试官会给一段多线程代码问在x86平台上会不会有问题在ARM平台上会不会有问题为什么。这背后是CPU指令重排和缓存一致性协议MESI在起作用。要答好这个问题得理解std::atomic的内存序参数memory_order_relaxed、memory_order_acquire、memory_order_release各是什么语义哪些场景会产生可见性问题和顺序违例。IO多路复用中select、poll、epoll的演进和区别是必考内容。关键点包括select的FD_SETSIZE限制默认1024、每次调用都要把fd集合从用户态拷贝到内核态、内核遍历fd的时间复杂度O(n)epoll通过红黑树维护fd集合、通过回调机制让内核主动通知可用事件、触发模式有LT和ET两种、边缘触发在处理非阻塞IO时要循环到EAGAIN。IEG的面试官可能会进一步问在单线程Reactor模式下如果某个事件处理回调里做了耗时操作会阻塞整个事件循环该怎么解决。标准答案是引入线程池将耗时操作投递到线程池处理主线程只负责事件分发和高速小任务。TCP三次握手和四次挥手是被问烂了的话题但IEG问的更细服务端处理大量TIME_WAIT连接会有什么问题如何优化客户端大量处于SYN_SENT状态意味着什么TCP快速重传和SACK机制的作用在游戏场景下如果要保证可靠UDP你会怎么设计应用层确认机制。3.2 数据库、缓存与消息队列场景化考察特别多IEG面试中的数据库问题很少只停留在SQL层面通常会结合业务场景来考察。我在面试中遇到的几个高价值问题MySQL索引失效的场景有哪些这也是高频八股题但面试官会在此基础上继续追问有一个联合索引(a, b, c)查询条件是WHERE a 1 AND c 2这个索引会不会生效答案是会走索引但只能用到a字段的部分c的等值条件无法在索引内命中会产生回表。这个问题的引申是如果查询是WHERE a 1 ORDER BY c排序能否也走索引与前面二面的问题形成了很好的呼应。分库分表是IEG重点考察的内容。面试官如果发现你做过相关项目会问你是按什么维度分片的分片键怎么选跨分片的事务怎么处理分片后全局唯一ID怎么生成全局ID的标准回答是用美团Leaf的snowflake模式或数据库号段模式关键点是保证全局唯一性、趋势递增、高可用。不建议只说用UUID因为UUID随机性导致索引页分裂严重且存储空间占用量大。Redis缓存和数据库的一致性问题是所有后台开发面试的必考重点。我这里也给出一个可靠通用的回答框架先更新数据库再删除缓存Cache Aside Pattern这是目前最通用的方案。为什么不能先删缓存再更新数据库因为如果删完缓存后数据库更新失败下一次请求会把旧数据加载回缓存导致缓存长期脏数据。先更新数据库再删缓存也会有窗口期更新数据库后尚未删除缓存期间有请求读到旧缓存值。解决方法是对缓存设置短TTL兜底例如1~5分钟或者采用延迟双删。如果要求强一致性依靠Redis缓存其实很难做到应该考虑用数据库自身的能力如读写分离、binlog订阅来驱动缓存更新让缓存成为数据库的派生视图。Key过期和淘汰策略也是IEG面试的高频考点。除了八股式的八种淘汰策略背诵面试官往往更关心热点key突然过期多个请求同时回源数据库产生缓存击穿怎么解决大量key同时过期导致数据库压力突增怎么处理。我的回答方案是互斥锁只允许一个请求回源重建缓存可以用Redis SETNX实现再加上布隆过滤器拦截根本不存在的数据请求同时各过期key的TTL加入随机偏移量打散过期时间。消息队列方面IEG主要考察你如何保证消息不丢失和不重复消费。不丢失要区分生产者、Broker、消费者三个环节生产者用同步发送Broker用持久化和多副本机制消费者消费成功后手动提交offset。不重复消费要做幂等设计数据库唯一约束、Redis SETNX加业务状态标记、消息体携带唯一业务ID做去重。Kafka的ISR机制和ack参数配置0、1、all也会是考察点面试官期待你能说出不同配置对可靠性和延迟的影响差异。3.3 手撕代码题型与答题策略总结IEG的手撕代码基本集中在LeetCode中等难度偏重数据结构和基础算法。我整理了自己面试遇到和周围同学反馈的高频题型LRU缓存HashMap加双向链表反转链表系列迭代、递归两种写法都要熟练最大子数组和Kadane算法注意空间复杂度可优化到O(1)手写线程池核心线程数、队列、拒绝策略、线程安全最长公共子序列/最长递增子序列动态规划和二分优化都要会二叉树的层序遍历/Zigzag遍历BFS框架要滚瓜烂熟手写生产者消费者用互斥锁加条件变量或者用信号量字符串转整数注意边界条件和溢出判断做题策略上我的经验是先和面试官确认清楚需求和边界条件再动手写。不要拿到题目就直接闷头写。比如LRU缓存你先要确认key和value的类型、是否需要泛型支持、容量上限是多少、达到上限后的淘汰策略是什么。确认完需求再开始写然后边写边解释思路。代码写完后主动用测试用例走一遍逻辑特别要覆盖边界情况比如缓存为空时get操作、容量为1时连续put不同key的场景。关于语言选择C或Go是为IEG加分的选择。如果使用C需要注意内存管理、智能指针的正确使用、C11及以后的标准特性如果使用Go要注意goroutine和channel的使用。4. 复盘与经验总结哪些坑是新人最容易踩的4.1 简历上夸大其词的惨痛教训我在交叉面时被面试官抓到过一次隐性夸大。简历里我写了实现了基于滑动窗口的分布式限流算法但面试官问到滑动窗口的边界条件处理前一个窗口未满加上本窗口新进的请求如何避免流量突刺时我确实没有把细节讲透。那个瞬间我意识到简历上的一行字面试官可以追问半小时如果没做过或者没有深入理解绝对不要往上写。后来我把简历里的所有技术点都做了标注熟练掌握能讲原理、能对抗追问、熟悉能说清基本机制、能回答常见问题、了解能说概念、能说出应用场景。这种分级方式让我在面试前有明确的复习重点不会盲目把所有内容平均用力。4.2 基础不牢导致的连锁溃败我在模拟面试中发现过一个特别典型的问题基础题答得不够快导致场景题时间不够。后来我才意识到基础部分的回答时间应当控制在15到20分钟内只有这样才能给场景题留出充足的展示时间。为了提升基础题的熟练度我反复练习高频问题的一句话结论加一段解释模式例如问哈希表冲突怎么解决一句话结论是链地址法和开放寻址法。解释时展开说在Redis中采用了链地址法而Java的ThreadLocalMap使用的是开放寻址法因为ThreadLocal的key数量少且冲突概率低。问什么是零拷贝一句话结论是DMA拷贝加内核态直接映射到用户态减少用户态与内核态之间的数据拷贝次数。解释时展开说sendfile和mmap的区别以及Kafka为什么用sendfile来加速消息消费。问什么是缓冲区溢出一句话结论是写入的数据长度超过缓冲区容量覆盖相邻内存区域。解释时说明用向量化IO加长度校验来防御。这个一句话结论加一段展开的训练方法非常管用它能保证你对高频考点形成条件反射同时又能展示技术深度。4.3 表达逻辑与技术深度同样重要面试不仅仅是答题还是在有限时间内向一个资深工程师展示你的思维过程和工程判断。我在模拟面试中发现同样是答对了一道题表达逻辑清晰的人比思维跳跃的人给面试官的印象分高出很多。我总结了一套实用的回答框架先给结论再讲原理最后举例子或说工程权衡。例如被问到MySQL为什么用B树做索引我可以回答先给结论因为B树能同时兼顾范围查询、排序性能和磁盘IO次数优化。接着讲原理B树的非叶子节点不存数据所以单节点能存更多索引项树的高度更低查询固定3到4次IO就能完成叶子节点用链表串起来天然适合范围扫描。再讲权衡如果用哈希索引等值查询非常快但无法做范围查找红黑树AVL虽然平衡性好但因为每个节点都会占用磁盘IO数据量大时IO次数明显更多。最后补一句InnoDB的主键索引是聚簇索引叶子节点直接存整行数据也正因如此主键的插入顺序和物理存储顺序强相关所以推荐自增主键而不是随机UUID。这套框架在应对绝大多数面试问题时都适用尤其是三类高频问题——原理类为什么这么设计、场景类如果线上出现XX怎么办、对比类A和B有什么区别、各适合什么场景。4.4 面试时间线与offer沟通技巧从投递简历到完成全部面试我的时间线是三周。第一周约二面第二周约三面和交叉面第三周HR面。腾讯的流程推进速度整体是比较高效的前提是你每一轮的反馈都足够好。如果你在某轮面试后一周内没有收到下一轮通知建议通过官方招聘渠道或内推人问一下进度不要干等。拿到offer后的沟通也需要注意技巧HR在谈薪资和入职时间时如果你有其他offer可以坦诚说明但不要用来过度施压。我当时如实说了有另一家公司的offer但明确表示IEG的岗位方向与我的长期规划更匹配并且强调了自己能实习的时长和稳定性HR沟通很顺畅。还有一个很多同学容易忽略的细节IEG内部的团队非常多不同团队的业务周期、技术栈、加班强度差异很大。如果你还没有明确偏好面试前可以了解一下你投递的事业群下面主要业务是哪些在交叉面或HR面时表达出对具体业务的了解和兴趣这会在一定程度上加深面试官对你的印象。5. 实用避坑指南送给准备投IEG后台开发的同学5.1 简历投递渠道与时间节点的选择腾讯实习招聘主要有三个渠道官网投递、内推、校园招聘会现场投递。内推的优势是简历会被优先处理且你可以在内推系统上看到面试进度状态。不建议多个渠道重复投递因为系统会合并你的投递记录多个重复申请反而会让HR觉得你目标不明确。时间节点上腾讯的暑期实习招聘一般在前一年的三月份启动部分团队会提前到二月份甚至在寒假期间就开始面试。如果目标是暑期实习建议尽早投递。腾讯的招聘机制是先到先得、招满即止好的团队名额有限越早投递竞争压力相对越小。日常实习非暑期的窗口期更灵活全年都可以投递。但日常实习的转正名额不像暑期实习那么多如果想通过实习转正尽量争取暑期实习的身份。5.2 面试中出现不会回答的问题该怎么办没有人能保证面试中每道题都会关键在于不会的时候怎么处理。我在面试中遇到过两个完全没准备的问题处理方式分别是第一个问题是在三面场景题中关于分布式链路追踪如何实现。我当时确实没有深入研究过但我知道链路追踪的核心是traceId和spanId的传递。我就从这个问题出发结合自己的理解讲了一个基础版的实现方案在网关层生成全局唯一的traceId通过RPC框架的元数据传递到下游服务日志框架自动打印traceId然后按traceId聚合查询整个调用链采集到的链路日志写入ES或ClickHouse配合Jaeger做可视化。当时面试官给我的反馈是虽然不是最优方案但能看出我有较强的工程推导能力。第二个问题是在交叉面问我OpenResty限流降级方案怎么处理Redis不可用。这个问题我一开始有点懵但马上想到了软件设计上的降级兜底优先于复杂方案的原则主动回答如果Redis不可用网关层可以降级为本地限流但要注意把限流阈值折减因为多个实例独立限流的总和会超过目标阈值。我又补充了通过心跳检测感知Redis故障并触发降级开关以及恢复后如何平滑切回而不是直接打满流量导致雪崩。所以核心经验是遇到不会的问题不要慌、不要装懂先把自己能关联上的知识讲出来再诚实地说明自己在这个方向研究得不够深入然后补充自己理解的思路。面试官更看重你是如何思考和推导的而不是你什么都见过、什么都精通。5.3 面试结束后的复盘与改进方法每轮面试结束后我建议当天就做复盘。趁印象还清晰把被问到的问题全部记录下来分类标注答得好的、答得一般的、完全不会的。对于答得一般的题目立刻去查资料把正确答案整理成文档对于完全不会的题目优先看官方技术博客和高赞技术分析文章搞清楚核心概念后用自己的话复述一遍。我还专门做了一个面试题库表格记录每轮面试的问题和我的回答要点包括面试官追问的角度。回过头来复习时这些真实面试记录比网上任何面经都更有参考价值。你甚至可以从中发现面试官的关注偏好和出题风格为后续轮次的准备提供方向指导。5.4 实习期间快速融入团队的建议拿到offer只是起点实习期间的表现决定了能否转正。我周围转正成功的同学普遍做了这几件事用一周时间摸清项目的完整系统架构而不只是自己接手的模块。包括上下游依赖、核心数据流、监控告警大盘。找到团队内部的技术文档库阅读核心模块的设计文档。理解为什么这样设计是快速融入团队的关键。主动要活干但不要盲目承诺。每天同步进度遇到风险提前暴露不要等到deadline前才说做不完。提交代码前自己先自测最好能补上对应的单元测试。在导师review代码后认真处理每一条评论哪怕有不同意见也要先讨论清楚再修改不要闷头把代码改了重推。在周会或分享会上主动做一次技术分享内容不用高大上哪怕是你读了一篇好文章、踩了一个坑都可以拿出来讲。这能帮你在团队里建立愿意分享、善于总结的印象对转正评审非常加分。说到底面试和实习都是同一个逻辑你是不是一个靠谱的人能不能把事想透、把活干成、把坑说清楚。技术能力当然重要但我见过太多技术不错却在表达和沟通上吃亏的人。反过来能把自己的思考过程讲得清清楚楚的候选人哪怕个别知识点薄弱面试官也愿意给机会。这一点在IEG的面试中体现得尤其明显希望这篇面经能帮你少走一点弯路。