面试造核弹的童话
小王回想起了自己的面试之旅：为了拿到 offer，他必须在电话里完成一个非常复杂的代码挑战。他表现得很好，走到了下一轮面试。经过一轮又一轮艰难无比的面试，他就像孙悟空护卫着唐僧一样，披荆斩棘，文体两开花，最终成功拿到了 offer。
但在加入公司后，他发现他所做的工作与预期相去甚远。他的主要任务就是为运行在虚拟机上的遗留系统构建基本的 CRUD。这就好比取经时他是无所不能、战无不胜的孙悟空，取完经后他就成了一个桌案上的供奉，每天只能吃点香烛贡品。
其实在招聘中，这类情况一直在发生。企业让工程师通过严格的筛选程序，问他们一些有挑战性的问题，但在把他们招进公司之后，只是让他们做一些枯燥乏味的事情，比如负责由五六个服务组成的系统，或者让页面看起来更漂亮些。当然，并不是说这些任务就不需要技能，只是这些任务所需要的技能与大多数面试涉及的内容根本不一样。
入职拧螺丝的管道工作业
软件是因为能够提供业务价值，所以才被创建出来。
虽然阅读有关软件开发的书籍并且在软件技术上追求卓越对小王们来说颇具吸引力，但归根结底，如果不能形成业务并从中赚到钱（或省钱），小王们的工作就毫无意义。
因此，软件行业的现状自有它的道理。就像管道工一样，他们获得报酬，是因为他们了解自己所使用的工具，并知道如何使用它们让设备运转起来，而不是让他们重新发明技术，或者花 80 个小时去优化只有 5% 的用户会用到的东西。
中小型企业很少会去处理与规模扩展或优化相关的问题——一部分原因是硬件变得越来越便宜，一部分原因是基础的开源软件已经做得很好了。
所以，企业一方面想网罗最优秀的人才，以便在重大的时间节点、关键时刻能够物尽其用（但通常没有这种情况），另一方面只派给这些优秀人才以增删查改的日常工作，最终每个优秀的小王都成了 Crud Boy。
某一天，小王被开发经理叫去了办公室，他敏锐地意识到这应该是他职业生涯中的转折点，公司一定出了什么问题，需要像 Jeff Dean 那样的技术人才来拯救公司，而他，就是那样的人！
“小王吧？公司最近业绩不好，亏损严重，要裁员了，实在是不好意思哈，你去找下 HR。”
公司的确出了一些问题，但却不是 Jeff Dean 能解决的，也不是他能解决的。他只是在推开门后回头骂了一句：“你才小王八，你全家小王八。”
技术实力的迷思
很多人觉得，自己肯定不会成为小王。因为自己是独一无二的，特别的那种工程师，而所有现状的不如人意，一定都是时候未到、伯乐未到，毕竟自己的技术实力摆在那儿。
可技术实力究竟是什么呢？
“我们组内的 XX 技术实力不如我，竟然他晋升通过了，我却被刷掉了，评委真的是~！@#￥”……
“面试官问的都是什么鬼问题，我知道的基本没问，我感觉他根本不会考察我的技术实力”……
“听说算法和数据结构最能体现程序员的实力，我要好好啃啃《算法导论》”（然而啃完又忘记了）……
当我们聊技术实力的时候，我们到底在聊什么？
有的人认为：技术实力就是指算法和数据结构很厉害……
有的人认为：研究过 Linux 内核源码和看懂《深入浅出 MFC》的才是技术牛逼的人……
有的人认为：会写 C++ 的才是真正的技术高手，因为 C++ 的对象初始化有 N 种写法……
有的人认为：技术高手必须对业务很熟悉……
有的人认为：贡献了开源项目代码的才是技术牛人……
有的人认为：只有架构师才是技术大牛……
其实简单来说，判断技术实力的一个总的原则就是：技术实力就是指解决问题的能力！
1）不存在放之四海皆准的技术
简单来说，问题是和领域相关的，技术是用来解决问题的，因此技术也是领域相关的，不存在放之四海皆准的技术。
有网友说：高斯林来做 iOS 开发，分分钟秒杀现在所有的 iOS 开发人员，因为目前 iOS 经验最丰富的开发人员，经验也不过 10 年。我认为这是不可能的，iOS 开发领域面临的问题，和开发 Java 编程语言面临的问题差异很大，当然，如果高斯林真的做上几年 iOS 开发，确实可能超过很多 iOS 开发人员，但一开始就秒杀哪些做了 7~8 年的 iOS 程序员，这个是不可能的。
2）技术要能解决具体问题才有价值
技术只有能够解决某个领域的问题才有价值，否则光知道某个技术没什么用；掌握了某个技术但在当前的领域用不上，这个技术对当前领域来说也没有价值。
当然，确实存在某些技术可能在当前看起来对当前领域没有用，但后面可能会用到，因此技术人员需要自己储备一些当前暂时没有用的技术以拓宽技术视野，例如当前大火的人工智能和区块链技术，但要注意“可能”这个词，这需要技术人员自己进行判断和平衡，不能拿技术储备作为托词一股脑的什么都储备，例如数据库开发工程师至少在这几年是不需要储备 VR 知识的。
3）问题的复杂度决定技术实力的高度
问题的复杂度不同，复杂度越高，解决起来越困难，相应的技术实力要求也越高。
打个比方，很多面试官喜欢让面试者现场手写冒泡排序、快速排序、链表之类的代码，以此来判断面试者的技术实力，但我们用这个原则去分析一下就可以发现，这样并不能考核技术实力，假如招聘了一个会手写快速排序的面试者，招进来后你会让他用自己写的快速排序解决什么问题？貌似绝大部分场景下都不可能让一个新来的员工自己写个快速排序来解决某个问题吧？
我们该如何自处？
我们生活在一个大多数“软件工程”基本上就是管道作业的世界里。我们该怎么办？这对于我们的职业生涯来说意味着什么？现金流会一直持续下去吗？
首先，我们应该认识到并接受这样的一个事实，即我们可以用更少的资源构建更多的东西。也就是说，我们工作中不是那么有价值的部分可能进行自动化，或者构建工具，让业务人员为我们做这些工作。例如，每当我的团队中有人想要修改自动电子邮件副本时，我就要去修改代码。而现在，他们只需要在可视化编辑器中编辑模板，我甚至都不知道它们被改过了。
其次，我们在设计系统时需要考虑到系统的复杂性。如果有现成的解决方案，那么就用它，不要再从头开始构建。我们要学会组装零件，这样就可以比那些每次在启动项目时都要自定义构建框架的软件工匠更高效、更快、更好。
第三，我们应该设定切合实际的期望。大部分编码工作都只要求 CS 学位，而这些工作所涉及的内容可能只比知道如何导入库和了解 HTTP 原理多那么一点点。不过确实有些工作需要进行微优化，但这类工作可能很少，而且离我们很远。你的软件可能没有你想象的那么特别。
最后，不要陷入了舒适区而不能自拔。这并不是软件工程师的普遍看法，但我相信在这个领域里，有很多人拿到的报酬已经远远超出了他们所从事工作的难度。有时候是因为他们是这个领域唯一知道怎么做这些事情的人，有时候是因为他们所在的公司无法从人才市场上招到更好的人，有时候是因为其他工程师故意过度设计，这样初级开发人员就需要花费很长时间才能理解它。无论如何，如果我们想要保持高薪和不被踢出局，就不能停止学习。加强知识的广度和深度，并学会如何将炒作从真正的突破性技术中过滤掉。