晋升失败后，我开始认真看面试题了
上周五晚上十点半，我盯着 Mac 上那封 HR 发来的晋升结果邮件，手指在键盘上悬了三分钟没动。窗外北京的初夏已经有点闷热，空调外机嗡嗡作响，仿佛在嘲笑我：“两年了，还是 Senior Engineer？”
是的，我在这家公司干快两年了，MacBook Pro 的 Touch Bar 都快磨平了（虽然它本来也没什么用）。平时写代码、调性能、和产品经理 battle 需求，日子过得还算充实。但这次晋升，我真的以为稳了——毕竟去年双11大促期间，我硬是把首页首屏加载时间从 3.2s 压到了 0.9s，还顺手重构了三个祖传模块。
结果呢？“技术深度尚可，业务影响力不足。”——HR 的话术向来滴水不漏，但翻译成人话就是：“你只会埋头写代码，不会搞政治。”
说实话，刚看到结果那会儿，我差点把咖啡杯砸了。不是因为不甘心，而是突然意识到：我好像被困在了一个舒适区里。
每天早上到公司，打开 iTerm2 + VS Code，连上跳板机，拉代码、跑测试、改 Bug。Windows 虚拟机只在需要测兼容性的时候才打开，像极了那个“只在团建时才出现的同事”。我对性能优化确实有点执念——比如看到一个 O(n²) 的循环就浑身难受，非得改成 Map 或者用 Web Worker 异步处理不可。但除了这些“工具人”技能，我似乎没留下什么能让老板记住的“高光时刻”。
于是周末两天，我没打游戏，也没刷剧，而是打开了尘封已久的 LeetCode 和牛客网。对，你没看错，一个工作快三年的老程序员，开始重新刷面试题挑战了。不是因为我马上要跳槽（虽然确实在考虑），而是想看看：外面的世界，到底需要什么样的我？
工具链升级：从“能用就行”到“极致可控”
刷题的过程中，我发现自己的开发工具链其实挺落后的。以前总觉得“只要代码能跑，工具无所谓”，但现在回头看，简直是浪费生命。
举个例子：我之前调试性能问题全靠 console.time() + Chrome DevTools 的 Performance 面板，虽然能定位大致瓶颈，但缺乏量化对比。直到我在一道关于“前端监控指标采集”的面试题里看到有人用 Web Vitals + RRWeb 做用户行为回放，才意识到：工具不是辅助，而是能力的放大器。
于是我花了一周时间，把自己的本地开发环境彻底翻新：
# 新增的几个必备工具
brew install wrk # HTTP 压测神器
npm install -g clinic # Node.js 性能分析
pip install locust # 分布式压测框架
还给项目加了个简单的性能基线脚本：
// scripts/perf-baseline.mjs
import { performance } from 'perf_hooks';
const start = performance.now();
await import('../src/main.js');
const end = performance.now();
console.log(`✅ Main bundle load: ${(end - start).toFixed(2)}ms`);
if (end - start > 500) {
console.error('🚨 超过性能阈值！');
process.exit(1);
}
现在每次提交代码，CI 会自动跑这个脚本。虽然被同事吐槽“卷王行为”，但至少下次晋升答辩时，我能拿出可量化的数据，而不是嘴炮“我觉得我优化了很多”。
开发心得：从“解决问题”到“定义问题”
真正让我心态转变的，是一次线上事故复盘。
事情是这样的：上个月某个周四下午，运维突然在群里@所有人：“首页白屏率飙升到 15%！” 我赶紧查日志，发现是某个第三方 SDK 在 iOS 16 上触发了 CSP 策略，导致主 JS 加载失败。
按照以往的习惯，我会立刻 hotfix：加个 try-catch，降级方案，然后 PR 合并。但这次，我停了一下，问自己：为什么我们总是被动响应？能不能提前发现问题？
于是我和 SRE 同学合作，在 CI 流程里加了一步“CSP 兼容性扫描”：
| 扫描项 | 工具 | 触发条件 |
|---|---|---|
| CSP 违规检测 | csp-evaluator | 每次构建 |
| 第三方脚本风险 | ThirdPartyWeb | 每周一次 |
| 首屏资源阻塞 | Lighthouse CI | 每次 PR |
虽然这个方案上线后被产品经理吐槽“又拖慢了发布速度”，但两周后，我们真的提前拦截了一个高危的第三方脚本注入问题。那一刻我突然明白：高级工程师和普通工程师的区别，不在于修 Bug 的速度，而在于能不能让 Bug 根本不发生。
面试题挑战：照妖镜 or 指南针？
回到刷题这件事。很多人觉得面试题都是“八股文”，工作中根本用不到。但我的体验恰恰相反——很多题目其实在逼你跳出日常工作的惯性思维。
比如这道题：“如何设计一个前端性能监控系统？”
乍一看，不就是埋点+上报嘛？但我试着拆解后发现，里面涉及：
- 用户隐私合规（GDPR/CCPA）
- 数据采样策略（避免海量上报）
- 异常指标识别（比如 FID 突增）
- 可视化与告警联动
这不就是我们团队正在做的项目吗？只是以前我只负责其中“异常指标识别”这一小块。现在从全局视角看，才发现自己之前有多局限。
我还特意整理了一个“面试题反哺工作”的清单：
- [x] 实现 LRU 缓存 → 优化了 API 响应缓存策略
- [x] 设计短链系统 → 重构了内部跳转中间件
- [ ] 实现虚拟滚动 → 计划用于商品列表页（已列入 Q3 OKR）
你看，面试题不是考你背了多少，而是看你能不能把知识点转化成生产力。而且神奇的是，自从开始这么干，我跟 leader 汇报工作时，他眼睛明显亮了——“你最近思路很系统啊！”
跳槽？还是留下？
说回最初的问题：要不要跳槽？
其实晋升失败后，我投了几份简历，也面了两家。有一家开的薪资确实诱人（比现在高 40%），但聊到最后，我发现他们所谓的“性能优化团队”，其实就是天天调 JVM 参数、写 Shell 脚本。而我现在虽然 title 没升，但至少能接触到全链路的性能治理，从 CDN 到 Service Worker 再到后端缓存策略。
更重要的是，我们组的氛围其实不错。虽然 PM 总喜欢在周五下班前说“有个小需求”，测试同学偶尔会把 staging 环境搞崩，但大家愿意一起扛事。上次大促，运维兄弟甚至给我点了奶茶，就因为我帮他定位了一个诡异的 TLS 握手超时问题。
所以目前我的决定是：再给自己半年时间。
- 把性能监控体系做成团队标准
- 主导一次跨端（Web + 小程序）性能规范制定
- 争取在 Q4 的 Tech Talk 上分享我们的实践
如果到时候还是原地踏步，那再走也不迟。毕竟，跳槽不是逃跑，而是带着筹码谈判。
最后一点真心话
写这篇文章的时候，我又打开了那封晋升邮件。但这次心情平静多了。失败不可怕，可怕的是把失败归因于“领导眼瞎”或者“公司不公平”。真正能掌控的，只有自己每天写的代码、学的新工具、思考的深度。
如果你也在经历类似的迷茫，不妨试试：
- 用面试题当镜子，照出自己的知识盲区
- 把工具当杠杆，小投入撬动大产出
- 从“执行者”转向“定义者”，哪怕只是一个小流程
对了，最近我在 GitHub 上建了个仓库，叫 perf-playground（名字随便起的），专门记录各种性能优化实验。欢迎来踩，star 不重要，能帮你少踩一个坑就行。
毕竟，程序员的成长，从来不是一纸晋升通知决定的。
是我们每一次 debug 到凌晨的坚持，
每一次对“还能更好”的执念，
和每一次跌倒后，默默打开终端，敲下 git checkout -b new-hope 的勇气。
P.S. 刚才 PM 又在群里@我：“这个需求很简单，明天上线就行。”
我深吸一口气，回了一句：“可以，但得先过性能基线检查。”
——看，改变，就这么开始了。
评论 0