十多年前，我曾经去BAT中的一家面试过（到现在也是我唯一一次BAT的面试经验）。当时刚毕业几年，写代码解决一般问题任务已经“得心应手”了，各方面知识也懂一点，会搭MySQL的Master-Slave，会用Memcache，HTTP协议也基本熟悉……
在那个许多公司还在为100万PV就头疼的年代，这样的水准在技术上算比较领先了。所以我以为，这次面试应当是十拿九稳。
结果大大出乎我的意料，可以说是“惨败”。
我熟悉的领域一个也没有谈起，我解决的问题一个也没有问到，却问了一大堆“技术细节”问题。比如一个int变量要占几个字节，字符串的查找-替换怎样最快…… 在学校里，我最熟悉的Java，C和C++的课程只是囫囵吞枣，这类知识早就忘记了，做题比较多的也是离散数学、数值计算等等，工作了之后一直做Java，根本不会深入到这样的细节。所以，面试结果用“惨败”来形容，是一点不夸张的。
当时我觉得很委屈，对已经工作的人，为什么要考这些细节的书本知识？而且是日常开发根本用不到的书本知识？难道不应当重视实际经验吗？
等再工作几年我逐渐发现，这些原本不是“细节的书本知识”。如果你要解决的问题稍微有点挑战性，没有现成工具可以利用，只能靠自己思考和分析，或者借鉴其它现成工具的原理，就离不开这些看不起的“细节知识”。
比如，后来（一直到如今也是）我经常说：“好的程序员不会凡事都靠实地测试，而是会预先计算”，就必须用到这些细节的知识。拿如今最热门的“高并发”应用来说，单个节点每秒处理多少个请求，每个请求包含哪些数据，每部分数据的大小是多少，机器的带宽是多少，网卡的吞吐率可以达到多少……能把所有这些数据综合起来，心里就大概有了把握，而且这种理性结算的结果，远远比“写个程序去压测”要靠谱得多。
所幸我在这次面试失败之后几年就领悟到这个问题，于是又花时间（那时候996还很少见）把数据结构、算法、网络、系统结构等等基础知识全部梳理了一遍。如今回想起来，当时的这轮梳理确实值得，自己后来受益匪浅。
行业内有句话说：搞技术的不玩虚的，就服实打实的解决问题的本事。我认为这句话是成立的。在我走上技术负责人的岗位后，也解决过不少技术上的疑难杂症，尤其是我“本职”领域之外的问题。比如困扰大家很久的接口概率性失败的现象，最后诊断出是证书问题；又比如HTTP能通SSH不能通的问题，最后发现是TCP的TIME_STAMP配置问题；再比如面对不稳定的遗留系统，迅速拿出方案隔离不稳定部分，为技术改造赢得时间……
能解决这些麻烦的问题，自然能赢得各团队伙伴的信任，不过我并非这些领域的专家，只是多亏了之前对基础知识和技术细节的掌握，再加上学习和分析而已。
在很长的时间里，我一度非常相信“技术负责人就是要懂细节”，否则内心也很慌张。对细节的把握，让我感到踏实、放心。同时，我也热衷于在面试中考察候选人对细节的了解，如果不了解细节，这个人就很浮躁。换句话说，优秀的技术人员应当像把篦子，一路梳理过去，各种细节了如指掌，所有的问题原形毕露，这样工作才称职，自己才放心。
然而，随着面临问题的复杂，职位的升高，我发现自己日益焦虑，因为这是“不可能的任务”——技术细节太多了，想要对每个细节都了如指掌只会让人疲惫不堪；技术人员也太多了，想要在每个人那里都保持权威也会让人高度紧张。
到最后我发现，这已经不是一个用不用功、专不专心的问题，因为精力有限，要照顾的方面又太多，所以无论你多么用功，多么专心，都会感到力有不逮、左支右绌的局面。看来，篦子这种模型有点问题——篦子当然好，但通常都不长，一手能够拿住，如果要覆盖很宽的面，就非常吃力。
那么，该怎么办呢？如果自己找不到出路，我尝试去观察其他人是怎么做的。观察一段时间之后，我还真有很大收获。
最大的收获是，我发现没有人可以了解所有的细节。如果光看媒体，似乎很多“大佬”无所不知、无所不晓，但仔细分析就发现，“大佬”往往只有在自己熟悉或者有充分准备的领域可以谈得很深，遇到自己不熟悉的领域，他们要么不发声，要么说错了但会有公关团队去掩盖。
不可否认...
点击查看剩余70%
{{collectdata}}
网友评论0