上一篇文章：從杉數到滴滴——未入門算法工程師工作日記（快手篇）
大家好！
《從杉數到滴滴》這個系列記載了猹哥這一年來，在不同的網際網路公司，做不同的工作的時候，所得到的各種心得體會與經驗。時間轉瞬即逝，在位元組呆了近四個月的時間，也和幾個同僚們一起度過了一段辛苦而充實的時光。如今也到了要離開位元組跳動的時候，是以《從杉數到滴滴》的位元組篇，也就應運而生啦。
這一篇是這個系列的第4篇，并且短期來看，這一個系列會告一段落，因為猹哥結束實習後，就要離開北京，結束北漂，回家準備下一年的留學了。我們在這一篇中會主要圍繞位元組跳動這一家公司，以及我所做的工作來介紹。值得一提的是，我的上一段實習經曆（從杉數到滴滴——未入門算法工程師工作日記（快手篇））位于快手，是抖音的競品。同時，做的工作也在廣告這個大的領域，是以其實很多方面是可以進行對比的，相信這樣的話，大家會對兩家公司具體做的事情更加了解，也會更容易加深對兩家短視訊網際網路公司的印象吧hhh
在這之前，還是要先做一個免責聲明（disclaimer）。就像我在快手的文章隻能說明快手商業化的情況一樣，在位元組也隻能說我自己的部門的情況，不能夠推廣到全公司。事實上這個對比完全是基于個人經驗，屬于一個公司的不同的組，可能會有完全不同的工作體驗，是以大家從中各取所需就可以了，千萬不要把我的想法當成正确的結論……
那麼我們開始吧～
01
位元組跳動簡介
北京位元組跳動科技有限公司，成立于2012年3月，是最早将人工智能應用于移動網際網路場景的科技企業之一，是中國北京的一家資訊科技公司，位址位于北京市海澱區知春路甲48号。公司以建設“全球創作與交流平台”為願景。位元組跳動的全球化布局始于2015年，“技術出海”是位元組跳動全球化發展的核心戰略 ，其旗下産品有今日頭條，西瓜視訊，抖音，火山小視訊，皮皮蝦，懂車帝，悟空問答等。
位元組跳動人工智能實驗室成立于2016年，旨在針對人工智能相關領域的長期性和開放性問題進行探索，幫助公司實作對未來發展的構想。其獨立研發的“今日頭條”用戶端，通過海量資訊采集、深度資料挖掘和使用者行為分析，為使用者智能推薦個性化資訊，進而開創了一種全新的新聞閱讀模式。
截至2020年8月，抖音日活躍使用者數已經突破6億，位元組跳動旗下全線産品總MAU（月活躍使用者）超過15億。
2021年5月20日，張一鳴宣布卸任位元組跳動CEO，聯合創始人梁汝波将接任。
提到位元組跳動，大家第一印象還是抖音和Tiktok，不過實際上位元組跳動的産品可遠不止這些。諸如更加本土化的火山視訊，投放廣告的穿山甲，投身教育的瓜瓜龍等等，其實都是位元組跳動的産品。也就是說實際上位元組跳動的短視訊業務隻是它的一個部分（雖然确實是利潤的絕對大頭），它的業務線的廣闊，可以保證網際網路的幾乎所有的業務，都能夠在夠在位元組跳動找到應用的場景。并且得益于位元組跳動研發線的高标準嚴要求，位元組的内部具有相對較強的中層力量，換句話說在infra側上，位元組的總體水準是處于網際網路公司相對比較高的水準的，但是如果說超過BAT什麼的，這個可能還是都去過的人體驗一下才有發言權，我就先閉麥了hhh。
總之如果想來到位元組跳動的研發線，嚴格的面試準備是必不可少的。這一點各有利弊，利在于篩選進來的人一定都是水準較高的人，弊則在于招人的高要求，會對應導緻符合要求的候選人的減少，這樣一定程度上會限制業務的擴張，同時在缺人的時候，項目的壓力就會相對較大。當然，如果真的是少之又少的人才，進入位元組之後，也要比對比較高的薪資，不然可能就真的招不了人了……即使是我自己已經來到了位元組目前的組（Adscore，後面會介紹）呆了幾個月，我也對高難度的面試持保留态度。但是事實上真正通過“千軍萬馬獨木橋”來到了位元組研發線的朋友，可能處于不同的部門，做着不同的業務，但是都沒有對自己所做的決定感到後悔。
02
我在位元組跳動做了什麼？
要說自己做的事情，其實是一個非常非常小的零件一樣的存在。不過在這之前，我想先唠唠我所在的部門的大概的組織架構（因為細節的架構業務是涉及機密的，這裡就不能多說了）。畢竟位元組跳動是非常強調扁平化的公司，是以他們的架構也一定程度上展現了這一點，就是有的時候讓人摸不着頭腦……
｜PART 1｜
首先說說大部門，我通過的實習部門是位元組跳動的Adscore，Adscore這個部門，就是Ads+core，是一個非常純粹的廣告算法部門（雖然最近大leader也開始招一些資料分析師，用來支援這裡算法的工作）。也就是說，基本上所有的廣告相關的算法與業務，其實都會落在這個部門，是以其實很多時候，我們會說這個組是一個中台組，就像中間件或者架構中的一些中間層，用于支撐一些實際業務。
｜PART 2｜
當然了，Adscore是一個非常大的組，内部有非常多的業務細劃。因為涉及架構等敏感資訊，這裡不詳談。但是大體上來說，算法這邊可以作簡單的三個部分的區分，就是模型，政策和生态。但是如果按照功能分的話，分為兩個子產品會比較好，就是模型和政策。我自己屬于的是政策組，是以相比較快手模型組的任務來說，就又是一塊全新的領域。政策組和模型組的差別，我之前寫過一個想法，就是說
搞模型的，數錯了，數倉有問題，表有問題，就你沒問題。
搞政策的，數錯了，數倉沒問題，表沒問題，就你有問題。
事實上就說明了，相比較模型來說，政策不是一個黑盒子，每一步都是可以被我們所定制化和追蹤的。這樣的話，從落表開始，到最終産品的政策上線結束，中間的每一步都是有可能有錯的和設計不合理的。這也是為什麼相比較而言，政策算法不容易受模型算法那麼受歡迎的緣故。因為政策算法的細節太多，要管的事情很多，不像模型你調好一個參數/結構，剩下的事情就是排隊等候訓練了……當然了，也是因為這一點，政策相比較模型來說，對于心細程度的要求是更高的，這也很好了解。
｜PART 3｜
終于可以說我自己做的事情了！我自己參與做的産品叫作bid landscape（大家可以在Google上搜尋這個詞）。思考一下，廣告主在投放廣告之後，這一個廣告會經過哪些步驟？網際網路公司比較傳統的廣告鍊路一定包括召回，粗排，精排等，具體細節可能不同公司設計的略有不同，但是一定是有這些步驟的。在這個步驟下，一個廣告到真正拿到收益（我們會說消耗），它的因素會和什麼有關？随便一想肯定都會很多。那麼這個産品要做的事情，就是考慮
當我們固定其他變量不變，隻考慮廣告主的出價（bidding）的話，我們可以如何給廣告主提出價建議（提價？降價？提價多少？還是說因為各種settings不合理，我們不提供建議？），使得廣告主的收益可以被優化。
這個事情相對來說是一個非常新的事情，即使是在國外，能夠說這一個任務做的很好的，也就Google和Facebook兩家。是以我所在的這四個月，雖然大家通力合作，做出了一個産品。但是實際上的效果，要想說“趕英超美”，還是有點異想天開了。但不可否認這個過程是極為充實和具有挑戰性的，對于一個實習生來說，也算沒有留下遺憾。
03
對比：快手和位元組的算法有何差别？
再次強調：這個對比完全是基于個人經驗，事實上屬于一個公司的不同的組，可能會有完全不同的工作體驗，是以大家從中各取所需就可以了～
03-01
“沒有内卷，隻有合作”
首先第一點，就是至少我所在的地方，可能因為要做一個産品的緣故，是以内部大家隻管你的職責是什麼，而不管你是實習生還是正式員工。但是這一點又不能等同于“如果你的工作沒完成，你就需要加班把它完成”，因為正如我在這裡的mentor所說
如果一個項目block在了一個實習生那裡，那麼擔責的應該是配置設定任務的人，而不是這個實習生。
比方說我們在做出價相關的事情，那麼我們要看表，表是全量的嗎（因為離線表的資料大機率都要采樣，否則無法落入Hive）？資料裡面有哪些字段？廣告的settings有哪些限制條件？這一塊大機率是需要數倉和開發來幫忙一起看和做的。再往後，你的政策是什麼？這就需要尋找其他人的文檔，去學習去讨論，再看可能的問題是什麼，優化點是什麼？再往後，效果不好，那麼為什麼不好，你可不可以解釋？如果可以解釋，有明顯的問題，這個問題可不可以量化？可以看出，政策算法是與實際業務，廣告鍊路緊密結合的，決定了全過程一定不隻是算法工程師在悶頭苦幹，而是算法，開發和産品的通力合作。
我們組的模型側也是很類似的，因為不管是在快手還是位元組，資源都是非常緊張的，并且對于一個比較複雜的模型，很多時候出錯的往往不是模型架構本身，或者訓練，而是serving的部分。有的時候可能制約速度的也并不是模型本身的問題，而是其背後的推理架構，這些嚴格來說都是開發要做的事情，與模型算法工程師本身其實關系不大。是以引用leader的話，就是
組内沒有内卷，隻有合作。
一定程度上也展現了位元組這種“團結辦大事”的作風。
在快手（快手商業化）的話，這一點相對來說不會有那麼明顯。其實如果你看了上一篇
從杉數到滴滴——未入門算法工程師工作日記（快手篇）
的話，你會發現，我在快手的工作時間其實是相對自由的（雖然論實際的工作時長，快手商業化平均是比位元組Adscore要長的），因為可以自己一個人，在一個相對比較初級的業務上去調研自己的東西，在這過程中mentor會努力輔助你，但是你的業務是相對獨立的。但是在位元組現在的部門，很多模型已經不再是看paper或者照搬paper可以了解的了，它們都根據實際的業務做了一些個性化的改造。這就使得“調參”這個事情變得幾乎不可能了，大家更多的是關心它與業務的交合（比方說，是否使用了正确的資料流，label是否使用了正确的計算公式，等等）。這就使得“合作”兩個字變得尤為重要。
當然事實上如果是快手的核心部門（例如社群科學部），情況可能就完全不一樣，但是因為我當時不在，這裡不詳談。
03-02
放眼全球，而不是全國
第二點就是位元組在全球（注意，不是全國）各個地方其實都有分部（雖然研發線還是主要在北京，上海，深圳，杭州，山景城，西雅圖等），這就使得出差這個事情變得普遍，也使得業務上絕大部分時間的溝通，都需要依賴遠端。比方說Adscore本身其實是有小部分人是在北美的，在北美的朋友如果要和國内合作，就必須要挑選一個兩個地方都合适的時間。是以事實上有很多組會都會安排在一大早，或者中午這樣的時間，這都是為了照顧兩邊的時間。當然這也使得相對來說，北美的成員的上班時間就會比國内更晚。我們這裡的上班時間平均是11點到晚上九點半，放到北美那裡，有很多人可能就是下午才開始上班，一直上到淩晨，然後早上做自己的事情……雖然聽上去其實挺不可思議的，但是畢竟美國的COVID-19還在肆虐，是以大家都是WFH（work from home）的，倒也無所謂了。
這一點快手就沒什麼好說的了，絕大部分人都是在北京的，最多也就是幾個工區不一樣。雖然也有合作（比方說之前在的時候，社群科學部的一個人就會到商業化的部門去debug一個訓練樣本的問題），但是相對來說距離不遠，也不是特别需要依賴遠端。當然個人感覺，雖然線上的效率不如線下，但有遠端的backup肯定是好的（這裡安利一波飛書，還有它的飛書妙記，開會和分享都會很快有錄屏，以後有空學習也會很友善），COVID-19的出現，就非常明白的說明了這一點……
03-03
讨論時間很多……
最後就是，這裡的會議是真的多……快一百人的大組有會議，非中國區的小組有會議，和mentor的項目也有幾個會議（這其實也可以算是遠端的壞處了，啥大事小事都得靠遠端電話解決，但是這也是業務不斷擴張之後帶來的必然吧，畢竟北京再大，也就地球上的一小塊233）。這也使得相比較快手商業化，你還可以理一個日程表出來，但是在位元組Adscore，由于項目在驅動，每天的工作時間其實并不是很固定。臨近sync或者項目會議的時候，你的數跑不出來，你的政策還在運作，那你一定是會十分緊張的。但是如果你沒有在這個時候，可能你的壓力就還好（當然了，壓力還好的意思就是，你可以按照自己的節奏正常下班。雖然說網絡上總說網際網路公司加班嚴重，但是事實上一個好的公司，對于員工的生活平衡必然是要有尊重和考慮的，雖然項目在忙的時候真的會很累，但是總體上來看，大家還是做到了相對比較好的一個平衡，沒有網上說的那麼玄乎。至于你想十一點來，然後六點七點就下班，可能和公司關系不大，而要看個人頭不頭鐵）。
04
位元組Adscore面試題
叙述過拟合和欠拟合的表現和常見解決方案。
叙述FbProphet的關鍵參數。
代碼題：二維數組，每一個元組内是一個整數，從左上角往右下角走，隻能夠向右或者向下，要求經過的數的和最少，空間複雜度為O(max(m, n))，其中m為行數，n為列數。
叙述GBDT與随機森林的差別。
機率題：給定一棵決策樹，輸出1的機率為p，0的機率為1-p。問如何使用兩棵決策樹進行組合，使得輸出1，0的機率分别為1/2。
代碼題：有序數組查到target元素的最左邊和最右邊，要求複雜度O(logn)
代碼題：消除字元串的pattern（比方說字元串為baba，pattern為ba，那麼會傳回一個空字元串），要求隻周遊一次數組。
解釋一下wide & deep。
xgb的并行化做在了哪裡？
給10min，上網查資料，解釋xgb如何去拟合一條單調上升的曲線。
給10min，上網查資料，解釋如果遇到了10^9維的資料，xgb如何做模組化和特征工程。
代碼題：最長上升子序列。
可以看出，這一次面試在代碼題上，沒有遇到hard，但是其實覆寫面上也是很廣的。傳統的機器學習，深度學習都有考察，還有考察一些開放題。關于面試會考察什麼，在之前的這一篇文章中已經介紹的極為詳盡，這裡我們也不多說啦～
從杉數到滴滴——未入門算法工程師再找實習工作記
05
發個内推連結吧
沒辦法，實在是太缺人了……
TikTok廣告算法工程師
北京 上海
職位簡介
職位描述：
--TikTok Global Ads全鍊路模型(CTR/CVR/LTR等)的優化與基礎技術創新，從模型結構、特征工程、訓練效率等多個次元疊代優化；
--TikTok Global Ads召回/粗排/精排/混排等檢索全鍊路Ranking政策&模型優化，極緻提升廣告配置設定與投放變現效率；
--TikTok Global Ads冷啟動與生命周期優化、智能出價政策、拍賣機制政策等的優化，極緻提升客戶投放效果與體驗，建設健康市場生态；
--業界領先的廣告模型與投放政策的創新&突破，持續保持state-of-the-art的技術水準；
職位要求：
1、有紮實的程式設計基礎、良好的程式設計風格和工作習慣，紮實的資料結構和算法功底；
2、有紮實的機器學習/深度學習理論和豐富的實踐經驗，熟悉至少一種主流深度學習程式設計架構；
3、在計算廣告、推薦系統、搜尋引擎等相關領域有經驗者優先。
4、有較強的邏輯分析與問題解決能力，對解決挑戰性問題充滿激情；
5、善于溝通，工作積極主動，責任心強，具備良好的團隊協作能力；
06
一些想法：算法工程師對工程能力的要求展現在哪裡？
事實上，我們一直在說，算法工程師不是調參工程師。但是如果反過來問，說算法工程師是什麼工程師？其實就有點難回答了，我自己也不例外。事實上，為了搞清楚這個問題，不僅僅是要親自去體驗不同種算法工程師做的工作，前人的經驗也是很重要的。是以我在這段時間還問了一下我們部門的mentor和兄弟部門的leader（Ads Infra，一個業務中台部門，主要會做後端和資料流的工作，是一個開發部門），他們在做什麼，怎麼了解這個工作。最後，其實可以得到下面這一個結論。
算法工程師對工程能力的要求不亞于計算機大學。
如果你是一位轉碼選手，那麼最友善的方法自然是刷題刷題刷題，然後拿到實習/正式offer了，對應的補一塊的知識。比方說你去做網絡相關的内容，那麼計算機網絡這一門課肯定是必不可少了。但是這樣的做法其實限制也很明顯，畢竟你也不知道你是不是就一直喜歡，或者可以勝任做某一個方向的工作。
對于算法來說，其實這種受制會更加明顯，因為我們根本不關心底層設計什麼樣，但是我們卻需要使用它們。舉個例子，我們在做政策算法的項目的時候，我們設計好政策，需要上線，需要實驗，那麼實驗平台代碼怎麼寫，業務邏輯是什麼？這些是不是都會接觸到後端的内容？我的mentor最忙的時候，會同時打開三個螢幕，一個螢幕放Python代碼，一個螢幕放C++代碼，一個螢幕放Golang的代碼。為什麼有三種語言呢？這是因為遙遠的子產品就是用這三種不同的語言寫的，是以他每次看都很崩潰……
有人可能會問，那既然如此，我把這一部分交給開發部門不就好了嘛？事實上這就是職責所在了。思考一個問題，如果一個政策算法工程師隻會寫Python政策，那它值得和一個開發工程師一個價嘛？事實上，除了這個原因，還有一個原因是，實際的業務中，我們要對結果負責，這個過程遇到什麼坑，其實每一個人都不知道。而你身處網際網路公司，你的模型/政策要上線，你不可避免要涉及到公司的架構。是以無論如何，或許你可以不需要背計網的各種術語，或許你可以不需要明白各種架構設計會帶來什麼優化，但是你不能看代碼的時候毫無章法，或者在修改調試的時候一頭霧水。而這，對應的恰恰好就是我們所說的工程能力。
事實上，我們在實際做項目的時候，遇到的各種block的問題基本上都是涉及到後端的。一個例子是，我們要對廣告計劃的政策做測試，這會涉及到一個循環。循環加速的方法是并行，這個如果做過項目的人可能也都聽說過。那麼進一步問，并行可以用多少核？在并行的時候開啟其他的項目，是否會對其他項目的性能産生影響？以及會不會觸發核的熔斷機制？這些都是作業系統的東西，你可以不懂，但是一旦遇到這個問題，真的會毫無頭緒。遇事不決走oncall，oncall雖然一下子就知道問題是什麼，可是時間可能也就這麼浪費掉了……至于各種落表的操作，打jar包，寫Redis，調網絡接口什麼的，這就實在是太常見了hhh。
是以，如果你仔細觀察一下身邊的同僚的話，你會發現絕大部分的人都是CS，EE，自動化這種工科專業，而這些專業不可避免的都會學習很多軟硬體相關的課程。是以我自己認為，算法工程師對于工程能力要求其實真的很高。這個想法固然是有些學生思維，畢竟你不可能到了工作場合之前，要把所有可能的内容都學習完，你也來不及。但是這一點要提示的是，如果現在有空，要努力學習一些算法工程師底層的内容，而不是上層的内容。而如果到了工作場合，也要養成持續學習的習慣，并且适當的去拓展自己在這一塊的邊界。如果想在算法工程師這一塊有自己的成果，而不隻是做螺絲釘的話，那麼對工程能力的把握不可含糊，這一點，無論是我的mentor，還是我的leader，還是我們組的leader，還是兄弟組的leader，都給出了一緻的意見。
是以最後其實可以補一句話，就是
算法工程師和開發工程師都是網際網路的工程師，隻是他們的思考角度不同，對技術棧的要求其實大同小異。
但是事實上目前算法相關的面試，幾乎不考察後端相關的内容。這個當然可以了解，畢竟隻考算法和leetcode都沒辦法招足夠的人了……但是事實上，如果有幸可以加入這個行業，做這一份工作，那麼千萬不要忽視開發，畢竟我們身處網際網路公司，CS基礎就是你的根基，根基不穩，搖搖欲墜，哪一天突然掉入深淵，深淵可能早就期待你很久了。
07
小結