Technical strength of the myth
As the saying goes, "the text first, weapons-free second," technology is a "text" of ability, very often it is difficult to visually see the strength of a technician, but whether the company's recruitment interview, or within the company surface assessment for promotion, we need to determine a relatively short period of rapid technical staff strength. Because of technical strength evaluation itself is no absolute objective criteria, very often hear similar Tucao:
"XX technical strength within our group as good as me, even he was promoted through, I was washed off, the judges really is ~! @ # ¥" ......
"The interviewer asked what the hell is the problem, I know basically did not ask, I feel he did not study my technique strength" ......
"I heard algorithms and data structures can best embody the strength of the programmer, I was going to sink my teeth into," Introduction to Algorithms "" (But Kenwan forgot again) ......
……
There are many similar problems and Tucao, behind can be summed up in one question: When we talk about technical strength, in the end in what we talk about?
Some people believe that: technical strength refers to the algorithms and data structures very powerful ......
Some people think: studied the Linux kernel source code and understand "simple terms MFC" is the technical Niubi people ......
Some people think: write C ++ is the real master of technology, because C ++ object initialization has N kinds of writing ......
Some people think: Technical experts must be familiar with the business ......
Some people think: the contribution of the technology is the open source project code cattle ......
Some people think: only is the technology architect Daniel ......
...... do not list them, I believe there are a thousand thousand people in the eyes of Hamlet, one thousand programmers heart 1000 Technical cattle!
The nature of the technical strength of
得益于工作岗位的关系，我在考核技术人员的实力时积累了较丰富的经验（包括踩坑的经验）。首先是招聘，前后面试了几百个人吧，技术范围包括服务器、android、iOS、前端，既包括初出茅庐的应届生，也包括腾讯的 T4 大牛；其次是晋升评委，作为职业等级晋升的评委，面评过几十个晋升的技术同学，各种案例都见过，也与其他评委一起互相交流，有时候甚至是针对某个同学通过还是不通过产生争执。通过这种不断的实践、思考、踩坑、交流的过程，逐步形成了一套完整的方法论，接下来就谈谈我的这套方法论，分享一下我是如何判断技术人员的技术实力的。
简单来说，判断技术实力的一个总的原则就是：技术实力就是指解决问题的能力！
我们将这个原则细化一下，可以得到几个细则：
1）不存在放之四海皆准的技术
简单来说，问题是和领域相关的，技术是用来解决问题的，因此技术也是领域相关的，不存在放之四海皆准的技术。
有网友说：高斯林来做 iOS 开发，分分钟秒杀现在所有的 iOS 开发人员，因为目前 iOS 经验最丰富的开发人员，经验也不过 10 年。我认为这是不可能的，iOS 开发领域面临的问题，和开发 Java 编程语言面临的问题差异很大，当然，如果高斯林真的做上几年 iOS 开发，确实可能超过很多 iOS 开发人员，但一开始就秒杀哪些做了 7~8 年的 iOS 程序员，这个是不可能的。
2）技术要能解决具体问题才有价值
技术只有能够解决某个领域的问题才有价值，否则光知道某个技术没什么用；掌握了某个技术但在当前的领域用不上，这个技术对当前领域来说也没有价值。
当然，确实存在某些技术可能在当前看起来对当前领域没有用，但后面可能会用到，因此技术人员需要自己储备一些当前暂时没有用的技术以拓宽技术视野，例如当前大火的人工智能和区块链技术，但要注意“可能”这个词，这需要技术人员自己进行判断和平衡，不能拿技术储备作为托词一股脑的什么都储备，例如数据库开发工程师至少在这几年是不需要储备 VR 知识的。
3）问题的复杂度决定技术实力的高度
问题的复杂度不同，复杂度越高，解决起来越困难，相应的技术实力要求也越高。
我们拿这个原则去分析一下前面提到的各种技术实力的理解：
“技术实力就是指算法和数据结构很厉害”
很多面试官喜欢让面试者现场手写冒泡排序、快速排序、链表之类的代码，以此来判断面试者的技术实力，但我们用这个原则去分析一下就可以发现，这样并不能考核技术实力，假如招聘了一个会手写快速排序的面试者，招进来后你会让他用自己写的快速排序解决什么问题？貌似绝大部分场景下都不可能让一个新来的员工自己写个快速排序来解决某个问题吧？
当然，肯定还是有人会说“我考核的是面试者的技术基础和思维能力”，这个说法没错，但如果是这个目的，现场手写快速排序这种面试方法就是错误的，如果是考察技术基础，考核的范围应该是算法的基本逻辑，优缺点、适用场景，因为这些技术点在后续具体应用中选择合适的算法来解决问题的时候很有用；如果是考察思维能力，考核的方式应该是给一个具体的算法应用题，来看看面试者的分析和思考过程，例如我在知乎上给了一道我们业务上曾经用到的“如何快速计算你好友的好友和你的共同好友数”，没想到引起了评论里面的大讨论，有兴趣的朋友也可以尝试一下。
“研究过 Linux 内核源码和看懂《深入浅出 MFC》的才是技术牛逼的人”
国内技术人员（不知道国外是否类似）对于底层技术有一种偏见，认为只有懂底层才是真正的技术高手，否则都只是简单的调用 API 完成功能。我当年也不例外，我曾经说过“程序员的三个大坑：Linux 内核源码、编译原理（龙书）、深入浅出 MFC”，我每个都跳过，而且还花费了大量时间却收效甚微。其实用原则去分析一下就可以发现这个说法也站不住脚，如果我们从事 Linux 内核开发，编程语言开发，MFC 框架开发，这些技术确实能解决问题；但如果做得不是这些领域的开发，这些技术并不能帮我们解决什么问题，我还没见过哪个 Java 编程的问题需要我去用编译原理的技术去解决，也没见过哪个数据库的问题需要我去研究 Linux 内核源码才能解决，当然并不是说这些问题一定不存在，Java 语言本身肯定也有 bug，但这些问题是需要 Java 官方去解决，我们在应用中无需亲自去解决，否则的话，效率会非常低，个人爱好无可厚非，但团队必须考虑效率。
“会写 C++ 的才是真正的技术高手，因为 C++ 的对象初始化有 N 种写法”
这是程序员群体里面永恒的一个话题，哪个语言才是最好的最牛逼的，其中两个著名的梗：PHP 是世界上最好的语言，C++ 是世界上最牛逼的语言。C++ 确实语法复杂，功能强大，真正能完全掌握 C++ 的程序员应该屈指可数，但这是否意味着掌握 C++ 就牛逼了呢？并不尽然，我们拿原则来分析一下，如果用 C++ 做游戏引擎，或者高性能中间件，C++ 确实能解决问题，但如果我们做的是 android 手机资讯 app，C++ 能解决什么问题呢？自己写个加密库可能比系统带的库漏洞还多，自己用 C++ 写个 SQLite 好像没什么意义。
“架构师才是技术大牛”
架构师几乎是每个程序员的技术梦想，能够成为架构师（真正的架构师，不是 PPT 架构师），技术实力肯定很强，这点是没有争议的，但问题是当不上架构师就不是技术大牛么？我们用原则来分析一下就会发现并不是这样的，架构师并不是全能的，他解决的主要问题是系统的结构设计，还有一些问题是架构师不能解决的，例如 MySQL 5.6 版本通过优化一个 false sharing 问题，性能提升 50%，
（http://www.cis.upenn.edu/~delozier/docs/tmi_micro_2017.pdf）
这种问题点的发现和处理并不比架构设计简单，能发现和解决这个问题的技术人员实力非常高。
以上分析了几个典型的误区，其它的观点，这里只贴一下简单的答案，大家有兴趣也可以套用这个原则去分析一下具体的原因，基本上八九不离十：
“技术高手必须对业务很熟悉” —— 正确
“贡献了开源项目代码的才是技术牛人”—— 错误
技术实力详解
理解评估技术实力的基本原则后，我们知道了需要解决的问题复杂度越高，技术实力就越高。在这个基础上，我把技术实力分为两大类 6 分类：
-
硬实力：真正解决问题的能力，别人可以看出来的能力，技术实力按照“点、线、面、体”的 4 个分类逐层上升；
-
软实力：比硬实力更厉害但也更虚的能力，简单来说，要想解决问题首先得发现问题，但很多时候问题并不是一目了然的，需要有一定的技术洞察力。软实力主要包括 2 个核心能力：发现问题、技术创新。
硬实力
我把技术硬实力分为四个等级：点、线、面、体，技术等级依次提升，解决的问题复杂度也越来越高，下面详细解释一下。
技术点
“点”就是某个具体的技术，用来解决某个具体的问题，例如使用 JDBC 从数据库读取数据，目的是解决数据掉电丢失的问题；使用 Java 多线程，目的是为了解决大量用户并发访问的吞吐量和时延问题。掌握了技术点，就可以开始基本的业务功能开发了。
技术线
“线”就是一系列相关的技术点组成，每个技术点都是为了解决某个问题。例如：
-
为了完成一个用户请求，开发框架首先要有路由 router 功能，路由到具体 Controller 后，Controller 进行业务逻辑处理，处理过程中可能会使用 JDBC 来读取数据，访问 Redis 读取缓存等，这一连串的技术每个都解决了一个问题点，串起来就完成了一个业务功能的处理过程。
-
为了定位一个线上 Java 服务器响应慢的问题，需要用到 tcpdump 抓包，使用 Java 工具查看 jvm 的状态，使用 mysql 命令行或者工具查看数据库状态，使用 explain 分析可疑 SQL 语句。
掌握了技术线，就可以完成某个业务功能的全流程设计和开发了。
技术面
“面”就是某一类相关技术线的综合。例如：
-
Java 开发是一个技术面，包括多线程、JDBC、文件读写、JVM 调优、JVM 工具等多个技术线；
-
高性能开发是一个技术面，包括：数据库分库分表、缓存、多线程、HTTP 优化等；
-
数据库维护是一个技术面，包括：数据库调优、数据库问题定位、高性能数据库表设计等；
掌握技术面，已经是某个领域的专家了，简单来说就是这个领域的问题找你都可以搞定。
技术体
“体”就是多个技术面的综合。
最常见的“体”就是架构设计，对于一个大型业务或者系统的架构师来说，需要掌握多个技术面，然后进行设计和取舍。例如，一个后台架构师需要掌握 Java 的技术面、数据库的技术面、网络的技术面等，以及业务领域知识。
架构设计是横向技术面的综合，我称之为广度技术体；还有一种纵向技术面的综合，我称之为深度技术体。例如 Java 的开发工程师，当达到技术面的水平时掌握了“多线程、JDBC、文件读写、JVM 调优、JVM 工具等”，如果需要进一步在 Java 这个领域提升技术，就需要向下了解操作系统、硬件（CPU、内存、磁盘等），从而更好的解决某些复杂的问题，例如 Disruptor 高性能并发框架的设计。掌握了技术体，就可以进行架构设计，或者成为某个领域的资深专家了，解决领域级的复杂问题。
软实力
发现问题
有的问题很明显，例如线上出故障，系统性能不达标，系统性能需要达到 5W QPS；但有的问题并不那么明显，并不能一眼看出是问题在哪里，是技术问题还是管理问题。
例如我们曾遇到团队间协作开发效率很低，每次开发一个业务功能，都需要几个系统的研发人员来讨论接口协议、接口数据格式、接口安全加密、业务逻辑等，大家都不厌其烦，但好像又都必不可少，团队间为了提高效率，项目经理制定了规范、流程、模板等，但作用最终都不大。那后来是怎么解决的呢？通过引入服务中心来完成系统间同步接口调用，通过引入消息队列来完成系统间异步消息通知，系统间协作效率大大提高，以前要开会讨论几个小时的事情，现在只要明确接口传输的数据内容即可，甚至都不用开会，两个研发一讨论就差不多了。
除此以外，问题的根源往往掩盖在很多问题表象之下，如果不解决根源问题，解决一个表象问题，获得一时安宁，一段时间后又发生另外的问题，长此以往反反复复。
例如我们曾有个系统，今天交换机故障导致业务问题，明天系统 bug 导致业务问题，后天机柜断电导致业务问题，还被黑客攻击过，这些问题看起来都很独立，问题的发生也感觉都是偶然的，按照出一个问题解决一个问题的方式也没什么问题，但全年来看，业务就是出了很多问题，怎么解决？我们经过分析，发现根本原因是业务需要异地多活，而架构是双机房单中心的，我们需要做到的不是避免每个问题的发生（事实上也不可能避免），而是应该做到问题发生后能够快速处理，于是通过将架构重构为异地多活，重构完成后还是有各种偶发问题发生，但对业务的影响就很小了。
发现问题的能力主要来源于经验，包括成功的经验、踩坑的经验、参考别人的经验，因此如果要培养自己这方面的能力，多思考、多总结、多学习、多参加行业交流。
技术创新
达到这个级别基本都是业界大神一般的级别，说实话我也没什么经验，只能仰慕这些大神。
例如：
-
当年贝索斯要求亚马逊公司内的系统都服务化，后来是哪位大神想到可以把这个能力开放出来转换为“云计算”？
-
阿里云王坚博士当年在众人都不看好的情况下为何坚持云计算是未来？
-
Google 在解决大数据问题时，如何能够提炼出三篇论文，开启了一个大数据时代？
技术实力案例点评
一个面试者面试 Java 技术专家岗位，其中有一项项目经验很牛逼：XX 架构重构，性能提升 10 倍。于是，我针对这个项目经验进行了深入的考察，结果……
下面是我们大概的对话过程：
我：请简单介绍一下这个项目重构。
面：我们某个业务和比赛有关，每次关键比赛前业务访问量是平时的 10 倍以上，原来的系统量一大就卡死了，用户体验很不好，需要重构。
我：具体怎么做的呢？
面：我通过引入 mc 缓存，将原来直接访问数据库的操作改为先访问缓存，性能比原来提升了 10 倍。我：为何你想到了引入 mc？
面：（卡了一下，有点惊讶我的问题）……我上网查了一下资料，很多都说 mc 能够大幅提升性能，并且使用后确实效果很好。
[点评 1] 这是典型的“代码靠抄，方案靠搜，效果靠试”，面试者看到了一个问题，但没有分析和思考，然后上网搜方案，看到了好像很多人都说引入 mc 都能解决问题，于是尝试引入了 mc，最终确实好像解决了，这让面试者自我感觉良好。
为何我在面试的时候问“为何引入”，这是不是一种“面试造航母，入职拧螺丝”的装逼面试呢？其实不然，我们的业务中遇到性能瓶颈的问题是非常常见的，而简单的“性能瓶颈”只是一个表象，我们看看可能的原因有哪些：
-
数据库慢查询，例如不合理的查询、没有索引、表数量太大等；
-
并发设计不合理，例如多线程锁设计不合理，采用了不合理的 Reactor 模型等；
-
代码逻辑不合理，例如本来可以异步处理的也采用了同步处理，某个循环里面重复访问数据库，某个接口打印了大量日志等；
-
外部系统性能低，例如依赖的某个系统性能低，太多无效的外部接口请求等；
-
数据访问不合理，例如没有用缓存，没有分页等；
-
非核心业务和核心业务互相影响；
以上仅仅是举例，还有更多可能的原因，如果一个技术专家不具备“面”的技术，只知道 mc 可以提升性能这个“点”的技术，是远远不够的，一次运气好能解决问题，但不可能次次都运气好。
当然，如果面试的是“Java 高级开发工程师”，面试重点和面试问题又不一样了。
我：mc 能大幅提升性能的原理是什么？
面：缓存访问快，数据库访问慢。
我：那 mc 性能多高，数据库性能多高？
面：……（想了 10 秒）抱歉，没有研究过。
[点评 2] 这是典型的知其然不知其所以然，开源方案拿来就用，基本的测试和原理研究都没做过。大部分人对于很多概念的理解都是“性能高”，“可靠性好”，“听说很厉害”，但在具体设计的时候，这个理解是远远不够的，一定要量化，例如：同样是负载均衡，Nginx 的性能量级是万级，LVS 是 10 万级，F5 这类设备是百万级（具体数值和硬件以及数据包大小相关，这里只给量级）。
Why study the principles of it? To mc, for example, the consistency of hash and expansion related to memory allocation and buffer capacity, and if these are not clear, the actual number mc node should be deployed, how much memory should be allocated to each node, these had not even OK.
Me: It does not matter, that we change the problem, the number of machines used in the reconstruction of your system is how much? Before reconstruction compared to reduce how much?
Face: the number of machines 100 is not reduced as compared to prior reconstruction.
Me: Oh, 100 machines, QPS each just over 300, I think your business is not very complicated, why so low?
Surface: ...... (jam 10 seconds) this ...... 300 QPS seems not low, right?
Me: Have you ever analyzed the performance of the whole process of consuming every request of each stage? Where is the bottleneck?
Face :( stuck five seconds) have not analyzed it?
Me: Why do you have identified the introduction mc effect?
Surface: ...... (jam 10 seconds) I think everyone says that the introduction of the cache can significantly improve performance, but the final effect is really good.
[Review] It is known technical points, do not know the technical and technological line, it stands to reason that the system for analysis of performance problems, at least the line-level technology, time-consuming and need to analyze each stage of the cause of each request; may be technical level, such as design and analysis of the database, such as server load balancing, can also be a technical level body, such as architecture is reasonable, whether you can split a subsystem, such as the introduction of message queues.
Me: Okay, another question, if let you optimize the system again, how do you think we can?
Surface: ...... (think 20 seconds) I think the current system performance is sufficient, should not need to optimize.
[Comment] study is the ability to identify problems, but he can not find the problem, in fact, as already mentioned, the 100 machines is the problem, QPS is too low is also a problem, but because he has no experience, can not see these problems.
Unfortunately, the interviewer did not pass the final interview.
Written in the last
Place to judge technical personnel strength, there is no completely objective and quantifiable criteria, how many are subjective judgment judge's, which is the most prone to controversy, this article is one of my own thinking and summary, one of the words, initiate , welcome to discuss the exchange.
Article reprinted from geeks time (jikeshijian)