引言
现在处于春招时期，各种面筋层出不穷，但是基本上都是硬实力的经验，事实上各家面试上也基本考察的人才的编码能力。但软实力也是一个很重要的考察环节，在备选人才硬实力相差不远情况下，领导优先考虑录用的必然是软实力强的人才。那么如何回答这些问题（因为这些题目，面筋基本不会给出答案）？我彻夜难眠思考后，产出了这篇文章，希望大家可以一起探讨下。
什么是软实力
一开始我看到这个词，有种大致理解，但解释起来又很模糊的感觉（不知道大家是不是也是这样）。那么我们来看看百科的解释吧。内容很长，我做下简单的总结：
一切无法证明出来的能力，都可以作为你的软实力。
软实力可能无法立刻给你带来收益，但是软实力能帮你的职业生涯走的更远。
我这边举一些软件工程师常有的软实力🌰
- 沟通能力：如何表达更容易让他人理解你的意思，接受你的见解
- 责任心：做完一个项目不能丢一边不管，想想怎么可以做的更好
- 执行力：老是空谈想法，不落于实践，不去执行，永远不会有结果
- 个人影响力：个人的工作态度，学习方法，人生观，对他人有所帮助，产生了作用
- 时间管理能力等等...
看完这些例子，是不是觉得身边有几个人的能力模型挺匹配？是不是其中有个人就是你的领导？（真不是拍马屁啊）
假如你是小组Leader
从上述软实力的一些例子上看，可以发现 Leader 是一个很好标杆，那么我们切换下视角，站在领导的角度去思考下面试上一些软实力问题。
这个转换角度的意义是，不能仅从自身的发展上去看待问题，还得需要从对团队、部门的影响去回答这些问题，扩展了我们回答问题的思路，即大局观。
Q1：你如何看待未来前端的发展？
A1：校招时，我记得一个挺深的问题，当时自己答的是未来前端可能不会人工编程，转为AI编程。
那么转换下角度，从领导角度去思考，可以转换为前端未来什么发展会影响到我带领的团队情况呢？
- 首要的必然是技术栈的发展，我校招的回答其实也是属于这个范围。这决定了我带领的团队如何去完成需求项目。
- 前端影响的范围，当年从HTML网页，前端发展到了 Android、IOS、Node、小程序、快应用。未来前端必然会有更多领域的发展，那么我们就需要结合实际的业务需求，评估是否必须要求团队所有成员、亦或是部分成员必须具备这些能力？亦或者只是作为技术分享，兴趣分享形式提高大家的认知广度即可？
- 发展速率：需要把握前端的发展情况，评估好所做项目渐进增强和优雅降级的程度。首要确保不会因前端迭代（包括技术栈、客户端等），而导致出现用户服务不可用这种情况。以及评估老项目重构的必要性、预期收益、时间成本等。
Q2：你认为前端开发工程师的核心价值体现在哪里？
A2：以前是这么答的：前端一直走在的是技术最前沿的地方，咱们前端工程师更多的作用体现在探索新技术的应用上。
那么站在领导的角度思考下，其实可以转变为前端工程师在整个部门担任的一个角色形象是什么，应该有什么作用的一个问题？
- 需求敏感度：前端工程师是与用户“距离最近”的工作者之一（与用户近的还有产品、设计同学）咱们是一个需求的一个量尺，把握住需求、交互是否合情合理，技术成本与带来的收益的评估。
- 用户信息提供者：同上，前端是最贴近用户的，那么也应该最懂用户。如何去懂用户，这就需要收集各种用户的操作习惯数据，比如这个一个按钮点击频率，一个页面PV等等。前端工程师需要提供足够强大的埋点收集功能，便于PM统计、思考数据反馈出的问题，促进做好项目的迭代。
转换了一下视角去看这些开阔性问题，会发现思考的点其实挺多，也挺有意思，妈妈再也不怕我张口无言啦！
如果真当上了Leader
正文开始（手动滑稽）！随着时间带来的经验积累，我相信大部分人都会走上Leader这条路，那么我们真当上Leader怎么做，才能带好团队？
类似把🐘塞进冰箱的三步法，我自己觉得当上Leader后也会走三步法
- 确定我要带一只怎么样的团队（明确目标）
- 带这样的团队，现在有什么问题（先解决当前的问题，再思考未来的）
- 怎么去解决这些问题
我们一步步来看这些问题
我要带一只怎么样的团队
第一点是：这只团队是重业务型还是重技术型？（这里只是指偏重，不是只做技术或业务）
第二点是：这是一只有什么能力的团队？
第三点是：这只对团队的目标是什么？
从这三点去思考🤔，我要带一只能完成跨端能力的技术型团队，短期目标是能让整个公司都认可我们团队的输出，最终目标是打造一只像奇舞团那样知名的前端团队。
为什么是偏技术型：
- 做业务，很容易产生拧螺丝的流水工人感觉，减少团队工作人员的成就感
- 技术型产出，能更容易帮助我的队员进行述职的输出
- 发现业务团队里更多的老油条。。。
- 业务团队，容易产生人力不足，但是又不肯招人的情况。原因或许是感觉前端只做交互逻辑，不需要太多人。毕竟我不是老板，我不知道老板想法。（问了两三个部门都这样，可能是我们公司管理方式？）
为什么是这个目标？做人嘛，要有梦想，没有梦想跟咸鱼有什么区别。
技术型团队会有什么问题
- 技术型团队容易自嗨，即产出的东西实际效果并不如预期效果设想的那么好
- 技术型团队，很难保证某些项目按期完成，可能一个坑就花了3-4天去解决。
- 一个公司，最重要看的还是这个团队带来的经济收益，没有足够的业务输出，难以保证技术型团队被转换为业务型团队
如何解决
- 需求调研时间延长，调研方式必须得更深入。怎么深入呢，比如做的是一个跨部门的构建工具，那么开发我们必须得去各个部门“采访”他们各个项目的构建方式，必然时还得加入他们的开发当中，找到业务方真正的痛点问题。
- 同上，延长技术调研时间，确保踩坑几率，留合理的时间buffer。
- 这样并不能保证上述两个问题一定能解决，因此一旦出现上述两个问题，必须得复盘项目，总结得失，输出记录，确定下一步的发展方向，以及不会再踩相同的坑。
- 根据业务繁琐程度，指定业务、技术项目人员参与比重，默认3：7，确保有业务输出。人员流动去做业务与技术项目，确保人员对各个项目都有一定的理解与认知。但是每个人都得担任1-2个项目或者更多的项目owner，促使各同学思考项目未来的优化、发展方向。
结束语
虽然是看各种面筋后，自己尝试的一个解题思路，但可能更多的是工作两年来，自己对职业生涯、对带领团队的一丝思考、认知。
最后，个人见识有限，可能会有些不切实际的想法，大家有想法可以评论交流，谢谢~
