前几天看朝珺的小报童分享了一个面试的感受：

在和一个候选人交流时，问他，你觉得在这个岗位下，「普通」和「优秀」的区别是什么

他说，这个岗位工作基本都是5年以上，有很多实战经验，首先都不差。

在这个基础上，普通和优秀的很显著的一个区别是：

普通人遇到一个难题，用自己的经验来解决问题，遇到了难题，卡住了，郁闷，难过，然后更努力地用自己的经验来解决问题。来来回回都是一套逻辑。

优秀的人遇到难题，也会用自己的经验来解决问题，没搞定，卡住了，他会重新思考问题出在哪里，换个方法继续试。

到这里就结束了。

顺着他们的面试，我接着对自己提问，那如何确保换个方法就能解决问题，或者说更逼近解决方案呢？

或者换个问题，如何解决不知道如何解决的问题呢？

补上我的思考：

1、以终为始，重新思考定义和转化问题

很多重复的信息，下面这篇文章里面都讲了。

关于深度思考的思考（二）

很多时候，我们以为要解决的问题是A，实际的问题却是B或者C。

编一个段子来解释，用户说，我想要一匹更快的马去北京。

实际背后的需求是想要更快地从上海去北京。

再问，去北京的目的是什么，是送信。

那更深需求是把信息最快速地从上海传到北京。

再问，送信是为了解决什么问题，是说在上海闯祸了，要去北京找人摆平。

所以真正的问题是想找人摆平祸事。

2、找到真正的问题后，能否将问题拆分成N个可验证的独立子问题，如果可以，先验证解决子问题。

这里有点像微积分的思维，将问题进行无限分解，如果子问题都能全部解决，那完整的问题也就不攻自破了。

3、如果不能拆分出子问题，那能不能设计出快速验证的方法？

面对不知道怎么解决的问题的时候，我过去总有一种倾向，倾向设计出完整的解决方案，然后投入大量的资源和精力去验证。

希冀自己是天选之子，一次就能成功，成为所有人都倾慕崇拜的大佬。

实际上，尊重常识，看看物理学和化学的实验就知道了。

没有什么理论是做一次实验就能彻底证明的，都是在逐渐逼近真相的过程中。

所以如何设计验证方法，结合light的一篇小报童：

• 验证方法成本是否足够低？

• 是否能确保足够多的测试？

• 有基于目标的反馈机制吗？

• 每次的反馈速度足够快吗？反馈结论足够清晰了吗？

• 思维被禁锢了吗?

写到这里，在微信的工作其实就非常不提倡用第三种方法来解决问题，强调用1和2来逼近问题的真相。

而似乎字节的工作则相反，更擅长用3这种工程化的方法来不断做低成本的快速测试，最终逼近问题的真相。

孰优孰劣，这里不做评价。 以上，最近的一些想法。