暑期实习offer比较，工行vs平安信托vs平安银行

简介给没有尝试过ai面试的家人们写的，可以了解一下它是一个什么样的流程，我是在牛客网上投实习简历给我发邮件的，应该是刚好抽到我这个小兵了，非常抱歉没能让ai大人尽兴。ai面试的女声跟豆包的那个是一样的（难道就是豆包？），可以去豆包听听看。流程一开始是说说你为什么想要应聘该岗位，做了哪些准备然后5道不定项选择然后有十个问题，中间有一次换题机会，每道题有限制的时间，可以提前提交第一问：进程和线程之间有什么区别？进程之间通信有哪些方式？第二问：什么是双端对列？相比于传统对列和栈，双端对列有哪些优势和应用场景？第三问：你了解HTTPS的认证握手过程吗？单向认证和双向认证的区别是什么？第四问：Android子线程为什么不能刷新UI，核心限制是什么？第五问：Java中final、finally、finalize各有什么区别？第六问：在客户端开发中,如何设计一个缓存策略来优化网络请求性能？第七问：描述你最近参与的一个客户端项目，并解释你是如何设计其架构的，包括技术栈的选择和理由。问完这个，ai会根据你说的内容进行总结然后根据你前面一问的内容进行提问接着同样是根据你上一问的问题进行提问到这第七问才算完第八问：假设你要使用MVVM架构模式来实现一个客户端功能，请说一下你的实现方式，并说明:1.你的ViewModel负责处理哪些业务?2.你是如何实现数据响应式更新?（ps：这其实是博主第一次面试，已经完全变形了，后面开始乱答，我都不知道MVVM是什么，估计ai听到我胡扯的也懵了）第九问：分享经历，这个感觉应该都是一样的第十问：也差不多，问你一个最有压力的场景。总结整个过程挺好的，没有跟陌生人说话那种社恐尴尬的感觉，ai的女声也很好听，虽然我没咋经历一般的面试，但这个ai面试压力确实小了很多，而且感觉相对来说很客观，不会受到很多面试官的影响（虽然也没有提示）。确实也比较节省资源，可以让更多的人同时面试，估计就是未来面试的方向了。我后面会写问题的面经想了解一下的可以关注一下博主。有问题可以问博主，看到消息都会回复的。原文链接https://blog.csdn.net/Eugene__Chen/article/details/145366648#牛客AI配图神器#

一、简历格式与排版（一）简洁至上去除多余装饰简历应保持简洁，避免使用华丽的封面、页眉和页脚等装饰性元素。作为大数据工程师，简历的重点应该是突出自己的技术能力与项目经验，而不是设计过多的视觉效果。控制简历长度大数据工程师的简历应控制在2-4页，对于经验较多的工程师可以适当扩展至6页。但注意内容要简洁且重点突出，尤其是项目经验和技术能力。简历内容应避免冗长叙述，确保招聘者快速获取核心信息。（二）字体与字号的选择标题字体标题可以使用加粗的黑体字，清晰区分如“教育背景”、“工作经历”、“技术技能”等板块，字号建议为小二号或三号，既突出又不突兀。正文字体正文建议使用宋体或Arial等简洁字体，字号控制在...

一面(12.20，结束后2小时约二面):你实习中实现的rpc接口的限流过程?怎么在问题出现前避免?消息队列信息一致性怎么保证?消息队列都有什么，各自都有什么区别?实习中mysql涉及到的锁?说说next-key lock?sql语句的leftjoin rightjoin innerjoin区别?讲讲消息队列+zookeeper的实现过程?zookeeper注册过程? zk的树状节点?redis优点? redis分布式锁分布式 id？说说死锁?如何避免死锁?redis有几种数据结构?每种数据结构能有什么应用?底层实现?mysql分库分表?redis缓存雪崩击穿穿透?在你的实习/项目中有什么有挑战的工作?相关工程代码有什么印象深刻的实现方法?为什么选择从原公司转到小红书实习?做两道题:左连接sql语句＋最长有效括号就是聊聊天，介绍一下岗位内容+反问环节，问问实习长度和最早啥时候能来。二面(12.23，无手撕，挂了):团队升级JDK版本的话你怎么调研？你对哪个Java版本熟悉？Java长期版本都更新了什么？ZGC？如果一个单库单表，有几亿条数据，你会想到什么，会有什么问题？插入新字段会有什么问题？B+树树高和数据量的关系。还提问了一些消息队列的内容，时间久远记不清了。在你的实习/项目中有什么有挑战的工作（一面问二面也问了）？提问实习项目。岗位介绍。-----12.25，挂了-----hr意思是跟我一起面的也都挂了，这个岗位要求比较高10月份到12月底都没招到合适的人选。。。不懂是不是话术。个人感觉是第一第二个问题答得不好，我是看Javaguide的，版本更新和ZGC确实有但是偷懒没看

华为OD的招聘铺天盖地，尽管已经有很多前辈进行了血泪控诉，但华为依然是某些时候的最高选择，让拿到了OD橄榄枝的朋友们十分纠结。如此庞大的公司，大家也很容易认为如果有烂的部门，一定也有好的部门；恶评虽然大多是经验之谈，但也难以逃避幸存者效应，待遇还可以的OD很可能不发声，给了OD招聘者很多回旋的余地。那么如何判断一个部门，乃至一个项目组到底是否适合OD生存呢？本文提出两个判断某个项目组是否适合OD生存的铁标准：三级部门总共有多少人？其中租赁员工多少人？项目组总共有多少人？其中OD有多少人？招聘时，接口人总有花言巧语，吹嘘部门前景、工作氛围、上升空间，但这都是难以衡量与判断的，尤其是对于尚未入职的...