[[386819]]

本文轉載自微信公眾號「全棧碼農畫像」，作者小碼甲 。轉載本文請聯系全棧碼農畫像公眾號。

面試了大小廠，有收獲也有沮喪， 結合工作和面試談一談看法：

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 ，技術人是標準的工具人。

1. 向上匯報 不是說要你耍語言藝術，搞花花腸子;
2. 向上匯報是一種職業素養：在上級提出需求的時候，給出幾個可行方案和方案的預期、風險點、人工成本;在項目進行中，主動以百分比形式匯報進度和遇到的新的風險點。

平級管理 也不是說 茶水間家長里短，閑言碎語;

而是說 與同事技術溝通，形成合理的技術預期;給產品經理一個讓他難以反駁的拒絕理由;給跨部門同事一個承諾必答的Deadline節點。

你據此在上級、平級同事中形成技術影響力，也是極好的。做到這些，剩下的你我無法決定。

• 向下共情

每個人的認知都會成長，時間會對齊你們當時的分歧。不干預 多引導， 多站在對方角度思考。

8. 多記錄，多分享

大多數人智力和能力的最高峰都是在高三階段，相信那時大家每個科目都有一個錯題本。

好記性不如爛筆頭，魯迅肯定沒有說過。

記錄是一個腦力活動，能刻意讓我們有層次、有角度、有策略的思考問題。