教你把普通简历“榨”出技术深度
学弟学妹们大家嚎，今天和大家聊一聊春招。
现在这个时间节点，准备春招的大概有两类人，一类是没拿到心仪offer的，一类是提前实习不满意想跑的。
今天我根据过往的经验（其实我个人提前批就结束了，主要是当时室友们、同届朋友们的经历）、看学弟学妹们简历过程中遇到的问题、结合自己的工作情况，写一篇总结性的帖子，希望对大家有帮助。
简历如何增色？
心态建设
很多同学都对简历不满意，觉得自己没实习，或者实习没做什么东西。其实这是一定的，客观上：
没有公司会指着实习生来做核心的工作，要不然你走了公司怎么办？
即使你入职了，绝大部分时间也都是在写业务、梳理业务逻辑等等。
所以首先，心态上不要有负担。 你没实际产出是一定的、别人其实也不会有的。 别人东西写得好，绝大部分情况是靠编，或者把组里同事写的说成自己的。
输入提升——视野扩展
聊完了心态，下面就要讲干货了。第一个重要的事就是视野扩展。 原因很简单，没有视野，你就没法写出很厉害的故事。
具体做法上，我推荐大家多看组内的技术方案、公司内的技术文章； 比如电商部门xxx设计解决了什么问题？比如搜索的xxx技术解决了什么问题？等等。 这里对大公司的同事们来说是非常有优势的，什么都能看。 没在大公司待过也没关系，可以多关注关注业内的公众号。
我这里推荐的有 货拉拉技术公众号、大淘宝公众号、得物公众号。 字节的不太推荐，虽然我自己就是字节的。但我感觉字节外网发的文章都不太适合应届生同学们学习、应用。
其实我还在学校的时候看的是美团的技术公众号，不过美团当时写了个红黑树的文章，不知道是哪个人写的，好像错误很多，在某平台被一顿喷，所以我后来就不怎么看了哈哈。
这里也说明一点，不要对公司有滤镜，不是大公司、牛公司的文章就一定好、一定适合自己。 饭要一口一口吃，路要一步一步走。 更何况很多文章其实质量也就那回事。要大胆祛魅。 很多中厂写的文更接地气，更好理解，好运用。
输出提升——把简单工作写的有深度
很多同学都说 自己没做什么，也包装了，但是好像效果也就一般。 这其实主要是视野限制的。所谓包装就是把自己做过的东西说的牛一点，那自然你得有“品味”，知道怎么样叫牛、有什么样的牛东西才行。
这里和每个人做过的事情都是很相关的，但我可以举一些经典的例子。
我们这里就拿一个最基本的XXL job来说吧。很多同学都会在简历上写 “熟练使用xxl job， 处理yyy数据， zzz延迟从什么到什么”（这里在反向引用自己之前写的文章，你说优化了xxx，指标对比是必须的。编也得编上吧？哪怕你工作了，你也得和领导有个量化的交代吧。 业务优化不好写也就算了，接口性能优化 有的同学也不写指标。那你优化什么呢？这在我这里看就是上厕所拉完没擦。）
当然很多学弟学妹们第一次接触这个定时任务框架，觉得很新奇，很牛，所以就写上了。我完全理解，第一次实习我也这么觉得hhh。 但光是这样，你可能就没什么竞争上的优势了。
具体问题1 深分页问题
定时任务处理大量数据很容易出现深分页问题。 如果你不知道什么是深分页，可以去问问gpt。
你可能觉得 诶这个东西很简单啊，不就带个cursor吗？这不是很基本的素养吗？写的时候就应该避免啊？ 但其实不是的，主要原因有：
a.开发着急，忘了这个事情了。然后功能很好用，数据量激增，自然出现深分页了。 这是很正常的，尤其是某节这样的快节奏公司。你开发写代码的时候都是orm框架 + 参数拼接，还要复用一些dao层的代码，写着写着漏了是很有可能的事情。
b.主键id不能直接用。 考虑一个场景：
你在写学校的教务系统，把所有2026届（简单理解level = 2026）, 未更新就业状态（简单理解status = 1）的学生的状态做更新。 就业状态需要通过接口查询， 接口会根据 stu_id 返回就业状态， (2 = 找到大公司工作， 3 = 找到工作， 4 = 灵活就业）
这时候，你可能会实现一个定时任务，第一步就是sql取数据 /* select * from student where level = 2026 and status = 1*/
那这么写，如果你这里现在没索引，数据量又大，直接就会sql kill（没错，大公司的sql查询有超时时间，通常2秒左右查不完就kill了）。
聪明的你可能想到，我加一个 level + status的索引，就能解决问题了吧？ 没错，短时间内可以解决问题。 但当你根据一个level + status 查出来的数据又太多了呢？
这时候聪明的你可能又想到，我加limit、offset，每次取一点，这样是不是就行了？ 没错，短时间还是可以解决问题。然后后面数据量大了，你发现 在这个where子句的约束下，你还是可能会深分页。
当然就这个例子来说，你可能会觉得，我这里建索引再带个id不就行了吗？ 这么说可能就没法聊了
具体问题2 背压
还是上面的例子，我们在查询就业状态的时候会调用接口，这时候必不可少的会对下游造成压力。 尤其是定时任务的调用，假如你一次查了10w数据，开了一堆goroutine/线程并发请求，你是快了，下游崩了。。。
当然实践上这个问题自身不会那么严重，因为一般下游也会配置默认的限流策略。比如最大qps 1000等等。还有sre啊、熔断啊，倒不会因为你一个人就把系统都弄挂。 但是如果没有，那你的这个行为可能压力就很大了。
最简单的实践是怎么做呢？ 比如原地sleep、比如用令牌桶限流器等等。
但这样其实并不是特别好。因为这些数值都是写死的，你不能根据下游的负载情况动态调整。 可能你会想到配置中心，那么谁来决定控制中心里的数值呢？
其实这里就是典型的背压问题。 大家每天背诵的tcp协议就考虑了这个问题hhhh。 具体实践上倒不是说你要实现一个tcp，不过你可以想想，这里是不是有很大的优化可能呢？
第一步，可能你没考虑了这个问题，弄出了线上故障；
第二步，你原地sleep优化了；
第三步，你可能接入了限流器；
第四步，你可能觉得限流器阈值太模板了，你参考了tcp的拥塞控制，基于特定错误码 + 配置中心 + 限流器，实现了一个通用的背压限流器，
......
所以其实知识都是相通的，八股文不是白背的（
具体问题3 hook#牛客AI配图神器#
实践上还经常出现一种情况，你有两个定时任务，希望做完一个定时任务之后，做下一个。
这其实是一个很简单的链式调用，最简单的解法当然是改业务代码了，在定时任务a里 调用定时任务b。
但如果你有一些条件判断呢？ 比如定时任务a里， 出现了x次error，重试调用自己；否则调用b，这种情况你也把这种调度控制问题全部写在代码里吗？
一种可能的解决方案是借助流程引擎，或者其他的分布式调度框架，等等。 你可以把故事写得很复杂，也可以很简单。 但是重点是可以讲故事。也是和上面一样， 可以渐近优化的。
总结
好了，这篇文章写到这里已经不短了。 总的来说，学弟学妹们优化简历的时候，要带着思考去审视自己的简历。 其实你不一定要有多少段实习经历，一个简单的工作，你也可以把它做的不简单。这也是字节跳动“敢为极致”想表达的内核。
Ai时代，还在坚持古法写作的人不多了，希望文章对大家有帮助。 如果自己想不到太多内容，也可以私信找我。我和你一起想（当然不是免费的哈，大家一年都大几十万工资呢，起码得请我吃个麦当劳四件套吧）。
如果大家对本文感兴趣，想看其他内容的文章，比如心态调整、如何在实习工作中很好的landing、等等，欢迎和我互动。要是没人互动我肯定就懒得写了（
#后端面经##春招启动，你开始投递了吗？#
华为HUAWEI稳定性 297人发布
