面试官喜欢什么样的求职者？（完结）
面试官喜欢什么样的求职者？（完结）
做了很多年的 Java 技术面试官，还真遇到几个能和我谈笑风生的求职者。
• 第一点，很重要，简历上写的项目不管是商业的还是自学的，千万不要随意造假、过
度包装。面试官都是身经百炼的，火眼金睛，很少看走眼，比如说我，哈哈哈。但是
作为求职者，多多少少还是要美化一下自己的项目经历的，毕竟人不可貌相，简历却
可以。
• 第二点，也很重要，面试官不在乎你以前做过哪些项目，在乎的是你在做过的项目中
贡献了什么。不要只停留在你会用 Spring Boot，你会用消息中间件的层面。
• 第三点，最重要，简历上项目一定是有价值的，比如说你自己造了个 RPC，你自己手
写了个高性能的连接池，你为某个知名的开源项目贡献了多少多少代码等等。
下面来具体分析一些面试场景。
1）校招生
不要只会背八股文，写算法题，现在的八股文那叫一个铺天盖地啊，到处都在教算法。
可如果你因此忽略了项目经历的重要性，那可能就得不偿失了。毕竟能说会背的校招生实
在是太多了，但真正能打能作战的不多。
因为实战经验是很难教会的，只能你亲身去尝试。
你能背会 Spring 的 AOP 和 IoC，不见得交给你一个博客平台定时发布博客的功能你能做
的出来。
我强烈推荐大家参与一些开源项目，用代码证明自己的经历与实力，简单粗暴。有一句俗
话不是说得好嘛：
Talk is cheap, show me the code.
翻译成中文就是，“废话少说，放码过来”。
现在有许多开源活动，目标参与群体主要就是大学生，例如 GSOC（Google Summer of
Code），还有国内新起的 CSOC（China Summer of Code）等，这些比赛是官方出钱（例
如 Google），培养广大学生开源积极性，与此同时推进开源项目进展的。
有好多都是大家耳熟能详的项目，比如 RocketMQ，Dubbo 等，国内的这个活动因为刚开
不久少一点，但依然有 20+ 社区。GSOC 因为规模大，活动年份久，已经有 200+ 个知名
成熟项目了，里面绝对有你了解，甚至整天在用的库。
1651923690360-de819723-09b9-4a20-869b-dd55e120b24b.png
GSOC 项目多而且整个流程非常规范，参与者都是来自世界各地的学生，大家交流可以通
过电报，Email 等手段。而且不仅有软件方面，我去年在逛社区的时候就发现了 Arduino
项目，其中任务之一是为 Arduino 标准库贡献指定功能的轮子，一旦发布通过，就可以让
全世界的上位机运行你的代码了，想一想是不是很酷。
1651923691015-5d1cc131-fdc5-476c-ba3e-58a180329b4d.png
我的一个读者，2022 年春招刚刚拿到了字节跳动的 SSP，互联网新人顶薪。
1651923690410-cfb959a0-2b92-4e5d-bf98-419314e698e0.png
他去年由于时间较晚，参加的是国内的，整个时间周期是每年中下旬，大概 6-9 月，持续
三个月。GSOC 的话 2 月底就报名了，想参加的同学一定要提前准备。
1651923690447-7f75a090-1f72-4d3a-b936-2359c3833d39.png
你只需要定期贡献，在报名时写一份 Proposal，说明自己曾经的贡献、实力以及参加的
决心即可，这个 Proposal 类似简历。不但有名师指导，开源经历，还有钱拿 。
据我所知，GSOC 现在结项后可以拿到 13K RMB 左右，前两年可以拿到 18K。国内的
CSOC 是 12K，至少 21 年是，分两次，中期报告和结项报告，各一半。税后到手 10K+，
作为大学生的你们可退税，不出意外到时候就是 12K。感兴趣的同学可以去了解下，官网
我放在下面了。
CSOC 官网，https://summer-ospp.ac.cn/
想强调的是，没有想象的难，原因是：
• 你往往只是负责某模块中的 Feature，贡献并不需要完全理解整个项目。
• 开发过程中，大家都很热情往往很活跃，贡献并不是你想象的埋头各干各的，如果真
是这样的话，开源这两个字也就失去了它的灵魂了。
所以，大胆卖出第一步才是最重要的。
在参与开源时，不仅可以锻炼你的项目/工程经验，也可以在实际场景中熟练应用并理解
Git 等软件，这与工作中是没有任何区别的，你会经历回滚，合并提交等等操作，也可能
会帮别人 code review。
1651923690420-7e251542-4cfd-4b22-93d6-a0487312acb2.png
在这样的高强度合作开发下，你就不仅仅只会 add,commit,push 了…
注：部分开源项目的经历来源于我读者的投稿，原文链接：https://mp.weixin.qq.com/s/
IhUeuxvjwjL1YbaniFIJtg
2）社招生
社招生的面试要求相对来说比校招生更高一些，就我个人以往的面试体验来说。
如果你面试的是一家小公司，或者初创团队，你是可以在项目经历上写你有从前端到后端
开发的经验，一肩挑过的求职者在小公司小作坊是很受欢迎的。
毕竟小公司的精力和财力都有限，大部分项目可能都是一肩挑，从前端，到后端，到测
试，包括需求文档啊，产品交付啊。
如果你只会某一项技术，或者专注于某一个领域，基本上是行不通的。
这种同样适用于，你之前在一线城市，想安享晚年回到了二三线城市，这种能力是必须
的。
但假如你面试的是一家大厂，那情况就完全不同了。
你就是个螺丝钉，你就必须在某个领域钻得非常深，而不是面面俱到。
你说你会高并发，那到底你的业务量有多少，你解决过什么性能瓶颈，吞吐量你提高了多
少？
你说你会 Spring，Spring 的源码你看过吗？
你说你做过电商系统，电商系统中常见的 9 大坑：库存超卖、重复下单、物流单 ABA…
都是怎么解决的？
举个例子，如果避免重复下单？
用户快速点了两次 “提交订单” 按钮，浏览器会向后端发送两条创建订单的请求，最终会
创建两条一模一样的订单。
解决方案：
解决方案就是采用幂等机制，多次请求和一次请求产生的效果是一样的。
方案一：
利用数据库自身特性 “主键唯一约束”，在插入订单记录时，带上主键值，如果订单重复，
记录插入会失败。
操作过程：
• 引入一个服务，用于生成一个“全局唯一的订单号”
• 进入创建订单页面时，前端请求该服务，预生成订单 ID
• 提交订单时，请求参数除了业务参数外，还要带上这个预生成订单 ID
方案二：
前端通过 js 脚本控制，无法解决用户刷新提交的请求。另外也无法解决恶意提交。
不建议采用该方案，如果想用，也只是作为一个补充方案。
方案三：
前后约定附加参数校验。
当用户点击购买按钮时，渲染下单页面，展示商品、收货地址、运费、价格等信息，同时
页面会埋上 Token 信息，用户提交订单时，后端业务逻辑会校验 token，有且匹配才认为
是合理请求。
注意：同一个 Token 只能用一次，用完后立马失效掉。
<font style="color:rgb(18, 18, 18);"><form action="/add-name-v2"
method="post"> </font>
<font style="color:rgb(18, 18, 18);">{% csrf_token %} </font>
<font style="color:rgb(18, 18, 18);"><input type="text" name="name">
</font>
<font style="color:rgb(18, 18, 18);"><input type="submit" value="提交"> </font>
<font style="color:rgb(18, 18, 18);"></form> </font>
再比如，如何解决库存超卖的问题？
常见的库存扣减方式有：
• 下单减库存：即当买家下单后，在商品的总库存中减去买家购买数量。下单减库存是
最简单的减库存方式，也是控制最精确的一种，下单时直接通过数据库的事务机制控
制商品库存，这样一定不会出现超卖的情况。但是你要知道，有些人下完单可能并不
会付款。
• 付款减库存：即买家下单后，并不立即减库存，而是等到有用户付款后才真正减库
存，否则库存一直保留给其他买家。但因为付款时才减库存，如果并发比较高，有可
能出现买家下单后付不了款的情况，因为可能商品已经被其他人买走了。
• 预扣库存：这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 30
分钟），超过这个时间，库存将会自动释放，释放后其他买家就可以继续购买。在买
家付款前，系统会校验该订单的库存是否还有保留：如果没有保留，则再次尝试预
扣；如果库存不足（也就是预扣失败）则不允许继续付款；如果预扣成功，则完成付
款并实际地减去库存。
至于采用哪一种减库存方式更多是业务层面的考虑，减库存最核心的是大并发请求时保证
数据库中的库存字段值不能为负数。
方案一：
通常在扣减库存的场景下使用行级锁，通过数据库引擎本身对记录加锁的控制，保证数据
库的更新的安全性，并且通过 where 语句的条件，保证库存不会被减到 0 以下，也就是
能够有效的控制超卖的场景。
<font style="color:rgb(18, 18, 18);">update ... set amount = amount - 1 where id
= $id and amount - 1 >=0 </font>
方案二：
设置数据库的字段数据为无符号整数，这样减后库存字段值小于零时 SQL 语句会报错。
再比如说，商家发货，物流单更新 ABA 问题
举个例子：
商家发货，填写运单号，开始填了 123，后来发现填错了，然后又修改为 456。
此时，如果就为某种特殊场景埋下错误伏笔，具体我们来看下
1651923691470-c6d9ef7e-b598-4c9d-bc5d-4b88a2132457.png
过程：
• 开始「请求 A」发货，调订单服务接口，更新运单号 123
• 但是响应有点慢，超时了
• 此时，商家发现运单号填错了，发起了「请求 B」，更新运单号为 456 ，订单服务也
响应成功了
• 这时，「请求 A」触发了重试，再次调用订单服务，更新运单号 123，订单服务也响
应成功了
• 订单服务最后保存的 运单号 是 123
是不是犯错了！！！！
那么有什么好的解决方案吗？
很多人可能会说，不重试不就可以了，要知道重试机制 是高可用服务的重要保障手段，
很多重试是框架自动发起的。
理想的解决方案：
数据库表引入一个额外字段 version，每次更新时，判断表中的版本号与请求参数携带的
版本号是否一致
<font style="color:rgb(18, 18, 18);">update order set logistics_num =
#{logistics_num} , version = #{version} + 1 where order_id= 1111 and version =
#{version} </font>
• 一致：才触发更新
• 不一致：说明这期间执行过数据更新，可能会引发错误，拒绝执行。
以上这部分内容，来自读者微观技术 的投稿，原文链
接：https://mp.weixin.qq.com/s/_7ZWqn5yPQcVRzOxiwkkmw
简单总结一下：
针对不同的求职者，面试官也有自己套路和打法。
但其实考察的重点，还是你在业务中解决了哪些技术难点，怎么实现的？
针对求职者来说，我的建议是，多去参与真实的项目，如果参与不了，就去 GitHub 上或
者码云上找一些比较优质的开源项目，搞清楚项目的架构和业务流程，对于不懂的问题，
可以问开源作者，加他联系方式，开源项目上一般都会留。
或者在技术群里讨论。
或者自己展开去调查。
推荐几个我认为不错的开源项目吧：
1）mall
https://github.com/macrozheng/mall
1651923691656-f4777443-803a-4365-9198-14d8d23bff5c.png
经常在 GitHub 趋势榜单上霸占着自己的位置，可以说参与的人数非常多。
1651923692632-10019314-aa9c-4a1d-bdc4-fab2d57f5266.png
Mall 的一套打法非常齐全。
2）vhr
https://github.com/lenve/vhr
1651923692647-38713d1c-9c6e-49dd-ad27-65edbf843ee6.png
我和作者很熟，还霸占了一个贡献者的名单。
1651923692921-0bfab160-ee4d-463f-9fe0-a5d572ecfc7b.png
配套文章也非常的全面。
3）codingmore
https://github.com/itwanger/coding-more
1651923693604-7836e2c7-d489-4996-9c2d-e516d67ad96d.png
虽然刚开始开源，star 还比较少，但我是有信心把这个开源项目做好的。
1651923694181-06409d70-1832-44ff-bdbc-5128e0ca2e36.png
配套的文章我也写了不少。
4）miaosha
https://github.com/qiurunze123/miaosha
1651923694894-1669e9bc-5602-4adc-9b89-147a7347193f.png
不仅有实战，还提供了很多经典高并发问题的解决思路。
1651923695674-652f7194-3185-4dd0-8973-25b01a55b8e5.png
好了，就推荐这么多吧，针对项目经历这一关来说，想要和面试官谈笑风生，最好在这些
方面着重发力。
• 项目中用了哪些技术，掌握程度如何，有没有比较有挑战性的。大厂注重原理，小厂
注重广度。
• 项目中解决了哪些难题，毕竟公司招你不是为了给你发工资，而是让你挣钱的，项目
开发中肯定会遇到各种各样的问题，你该怎么解决？
• 你得学会表达，不要紧张，紧张的话，就多面面，总结经验，反正面试又不要钱，但
表达得好，面试官很可能给你开个大 offer