前阵子整理硬盘翻出来一份落灰的PDF文件名写着“欢聚时代2017校招笔试iOS工程师类C卷”。当时我在帮一个学弟做校招复盘顺手把这份卷子从里到外过了一遍越看越觉得有意思。2017年正是直播和短视频烧钱最猛的年份YY、虎牙、斗鱼都在疯狂扩张欢聚时代的iOS岗也成了香饽饽。这份C卷虽然只有薄薄几页却把当年筛选iOS新人的思路写得很清楚不考花哨的新特性就考你对Objective-C、内存、Runtime、并发和性能优化的底层理解。这篇文章不适合只想背题库的人适合那些真想把iOS基础吃透、想知道一张校招笔试卷子背后出题逻辑的同学。我会把C卷的题型结构、每类题背后的考点、以及现在回看哪些知识仍然值钱全部拆开讲一遍。中间会夹很多我后来面试别人时发现的高频误区和实操经验这些都是当年踩坑换来的。1. 一份C卷的定位2017年欢聚时代校招到底在筛选什么1.1 试卷背景直播风口下的iOS岗先把时间拉回2017年。那一年iOS 11刚发布iPhone X的刘海屏还没完全铺开Swift 4.0正式版出来了但主流商业项目还在用Objective-C。欢聚时代是YY母公司当时直播业务正值巅峰期用户量、营收都在往上冲对iOS端的要求非常具体要能接得住高并发的互动消息要能在中低端机型上把直播App做到流畅不烫手还要能快速迭代那么多直播间玩法。这种业务形态决定了笔试不会太“学院派”。我当时拿到这份C卷的感受是它不像考研题那样绕而是直奔iOS开发的真实战场。所有题目几乎都能在开发日常里找到影子——属性怎么声明、block为什么会循环引用、Tableview滑动为什么掉帧、一个对象为什么没被释放。出题人摆明了要招那种“不是只会拖控件而是明白系统底层怎么工作”的人。1.2 筛选逻辑校招笔试不是考你会不会而是考你的“底层理解”很多人把校招笔试当成期末考试来准备死记硬背了一堆API结果看到C卷就懵了因为试卷里几乎没有“某某API的返回值是什么”这种送分题。它更喜欢的出法是这样的给你一段代码让你说出输出结果给你一个使用场景让你分析有没有问题或者把两个容易混淆的概念放在一起让你讲清楚区别。对应届生而言这种出题方式其实挺公平。大家都没有多少工程经验拼的就是大学期间有没有认真看过官方文档、有没有自己动手写过Demo、有没有在报错之后刨根问底。我在后来面试新人的时候也发现能把“weak为什么不会增加引用计数”讲透的人写代码时碰到崩溃问题的排查速度通常比只会背答案的快一个量级。C卷的出题人显然也是这个思路。1.3 阅卷视角的踩分点从阅卷老师的角度一份卷子发下去并不是按点给分那么死板。他们更看重几个信号概念表述是否准确、代码变量命名是否规范、算法题有没有考虑边界条件、开放题给出的方案是否具备可落地性。我见过不少同学简答题写得滔滔不绝但核心术语写错了比如把“消息转发”和“方法实现”混为一谈这种错误在阅卷时非常扎眼。反过来如果一道算法题你确实不会写完整代码但能把暴力解法的思路写出来把时间复杂度假设计算出来也会拿到相当一部分分数。原因是校招笔试本质上是海选阅卷人想知道的是你的思考路径能不能在引导下走通。所以整份C卷的答题策略可以总结成四个字宁可多写。多写不是瞎写而是把分析过程、边界条件、可能的优化方向都展示出来。2. 卷面盘点题型分布、时间分配与踩分策略2.1 C卷题型结构一览虽然不同批次的卷子会有差异但C卷整体结构基本稳定可以归纳成四类题型题目数量单个分值考察重点选择题8-10题中等属性关键字、ARC、多线程、UI概念填空题/代码输出6-8题中等引用计数、block、RunLoop执行顺序简答题3-4题较高Runtime、内存管理、网络机制算法与设计题2-3题最高算法、架构设计、性能优化整套卷子的完成时间一般是90到120分钟。说实话这个时间对于知识点熟的人来说足够做完但对那些在每道题上反复纠结的人来说非常紧张。C卷里简答题和算法题分值最重选择题每道只有几分所以如果你时间不够用优先保简答题别在选择题上磨太久。2.2 时间分配策略我复盘这套卷子时给学弟画过一个时间节奏实操下来比较稳前5分钟通读全卷把所有题目扫一遍在题目旁边标“会”“半会”“不会”三个记号。这五分钟是调试心理预期用的避免一上来就死磕一道题导致后面时间崩盘。选择填空控制在25分钟内。这一部分大部分是概念题会就是会不会就凭第一直觉别回头改。回头改答案在校招笔试里翻车概率极高。简答题留足40分钟。每道题至少要写出一半篇幅不管会不会把相关的概念、流程、结果全往上堆。算法和设计题放在最后40分钟左右先写思路再写代码。有些同学总想把代码写完才落笔结果时间不够思路一个字没留非常可惜。2.3 阅卷视角的踩分点阅卷人看卷子其实是在开盲盒。一份卷子如果字迹清楚、代码缩进规范、关键术语都落到了点上第一观感就会好很多。我后来帮人力筛简历时见过太多卷子写“block会循环引用的问题”只写一句“会循环引用”后面没了。这种答案等于没答。阅卷人真正想看到的是你能说出循环引用形成的三个条件对象持有block、block持有对象、形成闭环然后给出至少两种解决方案weak-strong dance、把block改成非逃逸闭包或代理再举一个NSTimer或网络回调的实际场景。同样的知识点答题深度不同得分是天壤之别。踩分还有一个技巧简答题里如果要求“简述”写到关键步骤即可如果要求“说明”就要把因果链条写完整如果是“谈谈你的理解”一定要带入具体场景。C卷里有不少“谈谈理解”的题这种题没有标准答案但有一个共同评价标准——你是不是真的踩过坑。3. 基础题深挖属性关键字、内存管理与weak的底层逻辑3.1 属性关键字那组题看着简单处处是坑C卷选择题部分几乎必考一组属性关键字辨析题比如property (nonatomic, copy) NSString *name; property (nonatomic, strong) NSMutableArray *data; property (nonatomic, weak) id delegate;这组题看起来基础但里面埋的坑特别深。第一个坑是copy和strong。很多同学背了“NSString用copyNSMutableString用strong”但没搞明白为什么。如果用strong修饰一个NSMutableString外部把同一个可变字符串对象赋给属性后再修改这个可变字符串name指向的内容也会被改动相当于属性值被外部篡改。用copy会把传入对象做一次不可变拷贝属性内部持有一个值为赋值瞬间快照的不可变字符串后续外部怎么改都不受影响。第二个坑是weak与unsafe_unretained。两者都不会增加引用计数但weak在对象释放后会自动置为nil而unsafe_unretained会留下一个野指针。C卷里的陷阱题往往会给出一个dealloc之后访问unsafe_unretained属性的场景让你选结果是崩溃还是不崩溃。正确答案是“大概率崩溃而且是难以排查的野指针崩溃”因为unsafe_unretained不会自动置nil。第三个坑是atomic。很多人以为atomic就是线程安全这完全是被“原子性”这个翻译坑了。atomic只能保证属性的getter和setter是原子操作也就是说你在多线程环境下同时赋值和取值不会取到半初始化状态的值。但它保证不了业务逻辑线程安全比如两个线程同时读、改一个字典属性虽然getter/setter原子但“读出来再改进去”这个复合操作并不原子。3.2 引用计数与autorelease的深层问题C卷简答题里有一道高出现率题给你一段ARC下的代码问你对象什么时候释放。这类题考的就是有没有真正理解引用计数而不是背一句“引用计数为0时释放”。ARC下strong会在赋值时retain并在旧值释放时releaseweak在对象销毁后置nil并且weak引用本身注册在runtime的SideTable里copy会先做一次拷贝再强引用。这些不是概念而是每条语句背后真实发生的事情。更阴险的是autorelease与RunLoop的组合题。比如- (void)viewDidLoad { [super viewDidLoad]; __weak id weakObj; autoreleasepool { id obj [NSObject new]; weakObj obj; } NSLog(%, weakObj); }这个流程里obj是strong局部变量出了autoreleasepool作用域就会被释放因为ARC会在作用域结束位置加release所以weakObj在NSLog时已经是nil。如果把[NSObject new]换成[NSObject autorelease]或某些系统方法返回的autorelease对象结果就会变成弱引用仍然有效因为对象还在当前autoreleasepool里要到pool被drain时才释放。这类题核心考的是ARC只管在作用域结束时插入releaseautorelease则是把release延迟到pool销毁时。真题里还有一种变化是问“自动释放池什么时候销毁”。标准答案是主线程RunLoop在一次循环结束时对autoreleasepool做drain。如果一段代码不经过RunLoop比如在后台线程的dispatch_async里手动开启autoreleasepool释放时机就由那个pool的边界决定。把这条逻辑串起来你就能解释为什么大量创建临时对象时要用autoreleasepool包裹不是为了提前释放strong对象而是为了及时回收autorelease对象。3.3 循环引用的所有经典场景循环引用这题在C卷里几乎算是必考题它考察的其实是一个工程师对对象生命周期的敏感性。标准场景包括三块第一块是block。控制器持有block属性block体里又引用了self形成self - block - self的闭环。解法是__weak typeof(self) weakSelf self在block内再用一个strongSelf持有一次避免执行过程中self被提前释放也避免每次访问weakSelf都加一次weak变量开销。第二块是delegate。这里有个非常容易忽略的点delegate属性是weak但如果你在dealloc里忘了把delegate置nil同时delegate是强引用的话依然可能形成循环。反过来如果一个对象被某个单例强持有再强持有单例也会形成循环。C卷一般会考“为什么delegate用weak不用assign”答案最后都要落到weak自动置nil上。第三块是NSTimer和CADisplayLink。NSTimer会强持有target如果在控制器里创建了一个timer属性并重复执行blockblock里又用了self就又多了一层循环。更常见的坑是定时器对象被添加到RunLoop之后如果不主动invalidate即使控制器dealloc了timer依然存在导致控制器无法释放。所以内存题里出现NSTimer答案一定要带上“在viewWillDisappear或dealloc里invalidate”。循环引用题在阅卷时最看重的不是你能不能说出“用weak”而是能不能说清楚“循环是怎么形成的”。我建议答题时一定要画出“三条引用关系”然后指出断在哪条边上这是拿分的核心。4. 进阶题拆解Runtime消息转发与RunLoop休眠机制4.1 OC的消息发送与消息转发从objc_msgSend说起C卷的进阶题库里Runtime是雷打不动的压轴大项。有一道题我印象很深大意是“当向一个对象发送它没有实现的方法时会发生什么”。很多没深入研究过的人会写“崩溃”但严谨的答案是先走正常的消息发送流程找不到实现后进入消息转发三步曲如果三步都无法处理最后才抛unrecognized selector并触发崩溃。完整流程可以这样写对象收到消息后objc_msgSend会先看对象的isa指针找到所属类从类的cache中查找方法实现没有就去方法列表里找再没有就沿继承链往上找直到NSObject。若最终找不到会先调用resolveInstanceMethod:让你有机会动态添加方法实现如果这里返回NO则进入forwardingTargetForSelector:把消息转发给另一个对象如果还不想转则走methodSignatureForSelector:和forwardInvocation:用NSInvocation封装消息做兜底转发。整个链路是OC动态性的核心也是很多热修复框架的底层依赖。这道题在C卷里还有升级版问“能否通过Category给NSObject添加方法实现所有方法”。这考的是消息发送的另一面Category的方法最终会合并进类的方法列表中但如果有同名方法Category方法会放到列表前面会“覆盖”主类实现。不过这只是在运行时的方法查找顺序上优先并不是真的覆盖主类实现。这种细节在笔试里特别容易把人绕晕。4.2 isa、class与KVO的底层关联还有一类进阶题是KVO的实现机制。KVO看起来简单注册一个observer属性变化时回调但底层实际上在偷偷做isa-swizzling。系统会在第一次注册观察者时动态创建一个当前类的子类并把对象的isa指针指向这个子类然后重写被观察属性的setter方法。新setter里先调用willChangeValueForKey再执行原来的setter再调用didChangeValueForKey从而触发observeValueForKeyPath回调。C卷里关联的一道题是“为什么KVO必须在主线程移除观察者或者至少保证add和remove成对出现”。直接原因是如果对象dealloc时还有观察者没移除系统会在dealloc流程里抛异常而且异常信息非常隐晦很难查。另一个原因就是这个动态子类机制如果你多次add同一个观察者而没有对应的remove内部会重复记录回调次数也会异常。4.3 RunLoop在iOS里到底在干什么RunLoop在2017年的校招里是区分度极高的一道题因为它是理解iOS事件循环的关键。C卷常考的问题有两种一种是“主线程为什么不会退出”另一种是“RunLoop的Mode都是干什么的”。我先说结论主线程不退出是因为主RunLoop在空闲时会进入sleep状态等待事件源唤醒。它不是忙等不会空转耗电。整个循环可以简化成三步接收输入事件Source/Timer/Observer- 处理事件 - 回到睡眠。触摸事件、定时器、CADisplayLink、NSURLSession回调、autoreleasepool的刷新都挂在RunLoop的某个Mode上或者通过Source事件唤醒之前休眠的RunLoop。关于Mode最常见的是NSDefaultRunLoopMode和UITrackingRunLoopMode。当你手指按住UIScrollView滑动时RunLoop会切换到UITrackingRunLoopMode此时默认模式里的定时器会暂停。所以很多人会发现一个使用NSTimer的轮播图在手动拖动时图片会卡住不动。解决办法是把Timer加到NSRunLoopCommonModes或者用GCD的定时器。这里我必须说一句如果笔试里遇到“为什么滑动列表时定时器不准”这种问题千万不要只答“因为主线程被占满”。正确的链路是滑动时RunLoop切到TrackingMode默认Mode下的Timer不被触发即使主线程并不忙定时器依然不准。这个区分在阅卷时非常加分。5. 实战题复盘并发网络请求、TableView流畅度与崩溃防护5.1 直播互动场景下的高并发请求设计欢聚时代的业务决定了C卷里会有一类接近真实业务的实战题。我印象里有一种变体是“直播间的点赞和弹幕消息是高频请求客户端怎么设计才能不卡顿、不丢消息”这道题考察的已经不是单一知识点而是并发、网络、UI更新的综合能力。当时比较合理的答题结构是先把三条链路分开网络层负责收消息存储层负责暂存UI层负责渲染。网络层用串行或并行队列收消息后把消息转成统一模型做一次轻量级去重放入一个有限容量的环形缓冲UI层用DispatchSourceTimer或者CADisplayLink定时从缓冲里取一批消息合并后异步渲染到cell上再切回主线程提交给Core Animation。这样做的核心思路是“批量合并”而不是“来一条刷一条”。如果时间允许还可以补充一个关键点用信号量控制并发数。比如同时最多发4个网络请求超出就排队。GCD信号量dispatch_semaphore_wait配合dispatch_semaphore_signal作答能体现你理解“限流”在客户端也是必要的。当年很多同学只会答“用SDWebImage缓存”说明没有get到这道题真正问的是“在高频消息下怎么保证主线程不被打爆”。5.2 TableView/CollectionView优化的“标准答案”TableView优化是2017年iOS面试的保留曲目C卷里至少有一道相关简答题。哪怕到了今天SwiftUI时代List的性能优化思路也依然没变。C卷的答案其实是标准化流程关键是踩点踩全第一cell复用。用dequeueReusableCellWithIdentifier不要再每次cellForRowAtIndexPath里alloc新cell。这个谁都会答但真正容易漏的是“复用之后一定要重置状态”比如把imageView的图片先置nil。第二高度计算。如果cell高度固定用estimatedRowHeight配合Auto Layout如果高度不固定必须做高度缓存不要每次都调用systemLayoutSizeFittingSize去算。我当时笔试专门写过用一个NSMutableDictionary缓存heightByIndexPath数据变化时更新对应缓存。第三避免离屏渲染。圆角加shadow同时出现在滚动列表里会让FPS崩得厉害。解决方案是提前用Core Graphics把圆角图片绘制好或者用图层合成减少GPU负担。第四按需加载。图片用异步下载 解码 缓存不要在cellForRowAtIndexPath里做同步的图片IO。C卷这道题的评分点一般分两档能回答出cell复用和异步加载是及格能说出高度缓存、离屏渲染、预解码的可以拿到高分。如果你还能主动说“滑动停止后再加载图片”“避免在cellForRow里创建太多对象”那基本可以封顶。5.3 崩溃防护与“诡异”闪退题C卷还会出一些“线上App崩溃”场景题比如“一个字典在某个机型上偶发崩溃怎么排查”。这类题本质上考察的是对常见崩溃根因的理解。常见的坑有向NSMutableDictionary插入nilvalue为nil会导致崩溃、操作已释放对象、数组越界、主线程操作UI、KVO不配对移除观察者。答题时不要急着写代码先写排查路径第一步复现拿到crash log第二步看堆栈判断是主线程还是后台线程第三步根据类型去查对应的可疑代码比如数组越界就检查index和count边界KVO崩溃就检查add和remove是否成对。如果题目允许再补一个防守方案通过Runtime消息转发和method swizzling给NSArray/NSMutableDictionary做一个防护层拦截越界和nil插入。不过必须强调这种防护是兜底不能替代正确的编码习惯否则反而掩盖了真正的问题。这个知识点我当时感触很深。真正线上问题永远是多个因素叠加笔试虽然只能写一页纸但把“先定位、再修复、后防御”的逻辑写完整阅卷人一眼就能看出你有排查真实问题的经验。6. 开放性设计题与算法从架构方案到链表问题的解题思路6.1 架构题设计一个IM/直播弹幕模块C卷最后通常会有一道架构设计题分值非常高。我记忆中的一种出法是“设计一个直播间的弹幕模块需要考虑消息稳定性、客户端性能、可扩展性”。这道题没有标准答案但阅卷时有一套隐藏的评分维度。我当时看到空间复杂度比较高的第一反应是拆模块。完整的答题结构应该是数据层定义消息模型区分文本、礼物、系统通知等类型带上消息ID和优先级。网络层建立长连接并处理重连本地维护消息队列失败时补拉。渲染层直播间内用单例弹幕渲染器去消费队列多路直播间互不干扰。扩展性点协议预留扩展字段模块之间通过接口依赖方便后续接入新消息类型。还要回答线程模型接收线程、解析线程、渲染线程明确分开用多个串行队列避免数据竞争。存储策略房间内只保留最近N条历史消息超出就丢弃防止内存膨胀。这套框架不仅针对弹幕所有IM类模块都可以复用。如果答题时能画一张简单的分层图文字描述或用表格列层次效果会更好。6.2 算法题链表反转是永远的神C卷算法题的难度不会太夸张通常集中在链表、二叉树、字符串处理这几个常规范围里。链表反转算是我见过出现频率最高的原题之一。不仅要会写循环和递归两种写法还要分析各自的空间复杂度。循环版是O(1)空间递归版是O(n)的栈空间。笔试阅卷很看重复杂度标注不写复杂度等于少一个得分点。二叉树一般考层序遍历用队列做BFS。注意输出形式是数组套数组。字符串类可能考“去除字符串中重复字符”或者“判断是否为回文串”。这类题没有太多花活重点在边界条件空串、只有1个字符、全是重复字符、超大输入。我当时给学弟的建议是不要只刷LeetCode难题校招笔试考的是你把基础算法能不能在纸上写出来的能力。最值得练的题目类型就是链表操作、二叉树遍历、数组双指针、字符串处理这四类每类练透5道题比盲目刷100道中等题管用。6.3 如何表达才能让阅卷人给分开放性设计题和算法题共同点是过程比结果重要。我从参与阅卷的角度告诉你三个得分技巧。第一先写思路再写代码。很多同学直接甩一段代码遇到复杂逻辑阅卷人要反推你脑回路。如果先用两三行中文描述一下思路再贴代码阅卷体验会好很多。第二写边界条件。代码里加上if (array nil || array.count 0) return nil这类判断会给阅卷人留下“这个人考虑问题完整”的印象。不要嫌它啰嗦校招笔试里这是实打实的印象分。第三代码可读性要过关。变量名用描述性命名temp1、temp2这种少用。行数无所谓缩进和命名清晰才重要。我见过太多考生逻辑完全正确但因为代码乱成一团阅卷人根本没有耐心看完。7. 2017的卷子2026的考纲哪些考点成了常青树哪些被淘汰7.1 仍然在问的考点时间过去快十年iOS生态发生了很大变化但C卷里有一批考点今天依然出现在面试中。列个表看得更清楚2017年考点2026年现状原因引用计数与内存管理依然是Swift ARC面试基础所有苹果平台的内存释放规则没有变Runtime消息转发面试常客但比重下降Swift不依赖动态消息机制但底层仍有关联RunLoop/Mode依然在性能优化面试中出现主线程调度原理没有改变HTTPS/TCP必考基础题网络协议几十年没有本质变化并发与线程安全依然高频多线程永远是客户端难题这说明一个道理好的笔试考的都是“底层的、稳定的知识”而不是当下热门的新名词。当年如果你把OC基础搞扎实放到今天学Swift也不会有太大障碍。7.2 已经被淘汰或变形的考点C卷里有少量题目放到2026年已经不太适合原封不动地问了。最典型的就是MRC和autorelease的细节题。现在Swift项目默认ARC连strong/weak的写法都不再需要显式声明MRC时代的retain/release底层细节虽然对理解有帮助但再作为笔试重点就没有必要了。另一个变化是UI框架。2017年还在问Auto Layout和UITableView优化现在面试更可能问SwiftUI的声明式布局、Combine数据流以及怎么处理复杂业务下的视图刷新。不是说你不用再懂Frame/Bounds和布局优先级而是考察重心从“怎么用约束布局”转向了“怎么让数据驱动UI并保证更新可控”。还有一块是架构模式。当年问MVC/MVP的异同现在更常问MVVM、组件化、TCAThe Composable Architecture甚至会用一道“多人协作的大型App如何组织模块”来考察工程化管理能力。这说明校招对候选人的要求变得更加“工业化”不再满足于一个人能写通一个功能。7.3 直播场景考题的变化C卷的直播场景题非常有时代特色。2017年直播主流的方案是RTMP推流客户端处理延迟、弱网、首屏秒开是重点到2026年面试官可能会跟你聊WebRTC、低延迟互动、AI字幕实时渲染。但底层的东西始终没变网络怎么调优、队列怎么设计、内存怎么控制、渲染怎么不阻塞主线程。所以我一直觉得准备这类实战题不要追新框架重点是把底层原理吃透。框架每年都在变但并发模型、内存机制、网络协议、渲染管线这些底层能力换了一个平台还是同一个逻辑。8. 给下一个校招季的iOS新人备考路线与考场心态8.1 备考优先级先把OC/runtime吃透再上Swift如果你现在还在准备iOS校招我建议的第一件事是分清楚优先级。不要一上来就抱着SwiftUI狂写要先确认自己对Objective-C时期的四大核心还有没有底属性与内存管理、Runtime、RunLoop、多线程。很多公司虽然新项目用Swift但老项目维护和面试考察重点仍然是这些底层机制。一个比较实用的三个月备考计划是第一个月把《Effective Objective-C 2.0》过一遍每章写小结第二个月开始刷题重点刷运行时、内存、并发三类同时每天一道基础算法题第三个月做综合项目尝试自己写一个小型IM模块或者直播弹幕模块把线程、缓存、UI更新全部串起来。这样的节奏比较符合校招面试“理论实践”的考察方式。8.2 考场中的高频失误我在文章最后想集中盘点几个我在笔试里见过的低分行为。第一不审题。题目让“简述”你洋洋洒洒写了两页题目让“计算并说明”你只给了一个结果。写得多不是问题答非所问才是。第二代码语法错误太明显。手写代码时出现拼写错误、漏了分号、用了中文字符括号。这些错误在笔试里都会扣印象分毕竟阅卷人默认你是iOS工程师写OC代码就像作家写字不能有太多错别字。第三时间分配失衡。有同学在选择题上花30分钟导致最后一道20分的设计题只写了两行。建议按照我在第二部分给的时间表格来控场。第四留白。整道题空着或者写“不会”在阅卷时是最差的结果。哪怕不会也要写“我的思路是……”或者把相关知识点写出来哪怕不对也能体现你是在思考问题而不是被题目打倒了。8.3 我个人的一点体会说回这份C卷。它已经不是一份需要背答案的真题了但它代表的那套筛选思路我到现在都认为值得所有做iOS的人认真看一遍一个iOS工程师的专业能力最终要落到“对系统机制的理解深度”上。这些年我见过太多iOS新人能熟练使用各种第三方库但一被问到底层就沉默不语。反观那些愿意把运行时、内存、并发原理啃下来的同学不管换什么语言、什么框架成长速度都要明显快一截。如果你也在准备校招我建议你抛开“押题”的侥幸心理找个下午静下心把这份卷子涉及的每个知识点串一遍。别急着背答案先问自己“为什么”。当你把每个“为什么”都答上来的时候一张校招笔试C卷就不再是拦路虎而是你进入这个行业的敲门砖。最后再分享一个小习惯每次答完题把那些模糊的知识点记到一个笔记里隔一周再回来问自己一次“我能不能用自己的话讲清楚”。能讲清楚才是真会了。