应聘者如何回答开放式提问
面试官学习开放式提问，是为了评估应聘者组织语言的功底。而作为应聘者，有没有什么应对的办法吗？Star框架用过的都说好，来瞧瞧。
什么是Star方法？
Star是Situation、Task、 Action、 Result的缩写，它可以帮助应聘者设计回答的架构。
- 面临的场景：你遇到了什么困难。有那些出乎意料的事情发生了。或者你对什么不满。总之这种情况不能一直保持下去。
- 承担的任务：你的职责是什么。你按月拿工资是为了完成什么任务。在其位思其政，你不能眼睁睁的看着上述情况继续下去。
- 采取的行动：在如此场景下你采取了什么行动，来改善情况，推动事情想好的方面的发展。
- 获得的结果：你最终改善情况了吗，完成了任务了吗，学到什么了吗。
为什么好用？
Star方法好用，一是它引人入胜，听起来像讲故事一样。这是因为它开头引入冲突，设置了悬念。然后介绍故事的主角，他是谁，他是干什么的，他为什么被拖进的冲突之中。进而表明他和困难做了哪些斗争，最后取得了什么结果。按照这个千百年来人们讲故事的套路，听的人肯定爱听并且能听懂。
第二个原因，就是Star方法是一种结构清晰的框架。它有利于人们不断的重复的训练而习得其精髓，进而把各色各样的故事给装进去。
什么时候别生搬硬套？
在学习这个框架之前，有必要提一下它的使用范围，别生搬硬套，闹了笑话。
如果面试官问的封闭的，或者是有标准答案的开放性问题，你最好开门见山，展现你的技能。比如说问你操作系统是如何控制CPU的。建议你不要讲一个你和CPU的故事，丁是丁卯是卯，你说明白就行了。可如果你真有一段和CPU美妙的故事，那么尽情的去征服面试官吧！
如何练习Star方法？
练习Star方法做好的方式就是日积月累。当你在平日的工作中，有什么心得，有什么经验教训，或者主动采取了什么行动的时候，可以试着用Star的方法把他们总结出来。这样你的素材会越来越多。接下来给大家分享几个我遇到的例子。
告诉我你曾经犯过的一个错误
听这个问题，一定要听到弦外之音，面试官真正想要的不是你犯的错误，而是你犯过错误之后学到了什么，做了什么来避免今后再犯同样的错误
场景：为了实现一个新功能，我需要修改数据库的数据模型，添加一个新的列。这个列很简单，我之前也做过类似的操作。为了节省时间，我没有在开发环境里测试，就直接把它部署到生产环境了。结果，我在修改的时候，不小心设置错了列的模型，导致生产环境中断了几个小时。
责任：作为Tech Lead，我犯了一个特别低级的错误，为了防止我的组员今后犯下同样的错误。
行动：我起草了一个部署数据库模型修改的清单，清单里确保所有的修改，不管有多简单，都必须事先在开发环境里经过测试，确保得到的结果是预期结果。
结果：这个清单帮助我们的组员切切实实的走过必要的每一步，避免了很多人为的因为疏忽大意而导致的错误。并且这个清单，在每次有新的经验或教训的时候，都会被更新。这样一来，我们不断积累数据库更新的经验，为我们自动化数据模型更新打下了基础。
请描述你曾做过的一次主动提议
这个问题算是问的比较直接，就是你的主观能动性，是不是曾经自驱改善过什么
场景：经过入职培训，我开始接受团队里的任务，可我发现很多东西在入职培训里我都没有接触，搞的我不得不四处打探那些其实很基本的问题。
责任：作为已经经历了入职培训的员工，一方面我不希望以后把自己的时间花在回答这些本来可以自学的问题上，也为了让今后的入职员工能更快的上手
行动：我找了我的经理，给他建议我们应该在入职培训中加上一个应用程序的实战演练。通过这个演练，新员工可以学会如何写一个API，如何写数据库的请求，如何部署一个服务。获得经理的同意后，我就着手设计了这个实战演练，并且把它加到了入职员工培训的手册里。
结果：如此一来，新入职的员工，通过完成这个实战演练，在结束培训后，做到了真正的可以直接为团队做贡献。并且这个实战演练，只写一次，却可以培训所有新入职的员工，事半功倍！
结语
希望你体会到了Star方法的好处。可就像学习其他任何技能一样，明白道理只是开始，愿你日常的生活中，能付诸行动，多多试验这个方法，等到真正用上的时候，厚积薄发。