干了十来年C/C++，面试过上百号人，也帮几个团队搭过完整的C/C++工程师能力评估体系。说实话，大多数团队在评估这件事上是拍脑袋的：拉几张八股文题，手写一个链表反转，再问问虚函数和智能指针，就结束了。这种方案不是没用，而是筛不出真正的功底，尤其是对高级工程师几乎失效。
为什么这么说？因为C/C++这门技术栈有一个非常特殊的地方：它的知识深度天然分了好几层，语法只是最薄的一层外壳，底下的内存模型、编译链接、并发同步、ABI兼容、跨语言互操作，每一个都能单独把人挂住。搜索热词里那些“vscode配置c/c++环境”“c and c++ compiler paths differ”“c/c++ opc da getitemid函数”之类的关键词，恰恰暴露了很多人在基础链路和真实工程场景上的短板。这篇内容就围绕“C/C++工程师能力评估”展开，把评估拆成语言功底、工程能力、系统思维、领域经验四个维度，讲清楚每个维度怎么考、考什么、怎么避坑，适合正在招人的团队leader、准备面试的候选人，以及想自查能力等级的从业者参考。
1. 整体评估思路：先想清楚要招什么人，再定怎么考
1.1 为什么不能只靠算法题筛人
很多人面试C/C++只考算法，这其实是个误区。算法题能证明候选人的逻辑思维和刷题量，但证明不了他能不能在真实项目里交付。我见过能轻松手撕红黑树的候选人，入职两周后把一个线程池写成了死锁现场；也见过算法题答得一般的老工程师，能从一个崩溃日志里五分钟定位到越界写入的模块。
算法题的价值是基础筛选，不是能力定论。尤其像GESP这类竞赛体系里的题目，常会标注“C/C++ 1000ms，其他语言2000ms”这样的时间限制，这类题的训练确实能提升编码速度和边界意识，但竞赛和工程是两种维度。竞赛题的环境是给定的、交互方式是明确的、评判标准是单点的；工程环境则充满了模糊性，编译器版本、依赖库、平台差异、老代码兼容、资源限制，每一环都能让一个“算法高手”折戟。
所以做C/C++能力评估，第一件事是先定义岗位需要的能力画像。做嵌入式裸机开发和做Windows桌面应用，对C++的要求是两套东西；做音视频处理和做数据库中间件，考察重点也完全不同。不能拿一套题库通吃，这样筛出来的人大概率匹配度不高。
1.2 四维评估模型的构建逻辑
我常用的评估框架是四个维度：语言功底、工程能力、系统思维、领域经验。每个维度再往下拆出可量化的考察点。
语言功底考察的是对C和C++语法、语义、编译模型的理解。不是“会用std::vector”这个级别，而是能说清楚vector扩容为什么是O(1)均摊、迭代器失效是怎么回事、move语义到底解决了什么问题。对C语言，要能解释指针和数组的本质差异、const的多种语义、volatile到底有什么用。
工程能力考察的是工具链和协作链路。环境搭建、编译配置、构建系统、调试器、性能剖析、版本管理、跨平台移植，这些才是C/C++开发者在日常工作中真正花时间的地方。搜索热词里“windows 安装 mingw w64 + 配置环境变量 + vs code c/c++ 完整步骤”能成为热门，说明大量人卡在这条最基本的链路上。对于评估而言，这条链路恰恰是最好用的试金石。
系统思维考察的是对运行环境全貌的认知。内存布局、栈和堆的关系、缓存局部性、并发模型、锁的粒度、IO模型、异常安全、RAII资源管理，这些决定了候选人能不能写出真正高性能、高稳定的系统级代码。
领域经验则针对具体方向做深度验证。音视频方向要考编解码封装格式、渲染管线、帧缓冲和线程模型；工业自动化方向要考OPC UA/DA、COM互操作、实时性保证；存储和中间件方向要考IO模型、网络并发、持久化一致性。
这四个维度用一张表可以粗略对应考察方式：
| 维度 | 典型考察方式 | 高频翻车点 |
|---|---|---|
| 语言功底 | 笔试陷阱题、代码评审、语义辨析 | 混淆C和C++语义、指针与数组混用 |
| 工程能力 | 现场环境搭建、构建配置、调试实战 | 编译器报错看不懂、环境变量不会配 |
| 系统思维 | 并发题、内存模型题、崩溃排查 | 死锁、数据竞争、栈溢出、内存泄漏 |
| 领域经验 | 项目深挖、场景方案设计 | 只懂API调用、不懂底层原理 |
这四层不是并列关系，而是递进关系。语言功底是地基，工程能力是脚手架，系统思维是承重墙，领域经验是装修风格。评估时要分层次打分，任何一个维度在特定岗位权重很高时，都需要做针对性的深度测评。
1.3 热词背后暴露的普遍短板
我特意观察了搜索热词里那些高频问题，它们暴露了C/C++社区的普遍现状。“vscode配置c/c++环境”“mingw w64 配置环境变量”这类词搜索量极大，说明很多人的基本工具链都是靠照抄教程搭起来的，一旦报错就不知所措。而“c and c++ compiler paths differ. c compiler may not work.”这种报错，很多人遇到后第一反应是重新装软件，而不是去理解gcc和g++、C和C++编译驱动的区别。
“C语言和Java和Python和C++”这个词也很有意思，说明很多初学者在语言选型上还在纠结。Python和Java有自动内存管理，而C/C++需要手动管理内存，这导致很多从其他语言转过来的人，写出来的C++代码带着浓厚的“Java味道”或者“Python味道”。比如用new创建一个对象却忘了delete，或者用裸指针到处传，该用unique_ptr的地方用shared_ptr，这些都是C/C++能力评估时一眼就能看出来的硬伤。
林锐的《高质量C/C++编程》至今仍是热搜书籍，这本书的价值在工程规范上，比如命名、注释、代码风格，但内容停留在C++98时代，很多现代C++的最佳实践并没有覆盖。如果候选人只背过这本书，而不了解C++11/14/17/20的新特性，那在新项目里很可能会把现代C++代码写成老古董风格。
2. 核心细节解析：四维能力怎么考察才有区分度
2.1 C和C++的差异是评估第一道关卡
很多候选人分不清C和C++的边界。网上常有人说“C++是C的超集”，这个说法在工程实际里是错的。C++虽然语法上兼容大部分C代码，但两者的类型系统、编译模型和编程范式差异巨大。C语言是结构化的、面向过程的，类型系统相对简单；C++引入了类、模板、异常、RAII、lambda、移动语义等大量机制，编译模型复杂得多。
我面试时常用一个问题开场：gcc和g++有什么区别？这个问题看似基础，但能刷掉不少简历写得天花乱坠的候选人。gcc对.c文件按C语言编译，对.cpp文件按C++编译；g++则强制按C++编译，会额外链接C++标准库。很多人在VSCode里配环境时，把C和C++的编译器路径搞混，出现“c and c++ compiler paths differ. c compiler may not work.”的报错，本质就是没搞懂编译驱动和源文件后缀的关系。
继续往下问，更深入的是extern "C"的作用范围。C和C++在符号层面的差异是链接器层面的事，C++编译后的函数签名会包含参数类型信息以实现重载，所以C代码编出来的符号名和C++代码对不上，必须用extern "C"来禁止名字改编。工业控制领域常见的OPC DA接口就有大量C接口需要C++工程去对接，不懂这一层的工程师经常会遇到“unresolved external symbol”这类链接错误，只能靠网上搜答案，搜到就过，搜不到就卡死。
再复杂一点，可以问C语言里NULL和C++里nullptr的区别。NULL在C里是(void*)0或整数0，在C++里通常就是整数0；nullptr是C++11引入的空指针字面量，有明确的类型std::nullptr_t，能避免在重载解析时把NULL当作整数处理。这种细节能反映出候选人对语言演进脉络的掌握程度。光是这个点，就能区分“背过八股”和“真正理解类型系统”的人。
2.2 内存管理是C/C++工程师的“生死线”
如果说只有一个能力项能决定C/C++工程师的下限，那一定是内存管理。Java和Python的自动垃圾回收把开发者保护得很好，但C/C++没有这种安全网，指针悬垂、内存泄漏、缓冲区溢出、未定义行为，每一个都能把程序变成定时炸弹。
评估内存管理能力，我常用的做法是让候选人分析一段代码的内存问题。比如下面的经典场景：
char* getString() { char buf[64]; snprintf(buf, sizeof(buf), "hello %d", 42); return buf; }这段代码的错误在于返回了栈上局部数组的指针，函数返回后栈帧被回收，指针立刻悬垂，任何使用都是未定义行为。这个问题对初级候选人来说是送分题，但对高级候选人，我会继续追问：如果把buf改成static变量，副作用是什么？答案是函数不再是线程安全的，多个线程同时调用会互相覆盖数据。如果改成堆分配，谁负责释放？这就是所有权问题，而所有权问题正是现代C++用RAII和智能指针解决的根源。
再高级一层，可以考placement new、内存对齐、cache line伪共享这些概念。比如在高并发场景下，两个线程频繁修改同一个cache line里的不同变量，会导致缓存行在L1 cache和L2 cache之间来回颠簸，性能断崖式下跌。处理方法是用alignas(64)让不同变量分布在不同cache line上。这种问题不是背出来的，是真的在压测中踩过坑才能答得有细节。
C转C++的候选人还有一个很典型的毛病：不会用RAII。他们在构造函数里new，在析构函数里不delete，或者搞出一个裸的head节点然后用free去释放C++对象。遇到这种候选人，我会专门出一个用std::unique_ptr管理Pimpl指针的题目，很多人当场就露馅了。
2.3 构建与工具链：环境配置是照妖镜
很多面试官忽略环境配置这个考察点，觉得“配环境根本不是技术活”。但无数现实案例说明，恰恰是环境配置最能揭示一个工程师的真实水平。你让一个候选人现场从零配置一个可用的C/C++开发环境，看他卡在哪一步，就能判断他是“理解工具”还是“依赖教程”。
以搜索热词里的“windows安装mingw w64 + 配置环境变量 + vs code c/c++完整步骤”为例，这条链路考察的其实是三件事：第一，是否知道Windows下的C/C++编译器选型，比如MinGW-w64和MinGW的区别、与MSVC的区别；第二，是否会正确修改PATH环境变量，理解PATH的作用机制和优先级；第三，是否理解VSCode中C/C++扩展的c_cpp_properties.json、tasks.json、launch.json三者之间的关系。
我见过太多人把VSCode配坏的情况，几乎都是同一个原因：从网上复制了一份配置，根本不知道compilerPath指向的是哪个编译器、includePath为什么找不到标准库头文件、IntelliSense模式和实际构建用的编译器不是同一个。这些人在简历上写着“熟练掌握C/C++”，但连一个从源码到可执行文件的完整编译链路都说不清。
评估时可以让候选人做这几件事：
- 用命令行手动编译一个多文件C++项目，而不是依赖IDE的“一键构建”。
- 解释动态库和静态库的区别，以及Windows上.dll和.lib的关系。
- 在编译报错“undefined reference”时，能判断是链接库缺失、符号未导出还是extern "C"问题。
- 用调试器打断点查看内存布局，而不是只会printf。
这些能力没有一项是“背知识点”能解决的，全部要靠真实操作经验积累。高级工程师和中级工程师的分水岭，往往就在这里。
2.4 现代C++的掌握程度决定上限
C++11是一个分水岭，C++14、C++17、C++20又持续演进，很多老项目的代码风格还停留在C++98时代。评估时如果不考察现代C++特性，等于用二十年前的标准给现代工程师打分。但反过来，如果候选人把新特性挂在嘴边却用不对，也是灾难。
现代C++里最值得考察的是移动语义和完美转发。移动语义解决的是临时对象拷贝开销问题，移动构造函数、移动赋值运算符、std::move、std::forward各自是什么角色，什么场景下编译器会隐式生成移动操作，什么时候用户必须显式自定义，这些问题比“虚函数表占用多少字节”有含金量得多。
其次考察RAII和智能指针的合理使用。正确理解unique_ptr、shared_ptr、weak_ptr三者的职责边界，能写出真正的现代C++代码。很多候选人会背“shared_ptr用引用计数”，但一问到循环引用就答不上来；或者为了炫技，在根本不需要共享所有权的地方到处用shared_ptr，反而造成性能损耗。
音视频开发是C++的重要应用方向，也是现代C++特性应用非常密集的场景。FFmpeg、WebRTC这类底层库，普遍要求开发者掌握移动语义、原子操作、线程同步和缓冲区管理。评估这个方向的候选人，除了问基础语言，还要看他对音视频数据流、帧内存管理、多线程模型的理解。市面上关于音视频C/C++开发的好教材不多，能够完整讲透编码器原理、封装格式、渲染管线这整条链路的更是凤毛麟角，所以这个领域的工程师尤其依赖扎实的底层功底，单靠调用API是撑不起来的。
3. 实操过程：一套从笔试到上机的完整评估方案
3.1 评估流程的整体设计
完整的评估我建议分成四个阶段，每个阶段考察不同的能力层面，总时长控制在三到四个小时。
阶段一是笔试或在线测评，四十五分钟到一小时，主要考察语言功底和部分系统思维。题目类型包括基础选择题、阅读代码找bug、简答语义辨析。这个阶段能快速过滤掉基础不牢的候选人，也能给后续面试提供讨论素材。
阶段二是现场上机，九十分钟左右，考察工程能力和实际动手能力。建议让候选人从零开始配置一个开发环境，然后完成一个小型功能模块。这期间面试官记录操作路径、报错处理方式、代码风格和调试习惯。
阶段三是技术面试，六十到九十分钟，围绕阶段一和阶段二的答案做追问，并深挖候选人过往项目。这一阶段的核心目标是验证候选人是不是真的理解自己做过的东西，有没有把话说到位的能力。
阶段四是综合评审，把各个维度的得分汇总，对照岗位能力模型做最终判断。这里很容易犯一个错误，就是被某个维度的突出表现“带偏”。比如一个人算法能力极强，但工程链路一塌糊涂，如果岗位是嵌入式底层驱动，那算法天赋救不了他的工程缺陷。
3.2 笔试题目示例与判分要点
我举几个实际用过的笔试题目供参考。
题目一：写出下面代码中所有未定义行为或未确定行为。
int arr[10]; int i = 10; arr[i] = 5; printf("%d\n", arr[i]);判分要点：数组越界写是未定义行为；但如果候选人只回答“数组越界”，只能给一半分，因为未定义行为这个概念本身就说明他理解C语言标准对UB的处理方式。追问：如果把arr声明为int arr[10]，然后执行arr[10]读取呢？在哪些平台可能读到什么值？这道题能区分出候选人是机械背题还是真的理解栈布局。
题目二：有一个C++类，包含一个裸指针成员，构造函数new，析构函数delete，但忘记实现拷贝构造函数和拷贝赋值运算符，会发生什么？
判分要点：默认拷贝构造函数会进行浅拷贝，两个对象指向同一块内存，析构时double free。候选人如果能进一步提到“应该用unique_ptr替代裸指针”或者“实现Rule of Five”，说明对现代C++所有权管理有正确认知。
题目三：简述C++11中的std::move和std::forward的区别，并用代码说明各自适用的场景。
判分要点：std::move是无条件把左值转换为右值引用，目的是启用移动语义；std::forward是在模板中按参数原始类型进行完美转发，保留左值/右值属性。高级答案是提到引用折叠规则，中级答案是能写对转发的代码，低级答案会把两者混为一谈。
这套题的设置逻辑是：不求难，求的是能一层一层挖。每个题都能追问三到四轮，从表面到原理，从原理到工程实践。
3.3 上机题目设计实例与操作记录
上机题是最难设计的，因为既不能太空泛，又不能过于偏向某个特定方向。我常用的一个上机题是：用C语言实现一个线程安全的环形缓冲区，并写一个生产者和消费者的测试程序。
这个题考察的点非常密集：环形缓冲区的索引计算是否考虑取模效率、是否处理边界条件、线程安全用什么机制、锁的粒度控制、CPU缓存是否会造成伪共享、测试程序是否有确定性和可验证性。为了对应热词里“时间限制：C/C++ 1000ms，其他语言2000ms”这种竞赛题的严谨性，我会要求候选人在不改变程序语义的前提下尽量优化，然后简单计时，看是否有明显的性能波动。
实际操作中，候选人会经历这样的流程：
第一步，先确认理解需求。很多候选人一上来就写，问也不问“buffer满的时候怎么办”“是覆盖还是阻塞”，这两个问题的答案完全不同，能直接决定实现方案。主动问清楚需求的候选人，通常工程经验更足。
第二步，实现基础版本。大多数候选人会用pthread_mutex或std::mutex。能写对缓冲区和锁的使用，算及格。
第三步，面试官追问：如果生产者和消费者速度差异极大，你的锁会不会成为瓶颈？怎么优化？好的候选人会讲无锁队列、CAS操作、内存屏障，或者双缓冲方案。差一点的会卡住。
第四步，让候选人用编译器开启-O2后重新测试，分析性能变化。很多人在开优化后代码行为发生变化，尤其是有未定义行为的地方，就会暴露。
这个上机题我已经用了三年，效果相对稳定，能比较忠实地反映候选人的真实水平。
3.4 代码评审式面试：让候选人“挑毛病”
笔试和上机之外，我还非常推荐“代码评审式面试”。做法是给候选人一段故意埋了坑的代码，让他扮演代码评审者，指出所有问题并提出修改建议。这种方式考察的是工程协作中的核心能力：读别人的代码、找问题、提出解决方案。
我常用的一个评审样例是一个简化版的字符串类：
class MyString { public: MyString(const char* s) { if (s) { size_ = strlen(s); data_ = new char[size_ + 1]; strcpy(data_, s); } else { data_ = nullptr; size_ = 0; } } ~MyString() { delete[] data_; } private: char* data_; size_t size_; };候选人大致能指出缺少拷贝构造和拷贝赋值；中级候选人会指出异常安全问题，比如new抛异常后对象状态不一致；高级候选人会指出整个类没有处理自拷贝、没有移动语义、没有const成员函数、size_应该是const还是可变的类型语义问题。能把这些全部讲清楚的候选人，对C++工程的理解是实打实的。
这个环节的额外收获是观察候选人的沟通方式。好的评审者会先说问题的严重级别，再给修改建议，而不是看到哪里就喷哪里。这一点对一个需要参与团队协作的工程师来说，非常重要。
4. 常见问题排查与避坑技巧实录
4.1 VSCode与MinGW-w64环境配置里的“隐形考点”
环境配置看起来和“能力评估”无关，但它实际上是最低成本的实战演习。我整理了最常遇到的几个问题和排查方法，这些问题也是热词搜索的高频来源。
第一个问题是“vscode配置c/c++环境后，IntelliSense报错但能编译通过，或者编译报错但IntelliSense正常”。这种情况通常是c_cpp_properties.json里的compilerPath配置和tasks.json里的编译器不一致。如果compilerPath指向的是MSVC，而tasks.json用的是MinGW-w64，两边基于的编译器都不一样，代码提示和实际编译结果自然对不上。正确做法是让配置统一，且必须理解：IntelliSense是按compilerPath模拟编译，不是真实编译。
第二个问题是“c and c++ compiler paths differ. c compiler may not work.”。这个报错的核心原因是C和C++的编译器路径配置不一致，比如说compilerPath指向了g++，但C编译器路径指向了某个不存在或不同的gcc，导致VSCode的C/C++插件无法用同一个工具链解析C文件。解决办法是检查编译器路径是否准确、对应，在MinGW-w64的bin目录下确认gcc.exe和g++.exe是否存在于同一个目录，版本是否一致。
第三个问题是运行C++程序时弹出“找不到libstdc++-6.dll”之类的错误。这说明编译时用的MinGW-w64动态库目录不在PATH里，或者构建配置里链接了动态运行时。排查思路是先检查PATH里是否包含了MinGW-w64的bin目录；如果包含但还报错，检查是否同时安装了多个MinGW版本导致版本冲突。
这类问题的排查方法，我总结为五步：第一步，确认编译器路径本体存在且版本正确；第二步，确认PATH环境变量里的顺序和值；第三步，确认VSCode里三个配置文件指向的工具链一致；第四步，在命令行手动执行编译命令，绕过IDE看真实报错；第五步，用最简单的hello world排除代码本身的干扰。这套方法虽然不是多高深的技术，但能完整体现一个工程师的调试逻辑。
4.2 候选人最常翻车的三类现场问题
这几年面试下来，我发现候选人翻车主要集中在三类问题上，值得所有准备面试的人对照自查。
第一类是内存与生命周期问题。最常见的翻车现场是：在函数内定义一个string对象，然后返回它的c_str()指针。因为string对象在函数退出时析构，底层缓冲区被释放，返回的指针就是悬垂指针。再比如使用vector时，在循环里不断往vector里添加元素，然后保存了指向元素的引用或迭代器，vector扩容后迭代器失效，后续访问直接越界。这类问题的共同点是候选人没有建立“所有权”和“生命周期”这两个心智模型。
第二类是并发问题。许多候选人能写单线程代码，一旦涉及多线程就漏洞百出。随手写一个共享计数器不做原子操作，或者用mutex锁了很短的一段代码但没覆盖所有访问路径。上机时如果让他跑一个多线程的测试程序，不崩溃的概率很低。排查这类问题需要懂数据竞争、内存序、原子操作，这些都是C/C++并发编程的核心知识点。
第三类问题是边界和异常路径。很多候选人写的代码只覆盖“正常路径”，对空指针、越界输入、内存分配失败、文件打开失败一概不管。比如用realloc时，有一个非常经典的问题：
void* p = realloc(ptr, new_size); // 错把结果再赋给ptr ptr = p;如果realloc失败，原来的内存块并没有释放，但ptr被赋成NULL，原始内存直接泄漏，而且无法恢复。正确写法是先保存返回值到临时变量，判断非空后再赋值。这种细节在教材里可能只有一行，但在真实工程里是常见的崩溃根因。
4.3 从OPC DA看工业场景里的C/C++底层能力
搜索热词里“c/c++ opc da getitemid函数”“查询item属性”“检测添加的itemid的dwaccessrights”这些词，透露出工业控制领域对C/C++工程师的具体能力要求。OPC DA是一个基于COM/DCOM的工业通信标准，虽然现在很多新项目转向了OPC UA，但存量系统中仍有大量OPC DA的代码在运行。能维护这类代码的工程师，必须具备扎实的COM编程能力。
以GetItemID为例，这个接口通常返回一个HRESULT值，很多候选人写代码时不检查返回值，拿到结果就开始用，这在COM编程里是致命的。因为COM方法可能因为各种原因失败，比如服务器未启动、item不存在、权限不足。面试时可以问：HRESULT的SUCCEEDED宏是怎么判断的？答案是检查符号位，负数表示失败，非负数表示成功。再深入一层，可以问为什么不用“等于S_OK”来判断，因为有些方法会返回S_FALSE或者其他正数的成功码，用等号判断会漏掉部分成功情况。
dwAccessRights是另一个典型考点。这是一个位掩码字符串或数值，用于描述item的读写权限。考察候选人时，要看他是否理解位掩码的运算：检查可读权限用(dwAccessRights & OPC_READABLE)，检查可写权限用(dwAccessRights & OPC_WRITABLE)，而不是用等号判断。这类问题在面试中能深入考察候选人对位运算和系统API返回语义的把控程度。
OPC DA场景还涉及BSTR字符串和COM内存的释放规则。BSTR是COM里专门的字符串类型，不能用free或delete释放，必须用SysFreeString。这些细节在微软文档里有明确说明，但很多工程师只是“照着老代码改”，根本不理解背后的内存模型。这种候选人一旦遇到内存泄漏问题，排查起来就会非常痛苦。
4.4 评估过程中的避坑速查表
根据过往经验，我整理了一个速查表，帮助面试官避开高频踩坑点：
| 考察环节 | 常见坑 | 正确做法 |
|---|---|---|
| 笔试判分 | 只看结果不看推导过程 | 让候选人写清楚思路，追问关键判断依据 |
| 上机环境 | 候选人用自己的电脑 | 尽量统一环境，避免“我本机没问题”扯皮 |
| 并发题目 | 只问理论，不跑程序 | 让候选人真实编码并运行多线程测试 |
| 内存题目 | 只看代码不看崩溃现象 | 用ASan或Valgrind实测，看候选人如何排查 |
| 现代C++ | 只考语法名词 | 结合具体场景问Should I use shared_ptr or unique_ptr? |
| 项目复盘 | 只听项目结果 | 连续追问“为什么这么设计”“遇到什么问题怎么定位” |
| 领域深度 | 问完语言就结束 | 针对岗位方向出场景题，比如OPC DA或音视频链路 |
我个人的体会是，面试官自己要持续保持学习，C++标准年年更新，编译器行为不断变化，如果面试官还停留在“虚函数表一个对象一个指针”的认知，那评估的准确度很难提升。C/C++工程师能力评估这件事，本质上是在用一套系统的方法判断候选人是否具备独立解决复杂系统级问题的潜力，比背答案更重要的是看他在真实问题面前的思维路径和工程习惯。
如果你也在搭建或优化自己的评估方案，我建议从第四章的构建链路考题开始，这是最容易被忽视、又最能看出真实水平的地方。先把环境配置、编译调试、生命周期这些问题跑通，再逐步扩展到并发和性能方向，会比单纯堆一套面试题有效得多。
)
