@dsw0719 Java 有 langchain4j ，或者你可以自己去封装一个调用 LLM API 的 SDK ，因为现在大模型的调用基本都是 Restful API ，和普通的 API 调用区别不大

@code0611 #16 谢谢

@qinghuazs 补充一点，保持对候选人的尊重，面试不要迟到，我一般是提前 5~10 分钟进入会议；如果可以，尽量开摄像头，如果没有条件，和候选人说明不开摄像头的原因；试本身就是一个双向选择的过程，不要摆出一个高高在上的态度

社招：
1. 首先梳理好对应岗位的人才画像，明确好该岗位对候选人的要求，包括学历、年龄、工作年限、专业、技术栈等要求，同时评估好该岗位的成本预算
2. 正式面试前建议抽出 10~15 分钟时间把候选人的简历整体过一遍，大概了解下候选人的工作经历和项目经历，然后从你感兴趣的项目中选择 1 到 2 个，以 STAR 的原则对候选人的项目进行简单的分析，提前准备一些问题，同时思考下
2.1 候选人是如何进行架构设计或者功能设计的
2.2 当前选择的方案是否有可优化的地方
2.3 如果是你来做设计，你会怎么做
3. 面试尽量围绕候选人简历中的内容进行提问，不要问候选人简历中未提及到的技术，除非候选人自己提到了
4. 建议通过项目经历来进行提问，根据业务场景和项目需求来组织问题，中间穿插技术性的提问，不要干扯八股文
5. 除了专业能力，还需要考察候选人的软能力，比如沟通表达能力、逻辑思维能力、学习能力、团队合作能力、解决问题能力、适应能力、抗压能力等，沟通表达能力、逻辑思维能力、解决问题能力在业务问答和技术能力考察时就可以体现出来，主要是看候选人是否有系统性思维，一般遇到事情是否去思考为什么会出现这个问题，原因、问题点、重点、解决方案等，表达顺畅，逻辑清晰。学习能力主要考察两点：遇到新的业务或者技术时，能否快速掌握消化；候选人是否有主动学习的习惯。针对第一点，主要问候选人的学习方法，看看候选人有没有一套自己的方法论，并结合我自己的学习方法进行一些交流。针对第二点，我一般会问候选人最近有没有在看书，或者有没有看到过一篇让自己印象深刻的文章，主要讲述的内容是什么，解决了哪些哪些，有没有什么启发，从这些问题中可以看出候选人有没有持续学习的习惯和能力。团队合作能力、适应能力和抗压能力这些在面试中一般较难考察到，我一般会问遇到紧急的生产问题时是如何处理的。
6. 关于算法题，我始终觉得算法题作为面试的一个考察项有点扯淡，就像辟邪剑谱一样，你不练要被打死，你练了，他也练了，结果是相当于没练~，对于实际工作（大部分岗位）的帮助其实是很小的。而且，如果候选人没有见过相关的算法题，或者没有自己实现过相关的算法，那么让一个人在 30 分钟内解决这类问题，是一个比较困难的任务，而如果这个人接触过相应的题目，那么算法题考察的更多的是他的记忆能力还是技术能力呢？算法题能体现出多少他的技术能力，这个是存疑的。
7. 关于 OP 提到的代码面试作弊的问题，可以试试共享屏幕，同时看看他在做题的过程中会不会眼睛乱转，没办法完全避免
8. 关于评分的问题，看你的人才画像和我前面说的几点进行参考性的评估吧，有时候面试也看缘分，看这个人顺眼不顺眼
以上是我自己的一些经验，仅供参考

OP 请教一下，滴滴第三轮技术面考察算法吗？下周一三面~

@winRain #39 有岗位信息吗，老哥

@netnr 老哥，你这个简历看不出来你的优势，建议再优化一下，当然我只是站在个人角度给出的**建议**

算法就别卷了 ，拿出更多的时间看看系统设计、架构设计的内容吧，可以把卷算法的时间释放出来写写文章画画图，为以后做做准备

从过来人的角度看，选钱多的，以后跳槽可以 battle 更高的薪资，如果选 12K 的，以后跳槽可能都给不到 18K

@des 把你管理工作中遇到的问题记录下来，去和你领导交流，看看他会怎么做，也可以去问问 AI ，AI 也可以给你答案；我很多经验都是日常观察我领导得来的

首先恭喜 op ，羡慕 op 。
说一下我自己的管理理念，不一定适合，仅供参考。
管理，我理解就是 4 个字：管人和理事。
管人方面：
1. 学会放权，不要想着所有事情自己都去参与或者干涉，要让团队成员有一定的自主性，不然你会特别累，而且事情也做不好
2. 允许团队成员犯错，当团队成员犯错时，要给予一定的鼓励，帮助他分析原因，以后如何规避；尤其不要因为一件事情就把某个人判死刑
3. 把握好每个人的特点，有的人可能喜欢研究，那就安排一些学习研究或者有难度的事情，有的人喜欢按部就班，那就安排一些通用性的工作；有些人做事情可能喜欢抓紧做完，后面几天空闲一些，有些人喜欢每天做一点，每天都不会有太大压力，这种情况就关注结果，不要太过度干涉过程

理事：
1. 绩效考核：公开公平公正，在绩效考核时，做好横向比较（和团队内其他成员的比较）和纵向比较（和自身前期表现的比较），明确好工作目标的实现情况，让团队成员知道自己为什么拿好绩效、为什么拿差绩效
2. 任务安排：给团队成员安排任务时要明确，目标明确、时间点明确，不要安排一些模模糊糊的事情让团队成员自己去猜（经历过这种事情，所以觉得太恶心了）
3. 多学学习一些方法论，如 STAR 、STOW
4. 从更宏观的角度去看待事情，遇事不要盲目下决定，多思考一点，当你做一个决定的时候，可能影响的是整个团队所有人（比较经典的事情就是你让某个人去某件事，干了 2 天后，你发现你想错了，但是另一个人已经因为你的决定干了两天，你说换个方向吧，别人 2 天白干）

最后：
思想上，不要想着自己高人一等，虽然你顶着主管的岗位，但是大家是一个团队，你的任务是带着大家去冲锋，而大家是你的后盾。但是，脱离开公司的环境，大家都是普通人

北京面了 2 次都挂了，第二次面试面试官要了微信和电话，结果还是挂了 https://i.imgur.com/NIvxivj.png

@wuxi889 #83 确实，包括我在上家公司当面试官也是这么做的，但是掌握一些方法论其实也有好处，更有指导性；最后，感谢分享！

@tairan2006 #56 确实，谢谢提点，我去把平常做的再分类归纳一下

最近也在面试，借这个帖子问一下，后端的性能优化大家都做了哪些工作？我日常工作中涉及到性能优化的，主要是涉及到几点
1. 不常修改但是经常性访问的数据用 Redis ，比如一些配置数据、档案数据
2. 一些可并行的任务或者查询尽量用 CompletableFuture
3. 能做批量处理的，尽量批量处理；但是对于一些特别大批量的数据，进行分批次并发处理，最后合并结果（ mapreduce ），之前遇到过一次某个大账号单月 200 万条流水信息，导致一次性查询到内存里 OOM 的情况，后来对这方面特别注意 https://i.imgur.com/NIvxivj.png
4. 一些数据结构的优化，比如数据库表设计的时候，尽量用能满足当前需求的占用空间最小的数据类型，tinyint 这种
5. JVM 的一些参数调整，比如 G1 的 younggc 会有一些毛刺，大部分回收时间在 20 30ms ，偶尔会有 90ms 的情况，去调整了下 region 的大小和 Rset
6. SQL 查询优化，自己写了个工具，每天定期去拉取监控平台的慢 SQL ，交给大模型分析，分析完成后发个邮件到邮箱
7. 还有就是业务上，有些长事务的场景去做拆分，长事务调整成几段小事务，前一事务处理完成后，新起事务或者通过事件中心去做下一阶段的事务，页面上增加人工补偿机制
目前能想到的就这么点，这些都是我在实际开发中真正去做的，但是面试的时候说这些，面试官好像都不太满意，想问问大家都是怎么做性能优化来支撑高并发业务的
（我几份工作都是面向 B 端用户的，C 端业务没做过，所以也很好奇）