在抖音 iOS 基礎組的體驗(文末附內推方式)


直言不諱的說,這是一篇內推推廣文。但本文講的是筆者在抖音 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 平臺(內部技術視頻分享),都具備至關高的質量,與外部不少付費資源質量至關。並且須要交流或者有什麼問題均可以直接飛書交流。

這些資源不但能夠促進自我成長,並且當你加入撰寫、分享技術文章後,還能收穫必定的影響力。教學相長,一箭雙鵰。

不少內部脫敏後的優質外網文章(你會發現不少都是咱們團隊的小夥伴,手動狗頭):

基礎與架構真的很高深嗎?

說穿了,作基礎技術須要這幾點:

  1. 瞭解業務同窗的痛點,經過技術手段來提升效率;
  2. 技術棧偏向全棧開發,更加看重腳本能力,以解決問題的角度出發;
  3. 持續學習,多接觸其餘大廠的技術方案;

咱們將研發效率當作產品的北極星指標來看待,那其實作基礎的同窗也就是」作業務」,只是成長的角度不一樣。

而工程架構與性能優化可能就須要資歷更深的工程師來加持,每每須要對業務的深入理解、對技術的清楚認識、對方案的廣度瞭解。這些你須要用本身的時間和精力去不斷培養和積累,可是誰都會經歷從零到一的階段?因此並不用過分擔憂和焦慮。

我的看來,作業務和作架構只是服務的對象和用戶不一樣,一樣都擁有價值。

總的來講,字節跳動從我的成長來看,很適合做爲你的第一份工做。

內推方式

後面就是關於此次校招內推的一些規則了,社招的話直接加羣聯繫冬瓜就好。另外還有一點我知道的就是,iOS 客戶端校招的標準,是不須要你有 iOS 基礎的,也就是計算機基礎達標就 OK。好了我就說這麼多,你品你細品 - -。



如下是內網提早批校招郵件放出的內容:

字節跳動2021校園招聘研發提早批內部推薦全面啓動!本次校招提早批主要針對研發類崗位,3000+HC 虛位以待!

超早上岸:幫助同窗們 6 月拿offer,快人一步;

超穩通關:多一次投遞機會,結果不影響秋招;

內推時間:2020/6/16-2020/7/16

招聘對象:2020年9月-2021年8月期間畢業的同窗(中國大陸以畢業證爲準,非中國大陸區以學位證爲準),且最高學歷畢業後無全職工做經驗的學生。

職位類別:研發類崗位

這邊我放出幾個內推碼,請你們按照城市來選擇不一樣的內推碼,這樣咱們比較好跟進和反饋:

  • 上海(及其餘城市的抖音客戶端部門): FFGFNVUDPC639Q
  • 北京: B2Y9RJK (小吉的內推碼)
  • 深圳: ZQVUCYU (丹子的內推碼)

內推連接 (注意複製後使用瀏覽器打開,WeChat 會對其域名屏蔽)
https://job.bytedance.com/campus/position

內推加羣

使用內推碼的同窗切記必定要加羣在羣裏和對應同窗跟進。

若是羣滿後,請在公衆號後臺:【點擊「加羣」】→ 【內推加羣】,添加 Bot 以後,回覆「內推加羣」,便可得到加羣邀請。

最後,但願你們在求職季,都能找到本身心儀的工做!成爲 offer 收割機!🤖



本文分享自微信公衆號 - 一瓜技術(tech_gua)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索