本文转载自微信公众号「全栈码农画像」，作者小码甲 。转载本文请联系全栈码农画像公众号。
面试了大小厂，有收获也有沮丧， 结合工作和面试谈一谈看法：
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在你核心技术体系中的地位 。
一万年太久，只争朝夕。我建议大家一开始就使用主流成熟技术 + 主流技能树。
3. 掌握通用的技术架构
微服务的服务独立性客观上为.NET参与高精尖项目提供了可能性， 微服务中各种技术语言可充分参与，取决与你的技术选型、习惯、喜好、
语言在整个体系中是最异变的，不变的是支撑整个业务的通用架构。
比如说 nginx/负载均衡，又比如说后端三大中间件
- 缓存 redis memorycache
- 消息 rabbitmq kafka
- 搜索 Elasticsearch
不管技术怎么升级， 这些核心的架构点始终存在， 现在有redis memorycache，以后有xxCache也不是没可能，但是这个技术点落地的场景基本不会变动。
提醒：.NET 程序员不要认为使用 sdk Client 对接了Elasticsearch rabbitmq， 就掌握了这些中间件。
??? 我个人的技术体系是 弱前端+后端(.NET) +sql+ DevOps，我希望具备一个完整的、能落地的web技术栈，当然整个技术栈里面有侧重，这个你从我公众号内容也能感受到。
4. 不要频繁造轮子，也不要图新鲜去使用什么不知名的小技能点
举个栗子：目前主流的Devops框架 Jenkins、Gitlab-CI等， 你倒腾什么中小轮子codeing等，
不管是职业生涯、还是大厂面试，谁会用，谁会问。
当然如果你已经倒腾并已经点亮这颗并不一定闪耀的技能点了，那沉淀下来的东西还是你的， 也无妨。
时间很宝贵!
5. 多深究 多提问
多深究，多倒腾，每一个你叫的出名的技术栈/技能点，都是经过开发者撸掉上万根头发丝弄出来的，后面也经过市场上的千锤百炼。
他们的技术深度 不是我们写一两个Demo就能参透
- 为什么会产生这个技能点?
- 整个数据流是怎样的?
- 为什么这样设计?
- 这个技能点如果用到其他场景(云、集群)我需要注意什么
- 这一段写法看似是骚操作， 开发者为什么推荐这么做?
很多时候，我们一时也难以参透， 没关系，记下来, 随着时间的流逝，认知和视野会解锁这些问题。
最怕的是遇到问题选择性忽略：
“这是骚操作写法，为什么?官方这么写，哎呀我也这么写吧，不知道!”
6. 多关注产品和市场
工作时以主人翁的心态Cover所有与你有关的事情，什么意思?参见美帝"长臂管辖权" 。
把成果推到市场验证，你的产品体验做得好、市场反馈爆棚，资本家受益，自然会给你多分一点口粮。
回过头来，如果在可预期的未来，这个产品不会好过，我建议你适时执行“沉末成本”“时间成本”的方案， 改变不了公司，那就改变自己。
产品有没有潜力，能不能增长?
- 可对比公司年报增长率;该产品的贡献率;业内对公司产品的关注度;竞品的能级。(上市公司)
- 从公司产品的活跃度、留存来感受;从你们团队的实力或者态度来感受;公司年会老板在画饼的时候提到你们团队的次数;把你们的产品手把手推给认识的素人，看看他们的评价。 (非上市公司)
--- 两者可结合---
我承认产品和团队是有生命周期的，不可能一直优秀，这就有点像NBA鱼腩球队重建，有的甚至是摆烂重建。
落实到个人，每个人背后的环境不一样、每个人所处的阶级不一样、每个人所处的人生阶段也不一样，最后每个人的诉求也会不一样。
7. 做好向上汇报、平级管理、向下共情
技术人养成了教条式输入输出的思维， Stateless Serverless ，技术人是标准的工具人。
- 向上汇报 不是说要你耍语言艺术，搞花花肠子;
- 向上汇报是一种职业素养：在上级提出需求的时候，给出几个可行方案和方案的预期、风险点、人工成本;在项目进行中，主动以百分比形式汇报进度和遇到的新的风险点。
平级管理 也不是说 茶水间家长里短，闲言碎语;
而是说 与同事技术沟通，形成合理的技术预期;给产品经理一个让他难以反驳的拒绝理由;给跨部门同事一个承诺必答的Deadline节点。
你据此在上级、平级同事中形成技术影响力，也是极好的。做到这些，剩下的你我无法决定。
- 向下共情
每个人的认知都会成长，时间会对齐你们当时的分歧。不干预 多引导， 多站在对方角度思考。
8. 多记录，多分享
大多数人智力和能力的最高峰都是在高三阶段，相信那时大家每个科目都有一个错题本。
好记性不如烂笔头，鲁迅肯定没有说过。
记录是一个脑力活动，能刻意让我们有层次、有角度、有策略的思考问题。
