实话实说：只会.NET，会让我们一直处于鄙视链、食物链的下游

金三银四，是个躁动的季节。 结合最近的面试，谈一谈一个老牌开发人员的面试感悟。

大家都知道我的主力技术栈是 .NET + Devops + 弱前端 (当前技术认知，不排除以后变化)。

面试了大小厂，有收获也有沮丧， 结合工作和面试谈一谈看法：

1. .NET 技术栈的现状#

目前.NET普遍用在数字化转型的中小企业，或者用于一些OA、CRM等中小流量的站点。

.NET 技术频繁升级，虽然我自己也升级到最新的.NET 5, 但是并不会刻意关注新版本的功能。

从我实际使用看，每次这种升级也没带上肉眼可见的改变；或者说每次升级，并不能从Java、Javascript群体中抢的一块肉食。

这与一些自媒体上吹嘘的能力、抛出的JD并不匹配， 当然我这样说，肯定会引来很多骂战。

• 每次这种挤药膏式的小升级，我内心只会觉得是不是早期.NETcore 1.0设计不达预期，并不如当初横空出世时标榜的这么牛逼；

  乃至每次升级都鼓噪.NET 2.0最佳、3.0最佳、5.0最佳，以后出.NET6,7,8是不是又打脸.NET5是最佳设计。

• .NET 客观上讲处在追赶Java的时代， 这里我用时代这个时间概念； 物竞天择，不进则退，其他语言JAVA，javascript 也在进化，
  主流技术大厂的技术洞察力相比信息化转型的中小企业更加深厚，主流技术大厂的技术雷达里面目前选择性忽略.NET， 他们宁愿用Go，也不会用已经20岁的.NET

🧛‍ 二面鹅厂的对话： ".NET只能windows服务器下”的，当我准备说.NET 5年前已经跨平台, 有runtime时， 他们适时打算了我的话，下一个话题。 另一大厂面试官一开始也有这样的疑惑。

(不管你愿不愿意承认，市场上确实存在语言鄙视链(҂⌣̀_⌣́))

2. .NET的价值#

大前端、微服务、云原生蓬勃发展， 但是大多数时候主流.NET技术还是用来做api 。
从我近2份工作（6年），不管是技术经理还是开发人员自身 ，都将.NET 定位为api;

不是说我们要刻意迎合微服务、云原生这些高精尖概念，
但是客观上讲，微服务、云原生提高了应对复杂业务的天花板，提高了应对高并发、高可用、可伸缩场景的能力， 而这些能力也是主流大厂目前需要的。

🧛‍ 你现在回想一下, .NET结合微服务、云原生用到了哪些知名项目上；就算你有心想用，这些技术理念里面的必要组件在纯.NET技术栈能信手拈来吗？ 敢用吗？

网上有个调侃，. net从不加班，从不996，这侧面反映. net没能用于大场面。（手动狗头，轻喷）

所以， 如果.NET还是被定义为api能力，或者大多数时候CRUD用于中小站点，那我内心觉得.NET程序员确实只能值目前的市场价。

(本文标题所说的食物链，还可以解构为：使用这门语言，得到的报酬让我们能吃的食物链)

以上的1,2点都是基于普遍观感，不排除有少量大佬将.NET技术体系用到高精尖项目，并据此获得产品高价值、个人高回报。

😥 那怎么办？ 我也是吃.NET这碗饭的。 还是那句话，弱化.NET在你核心技术体系中的地位，降低预期 。 （可能有骂战，我并不贬损.NET体系）

一万年太久，只争朝夕。 我建议大家一开始就使用主流成熟技术 + 主流技能树。

3. 掌握通用的技术架构#

微服务的服务独立性客观上为.NET参与高精尖项目提供了可能性， 微服务中各种技术语言可充分参与，取决与你的技术选型、习惯、喜好、

语言在整个体系中是最异变的，不变的是支撑整个业务的架构。
比如说 nginx/负载均衡，又比如说后端三大中间件

• 缓存 redis memorycache
• 消息 rabbitmq kafla
• 搜索 Elasticsearch

不管技术怎么升级， 这些核心的架构点始终存在， 现在有redis memorycache，以后有xxCache也不是没可能，但是这个技术点落地的场景基本不会变动。

🧛‍ 我个人的技术体系是 弱前端+后端(.NET) +sql+ DevOps，我希望具备一个完整的、能落地的web技术栈,当然整个技术栈里面有侧重，这个你从我公众号内容也能感受到。

4. 不要频繁造轮子，也不要图新鲜去使用什么不知名的小技能点#

倒腾主流技能， 对新事务保持关注（不要刻意花时间）

举个栗子：
目前主流的Devops框架 Jenkins、Gitlab-CI等， 你倒腾什么中小轮子codeing.net等，（包括现在耳边狂轰乱炸的Blazor，我目前持保守态度！）
不管是职业生涯、还是大厂面试，谁会用，谁会问。

当然如果你已经倒腾并已经点亮这颗并不一定闪耀的技能点了，那沉淀下来的东西还是你的， 也无妨。

时间很宝贵！

5. 多深究 多提问#

多深究，多倒腾，每一个你叫的出名的技术栈/技能点，都是经过开发者撸掉上万根头发丝弄出来的，后面也经过市场上的千锤百炼。

他们的技术深度 不是我们写一两个Demo就能参透

• 为什么会产生这个技能点？
• 整个数据流是怎样的？
• 为什么这样设计？
• 这个技能点如果用到其他场景（云、集群）我需要注意什么
• 这一段写法看似是骚操作， 开发者为什么推荐这么做？

很多时候，我们一时也难以参透， 没关系，记下来,
随着时间的流逝，认知和视野会解锁这些问题。

最怕的是遇到问题选择性忽略：

😇 “这是骚操作写法，为什么？ 官方这么写，哎呀我也这么写吧，不知道！”

-------------- 下面是技术之外的唠嗑--------------

6. 多关注产品和市场#

工作时以主人翁的心态Cover所有与你有所关联的事情，什么意思？ 参见美帝长臂管辖权。

把成果推到市场验证，你的产品体验做得好、市场反馈爆棚，资本家受益，自然会给你多分一点口粮。

回过头来，如果在可预期的未来，这个产品不会好过，我好建议你适时执行“沉末成本”“时间成本”的方案， 改变不了公司，那就改变自己。

产品有没有潜力，能不能增长？

• 可对比公司年报增长率； 该产品的贡献率；业内对公司产品的关注度； 竞品的能级（上市公司）。
• 从公司产品的活跃度、留存来感受；从你们团队的实力或者态度来感受；公司年会老板在画饼的时候提到你们团队的次数； 把你们的产品手把手推给认识的素人，看看他们的评价。 （非上市公司）

--- 两者可结合---

🧛‍ 我承认产品和团队是有生命周期的，不可能一直优秀，这就有点像NBA鱼腩球队重建，有的甚至是摆烂重建。

落实到个人，每个人背后的环境不一样、每个人所处的阶级不一样、每个人所处的人生阶段也不一样，最后每个人的诉求也会不一样。

7. 做好向上汇报、平级管理、向下共情#

技术人养成了教条式输入输出的思维， Stateless Serverless ，技术人是标准的工具人。

• 向上汇报 不是说要你耍语言艺术，搞花花肠子；
  向上汇报是一种职业素养：在上级提出需求的时候，给出几个可行方案和方案的预期、风险点、人工成本；在项目进行中，主动以百分比形式汇报进度和遇到的新的风险点。

• 平级管理也不是说 茶水间家长里短，闲言碎语；
  而是说 与同事技术沟通，形成合理的技术预期；给产品经理一个让他难以反驳的拒绝理由；给跨部门同事一个承诺必答的Deadline节点。

你据此在上级、平级同事中形成技术影响力，也是极好的。 做到这些，剩下的你我无法决定。

• 向下共情
  每个人的认知都会成长，时间会对齐你们当时的分歧。
  不干预 多引导， 多站在对方角度思考。

8. 多记录，多分享#

大多数人智力和能力的最高峰都是在高三阶段，相信那时大家每个科目都有一个错题本。

好记性不如烂笔头，鲁迅肯定没有说过。

记录是一个脑力活动，能刻意让我们有层次、有角度、有策略的思考问题。

🧛‍ 经常看到 findi pointer 军哥手记 等意见领袖的公众号文章，你会惊叹于他们视野之广阔、思维之严密、角度之新奇，

大佬之所以是大佬，刻意练习，卖油翁说 唯手熟尔。

说到分享，分享是带有少量私心，目的是在圈内扩大影响力。但是大部分时候，分享是一个加深理解、广开言路的过程，近两年我写公众号加深延伸了自己的技术体系，结识了很多有深度的号主。

说点题外话， 遇到好的文章（阅读时对我有价值的），我通常不吝点赞分享 👍❤️‍。
大部分技术人性格上都是白嫖党，不要试图考验人性，白嫖就白嫖吧，落得下来是你本事。

---

我不是什么大佬，以上也算不上什么金玉良言，仅是我多年工作、最近面试的感想， 不接受恶意指责，你杠你对。