3.简历

合格的简历

1、基本信息

本栏一定要放在开头或者最显眼的地方，为什么要放在显眼处？因为它是给 hr 看的，尽量让他第一眼就能扫完你的基本信息，主要包括：姓名，性别，学历，毕业院校，年龄，电话，邮箱，居住地，期望地，最好能留一些备用联系方式，便于 hr 能第一时间联系到你。

2、教育经历

这里一般建议写本科/专科及以上的学历经历，切记不要写什么小学、初中、高中。

3、技能

这个栏目主要给面试官看的，尽量能让面试官在 10 秒内知道你会什么，既不能太夸张，也不能过于空洞。比如你会那些编程语言，你使用过那些平台，你用过那些数据库，你使用过那些中间件等。 尽量写跟你所应聘岗位相关的且你又熟悉的一些东西，一定不要求多求新。太新了，有可能你的面试官并不知道，那就并没有什么用，也浪费了版面。如果你写了一个你不太熟悉的，面到了有可能会 gg。

4、工作经历

本栏一般有大厂工作经验的同学，能加分不少。

以公司为单位，分别写你在该公司的任职时间段，并且写明你在该公司主要负责什么，有什么成绩。

5、项目经验

这里一定务必真实，不要乱虚构项目，实验项目与真实项目一定要注明，否则可能会成为你的呈堂供证。

一般来说，能面试你的人水平都还不错，一个项目是不是堆热门的技术，一眼都能看出来，所以，你的那点小九九一般都经不起几个为什么要这么做。

项目背景一定要交代清楚。比如你调研过哪些同类项目，我们的项目有什么特点及优势。

运用了那些技术。比如数据库用的什么，中间件用的什么，MVC用的什么等等。

遇到的问题。比如开发过程遇到的问题是怎么解决的，尽量有一定水准的问题。

最终的效果。跟以前相比，现在能承受了多大的流量。

6、个人评价&其它

本栏主要写你对自己是如何评价的，比如，你对技术的热情，你跟团队如何相处。

如果你有自己的博客或者你为某个开源项目贡献过代码都可以写在这里，也许能为你加分不少。

最后，再提醒一下，你简历中的每一句话一定要保证真实！

项目介绍

面试官："聊聊你最复杂的项目"为什么90%的候选人第一句就栽了？

1.抛砖引玉

面试过程中常见的问题"谈谈你做过的最复杂的项目或者说你认为最有价值的项目？"

反面案例：

1. 从微服务架构的拆分一直聊到Docker的容器化部署，各种技术名词甩得飞起。
2. 但是面试官听见的可能是项目听起来这么"廉价"。
3. 容易给人留下：技术面广，但深度不够，理解浮于表面的印象。

正面案例：三句话炸开场面

1. 我做过的最复杂的项目，是一个日活跃用户近百万的社区Feed流系统，核心痛点就是在追求极致读取速度的同时，应对海量写扩散带来的压力。
2. 作为团队的核心开发者，我主要负责处理粉丝关注关系变更时，那种写操作爆炸式的性能瓶颈和存储开销。
3. 最终，我引入了多级缓存机制和延迟扇出的消息队列方案，把Feed流的发布延迟从原来的分钟级优化到秒级，还帮公司省下了50%的缓存机成本。

项目介绍三大忌讳

1. 像产品经理一样罗列功能清单。显得自己是一个纯执行者、要让人知道你推动了什么。
2. 堆砌技术名词，像个"技术贩子"。显得自己是一个API调用工程师。
3. 缺少量化数据，像是技术自嗨。

2.STAR+L框架

项目介绍标准模板：STAR+L框架。

• S (Situation): 项目背景——一句话点燃冲突，别啰嗦
• T (Task): 我的任务——明确你的角色和战场，别抢团队的风头
• A (Action): 我的行动——技术深度秀场，讲清楚"怎么做"的过程
• R (Result): 最终结果——用硬数据+业务影响证明你的价值
• L (Learnings): 我的反思——秀成长，证明你不是一锤子买卖

案例：

S: 当时，我在一家中型互联网公司，负责一个日活刚过百万的社区Feed流系统。痛点是‘头部效应'：少数大V有上千万粉丝。 这导致系统有两个核心矛盾：

1. 一是用户刷新Feed时需要极致响应速度（200ms内）；
2. 二是写操作的扩散成本巨大：大V发帖，后台得为每个粉丝的Timeline插入记录，动辄上千万次写入，数据库和缓存都扛不住。
3. 加之用户投诉延迟高（平均3分钟见更新），产品天天追杀

T：系统瓶颈主要卡在‘写扩散'模型上：大V发帖后，粉丝可能要等几分钟甚至半小时才能看到更新。用户投诉不断，产品经理天天催。 更糟的是，这还引发了存储风暴，Redis集群经常报警。作为团队的核心后端开发者，我的任务就是重构这个写扩散逻辑，目标是：延迟降到秒级（具体<10s），不崩系统。 团队分工，我专注后端优化，产品给的KPI是用户留存涨10%。

A：为了解决这个问题，我分三步走

1. 引入消息队列来‘削峰填谷'和解耦合。 改同步写为异步：发帖API即返成功，Kafka投消息，后台消费者并行写Timeline。为什么用Kafka？对比RabbitMQ，它有exactly-once和分区（我自定义分区公式：hash(user_id) % partitions，避免热点）。结果，API TP99从2s到50ms。但风险：消息积压，我加了监控（Prometheus），阈值超了自动扩容消费者。
2. 重构存储模型，从纯‘写扩散'（推模式）转向‘读写结合'。 纯推太废：写复杂度O(fans)。我设阈值1万粉丝——小用户推，大V拉（刷新时聚合大V池）。数学上，拉模式读复杂度O(1) per user，但峰值时聚合QPS高，我用预聚合（cron每分钟刷热点大V）。对比纯拉（如Instagram部分用），我们混搭省了80%写，但加了读压力，测试了一下，峰值QPS涨20%，这暴露了读性能瓶颈（查询变多、变慢），所以需要优化数据库层来"消化"这个额外负载，最终我优化了索引（MySQL分区表）。
3. 构建多级缓存体系+一致性方案，确保拉模式的读取如丝般顺滑。 我用了三层设计：本地缓存 (Guava Cache) 扛热点（热点TTL 1min），分布式缓存 (Redis，Lua脚本原子更新) 存主体，底层数据库 (MySQL) 做持久化。至于数据一致性，我没用延迟双删那种不靠谱的方案（race condition），而是引入阿里的Canal订阅MySQL的Binlog，实时解析变更事件，异步更新Redis，保证了最终一致性，没出过大乱子。" 代码级例：Canal handler里，我写了try-catch重试，防丢事件。备选是Redisson锁，但太重，我测了开销高10%。

R:方案上线后，效果超出预期：

1. 性能跃升：平均发布延迟从3分钟砍到5秒，用户直呼‘终于实时了'。
2. 成本优化：写操作减少80%，Redis集群从20台缩到10台，省了50%的服务器费用。
3. 业务影响：Feed刷新99%在200ms，用户留存涨15%，DAU多5%。

L: 架构无银弹：我们用混搭模式换稳定，但牺牲了绝对实时性（用户得刷新）。这让我明白，设计时必须紧贴业务场景。下次我会加AI预测热点（像字节的ML预载）。 参考竞品，Twitter用的是Timeline Service混推拉，我们类似但加了本地缓存。

---