实习/试用期转正，如何写好答辩文档？

实习或者试用期转正的时候，大部分公司转可能都需要答辩，小部分只需要交表就能进入流程（这个我真的羡慕了）。

本人去年转正的时候，答辩文档有好几千字，外加几十张图，提前一个多月就开始准备文档，然后每周一到周四改文档，周五下午和mt还有ld去会议室模拟答辩，他们会review我的文档，然后提出修改意见，下一周我就开始按照意见修改，如此循环，前前后后review了5轮。

最后答辩的效果确实很好，我感觉+2和hrg都还比较满意（希望不是我的普信，最后确实转正成功了😇😇），我很感谢我的师兄和主管，不愧是经验丰富的老员工，我的答辩文档从最开始的一坨答辩到最后井井有条，离不开他们的鼎力帮助。

这个过程中我也有一些收获，在此分享给大家，真的全是干货，希望能帮到大家的实习转正或者是试用期转正的答辩~

有意识的提前准备

这个提前准备不是说每做一个需求你就开记录哪些亮点可以作为答辩文档的汇报资料，这是最基础的。并且公司里每个需求都有技术文档保存，就算你最后一个月开始回忆，其实也没什么差别。我觉得更重要的是，在你做这个需求的时候，你就要有意识的想着，这个需求我应该怎么做才能有亮点能够让我汇报，这样才不至于最后总结资料发现全都是简单的增删改查🤐。很多牛友可能不太清楚具体该怎么操作，我可以举一些例子。

最简单的，有意识的使用一些可以预防大流量高并发的代码，这样文档里就可以写自己提前做了性能预案，能够承接大流量大数据量；再比如，设计代码的时候思考如何增加可扩展性，例如多用接口，多用设计模式，这样文档就能写自己做了可扩展设计，便于其他业务平滑接入，提高接口的横向扩展能力。再比如，可以用读取配置中心的配置来代替硬编码，这同样也是提高代码复用和扩展性；再比如将根据参数差异化处理的代码收束到一个代码文件，降低代码耦合度；再比如组件化开发，将其他业务可能用到的代码单独封装，这就是组件拆分与复用......

我上面举的都是一些切实可行的路径，只要你有知识积累，然后有意识的增加亮点，答辩文档上绝不可能无东西可写。并且上面的东西，不只是实习可以用，正式入职同样也应该是必备技能之一。

文档结构

这个部分比较看公司或者你的ld的喜好，不过大的框架是一定的，可以按照下面的框架进行一定的增改。

第一部分介绍自己的背景，包括mt/ld、所在团队、学校、实习经历，如果是研究生，可以加上自己的科研成果。

第二部分则应该是总起，讲述自己在这一段时间内，负责过哪些业务模块，分模块介绍自己的大致工作。

第三部分就是分模块仔细汇报工作了，模块下以需求为单位进行汇报，这也是整个文档最能体现你含金量的部分。

最后一部分就是未来展望，至少应该从业务、技术和团队三个方面去讲述，其他的自由新增。

上面的部分应当是必备的，其他的可以自由增加，比如可以加上自己在这段时间学到的业务知识和技术知识，也可以加上自己对团队和部门协作的认识等。

工作汇报

一个需求如何汇报，才能让评审人觉得有价值有含金量呢？

首先是整体的结构遵循STAR法则，这样来组织一个需求亮点，能让评审人比较清楚的知道需求的背景和你的解决思路以及最后的成果。

其次是图文并茂，这个很重要，比较复杂的需求一定要上图，无论是需求文档里的图、还是你自己的技术文档里的图表，只要你觉得有助于理解这个需求或是你的解决思路，你都可以把它放到答辩文档上来。并且一定要学会画图的技能，比如在一个简单的需求中你写出了横向扩展性强、兼容其他业务的代码，完全可以画一张不同业务接入这个接口的链路图，对比普通版本，直观的体现你的工作亮点；再比如系统新增了小程序端，虽然你只在代码里加了几行判断，你依旧可以配一张不同平台来源的请求进入系统后的不同处理流程的流程图，马上就会高大上很多，这就是合理配图的魅力！

其三是发掘亮点，这一部分需要配合第一部分“有意识的提前准备”的内容进行，在第一部分里我已经讲过了怎么让一个普通的需求拥有可以讲述的亮点，没有亮点的需求也可以按照上面的思路发掘亮点，只要你做了一些数量的需求，并且运用了上面提到的tips，肯定是能撑起一篇答辩文档的。

很多时候，简单的东西不一定没有亮点。比如在一个需求中，你发现了有可以复用的模块可以很好的解决眼前的问题，你就接入了这个模块，问题就解决了需求也做完了。你觉得这很简单，没什么可以说的。但是真的没什么可以说吗？你要知道，其实不是这个可复用的模块解决了你的问题，而是你需要一个工具来解决问题，在你的研究和分析过程中，发现了这个可以复用的模块，这个模块刚好满足你的所有需求，并且能带来一些优势，然后你使用了它，并解决了问题。从这个角度看，你的工作似乎并不是毫无亮点。你的思考方式和解决问题的思路才是最大的亮点。