11.28

最近在准备求职面试时，我重新审视了自己的简历。上面写着：“掌握 Java 编程，熟悉 Redis、RabbitMQ、Elasticsearch，能使用 Spring Boot 开发微服务……”乍看之下，技术栈齐全，符合大多数 Java 岗位要求。但当我模拟面试官视角提问时，才发现——“熟悉”不等于“会用”，“了解”更不等于“理解”。

简历不是罗列，而是承诺
很多同学（包括我）容易陷入一个误区：把学过、用过、接触过的技术都写进简历，用“熟悉”“掌握”“了解”模糊边界。然而，面试官看到“熟悉 Redis”，第一反应往往是：“那说说缓存穿透怎么解决？分布式锁有什么坑？”

如果你只能背出标准答案，却说不出项目中的真实场景，很容易被判定为“纸上谈兵”。

我在一次模拟面试中就被问到：“你说用 RabbitMQ 处理异步任务，那消息丢了怎么办？”

我一开始只答了“开启持久化”，但面试官追问：“生产者确认开了吗？消费者 ACK 是自动还是手动？”——这让我意识到，工具的使用深度，决定了你能否扛住高并发系统的稳定性挑战。

技术要落地，才有说服力
后来我调整策略：每项技术背后，必须绑定一个具体场景。

不再说“熟悉 Redis”，而是：“在商品详情页项目中，用 Redis 缓存热点数据，QPS 从 800 提升至 5000+，并通过逻辑过期 + 互斥锁解决缓存击穿。”
不再说“了解 Elasticsearch”，而是：“通过 Canal 监听 MySQL binlog，将商品数据实时同步到 ES，支持多条件筛选，搜索响应时间 < 200ms。”
这种表达方式，不仅展示了技术能力，更体现了问题意识与结果导向——而这正是企业最看重的。

设计模式不是炫技，而是解耦利器
简历中我提到“能灵活使用设计模式”。起初我以为举个单例、工厂就够了。但面试官更关心：你为什么用它？解决了什么痛点？

在订单审核系统中，我引入责任链模式，将风控、库存、支付校验拆成独立处理器。新增规则时，只需实现接口并注册到链上，主流程零修改。这不仅提升了可维护性，也让团队协作更高效。

设计模式的价值，不在模式本身，而在它如何让代码更清晰、更易扩展。

工具链是效率，更是规范
很多人忽略工具的重要性，觉得“会写代码就行”。但 Git 分支管理混乱会导致线上事故，Swagger 文档缺失会拖慢联调进度。

我们团队强制要求：

功能开发走 feature 分支，MR 合并需 Code Review；
接口变更必须更新 Swagger 注解；
生产日志按 traceId 串联，便于链路追踪。
这些看似“琐碎”的规范，恰恰是专业开发者与业余爱好者的分水岭。
写在最后：真诚比完美更重要
回顾整个准备过程，我最大的感悟是：面试不是考试，而是一场技术对话。

与其堆砌 buzzword，不如坦诚地说：“这块我用过，但原理还在深入，目前的理解是……”

企业招人，不是找全知全能的神，而是找能解决问题、持续学习、靠谱合作的伙伴。

我的简历仍在迭代，技术也在精进。但我知道，只要每行代码都有思考，每次优化都有依据，每一次“熟悉”都经得起追问——Offer 自然会来。

共勉。