VIVO C++暑期实习(嵌入式方向)

vivo 的 C/C++ 开发(嵌入式方向) 暑期实习,一面整体更偏 「基础操作系统 + C/C++ 功底 + 项目真实性」,算法题压力通常小于纯后台岗,但若操作系统和并发答得虚,很容易被追问穿。

这篇面经根据 2025 届暑期实习一面回忆 整理,岗位说明里强调工作落在 Android 与 Linux 之间的中间层(性能优化、模块开发、接口适配等),因此面试题会围绕:

  • 你能不能讲清楚自己做过的 嵌入式 / 底层相关项目;
  • 对 Linux 用户态、进程线程、同步、I/O 是否有体系化理解;
  • C/C++ 混用、内存、调试 是否像写过真实代码的人;
  • 是否具备进入 中间层模块 的学习意愿与基础。

岗位在做什么?

根据一面 反问 环节,面试官介绍的大致方向是:

做 安卓层和 Linux 层之间的中间模块 的优化或开发。

可以粗浅理解为:

Android 框架 / 应用

Java/Kotlin、系统服务

中间层(本岗位相关)

Native C/C++、HAL 适配、缓冲与性能、与内核驱动对接

Linux 内核 / 驱动

字符设备、platform 驱动、中断 DMA 等

因此备考不必把重点全放在「纯 MCU 点灯」,而要 往 Linux 用户态 + Native 开发 + 基础 OS 理论 靠;有 STM32/RTOS 项目依然加分,但要能翻译成「和 Linux 世界怎么衔接」。

面试问题:

  1. 问项目:介绍一个和嵌入式相关的项目,你在里面写了哪些 C/C++ 模块?面试官通常会追问:模块边界、你怎么验证是对的、如果流量/负载变大瓶颈在哪。
  2. 用户态与内核态:为什么需要分两层?嵌入式/Linux 里哪些操作必须进内核?(例如直接操作部分硬件、缺页处理、系统调用入口)
  3. 进程与线程:在 Linux 上,创建线程比 fork 子进程更「轻」,主要体现在哪些资源或开销上?
  4. 虚拟内存:简述页表的作用;两个进程的虚拟地址相同,如何映射到不同物理页、互不干扰?
  5. 阻塞 I/O:线程在 read 上阻塞时,内核大致做了什么?select / poll / epoll 分别想解决什么问题?
  6. 死锁:死锁的四个必要条件是什么?工程里更倾向 按固定顺序加锁 还是 trylock + 退避?各适合什么场景?
  7. 条件变量:为什么 pthread_cond_wait 必须放在 while 循环里,而不是只 if 判断一次?(虚假唤醒、竞态)
  8. 内存对齐与结构体:#pragma pack / __attribute__((packed)) 的利弊?和 DMA、外设寄存器映射、跨平台协议结构体 一起用时要注意什么?
  9. C 与 C++ 混编:驱动或 HAL 用 C、上层用 C++ 时,链接阶段常见坑有哪些?(extern "C"、name mangling、ABI、谁分配谁释放)
  10. 性能排查:系统卡顿或 CPU 占用异常,你会用哪些手段?(如 top/htop、perf、strace、/proc、日志分级)各能看到什么、如何缩小范围?

核心大厂开发面试题以及基础八股文资料汇总:

https://www.nowcoder.com/creation/manager/columnDetail/Mq7XWW

准备策略

一、时间规划:建议 3~4 周

第 1 周

项目故事 + OS 概念导图

2h

第 2 周

进程线程、同步、死锁、条件变量

2h

第 3 周

I/O 多路复用、虚拟内存、对齐与混编

2h

第 4 周

模拟面试 + 反问 + 薄弱点回炉

1.5~2h

若只有 1~2 周,优先:项目主线 + 第 2~7 题对应知识点 + 手写一个小 demo。

二、项目:占准备精力 40%~50%

vivo 一面几乎必问项目,建议准备 「1 主 1 备」:

主项目(5~8 分钟)结构:

  1. 背景:解决什么问题(监测、通信、人机、采集等)
  2. 架构图:任务/进程、模块、数据从哪来到哪去
  3. 你的 C/C++ 贡献:具体文件/模块,避免只说「我们组」
  4. 一个难点:现象 → 假设 → 验证 → 根因 → 防复发
  5. 可量化结果:延迟、吞吐、稳定运行时长、内存占用等(有一个即可)

和岗位衔接的一句话(建议背熟):

我在 MCU/RTOS 里做过采集与协议栈;理解中断、DMA、任务同步;若做 vivo 中间层,希望把「数据通路、缓冲、同步」经验迁移到 Linux Native 模块。

有 STM32 / RTOS / 驱动 经历是加分项,但要主动往 Linux 用户态、阻塞 I/O、多线程 上靠,否则容易被认为「只会裸机」。

三、操作系统:按「题号」对标突破

2

用户态/内核态、系统调用

画一张 syscall 路径简图

3

进程 vs 线程、资源开销

对比 fork 与 pthread_create 复制了哪些东西

4

虚拟地址、页表、隔离

口述:为何野指针常只杀自己进程

5

阻塞 I/O、多路复用

写个 echo server:select 或 epoll 版二选一

6

死锁四条件、预防策略

举一个「锁顺序不一致」导致死锁的小例子

7

条件变量、虚假唤醒

手写生产者-消费者伪代码(while + cond)

不要求背完整内核源码,但要能 连续说 2~3 分钟不乱,且能接一句「实际工程里我会怎么做」。

全部评论

相关推荐

在我来鹅之后,接到的第一个完整大需求就是需要编写一个skill,之前的实习也写过一些skill,但是在我的理解中skill就是跟提示词没差,把你需要的目标全写上就好了,所以第一次mr我提交了一个超过1200行的md,被mt打了回去,为了完成这个需求,我又赶紧请教了我身边的大神同学,获取一些写skill的经验,将原先1200行的md进行了对应的references拆封,又通过我朋友教我的验证机制验证这个skill的效果,最后完成了我的第一个需求。正好前两篇文章给大家分享了写好的用来包装简历的skill,那么今天来给大家分享怎么去写一个好的,可以实际用来工作的skill,摆脱只会写提示词的尴尬。构建 Skill 的五个步骤Step 0:先写 EvalsEval(Evaluation,评估)是一套结构化的、可重复运行的测试用例集,用来判断 Skill 的表现是否符合预期。它不是泛指"测试一下",而是开发 Skill 的前提条件。一个典型的 Skill eval 集至少包含三类用例:- 正例(Positive):用户说“帮我看一下这个 PR 能不能合”,验证 Skill 应该被加载- 负例(Negative):用户说“帮我把代码格式化一下”,验证 Skill 不该被加载——路由别跑偏到不该触发的地方- 边界(Edge):“这个 PR 改了一行日志,要不要审”,验证边界情况下的路由行为正例和负例都要写,而且负例往往比正例更值钱——误触发是 Skill 路由的头号失败模式。Eval 不只是测一次。Perplexity 的 eval 分三个层次:如下图每种都要在 GPT、Claude Opus、Claude Sonnet 不同的 orchestration 模型上分别跑——Sonnet 和 GPT 的 Skill 行为差异很大,只在一种模型上过了不够。没有 evals,你改 description 就是在盲改,一个新 Skill 也可能悄悄搞坏已有的十个 Skill。Step 1:写 Description(最难的一行)description 是路由触发器,不是文档。写好它不需要关心 Skill 的内容,只需要关心能不能在正确的时间加载、有没有意外触发到不应该触发的地方——误触发是头号失败模式,每加一个 Skill 都有可能让其他 Skill 变差。糟糕的 description 描述 Skill 做什么,好的 description 说什么时候加载。举个监控 PR 的例子:不要写这个 Skill 做什么,要写工程师感到焦虑时会说什么——"babysit"、"watch CI"、"make sure this lands"。快速检查清单:- 以"Load when…"开头- 控制在 50 词以内- 描述用户意图,最好来自真实查询- 不总结工作流程Step 2:写 Body跟同事讲工作流程和跟 LLM 讲工作流程完全是两回事。对几乎任何面世超过一年的软件工具,只要提名字,模型已经知道怎么用。所以跳过模型已经懂的部分。不用写出每一步命令。比如不要写 git log → git checkout main → git checkout -b clean-branch → git cherry-pick commit。写 "Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why." 模型在后者上表现好得多,尤其是事情不按预期走的时候。太规定的指令比灵活的指令更脆弱。然后聚焦 gotchas 和反例,它们是最高信噪比的内容。每次 Agent 搞砸了就加一条,gotcha 会自然地累积起来。条件逻辑或内容太重的东西移出 SKILL.md,放到 accessory file 里渐进加载。Step 3:用层级结构- scripts/ —— 确定性逻辑,模型不用每次重新发明- references/ —— 重型文档,条件触发才读("如果 API 返回非 200,读 api-errors.md")- assets/ —— 输出模板,模型直接复制填充- config.json —— 首次运行设置,问一次保存下来对于极其复杂的 Skill,进一步考虑是否应该拆成一组 Skill,用 depends: 声明加载关系。Step 4:迭代切分支出来,在无 Skill 的状态下跑 hero query(核心用户场景查询),建 eval 集,反复调。提交 review 时最好一个 changeset 里自带 eval 集。Description 里的小词改动对路由影响很大,甚至会 spillover(溢出)到其他 Skill,所以这些在 Step 5 之前做完。Step 5:发布大家快把这5步实行起来,成为写skill专家吧!
琉璃梦忆:直接skill creator 管你这那的
AI了,我在打一种很新的...
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务