直言不諱的說,這是一篇內推推廣文。但本文講的是筆者在抖音 iOS 基礎組兩年的工做經歷,誠心推薦,並沒有合做。本文所描述經歷只侷限於抖音 iOS 客戶端團隊,若與其餘團隊狀況有較大誤差也是合理的。文末有內推羣,固然此次主要是以校招內推爲主。web
2018 年 4 月,我去面試了字節跳動的 Musical.ly 團隊而且得到了 offer(面經可在我博客中查看:www.desgard.com/summary-2018)。當時內心仍是很開心的,由於很早就知道 Musical.ly 這個產品,而且 2018 年春節,抖音成爲現象級 App,因此天然而然地就會想到 Musical.ly 和 TikTok 會爆紅全球。面試
考慮到現象級產品效應以及我的待遇問題,便選擇了跳槽字節跳動。瀏覽器
剛入職的時候正趕在 Musical.ly 和 TikTok 的「技術融合」階段;組件化剛剛起步,剛剛開始下沉第一個組件;在研發平臺以及本地研發工具方面也是從未有人接觸過的領域。性能優化
既然是這種狀況那咱們就開始搞起!微信
筆者在字節作了什麼
仔細想一想,在字節的兩年作的都是關於組件化和研發流程的事情,但主要兩個從零到一的項目就是研發工具鏈 MBox 以及遠程依賴 Seer 服務。下面先單獨講講。架構
研發工具鏈 MBox
考慮到組件化以後業務同窗的開發成本,迫切但願一個多倉庫管理工具。而且因爲抖音項目是使用 CocoaPods 進行多組件的整合與集成,因此咱們須要一個研發工具來實現 Pod 源碼形態的快速轉換。在此基礎上 MBox 誕生了。
編輯器
對比與市面上各路大廠的倉庫管理工具:螞蟻夥伴(螞蟻金服)、EasyBox(百度)、One(滴滴)等,MBox 吸收了不少工具的優勢,而且考慮到後期功能的加強以及其餘業務團隊的定製化,咱們將全部子模塊所有拆成插件。如此一來,在集團內的每一個同窗均可以參與 MBox 的開發,打造本身團隊的 Workflow。工具
如下是 MBox 在原生能力上的主要功能模塊,但全部的實現方式均是 MBox 插件,在產品接入時能夠按需選擇接入,也能夠按需增減。組件化
從 2018 年 9 月至今,MBox 已經服務於全公司的 30+ 個產品線,協助你們完成平常的需求開發,提高總體研發效率。性能
遠程依賴 Seer 服務構建
在阿里的 MTL 工程管理平臺中會有一個「依賴表」的概念,其實咱們能夠理解成是講當前穩定的一套 Pods 依賴表(經過 CI/CD 出包後的 Podfile.lock
)。經過這個依賴表,咱們能夠自由的實現對應版本的依賴情況;在組件低耦合的場景下,實現換殼多項目開發;能夠快速進行 CocoaPods 依賴決議。
因爲團隊規模日益增加,研發同窗習慣組件化開發模式,而對於字節這種中臺業務的獨立,其「研發換殼」逐漸成爲最大的痛點。(好了不說了,這個功能咱們要有 (╯‵□′)╯︵┻━┻)
一個服務考驗的是一個全棧的能力,如下是使用的技術棧。
其中的難點就是解析 Podfile.lock
進行版本分析,以及如何根據差別化的 Podfile.lock
計算出版本的 Diff。剩下的就是在 Pods 中如何注入依賴,因爲有以前 MBox 寫 CocoaPods 插件的經驗,這裏也就十分容易了。
Seer 上線後持續迭代,目前已經成爲抖音 iOS 項目中不可缺乏的一個環節。而且還會用在中臺項目對於抖音適配的開發流程中。
具體的技術細節須要等開源才能細說,固然若是你也是相關效率工程方向的開發同窗,也歡迎一塊兒交流和溝通。
有什麼收穫
如下是我概括的在字節跳動客戶端基礎團隊工做的一些收穫,因爲我是在工做第一年加入的,我以爲也能夠適用於剛入職場的小白:
如何在一個百人團隊中與同事協做開發;
瞭解了巨型 App 的所有迭代流程;
如何肯定產品痛點,如何打磨技術產品;
如何調研技術方案,如何解決問題;
怎樣進行指標監控和量化;
如何 Oncall 本身負責的服務;
如何將我的的產出同步和分享出去;
...
字節值得稱讚的那些事
免費三餐、下午茶、房補、加班打車、活動日、健身房這些我就不說了,本身腦補就好。
1. 經過數據來衡量成果
-
對於業務同窗來講,會定義不少產品指標來評判業務的有效性。例如:用戶轉化率、滲透率、留存率等等。這些埋點會最終決定需求是否在下一版本保留以及 AB 實驗的選擇等。 -
對於技術同窗來講,也會增長需對技術指標埋點來衡量效果。對於抖音項目來講,除了那些常規指標(冷熱啓動、卡頓、Crash 率等等),還會有與垂直業務關聯度較高的一些指標,例如首幀、首次啓動相機等等。這些指標不只會統計抖音每一個版本,並且還會統計對應競品的每一個版本數據,在比較中才能知道自身 App 的短板。 -
對於咱們研發工具而言,用戶就是全部的開發。因此咱們也會增長不少數據埋點,例如 pod install
的耗時、編譯耗時等等。這樣咱們就能夠明確的知道研發同窗吐槽效率低的緣由是什麼。
2. OKR 是「我的管理工具」,而不是「我的工做管理工具」
這二者有什麼差異?我的管理工具其實你能夠寫不少自身相關的 Object Key,然後者只是一個變相的記錄向上管理工做工具。
例如在咱們團隊中,可能有的同窗 OKR 中會出現 「這個雙月減肥 XX 斤」 或者是 「這個雙月 LeetCode 刷 XX 道題」等,由於關係到我的規劃而不是我的工做規劃,OKR 會集中的把你的目標記錄在一個位置,這樣在雙月末能夠一塊兒 Review,來衡量本身的時間。
因此,你想成爲時間管理大師嗎?👀
3. 優秀的內網學習資源
在字節內部有不少優質的學習資源,不管 byteKM 平臺(內部技術博客)、仍是 Study 平臺(內部技術視頻分享),都具備至關高的質量,與外部不少付費資源質量至關。並且須要交流或者有什麼問題均可以直接飛書交流。
這些資源不但能夠促進自我成長,並且當你加入撰寫、分享技術文章後,還能收穫必定的影響力。教學相長,一箭雙鵰。
不少內部脫敏後的優質外網文章(你會發現不少都是咱們團隊的小夥伴,手動狗頭):
-
《抖音研發實踐:基於二進制文件重排的解決方案 APP啓動速度提高超15%》 -
《iOS 渲染原理解析》 -
《模糊的 Any 和 Optional》 -
《Swift 5 以後 "Method Swizzling"?》
基礎與架構真的很高深嗎?
說穿了,作基礎技術須要這幾點:
-
瞭解業務同窗的痛點,經過技術手段來提升效率; -
技術棧偏向全棧開發,更加看重腳本能力,以解決問題的角度出發; -
持續學習,多接觸其餘大廠的技術方案;
咱們將研發效率當作產品的北極星指標來看待,那其實作基礎的同窗也就是」作業務」,只是成長的角度不一樣。
而工程架構與性能優化可能就須要資歷更深的工程師來加持,每每須要對業務的深入理解、對技術的清楚認識、對方案的廣度瞭解。這些你須要用本身的時間和精力去不斷培養和積累,可是誰都會經歷從零到一的階段?因此並不用過分擔憂和焦慮。
我的看來,作業務和作架構只是服務的對象和用戶不一樣,一樣都擁有價值。
總的來講,字節跳動從我的成長來看,很適合做爲你的第一份工做。
內推方式
後面就是關於此次校招內推的一些規則了,社招的話直接加羣聯繫冬瓜就好。另外還有一點我知道的就是,iOS 客戶端校招的標準,是不須要你有 iOS 基礎的,也就是計算機基礎達標就 OK。好了我就說這麼多,你品你細品 - -。
如下是內網提早批校招郵件放出的內容:
字節跳動2021校園招聘研發提早批內部推薦全面啓動!本次校招提早批主要針對研發類崗位,3000+HC 虛位以待!
超早上岸:幫助同窗們 6 月拿offer,快人一步;
超穩通關:多一次投遞機會,結果不影響秋招;
內推時間:2020/6/16-2020/7/16
招聘對象:2020年9月-2021年8月期間畢業的同窗(中國大陸以畢業證爲準,非中國大陸區以學位證爲準),且最高學歷畢業後無全職工做經驗的學生。
職位類別:研發類崗位
這邊我放出幾個內推碼,請你們按照城市來選擇不一樣的內推碼,這樣咱們比較好跟進和反饋:
-
上海(及其餘城市的抖音客戶端部門): FFGFNVU 、 DPC639Q -
北京: B2Y9RJK (小吉的內推碼) -
深圳: ZQVUCYU (丹子的內推碼)
內推加羣
使用內推碼的同窗切記必定要加羣在羣裏和對應同窗跟進。
若是羣滿後,請在公衆號後臺:【點擊「加羣」】→ 【內推加羣】,添加 Bot 以後,回覆「內推加羣」,便可得到加羣邀請。
最後,但願你們在求職季,都能找到本身心儀的工做!成爲 offer 收割機!🤖
本文分享自微信公衆號 - 一瓜技術(tech_gua)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。