我是搬砖哥我来回答。
高并发的核心原理，是网络io的事件处理机制，就细节来说，一些重要环节，比如协议的断包组包处理，还是比较复杂的，但就大部分的面试和日常工作来说，做到切实理解reactor机制的核心，就差不多了。关于高并发，可以多看下陈硕的那本书。
关键问题在于如果编程能力很稀松，那么问题很大，简单说交给一个任务，或者解决一个问题，动手能力弱的话，可能会久搞不定，还容易出错。对于开发岗位来说，现在公司不论大小，日常工作不会有特大难度或规模的开发，换句话说谁的基本功更过硬，谁的任务往往完成的又快又好。
动手能力弱有个特别简单直接的改进方法，就是刷leetcode之类，把代码先写起来。不论什么语言，先多写，写的多了自然不会稀松。
然后从简单面向对象到最基础的两三个设计模式，串行到并行，结合自己的编程语言，把语言的特性逐渐吃透，过程也是和刷题一样，写代码不断加深印象。包括学一门新的编程语言也是如此。
对大多数人来说，达到编程高手都不容易，但达到合格员工完全可以的，付出够的努力即可，好脑子不如烂笔头。
满嘴高并发的前提是真的要接触过高并发系统，或者目前正在负责的就是高并发系统。
如果压根就没有接触过高并发系统，或者连百万级用户的系统都没负责过，就不要谈高并发。因为，99%的程序员都接触不到高并发系统。
高并发这个词语对于我，或者说对于我的项目组一点不陌生，因为我们做的是真正的高并发系统，当 然不是那么的“高”，算是一般高并发吧！集群的QPS在15万左右。
高并发系统面临的另外一个问题就是“高”的倾斜性。 根据“二八”原则，80%的请求都发生在20%的时间内 。也就是说，系统只有在20%的时间面临高并发请求，其余时间并非高并发请求。而这种情况下，我们就要做好系统的弹性扩容伸缩。我们可以根据前置负载均衡器的QPS（SLB）、CPU等指标弹性的扩容或者收缩机器。这样，当请求量大的时候，我们就自动扩容更多的机器来处理请求，当请求少的时候，我们就收缩机器，降低成本。
总之，高并发系统所涉及到技术是非常复杂的。 如果想侃侃而谈高并发概念，必须要亲身实战过高并发业务 。通过高并发业务的实操，我们能更深的理解高并发的精髓。至于，编码...我觉得是最底层的工作，只要思路清楚，写代码就是个体力活。
面试造航母，工作拧螺丝
给我第一感觉是这人可能培训班出来的，因为培训班天天拿这些来忽悠人，90%以上的的公司都没什么高并发，说这些无非显得自己很牛逼，我对这种人都笑笑而已，同行之间都知根知底，忽悠外行吧！
高并发怎么做？把别人写好的框架，多配置几个线程，内部代码基本还是单线程处理逻辑，最多做个互斥锁，遇到高并发就选择非并发的服务器或者组件来避开，然后数据分发给多线程。
现在有多少人自己写并发的？很少了
不会高并发。
自己写了个框架，2000一年的入门服务器。可能也就只能顶几百并发吧。然后拿去做了个项目，后来法律出来了，停了不做了。
不过如果从技术角度看，要15万的并发，快速的做法就是上硬件负载均衡。然后堆服务器，数据直接进内存数据库，后台慢慢进关系数据库。
毕竟我这边就一个人，短时间要上大并发，还是用设备顶省事。
背的面试题呗。
现在招聘，尤其是互联网公司招聘，一看学历是否符合，二看面试题背的是不是6。
至于写普通代码的能力，who cares ，反正进去是上螺丝。
张嘴就来高并发，一开始是由培训班带来的风气，他们这样做主要是为了吸引生源，后来慢慢的就转变成面试内容，90%的应用开发都没有高并发
我很少会说高并发，但是我会经常说并发编程，两个概念。高并发涉及到的知识点太多了，不光是并发编程这一块。而且一般公司也用不到高并发。不过并发编程就不一样了，并发编程还是很多项目会用到的。所以，切合实际，可以从并发编程入手。
都是为了找工作，没啥好说啊！只能说成年人的世界没有容易二字。