360 安全开发-C++ 一面

1. 自我介绍

2. 你在CVTE实习学到了什么?

3. 同学,我看你是农学专业,怎么想着转行计算机

4. 你编程主要在什么操作系统下进行的？

答案：我主要还是在 Linux 环境下进行编程和调试。因为我学和练得比较多的是 C++、操作系统、网络编程这些方向，而这些内容在 Linux 下的工具链和实验环境会更完整一些，比如 gdb、make、cmake、valgrind、strace、top、lsof 这些工具都比较常用。另外很多服务端开发、并发问题、系统调用、进程线程相关的知识点，在 Linux 下也更容易直接观察和验证。Windows 我也会用，主要是日常使用和部分开发工具环境，但如果是偏系统、偏服务端、偏调试分析的内容，我还是更习惯 Linux。

5. Windos和Linux操作系统的区别是什么？

答案：如果从开发者视角来看，Windows 和 Linux 的区别可以从生态、使用场景、工具链和系统风格几个方面理解。Windows 更偏桌面应用、商业软件和图形化生态，很多开发工具和办公环境在 Windows 上更常见；Linux 则在服务器、云计算、后端服务、基础设施这类场景里更主流。从开发体验来说，Linux 的命令行工具、调试分析工具和自动化能力更强，尤其适合做系统编程、网络编程和服务端开发。像进程管理、文件权限、脚本化处理、日志分析这些，在 Linux 下通常更直接。另外，两者的内核设计、驱动生态、权限模型和系统接口风格也不同。Windows 更偏商业化封装，Linux 更开放，也更适合学习底层机制。所以如果是做 C++ 服务端、系统开发或者高性能程序，Linux 往往更常见；如果是桌面应用或者特定商业软件环境，Windows 使用会更多。

6. Linux操作系统的内核了解过吗？进程和线程的区别？

答案：Linux 内核我了解过基础模块，比如进程调度、虚拟内存、文件系统、网络协议栈、系统调用这些内容，大致知道它们在系统里承担什么职责。进程和线程的区别，我一般会从资源和调度两个角度来说。进程是资源分配的基本单位，每个进程有自己相对独立的地址空间，像代码段、堆、栈、全局数据这些在进程之间默认是隔离的。线程是 CPU 调度的基本单位，同一进程内的多个线程共享进程的大部分资源，比如地址空间、代码段和全局变量，但每个线程有自己的栈、寄存器上下文和线程局部存储。所以进程之间隔离更强，但通信成本相对更高；线程之间共享数据更方便，但也更容易出现同步和竞态问题。在 Linux 里，从实现角度看，线程和进程底层都可以看成 task，只是共享资源的程度不同。

7. 写代码的时候用ai吗？

答案：会用，但我把 AI 更多当成辅助工具，而不是替代思考的工具。比如我会用它来做一些 API 查询、代码解释、报错信息辅助分析、测试样例生成，或者让我对一个问题多看几种思路。但如果是涉及并发、内存管理、对象生命周期或者系统行为分析这类问题，我不会直接照着它的结果用，因为这类问题最怕表面上看起来对，实际上自己没有理解。我现在对 AI 的使用习惯是，先自己形成一个基本判断，再借助它去补充、对照或者提效。这样既能提高效率，也能避免过度依赖工具。

8. 用的ai工具叫什么？是编写代码的IDE工具，类似于Cursory，有了解过吗？

答案：我接触过一些通用的 AI 问答和代码辅助工具，主要用在代码解释、文档理解、错误定位思路补充和一些重复性代码生成上。像 AI IDE 这类工具我也有了解，它的优势在于不只是单点问答，而是把代码补全、工程上下文理解、文件检索和交互式修改结合在一起，能更直接融入开发流程。我对这类工具的看法是比较开放的，因为它确实能在很多重复劳动上帮忙提效。不过我也会比较注意边界，尤其是对 C++ 这类对内存、生命周期和边界条件要求很高的语言来说，工具可以提速，但最终判断还是要靠自己。

9. 字节的ai工具Trae用过吗？

答案：我有关注过这类新出的 AI 工具，但不一定每一个都长期深度使用过。我对这件事的理解是，工具迭代很快，不一定要求自己每个工具都立刻非常熟，但要保持关注和快速上手新工具的意识。如果一个工具能够明显提升代码理解、工程检索、问题定位或者开发效率，我是愿意很快去学习和适应的。所以我不会把“有没有长期用过某一个具体工具”看成核心，核心还是自己有没有用工具提升效率的意识，以及能不能比较快地接受和适应新的工作方式。

10. 实习拷打

11. 在你上一段实习，你们软件开发的流程是什么样子的？

12. 上一段实习在那里呆了多久？

13. 了解360吗？来了这里你想达到怎么样的成果呢？

14 . 什么是死锁，怎么避免死锁？

答案：死锁指的是多个线程或进程互相等待对方持有的资源，结果谁也无法继续执行。经典条件一般有四个：互斥、请求并保持、不剥夺、循环等待。只要把其中一个条件破坏掉，就有机会避免死锁。实际开发里常见的避免方式包括：统一加锁顺序，避免循环等待；尽量缩小锁粒度和持锁时间；使用 try_lock 或带超时的锁机制；对于复杂资源依赖关系，提前做好层级设计。很多死锁问题不是语法错误，而是设计阶段对资源获取顺序考虑得不够。