如果你是一名軟件工程師，在一家數據公司找工作，我會告訴你一個公開的秘密--大數據的爆炸性增長意味著世界是你的。作為一名招聘經理，我可以告訴你，大多數工作在薪酬、頭銜、福利和額外津貼方面都并駕齊驅。

令人遺憾的是，工程文化被忽視了。

我不是在說“有趣”的表面跡象。我指的是一個公司有意組織自己為客戶創造最大價值的指標--即使這意味著以一種非正統的方式管理它的組織。

根據我作為一名工程團隊領導的經驗，我將分享表明一家公司是為了創新和忍耐而建立的五大標志。請放心，無論你去哪里，你都會得到豐厚的報酬。但是，如果你進入這個領域是為了滿足一個真誠的目標，建立一些有價值的東西，在下次面試時扭轉局面，評估一家公司的工程文化，選擇值得你的團隊。

1。他們慶祝全堆棧能力嗎？

對于那些輕視通才、認為通才不如專家有價值的人，請三思而后行。

全棧工程師是一個全面的球員，不依賴任何人來完成他們的工作。它們可以單獨為您的組織提供價值。

簡而言之，他們很棒。

本周，我請我們出色的全棧開發人員Ilan Techenak開發一個服務，該服務在我們的部署中運行，監視Google的BigQuery數據倉庫，并允許用戶從我們的Databand應用程序中與之集成。

讓我們花一點時間來承認完成這項任務所涉及的子任務所需的知識和專長的廣度：

1. 這個任務中還有許多其他方面--我們如何管理用戶的秘密，如何與用戶的GCP服務帳戶集成，如何監控自己的系統，如何對它進行端到端測試，等等。
2. 我們需要開發一個BigQuery代理--一個明顯的后端服務。
3. 我們需要讓用戶將監控系統與我們的應用程序集成--包括前端和后端工作，包括引入新的API和UI更改。我們的大部分后端都是用Python和Vue.js編寫的，我們使用PostgreSQL作為數據庫。
4. 我們需要讓這個服務在我們的部署中運行--我們的系統在Kubernetes中運行，并由Helm部署管理。我們使用GitLab作為代碼管理和CI/CD。是時候伸展你的DevOps肌肉了。
5. 在這一點上，BigQuery對我們來說是新的--我們需要一個有能力深入研究新技術并專注于了解我們需要什么來獲得產品需求的人。我們可以請數據庫專家了解BigQuery是如何工作的，讓BiQuery用戶熬夜的內部機制，以及他們關心的度量標準。雖然這在紙面上聽起來不錯，但我們的BigQuery客戶都不需要這種粒度級別，學習它需要很多時間。

一個全棧工程師需要擁有大量的技能集才能完成這一系列的任務。但更重要的是，它們首先圍繞著如何實現業務目標，以及如何為客戶（從而為公司）創造影響和價值。全堆棧工程師會處理一個大問題，例如“我們想要監視BigQuery”，并將其分解為不同學科、不同代碼語言、不同技術和不同專業知識中的多個子任務。在他們的核心，他們是專家問題解決者，他們根據給出的任何問題自己找出解決方案。

就像我說的，他們很棒。

一個重視跨學科能力的公司通常包含新的想法、看待事物的新方法和解決問題的新方法。傾向于創新的公司不能不以更有創造性的方式運作。

2。他們重視技能的多樣性嗎？

盡管如此，當全棧工程師得到專家和基礎設施團隊的支持時，他們會茁壯成長，這些團隊專注于基礎設施的健全性，并在風險開始增加時發出警告。

看看Jonny Barda吧--一個頂尖的后端工程師，一個代碼哲學的粉絲，一個純粹主義者，一個真正復雜的工程問題的愛好者。一個全棧工程師需要像Barda這樣的人來幫助設置參數，以確保我們支付技術債務，并在設計規劃和審查期間提升架構問題。

說實話，巴爾達在我們隊里是不可或缺的。他為我們的進步提供保證，因為他確保我們的系統不會經常崩潰，也不會變得幾乎無法維護。

除了我們團隊中的專家，我們還有一個基礎設施團隊，由全公司的人物組成，他們幫助導航船只。我們的架構師確保我們所有的服務都處于良好的狀態，幫助工程師解決最大的設計問題，并領導基礎設施團隊。我們的前端技術領導擁有我們的UI架構，并能夠選擇正確的技術棧，以確保我們有正確的測試和共享組件的基礎。

最后，我們有DevOps管理員負責所有的部署、監控和CI/CD。

正如您所看到的，系統的任何部分都不缺乏所有權。

我們的全棧工程師依賴于基礎架構團隊來思考大的公司范圍的問題，共享知識，解決復雜的問題，并防止我們做其他團隊已經在做的雙重工作。

共同作用，每個功能發揮獨特的作用，以建立一個將為我們的客戶帶來價值的產品。讓他們作為一個團隊閃耀的是他們在優勢上的差異以及他們如何互補。對于我們的全棧工程師被授權在他們測試和解決問題的探索中打破的一切，有一個專家和一個基礎設施團隊來防止問題的出現。

有意讓團隊擁有廣泛技能的公司會更大膽地承擔更大的風險，以追求更好的結果，從而成為更具競爭力的企業。雖然大膽的決定可能會導致風險升級，但專家和基礎設施團隊提供的支持確保了所有風險實際上都得到了計算和減輕。

3。他們的團隊結構是否鼓勵敏捷性？

軟件的變化是對客戶理解的變化。接受這一現實意味著敏捷必須被構建到工程文化中。即興創作并不罕見，而是團隊經常發揮的獨特能力。

想象一下，你有一個樂隊--就像我們在Databand一樣--你的樂隊正在并行地創作許多新歌。在制作過程中，靈感來襲，你需要添加更多的聲音，如一個小吉他線或幾個低音鼓踢來完善的聲音。全棧工程師是那種能在飛行中即興發揮的多樂器樂隊成員。當您運行多個復雜的項目時，它們尤其能證明它們的價值，這些項目涉及許多活動部件。我向你保證，偉大的音樂很大程度上歸功于即興創作，偉大的軟件也是如此。

如果我們按照功能專業組織我們的團隊--前端團隊、后端團隊等等--需要一個全棧工程師的事情現在需要3-4個不同的團隊來處理。

在Databand公司，我們確保我們的產品團隊由70%的真正的全棧工程師和30%的專業專家組成。這允許每個團隊完全專注于一個業務目標，并擁有成功所需的所有能力。我們的基礎設施團隊致力于解決跨公司的工程難題，改善我們的內部開發經驗，并確保我們奠定正確的基礎，使我們能夠有效地發展。

工程團隊的組成是衡量工程文化優先級的最簡單的方法之一。擁有更大比例的全棧工程師的團隊將能夠始終如一地敏捷執行。敏捷不是一個目標，而是一種有機的存在方式。

4。他們是否根據每個人自己的功能來衡量他們？

根據Emily Heaslip在Index上的文章，度量開發人員似乎基于以下KPI：

• 周期時間-開發人員將任務從一個狀態轉移到另一個狀態所需的速度，也就是開發特性、修復bug和消除瓶頸的速度。
• Sprint burndown--它允許您理解是否要“使這個Sprint工作”，即完成您計劃在這個Sprint中完成的大部分事情。
• Velocity-交付了多少完整的特性
• 打開的請求-有多少“Jira票”沒有得到答復
• 吞吐量-總結上一周月份的所有上述情況。

盡管如何度量軟件工程是一個非常有爭議的話題，但上面的5個項目可以給我們提供一個合理的工具來度量專家或面向基礎設施的工程師。

在度量這些類型的工程師時，您將關注他們的代碼質量、他們創建和解決的技術債務的數量、他們如何減少所需的維護工作、他們的測試復蓋率以及他們為解決方案選擇了最終工具的事實。

全棧工程師需要用一種不同的方法來衡量，而我們關注的是其他類型的性能：

• 業務影響-它們的特性如何改進我們的業務KPI？有多少新用戶因此而使用該系統？有多少用戶重新使用此功能？它是否為用戶解決了一個真正的問題？
• 敏捷性-如果我們明天需要刪除整個特性或擴展它以支持不同的技術棧，他能多快實現所需的特性？
• 端到端責任-全棧工程師應該能夠獨立工作，從DevOps到FE開發他的特性，能夠使用該特性，確保它經過充分測試，并修復我們在其中發現的任何bug。
• User Experience-為了適應業務目標，全棧工程師最有可能了解最終用戶將如何使用他的特性。
• 技術債務-我們期望全棧工程師指出他為了快速交付而做出的權衡，并在他創建一個大的技術債務時發出警告。

總而言之，全棧工程師應該根據他們被要求達到的大的商業目標來衡量。

這種衡量標準的區別很重要，因為它告訴你公司是否真的要讓員工成功。

5。他們重視你的性格和人性嗎？

要注意的最重要的標志是，一家公司看中的不僅僅是一套與他們相匹配的技能。找一家比你所有技能和經驗的總和更看重你的公司。

我們所有的招聘經理都認識到，技能是可以學習和磨練的。我們有一些非常優秀的開發人員，他們都來自不同的經驗水平。它們的共同點是我們認為比正統的代碼掌握更有價值的品質：

謙遜。雖然我認為這在任何環境中都是一個重要的特質，但在新事物永不消失的研發環境中，這是最重要的。謙遜標志著嘗試新事物的信心和對錯誤的容忍之間的平衡。

快速學習者。當我們招聘開放角色時，我們并不總是在尋找非常有經驗的開發人員。我們只是要求應聘者讓我們相信他們能夠輕松快速地學習新技術。

對成長的渴望。我們認為的所有候選人都是聰明和敏銳的。那些脫穎而出的人總是表現出一種有朝一日成為特定領域專家的動力。

業務驅動。我們的團隊中不乏出色的開發人員，他們可以編寫漂亮、優雅的代碼。但是，我們的團隊與其他團隊的區別在于，我們的開發人員并不滿足于不服務于業務目的的漂亮代碼。他們都認為自己是我們底線的貢獻者。他們是以客戶為導向的，當他們的工作得到滿意的客戶時，他們感到最受認可。

雖然這五個標志是幫助你評估未來雇主的極好指標，但它們絕不是全面的。當你考慮機會時，還有其他因素是至關重要的。下次面試時，請記住，投資于你潛力的公司才是值得你花時間和才干的公司。

準備好問題來幫助你做出決定。祝你好運！