金三銀四，是個躁動的季節。 結合最近的面試，談一談一個老牌開發人員的面試感悟。
大家都知道我的主力技術棧是 .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 軍哥手記 等意見領袖的公眾號文章，你會驚歎於他們視野之廣闊、思維之嚴密、角度之新奇，
大佬之所以是大佬，刻意練習，賣油翁說 唯手熟爾。
說到分享，分享是帶有少量私心，目的是在圈內擴大影響力。但是大部分時候，分享是一個加深理解、廣開言路的過程，近兩年我寫公眾號加深延伸了自己的技術體系，結識了很多有深度的號主。
說點題外話， 遇到好的文章（閱讀時對我有價值的），我通常不吝點贊分享 ?❤️。
大部分技術人性格上都是白嫖黨，不要試圖考驗人性，白嫖就白嫖吧，落得下來是你本事。
我不是什麼大佬，以上也算不上什麼金玉良言，僅是我多年工作、最近面試的感想， 不接受惡意指責，你槓你對。