Java 后端实习面试：AI 教育平台与智能鼠标项目深挖

《面试题目》

1. 请先做一下自我介绍。
2. 你对前端技术的了解程度怎么样？
3. 你对服务器运维方面的知识了解多少？
4. 你的两份实习都是 AI 应用方向，未来更倾向于往哪个方向发展？
5. 平时有没有和同学、学长或者前辈交流过简历应该怎么写？
6. 你上一份实习在 9 月离职，为什么准备换一份实习工作？
7. 现在很多实习生的简历都是 AI 应用、知识库和 RAG 项目，你有没有发现这个现象？
8. 对于大部分公司来说，做 AI 应用可能没有出路，你怎么看待这个问题？
9. 市场上有大量类似的 AI 智能教育平台，你觉得最终能有多少个生存下来？有没有思考过这个问题？
10. 如果一家公司不打算重点投入 AI 应用，而是主要开发传统业务系统，你怎么看？
11. 你花了很多时间学习 AI 开发，会不会导致你的后端技术和业务逻辑能力比其他专注后端开发的实习生弱一些？
12. 你离职之前，AI 教育平台大概处于什么状态？是否已经正式上线？
13. 既然平台已经上线，你知道当时大概有多少用户吗？
14. 你参与开发的智能鼠标主要解决什么问题？
15. 这个产品最终以什么形式提供给客户？是安装桌面客户端后，通过鼠标组合键触发相关功能吗？
16. 你怎么看待智能鼠标这个项目的市场前景？
17. 鼠标的按键功能是不是需要通过专门的驱动来对接？
18. 你们能识别具体的鼠标品牌吗？
19. 你了解公司定制化鼠标的价格吗？
20. 智能鼠标调用 AI 服务产生的 Token 费用是如何计算的？采用买断制还是按使用量收费？
21. 用户购买智能鼠标之后，是否还需要额外支付 AI 服务的使用费用？
22. Java 中，方法重载（Overload）和方法重写（Override）有什么区别？
23. Java 中，如何创建一个新的线程？
24. MySQL 中，INNER JOIN 和 LEFT JOIN 在查询结果集上有什么区别？
25. 公司规定，实习生在具备足够的独立开发能力之前，可以使用 AI 查询知识，但不能直接使用 AI 生成代码。你怎么看待这项规定？
26. 平时和老师、同学沟通，或者与其他人配合完成任务时，你会不会感到胆怯？
27. 如果需要直接与大型企业或政府机构的客户沟通，你会不会有心理压力？

《参考解析》

重载与重写的区别

重载（Overload）发生在同一个类里，方法名相同、参数列表不同（个数、类型或顺序），返回值类型不参与区分，编译器在编译期就根据实参的静态类型选定调用哪个版本，所以是编译期多态。重写（Override）发生在父子类之间，子类重新实现父类的方法，要求方法签名一致、子类方法的访问权限不能更窄、不能抛出更宽的受检异常，运行期由对象的实际类型决定调用版本，是运行期多态，靠虚方法表分发。

容易被追问的边界：光改返回值类型不构成重载，会直接编译报错；private、static、final 方法和构造方法都不能被重写（static 只能被隐藏）；子类方法加 @Override 注解能让编译器替你挡住签名写错的问题。

创建线程的方式

Java 里严格说只有一种「创建线程」的原语——new Thread(...).start()，其余都是把任务交给它执行的封装方式：实现 Runnable 交给 Thread；实现 Callable 配合 FutureTask 拿返回值并能抛异常；继承 Thread 重写 run（不推荐，Java 单继承会限制扩展）；用线程池 ExecutorService.submit/execute 提交任务。JDK 21 之后还有虚拟线程 Thread.ofVirtual()，它由 JVM 调度、阻塞时不占用平台线程，适合高并发 IO 场景。

回答时值得点出的三个细节：start() 才会真正创建线程并由 JVM 调用 run()，直接调 run() 只是普通方法调用；同一个 Thread 对象只能 start() 一次；实际工程里应该用线程池而不是裸 new Thread，否则线程创建销毁开销大、数量不可控，还会因为没有统一入口而丢失监控和拒绝策略。

INNER JOIN 与 LEFT JOIN 的结果集差异

INNER JOIN 只保留左右两边都能匹配上的行，任一侧没有匹配记录该行就整体消失。LEFT JOIN 以左表为基准，左表的每一行都保留，右表没有匹配时右表字段补 NULL。

真正容易翻车的是三个衍生考点：① 过滤条件写在 ON 还是 WHERE 结果完全不同——LEFT JOIN ... ON a.id = b.aid AND b.status = 1 会保留左表全部行、只是匹配不到的不带右表数据，而把 b.status = 1 挪到 WHERE 会先把补 NULL 的行过滤掉，语义退化成内连接；② LEFT JOIN 后右表有多条匹配会让左表行数膨胀，再套 SUM/COUNT 就容易重复累加，需要先在子查询里聚合；③ 判断「右表不存在」的经典写法是 LEFT JOIN ... WHERE b.id IS NULL，或直接用 NOT EXISTS。

怎么看待「可以用 AI 查知识、但不许 AI 直接生成代码」

这条规定的落点其实是「不能把不懂的代码提交上去」，而不是排斥工具，所以回答时可以先承认它合理的部分：实习生阶段的核心目标是建立独立定位与设计能力，直接贴 AI 生成的代码最容易造成「能跑但讲不出为什么」，出了线上问题也没有排查能力。然后给出自己可落地的边界：把 AI 当检索和解释器用（查 API 语义、让它解释一段框架源码、帮我列出排查思路），代码自己写；对 AI 给出的方案一定先本地验证再采用，能说清每一行的作用、边界条件和失败时的表现；不把含公司代码、日志、密钥的上下文贴给外部模型。

更好的答法是给一个具体例子，说明自己曾经用 AI 缩短了哪一步的耗时（比如把一段正则或工具方法的写法问清楚、对照官方文档验证），又在哪里拒绝了它的建议（它给的方案没考虑并发或事务边界）。这样既表明态度，也顺带证明了自己的技术判断力。