二面（技术深度面）基本信息形式：1V1视频面试，面试官层级更高，侧重项目难点、场景设计和系统架构。 时长：约40-60分钟。一面结束后很快通知二面，节奏紧凑。 氛围：面试官会追问到答不上来为止，考察知识的边界和深度。场景题是拉开差距的关键。
面试流程一面通过后→二面通知→按时参加面试→项目难点深挖→场景设计题→进阶八股→手撕代码/系统设计→反问环节→退场。 二面问题及参考回答
一、项目难点与解决方案
问题1：你实习/项目中最难的一个点是什么？怎么解决的？ 参考回答：在XX项目中，最大的难点是大数据量导入的性能瓶颈。我从四个方面优化：①缓存预热：将热点数据提前加载到Redis；②多线程并发导入：使用线程池并行处理；③预加载机制：异步预加载下一批数据；④SQL优化：分析慢查询日志，优化索引设计（覆盖索引、联合索引），减少JOIN操作。
二、场景设计题（滴滴面试特色）
问题1：微博点赞系统怎么设计？ 参考回答： 数据库表设计：点赞记录表（user_id、target_id、status、create_time），复合索引(user_id, target_id)；统计表（target_id、like_count），定时更新。 缓存设计：热点内容的点赞数缓存在Redis，使用hash结构存储；用户点赞状态用String存储（过期时间适当设置）。 缓存过期策略：根据内容热度分级——高热内容永不过期（主动更新），普通内容设置较短过期时间。 大V数据缓存：按时间统计定期入库，冷热分离。 取消关注：用户取消关注时，需要批量删除对应的点赞关系，可以用消息队列异步处理。
问题2：设计司机智能接单助手（后端+大模型） 参考回答： 架构：订单信息输入→大模型决策引擎→输出接单建议。 影响因素：路况拥堵、司机偏好（长单/短单）、目的地方向、收入预期、疲劳度。 知识存储：司机历史数据用RAG（检索增强生成） 更合适，因为司机的偏好是动态变化的，微调成本高且更新周期长。 延迟优化：200ms内完成的关键——预处理缓存常用路线；模型轻量化；部分决策走规则引擎降级。 体验平衡：若连续多个“建议不接”，需加入兜底逻辑——随机推荐一个可接受订单，或提高后续订单的推荐分。
问题3：滴滴核心场景——如何匹配司机和乘客？ 参考回答（调度/算法方向）： 算法选型：即时匹配用贪心策略；多目标优化（兼顾司机收益和乘客等待时间）用二分图匹配。 实时路况：结合实时路况数据动态调整权重，A*算法更适合路径规划，Dijkstra适用于静态路网。 供需失衡处理：高峰期提价（动态定价）、扩大匹配范围、引导乘客预约/拼车。
三、进阶八股
问题1：Redis持久化方式？优缺点？ 参考回答：RDB（快照）和AOF（追加日志）。RDB恢复快，但可能丢失数据；AOF数据更安全，但文件大、恢复慢。生产环境通常两者结合使用。
问题2：聊聊Go的GMP模型（Go方向） 参考回答：G（goroutine）、M（machine线程）、P（processor处理器）。P的数量决定并行度，G挂在P的本地队列或全局队列，M绑定P执行G。当G阻塞时，M会与P解绑，新建M承接P的任务。
问题3：C++智能指针与系统调用（C++方向） 参考回答：智能指针解决资源生命周期管理（RAII）。系统调用会引发线程切换（用户态→内核态），malloc不是系统调用（底层调用brk/mmap），brk用于小内存分配，mmap用于大内存分配。
四、手撕代码
难度 高频题 解题要点
简单非零元素移到数组后面双指针（一个遍历，一个记录非零位置）
中等手写HashMap with TTL数组+链表+过期清理线程
| 
发表于 2026-5-27 22:43:51