C++ 程序员面试，怎样设计高质量考题

在技术招聘中，C++ 岗位的面试题设计一直是一个容易产生争议的话题。很多面试官习惯于直接使用网络上流传的固定题型，例如手写字符串类、手写链表、套接字流程默写、经典改错题等。这些题目并非毫无价值，但当它们成为面试的主要甚至全部内容时，面试的区分度和有效性都会显著下降。原因在于，这类题目已经高度套路化，候选人完全可以通过短期背诵和机械训练获得较好表现，却未必真正理解 C++ 语言的核心机制与工程实践中的关键权衡。

面试的核心目标不是考查候选人“是否见过某道题”，而是判断其是否具备扎实的语言功底、清晰的底层认知、良好的工程习惯以及面对未知问题时的推导能力。因此，与其追求题目本身的新奇，不如重新思考：什么样的问题能够更稳定地区分出不同层次的 C++ 开发者。

一、低质量面试题的典型特征

在设计高质量问题之前，有必要先厘清低质量问题常见的问题模式。这有助于面试官在出题时主动规避。

1. 纯语法记忆题

例如直接提问“const 有哪几种用法”“static 在类和函数中的作用分别是什么”。这类问题只能反映候选人是否背诵过知识点，无法体现其是否理解这些关键字背后的编译模型、符号绑定和对象生命周期含义。一个能流利背出答案的人，未必能在多文件项目中正确处理内部链接与外部链接的冲突。

2. 已被充分解析的网红题

“实现一个 String 类”“实现一个线程安全单例”“找出代码中的内存泄漏”等题目在网上已有海量范文。候选人只要提前准备过，就能在几分钟内写出一份看起来很完整的答案，甚至在白板上默写出带有引用计数、写时拷贝的版本。但这种表现很难说明其真实水平。

3. 场景割裂的算法题

C++ 面试中有时会混入大量与语言特性无关的纯算法题。虽然算法能力对工程师很重要，但如果题目完全不涉及 C++ 的资源管理、对象模型或编译期行为，就无法判断候选人对这门语言的掌握程度。面试时间有限，每一道题都应尽量承担多重考察职能。

4. 只有唯一标准答案的判断题

一些面试官喜欢问“这样写对不对”“这里会不会崩溃”。这类问题往往只有“是”或“否”两种结局，一旦候选人答对或答错，追问空间很小。更好的做法是让问题本身具有层次感，给面试官留下根据回答逐步深入的机会。

二、高质量 C++ 面试题的四个核心原则

原则一：从“语法正确”走向“行为可解释”

高质量问题不应停留在“这段代码能不能编译通过”，而应聚焦于“这段代码在运行时会经历哪些关键步骤，为什么”。例如给出一个包含构造函数、拷贝构造函数、移动构造函数和析构函数的类，让候选人解释在参数传递、返回值优化、容器扩容等场景下分别会发生什么。这种问题可以自然引出对临时对象、NRVO、移动语义和异常安全等多个知识点的考察。

示例问题可以设计为：

class Buffer {
public:
    Buffer(size_t n);
    Buffer(const Buffer& other);
    Buffer(Buffer&& other) noexcept;
    Buffer& operator=(const Buffer& other);
    Buffer& operator=(Buffer&& other) noexcept;
    ~Buffer();
private:
    char* data_;
    size_t size_;
};
Buffer createBuffer(size_t n) {
    Buffer b(n);
    return b;
}
void test() {
    Buffer x = createBuffer(1024);
    std::vector<Buffer> vec;
    vec.push_back(std::move(x));
}

围绕这段代码，可以追问：createBuffer 返回时是否必然发生拷贝？push_back 内部可能触发哪些操作？如果 Buffer 的移动构造函数没有标记 noexcept，对 std::vector 的行为有何影响？这些问题不需要候选人记住标准文本，只要能基于对象模型和资源管理逻辑进行推导，就能给出合理答案。

原则二：让题目具备分层追问空间

一道理想题目应当能够让初级候选人有话可说，同时也能让资深候选人展现出更深的理解。实现这一点的关键是题目本身不要封闭，而是保留开放扩展的余地。

以“设计一个日志缓冲区”为例。初级候选人可能会给出一个简单的数组加写指针实现；中级候选人会考虑多线程并发写入时的数据竞争，引入互斥锁或原子操作；高级候选人则可能进一步讨论锁竞争对性能的影响、无锁队列的适用条件、缓存行对齐、批量刷盘策略、崩溃场景下的数据一致性等。面试官可以根据候选人的实际表现决定追问深度，而不是所有人都回答同一套固定问题。

原则三：覆盖“编译期—运行期—工程实践”的完整链条

C++ 的复杂性不只体现在运行期，编译期的模板推导、重载决议和 SFINAE 同样容易暴露候选人的真实水平。高质量问题可以有意识地将这三个层面串联起来。

例如一个函数模板：

template <typename T>
void process(T&& arg) {
    if constexpr (std::is_integral_v<std::remove_reference_t<T>>) {
        // 处理整数
    } else {
        // 处理其他类型
    }
}

可以追问：T&& 在此处的含义是什么？传入左值和右值时 T 分别被推导为什么类型？std::remove_reference_t 的作用是什么？如果把这个函数放到头文件中，是否需要额外的声明或定义处理？这些问题分别涉及万能引用、引用折叠、类型萃取和模板的编译模型，能够较全面地反映候选人对 C++ 现代特性的掌握程度。

原则四：注重工程判断而非唯一答案

在很多真实场景中，C++ 开发者面临的并不是“只有一种正确写法”的问题，而是需要在多种可行方案之间做出权衡。面试题应当允许甚至鼓励候选人表达自己的工程判断。

比如可以提出这样的问题：“假设你需要在一个高频交易系统中维护一个固定大小的订单表，同时有多个线程并发读取、少量线程更新。你会如何设计数据结构？说明理由。”这个问题的答案不是唯一的。候选人可以选择读写锁、分片锁、无锁结构或基于版本的乐观并发控制，每种方案都有适用边界。面试官关注的不应是候选人是否选择了“标准答案”，而是其能否清楚地说明选择依据、识别潜在风险并给出可落地的优化路径。

三、高质量问题如何设计追问链

追问链是区分候选人水平的关键手段。同样的初始问题，不同的追问方向会产生完全不同的面试效果。以下是一个示例追问链。

初始描述：

class Widget {
public:
    Widget() { std::cout << "default ctor\n"; }
    Widget(const Widget&) { std::cout << "copy ctor\n"; }
    Widget(Widget&&) noexcept { std::cout << "move ctor\n"; }
    ~Widget() { std::cout << "dtor\n"; }
};
Widget makeWidget() {
    Widget w;
    return w;
}

第一层问题：调用 makeWidget() 时，会输出什么？这个问题可以考察候选人对返回值优化的基本认识。即便候选人回答“只输出 default ctor 和 dtor”，也需要继续追问：这是语言标准保证的行为，还是编译器优化导致的结果？如果禁用优化，行为是否改变？

第二层问题：如果把返回类型改为 Widget&&，会发生什么？进阶候选人会识别出返回局部对象右值引用会导致悬垂引用。这个问题可以引出对对象生命周期和引用绑定规则的深入讨论。

第三层问题：如果 Widget 包含一个 const std::string& 成员，构造函数接收字符串字面量，那么该对象的生命周期边界在哪里？此时可以考察候选人对临时对象生命周期延长的理解，以及引用成员在拷贝和移动操作中的行为差异。

第四层问题：如果把这个 Widget 放入 std::vector 并在运行时频繁扩容，你会如何优化？此时可以考察候选人对容器内存管理、移动语义、异常安全以及自定义分配器的理解。

通过同一个小例子，面试官可以沿着语言特性、对象生命周期、容器行为和性能优化四条线逐步深入，远比单独出一道“什么是右值引用”更能反映真实水平。

四、针对不同层级的考察侧重点

初级候选人

对于工作经验较少的候选人，重点应放在基础概念的准确理解与简单场景下的正确使用。例如：指针与引用的区别、构造函数与析构函数的调用时机、new/delete 与智能指针的基本用法、常见容器的时间复杂度等。问题可以相对聚焦，但要避免纯概念背诵。

中级候选人

中级候选人应当具备一定的工程经验，问题应更多围绕资源管理、异常安全、多线程基础以及常见设计选择展开。可以设计一些包含资源获取和释放的类，要求候选人处理拷贝策略、移动语义和自赋值安全，并结合实际场景说明为什么需要三/五法则。

高级候选人

高级候选人应当在语言机制、并发模型和性能工程上有更系统的认知。问题可以涉及模板元编程、内存序、无锁算法、运行时多态与编译期多态的取舍、ABI 兼容性、构建系统与依赖管理等内容。更重要的是考察其在模糊需求下拆解问题、提出方案并识别风险的能力。

五、面试流程设计的几个实用建议

除了题目本身，面试流程的安排也会显著影响评估质量。

建议一：设置一个基础编码环节，但不以完成度为唯一标准。 给出一道中等难度的编码题，观察候选人的编码习惯：是否先明确接口约定？是否主动处理边界条件？是否考虑异常路径？这些信号往往比最终输出更能说明工程素养。

建议二：每道题都预留追问时间。 面试官不应在候选人给出正确答案后立即进入下一题。一个优秀的候选人通常能够说出答案背后的原因，甚至在面试官的引导下发现新的问题。追问时间应当至少占每道题讨论时间的百分之三十。

建议三：允许候选人使用现代 C++ 特性。 部分面试官习惯于面向 C++98 风格出题，但现代 C++ 已在资源管理和并发表达上有了显著进步。如果候选人选择使用智能指针、std::optional、std::variant 或范围 for 等特性，不应被视为“偷懒”，反而说明其对标准库有基本认知。

建议四：设计一至两道与真实系统相关的综合性问题。 例如“设计一个支持并发读写的配置管理组件”“实现一个带超时机制的任务队列”“分析一段日志处理代码的性能瓶颈”。这类问题更贴近日常工作，能够让候选人展示其在需求理解、接口设计、并发处理和性能调优方面的综合能力。

六、面试官自身的持续校准

再好的题目，如果面试官自身缺乏校准，也可能导致误判。建议技术团队对面试题进行定期评审，记录每道题在不同候选人身上的表现，并分析是否存在“区分度低”“过于依赖背景知识”“容易被背诵”等问题。

面试官在提问前也应明确本道题希望考察的能力维度，是语言基础、设计能力、调试能力还是性能意识。不建议在同一个问题上同时追求过多目标，否则容易导致评估标准混乱。面试结束后，应基于事先确定的能力维度进行评分，而不是仅凭整体印象。

结语

C++ 是一门层次丰富的语言，真正高质量的面试问题应当能够帮助面试官穿越“背诵正确、理解不足”的表象，看到候选人对底层机制、资源管理和工程权衡的真实判断。与其继续使用那些被网络答案覆盖的固定题型，不如把精力放在设计具有追问空间、能够触发深度思考和体现工程判断的问题上。这不仅能提高招聘的准确性，也能让候选人在面试中感受到专业与尊重，从而提升整个技术团队的选才质量。