你見過最差的演算法工程師能差到什麼程度？

先歪個題，從反面回答一下，我碰到什麼樣的演算法工程師會認為他/她是優秀甚至是卓越的大佬，並選擇緊緊抱住大腿不鬆手。之前與

1. 基礎非常紮實。問他/她一些比較經典的演算法，能夠很清晰地說出演算法的特點、適用的場景、坑點、裡面的細節等等。
2. 工程能力很強。我是一位“工程狗”，自己的工程能力很菜，但對工程能力強的同學非常崇拜 Orz 如果碰到一位演算法工程師的工程能力很強，僅憑這一點，我就認為他/她基本上一定是大佬Orz
3. 重視程式碼的測試。演算法崗的工作並不完全就是調參煉丹，往往也是需要去寫一些程式碼的，例如寫些spark/sql程式碼獲得特徵，寫模型等等。既然是寫程式碼，就可以而且應該在其中加上測試。實際上，根據我的經驗，如果碰到某個其他地方好用的模型在自己的場景下效果很差（不reasonable得差），那很可能是資料、特徵的處理程式碼有問題，或者模型的程式碼有問題。這種問題可以用單元測試（斷言等）來提前發現，也可以用一些sanity check來發現。
4. 對場景業務的認識很深刻。軟體工程沒有銀彈， 機器學習也沒有銀彈。用什麼樣的特徵、什麼樣的預估目標、什麼樣的評價指標、甚至什麼樣的模型，這些東西都是要與場景業務結合的。換言之，工業屆裡，業務先於技術。很多大神在這個方面做得尤其出色。
5. 在實際場景中，注重先把整個pipeline搭建起來。個人認為，這一點在實際應用中往往應該是最優先的。搭建起來之後，機器學習系統的上下游也都可以工作，也可以更好地判斷系統的瓶頸所在，把好剛用在刀刃上。這其實就與做開發的程式設計一樣，較早地抽象出比較好的介面、搭建一個系統原型是很重要的。
6. 能夠持續學習新的知識，跟蹤最新的成果，對各種模型的motivation有自己的理解，有自己的insight與vision。這裡舉幾個我自己學習過程中碰到的例子來說明一下這點。例如，推薦系統中，在Youtube 16年的推薦paper中，為何step1和step2的最佳化目標是不一樣的？人臉檢測中，MTCNN為何要分為多階段？landmark檢測中，3000FPS為何要分為兩個階段？（這些是設計相關的motivation）Google的wide&deep為何在Google store的場景下效果好，而在其他的場景下效果不一定好（這是對場景的motivation理解）？文字檢測中，PixelLink為何要引入link？OCR中，CRNN為何要引入一個RNN？機器學習系統中，LightGBM是如何針對xgboost存在的哪些缺點進行改進的？（這些是對改進的motivation理解）我認識的一些大佬們會主動結合文章思考這些問題，有的時候會有與paper所claim的不同的理解（畢竟寫paper的story很多時候也不一定靠譜，大家都懂），甚至還會做實驗驗證自己的理解。然後拿這些問題來考我，在我思考不出來後再告訴我他們的理解與實驗結果Orz
7. 做多數實驗之前有自己的假設，根據實驗結果會根據實驗結果做進一步實驗，或修正假設、或進一步探究。
8. 自己參與的專案，對其中與自己比較相關的內容的細節比較清楚，自己負責的部分能夠了如指掌。
9. 能系統性地分析出機器學習整個系統的瓶頸所在，並提出相應的解決方案。當系統效果不好的時候，知道如何去debug，找到問題所在，改進系統的效能。這方面是我個人尤其欠缺的點。

相應地，這些也是我要努力提升的地方。如果我是面試官，我想我也會從這些方面去考察演算法工程師的候選人。當然了，以上幾點不一定要面面俱到，例如很多大佬不一定工程能力很強，但仍然可以做出很好的東西。換言之，上述特點的precision應該很高，但recall不一定特別高。不過，在我看來，與以上描述相反的演算法工程師，即基礎不牢、工程差勁、不做測試、不怎麼考慮場景、在搭建起pipeline之前過早地沉迷於某一步的最佳化、不學習新東西、拿所有實驗當黑箱煉丹等等，這樣的演算法工程師（其實就是我了）在我看來就比較一般。 而差勁的演算法工程師，在我看來，是不僅這些方面做不好，還瞧不起這些方面的人。

這周面試了一個候選人，面CV/DL/AI的TechLead。簡歷很牛逼，做過很多CV的工業專案，涵蓋detection, OCR, face recognition, fire/smoke detection等好多專案. 給我們講了45分鐘做得專案，講得很自信。我挑了一個大專案，我說你在這個專案中的貢獻是什麼？他說整個專案的所有演算法部分都是他實現的。

OK,我開始進行深度學習的技術面。

我先問了兩個深度學習的中等難度的問題，他都說不知道。有點冷場，那我趕緊問點簡單的吧。我說，深度學習網路，進行分類時有哪些loss?他猶豫了一下，回答: relu.

瞬間把見過大場面的我還有同事都震住了。

我們組一個年輕的印度小哥，UCSD畢業的，按說教育背景也不錯，寫model serving過程中的一步。每個request開20個執行緒計算。

我說你一個m*n複雜度的過程，m和n還都小於100，有必要開20個執行緒計算嗎？你那執行緒開銷絕對比平行計算收益大多了好嗎。不聽，給我說（大概意思）：

平行計算比較cool，老老實實寫那個過程太boring。

行吧，不聽不聽吧，自己折騰去吧。

過兩天給我說load test的時候server的latency翻倍，我一看執行緒數都超過JVM上限了能不翻倍嗎。

講這個倒不是想取笑這小哥，而是跟大家討論一個問題，就是什麼是比“技術上最差”更糟糕的情況。

如果你只是基礎差，但總體上是一個嚴謹的人，其實到不那麼麻煩，就是按部就班的學習，按部就班的積攢工程經驗，無論是哪個領導還是老同事應該都是樂於幫助這樣的年輕人的，因為總體來說你還是在解決問題，哪怕速度慢一點，你總歸在成長，而且是讓系統整體混亂程度降低的。

最差的演算法工程師其實是什麼呢？是自己對技術的感覺很差，但對自己的感覺挺好，試圖用一些比較fancy的手段解決問題，但實質上引入了更高的系統複雜度，增加了系統潛在風險，這樣的人，其實對整個團隊是負能量的存在，始終需要更senior的人幫著擦屁股，這無形增加了整個團隊的工作量，這就是最差的演算法工程師。

我特別喜歡的一句話是：

“不帶評論的觀察是人類智慧的最高境界”

希望剛入行的演算法同事們能夠知道這句話的意義，其實公司不急於讓每個人都發表意見，在自己技術能力不那麼足的時候，不帶評論，不帶主觀情緒的去學習一段時間，好好思考一下別人為什麼要做出這樣的技術決策，好好積攢一下自己的技術感覺，這是最重要的。相信度過最初的積累階段之後，你能夠為團隊做出，為整個系統做出“熵減”的技術決策。