你做过的项目里，哪个最有成就感？

本题是回答思路与示例，不对应某个官方规范。示例中的经历和数字只用来演示怎样表达，讲自己的项目时请用真实数据。

简答

比如可以讲：“最有成就感的是我主导的内部组件库，它让团队新页面的开发时间少了一半左右，后来五个项目都在用，我也从只写业务页面变成了会考虑别人怎样用我的代码。”一句话里交代项目、价值和成长。

面试官问这道题，想了解的是你看重什么、在什么情况下最有动力。所以重点放在两件事上：这个项目给用户、业务或团队带来了什么价值，以及你自己在里面有什么成长。

讲的时候按三步来：项目是做什么的、你负责哪部分；带来了什么价值，尽量用数字或具体的反馈；你学会了什么，思路有什么变化。最后可以补一句，这种成就感和你想在新岗位做的事是一致的。

要注意和“最难的问题”区分开。最难的问题讲的是一次具体的排查和解决过程，这道题讲的是一个项目整体的意义。可以选同一个项目，但讲的侧重点要不同，也不要夸大自己的角色。

一个完整的示例

我最有成就感的是在上一家公司主导的内部组件库。当时团队有三条业务线，每条线都自己写一套表格、表单和弹窗，样式不统一，同样的 bug 要在三个地方各修一次。我向领导提出统一做一套组件库，由我负责设计和主要开发，另外两位同事参与一部分组件。

组件库上线大半年后，五个项目都接入了。按我们自己的统计，一个常规的列表加编辑页，开发时间从两三天降到一天左右；设计同事也说，验收时样式问题少了很多。

对我自己来说，最大的变化是思考方式。以前写代码只要自己用着顺手就行，做组件库时得考虑别人会怎样用：接口怎样设计才不容易用错，文档和示例要写到什么程度，改动怎样做才不会让已经接入的项目出问题。我也第一次学着去收集使用方的反馈，排优先级。

我很喜欢这种做出来的东西能让很多人受益的感觉。贵公司的岗位里提到要建设前端基础设施，这也是我想继续做的方向。

这个回答有项目背景、个人角色、可衡量的价值和具体的成长，最后和岗位联系起来。面试官会顺着问组件库的设计细节，比如版本怎样管理、怎样做按需加载，要提前准备好。

和“最难的问题”有什么不同

两道题经常在同一场面试里出现，所以要提前想好怎样区分。讲《面试官问“你项目中遇到的最难的问题是什么”，应该怎样回答？》时，主线是“遇到问题 → 定位 → 方案 → 结果”，展示的是解决问题的能力。这道题的主线是“做了什么 → 有什么价值 → 我怎样成长”，展示的是你的动力来源和视野。

可以用同一个项目，但选不同的角度。比如组件库项目里，“最难的问题”可以讲一次升级导致多个项目样式错乱的排查，“最有成就感”讲的是组件库整体对团队的价值。

怎样准备这道题

MDN 的 Finding a job 建议，面试前准备一组自己的经历故事，用来回答基于经历的问题，随着经验增加，这会越来越容易。这道题正是这类问题，最好事先挑好项目，把价值和成长各准备一两句话。

选项目时不一定要选技术最复杂的。帮客服团队做了一个小工具，让他们每天少花一小时整理数据，只要你能讲出它的价值和你的收获，同样是好答案。关键是成就感要真实，面试官很容易听出是在背稿还是在讲自己真正在乎的事。

哪些说法要避免

“每个项目都很有成就感”，等于没有回答。

只讲项目多厉害、用了多少新技术，却说不出自己在里面做了什么，面试官会怀疑你的参与程度。

把团队成果说成个人成果。被追问分工时说不清，会比选一个小项目更扣分。

常见追问

如果重新做这个项目，你会改什么？

说一个具体的改进，比如“一开始没有写变更日志和升级说明，后来几次升级让接入方很被动；如果重来，我会从第一个版本就按语义化版本发布并写清楚变更”。这能体现你在持续反思。

这个项目有没有让你觉得不满意的地方？

如实说一两点，并讲你后来怎样弥补，比如“文档一开始写得比较简略，接入方经常来问，后来我补了每个组件的示例和常见问题”。不要说“没有不满意的地方”。