最近兩年，我一直跟it公司裡面的演算法工程師們一起工作，自己也算一名演算法工程師，也面試過各個級別的演算法工程師。來了it公司之後，我剛開始面臨的乙個很大的問題，短時間內很難看清楚申請人真實的演算法水平。主要難點有兩個：
這兩個難點就是短時間內，沒有乙個可信的標準來衡量對方的演算法水平。
我在學界做了快20年的研究，培養了一批人才，一部分人去了學術界（nyu，unc，emory，uot，purdue，yale，uoa，fsu等），另一部分人去了工業界（像uber，didi，高盛等）。在我實驗室的幾年中，他們都是跟我一起研究某個應用場景內的一些有意思的問題，收集和/或處理相關資料，設計各種演算法，與推導相關的理論。在學界中，我也面試了許多青年才俊們，主要看他們的推薦信，發表的文章，與面試的交談和學術演講。在這種情形下，高水平的文章/專著一直是在學界中找到好工作的必要條件。在頂刊/頂會發表文章的數目以及被引用的次數一般被認為是可信的標準，因為這些地方大部分審稿人的要求都是非常高的，標準基本上就兩個:
我現在考察面試人的演算法水平, 主要是基於面試人常用的演算法來問如下幾個基本問題：
許多沒有受過嚴格演算法訓練的同學們經常到第二個問題的時候就卡住了。對於中高階的演算法工程師，最好還要有高質量的學術**/專著或被行業所廣泛認可的產品，這些積累反映了他/她對一類問題的深度思考，這就是一種可信的硬性標準。相對應地，在google的deepmind工作過幾年的同學，大家一般會認為其實力應該不錯，因為deepmind本身就代表了乙個可信的軟性標準。乙個好的演算法團隊最好有許多有軟硬實力的演算法工程師，但問題是高效的資料產品開發到底需要什麼樣的演算法工程師呢？
首先，在資料產品開發中，選取好的業務指標是保證資料產品質量最重要的標準，定好合理的業務指標是所有資料產品應用層實現技術落地的核心。
其次，在資料產品開發中，我們要考慮兩類技術指標：演算法的技術指標和模型的診斷統計量。大部分資料產品都是可以拆解為一系列分類和回歸模組的有機組合。
有了這些準備，我們再談談在資料產品開發中技術指標和業務指標之間的關係。
在每個模組的開發中，我們一般收集一組/幾組訓練資料集，構建一組模型，用交叉驗證法從演算法的技術指標和診斷統計量得到反饋，選擇模型，改進模型，直到達到一定的準確度。
一般來說，所有模組上取得好的技術指標不能自動地轉化為好的業務指標，這個依賴於對業務指標的有效拆解。拆解好了，一些模組的技術指標做得差點對提公升業務的指標影響可能不一定很大，所以做產品的過程中，我們一定把整個流程跑通。再找到一些關鍵模組來優化，但是在一定成本之下，大家還是都希望把每個模組的技術指標做到極致。這個問題是落地最難的點，需要更多的案例來剖析其中的深度。
最後，我們以阿爾法圍棋這個資料產品為例. 它的業務指標就是下贏對手, 它被拆解成四個模組，形成乙個完整的系統。
在演算法層面上，alphago結合了深度學習，強化學習和蒙特卡洛樹搜尋法等多個方法，並對這些方法進行了開創性的發展，使其實力有了實質性飛躍，以取得打敗多名世界冠軍的記錄。這些成果都是**於alphago團隊對指標的高效拆解、高深的演算法水平和有效的底層資料建設。
北卡羅來納大學教堂山分校生物統計學終身教授 ，2023年加入滴滴出行，帶領工程師們為滴滴出行平台的運營打造一套雙邊市場的創新理論和平台。
北卡州立大學統計博士，2023年加入滴滴出行，主要從事統計和機器學習在雙邊交易市場的研究和應用。
歡迎對大資料底層引擎（如 spark、flink 等）有研究和實踐經驗的工程師/專家加入滴滴大資料架構部，一起面對網際網路+出行行業的每天萬億級海量資料處理挑戰。
投遞郵箱 | [email protected]
郵件主題請命名為「姓名+應聘部門+應聘方向」
本文由部落格**一文多發等運營工具平台 openwrite 發布
網路遊戲成功的四個關鍵要素
準備 執行 測試 維護。網路遊戲開發者常常會違反這些常識性的步驟。開發者通常極具創造力，他們進入這個行業就是要開發遊戲 他們整體來說也很年輕，不具經驗。當你要能理解了第一階段 準備 在整個過程中是成功的關鍵 你的團隊就會迫不及待進入到第二個階段 執行。幾乎每個網路遊戲團隊都同意應該把準備工作 設計 ...
設計模式的四個要素
設計模式 design pattern 是一套被反覆使用 多數人知曉的 經過分類的 設計經驗的總結。使用設計模式的目的 為了 可重用性 讓 更容易被他人理解 保證 可靠性。設計模式使 編寫真正工程化 設計模式是軟體工程的基石脈絡，如同大廈的結構一樣。我們使用設計模式最終的目的是實現 的 高內聚 和 ...
設計模式的四個基本要素
設計模式的四個基本要素 1 模式名稱 pattern name 乙個助記名，它用一兩個詞來描述模式的問題 解決方案和效果。2 問題 problem 描述了應該在合適使用模式。它解決了設計問題和問題存在的前後因果，它可能描述了特定的設計問題，也可能描述了導致不靈活設計的類或物件結構。3 解決方案 so...