.NET架構師招聘不如JAVA那麼順利，可以搜尋到的.NET架構師可以說是鳳毛菱角。當然好的架構師都是需要長期觀察和挖角才能得手，如何去招聘到合適的.NET架構師可能是擺在所有求賢者面前的難題。這裡的難分兩方面，一個是數量少，二個是考核點難。那麼到底.NET架構師需要具備哪些必備的技能和素質呢？這裡結合這次公司的招聘遇到的困難和個人對架構師的理解，做以下的分享。

一、技能方面

　　在寫招聘技能要求的時候，腦子裡會閃現一系列清單，比如

• 不低於5年的基於.NET平臺架構設計經驗【必須】

• 融會貫通常用的設計樣式【必須】

• 扎實的資料結構和演演算法、作業系統、網路等基礎知識【必須】

• 熟悉分散式架構設計和實戰經驗，有大型分散式系統架構的實際經驗，比如分散式事務、分散式儲存、效能調優、高併發、高可用的設計經驗；【必須】

• 熟悉流程引擎，規則引擎，訊息引擎；有Redis或Kafka或RabbitMQ等中介軟體使用或開發經驗。【必須】

• 對新技術有一定的敏銳度，有廣博的知識面，雖然不一定很深入，但是能很好的做技術判斷和選型。【必須】

• 熟悉基於.NET Core的微服務架構和相關技術棧；熟悉Docker容器化技術，對K8S有一定的熟悉度；有DevOps的開發經驗【加分】

• 擁有自己的開源的框架，並且Star數量不低於某一個閾值【加分】

• 擁有自己的部落格，具備長期寫博的習慣【加分】

• 研究並精通不少於5個以上的開源框架【加分】

• 有物聯網架構經驗優先考慮【加分】

• 高效強大、持續輸出的學習能力，特別是對新技術有比較敏銳的意識【非必須】

• 有大資料業務處理的實踐經驗優先考慮。【非必須】

• 社群活躍度高，有個人技術部落格或個人開源框架【非必須】

　　由於公司要招牛人，我想怎麼的也要技術在我之上，於是就有了上面的內容，不知道這個清單看起來有沒有恐怖，至少我寫完自己嚇一跳。寫招聘需求的目的是要招到合適的人才，但是這個合適的度在哪兒？是不是為了招聘而招聘？至少個人覺得【必須】的選項對架構師的要求不算是高了。我有個困惑在為數不多的.NET架構師群體裡，又是在小城市廈門，如何能淘到這個寶？就算存在，賢人也都是每個公司的寶貝，拿著不低的待遇和公司的榮譽，想去跳槽基本上是不大可能了，就算是跳了是否意願繼續做架構開發也是未知數。

　　所以非常的困惑和迷茫，想在.NET架構師池裡挖到寶難度可想而知，除了更高的職位或待遇，對於中小公司挖寶的機會真的微乎其微。所以招聘的標準如果再往下調整調整，比如不苛求是否有自己的開源框架，也不必苛求是否有寫部落格的習慣，或者直接從高階開發招聘起，然後進行培養。從隨手羅列的條件看，人才的缺乏源於對人才的苛刻要求，掌握這些技能的人除了要聰明還要能堅持，面對各種撲面而來的誘惑和浮躁的社會，能堅持下來的幾乎又陣亡了不少。

二、非技能方面

　　當你對面試者的架構技術贊嘆不已的時候，你也許會繼續想去瞭解對方的非技術能力，具體要瞭解哪些內容呢？我這邊結合自己在招聘過程中的經驗，做如下幾個維度的分享。非技術方面主要表現在角色認知，溝通能力，技術規劃，技術管理，任務管理五個方面來考察。

　　這五個方面如果單獨寫可以形成一個專欄，這裡只是為了招聘本身設定問題而做簡單的分析。

2.1角色認知：

　　為什麼架構師要有角色認知的概念。我覺得有個重要的原因是很多架構師從一線開發起來，往往喜歡過程導向，技術能力沒有任何問題，但是忽視了自己除了是要攻剋難題，還要服務其他的開發人員。至於如何巧妙得去提升團隊的戰鬥力往往並沒有投入思考。

角色認知應該是劉建國老師講的，是空氣，無處不在。因為架構師的成果最終還是要透過團隊最後的結果來檢驗。所以無時無刻，無處不在的角色認知將最終決定一個專案的質量高低。至少架構師是透過服務他人來滿足自己的成就感，所以我把這個角色認知放在招聘考核的首位。

2.2溝通能力：

　　溝通可以看做承載事情的大地，厚德載物。但我更細化把溝通看做潤滑劑，從團隊建設的齒輪模型來看，團隊之間的協作不應該只是看得見的命令式，顯得生硬，畢竟人不是程式碼和機器。更多的溝通應該回歸文化和人性上，以人為本，遵循科學民主的方式來審視。

溝通大概分向上、向下、平級三個維度，如下圖所示。架構師更多的是向上和向下兩個方面居多，而最難的是向上溝通。

 

　　溝通也是技術人的短板，技術是死的，人是活的，很多技術人剛開始都會本能的排斥溝通，覺得和領導溝通太累了，一則領導喜歡神龍見首不見尾，不怎麼懂細節，但是特別關註你的設計流程；二則明明很簡單的內容，還要向領導彙報設計和實現思路，內心會本能的鄙視領導技術能力；三是彙報過程中的各自檔案編寫和PPT，會讓技術人覺得沒有技術水平。

　　以上是向上溝通的麻煩事，架構師內建管理因子這是這個崗位本身的重要性決定的。所以溝通看似務虛，其實非常關鍵，我把它作為考核的第二個位置。

2.3技術規劃：

　　這裡的規劃主要指技術方面的規劃和選型、研究。技術規劃應該從哪幾個維度來考核呢？這裡借用前人的馬車模型進行分析，如下圖所示

 　　馬車模型至少包含以下四個要素：第一是要到達的架構標的是什麼？第二是到達目的要選擇什麼路徑？第三是馬群這個團隊要如何排兵佈陣，以少勝多？第四是每匹馬的職能要如何設定？

能對這四個要素很好的給出合理的方案，對症下藥，開出針對性的技術藥方，我覺得這種架構師應該值得去珍惜。

2.4技術管理：

　　我在想架構師其實並不是真正意義上的管理人員，但是他確有著管理整個專案技術的要求。也就是說架構師管的不是人，是技術，是屬於有職無權的角色。當然不妨礙架構師可能拿的薪資比管理人員還高，我覺得這是合理的。

　　所以考核架構師如何把技術開發流程管理好，如何讓技術落地開花，如何保證開發者規範、標準等等是技術之外的軟實力。

2.5任務管理：

　　架構師有點像將軍，除了自己有過硬技術本領，還要帶兵打仗搞管理，兼職做點軍師的活。所以任務分配，排兵佈陣這些管理者做的事一個也不能少。那麼如何去考察架構師的排兵佈陣的能力呢？

這裡參考我尊敬的劉老師的建議，按照時間維度，瞭解對方事前、事中、事後如何做技術管理。事前是如何做任務規劃，這些規劃是否遵循架構標準，是否遵循SMART原則；事中是否有效執行，風險如何做預案；事後有沒有歸納總結等。

三、問題設定

　　以下是個人從以上兩個方面設定的簡單提問，純屬個人編製，希望對你有所啟發。

原文地址：https://www.cnblogs.com/jackyfei/p/10402162.html

---

.NET社群新聞，深度好文，歡迎訪問公眾號文章彙總 http://www.csharpkit.com