實習一圈以後我認爲實習生的生存指南

當你踏進公司的那一刻,說明你已經具有了某些留在這家公司的潛質,你要作的就是展示你的能力和潛力,留下來。前端

樓主渣碩,曾在網易、微信和阿里短暫實習過,目前手上收到了零星幾個offer,可是應該會大機率留在阿里(由於買不起北上深的房子,只能來杭州了)git

說實話,從學生到員工、從學校到公司、從獨立開發者到團隊協做開發有着很大不一樣,樓主也苦於大多數文章都是在說什麼面試技巧和刷題指導(滑稽,真香),固然,這些連同你的學校是進入公司的門檻,可是如何完成轉變融入team,則是你的立身之本。(可能下面這張圖會說明這個變化)面試

因此,我把這幾段實習以及最終轉正的經歷總結了下,說了一些我認爲比較重要的點,固然,都是些拙見,各位看官取其精華(可能沒有)、取其糟粕(可能全是)。微信

section1.入職前

因爲是團隊協做,因此投入實習工做前你須要學習融入團隊的基本功:

  • 熟練使用你的IDE:例如個人工做相關就是Xcode
  • 瞭解經常使用的調試工具的使用好比:Charles、iHost,Chrome dev tools等
  • 代碼工具:git或者sourceTree等(熟練的使用工具能夠極大的提高你的工做效率)
  • 你本身的效率工具:Xmind、keynote、pages等
  • (可選)一些通用型工具:Aone、JIRA等(這些根據公司決定,但使用流都是相似)

section2. 入職後一週你須要作的:

  • 瞭解清楚你所在的組負責的產品和模塊,這部分直接經過導師獲取輸入便可,直接在該模塊發力,能夠省去你不少時間,畢竟一個產品太大了,2個月的實習週期來不及。這些能夠從你們每週的週報看出來,你們都在負責什麼模塊和每週的工做量。
  • 學習團隊的技術大圖和了解模塊owner。
  • 把你的項目環境配好,項目跑起來,先參照gitlab和團隊文檔的說明獨立完成,這裏面會夾雜着權限審批什麼的,及時記錄防止錯亂。在跑項目的過程當中其實就能夠看出一個實習生的水平和學習能力了,不要一上來就問,先自行解決block住後再詢問。
  • 若是你參照文檔不能順利的解決的話,記得解決後及時更新大家的文檔,方便後面的新人同時也能顯示你新人的素養。
  • 儘快和導師計劃好你接下來的工做內容,工做內容必需要是有些挑戰的、會有產出的、有可借鑑案例的、會對業務有推進做用的且有價值的。否則你最後的實習答辯會很難受。固然,最好是可上線能拿到數據的。畢竟沒有數據就只是我的YY了,對高管也沒說服力。

section3. 開始搬磚工做

我認爲這部分由具體的工做內容決定,可是有一些工做原則做爲指導:架構

1.owner你的模塊體如今:

  • 認真負責:體如今你的代碼必須是易維護的、易擴展的,拒絕很挫的代碼,畢竟有code review。能夠參考集團的代碼規約和內部同窗的代碼規範,你們的代碼風格一致。這會減小code review的時間而且提高組內同窗對你的好感度,畢竟大多數實習生的代碼習慣都與團隊會有些出入。
  • 主動提優:這部分是對PD的補充,畢竟PD不是實現者他確定會有些疏忽,而咱們真正實現時會覆蓋全部細節邏輯,這部分PD大機率會有疏忽,一個優秀的技術會注意到這些點並優化他
  • 關注數據:對於埋點數據的計算方法有認知,知道業務背後的價值如何再數據上體現出來。

2.優先級:

咱們天天會被各類事情扯皮,我建議以時間節點和花費估時爲緯度去對事情進行優先級劃分,儘可能把事情的粒度控制好,作到有條不紊,不delay項目。工具

3.認可錯誤、實時檢討:

實習期犯下的錯誤是你踏入這家公司後成本最低的,這種機會不要浪費。gitlab

  • 遇到問題,第一反應不要甩鍋,固然也不要背鍋。錯了就是錯了,就坦誠地認可,不要說「沒人告訴我,我也不知道」
  • 實習生必不可免的會踩坑,固然在可接受範圍內的坑是團隊能夠接受的,可是同一個問題不能犯第二次,每次踩坑以後須要及時反思,大多數狀況下是咱們沒有徹底吃透引發的,因此咱們須要實時反思,把工做規則化、流程化。作到杜絕。
  • 有bug不要慌,不要試圖隱瞞bug。沒bug那就說明要麼是你太牛逼,要麼是你寫的模塊太簡單了

4.交流:

把想說的話先嚥下去,通過大腦過濾後再表達出來,表達的內容要凝練、簡潔、有說服力、有表現力。 每一個人時間都很寶貴,不要浪費別人的時間,可選擇一些你們都舒服的時間節點去交流:性能

  • 天天下班前給你20分鐘
  • 利用中午吃飯的時間
  • 將不緊急的問題總結到一塊兒,用釘釘或郵件發送給師兄、師姐,待他們下班後統一解答
  • 其餘任何讓雙方「舒服」的方法

5.拒絕:

有些事情是你應該拒絕的,隨着業務發展,原先的實現確定是須要更新的,好比這期的業務,應該服務端打的補丁,在前端去打補丁顯然是不合適的,徒增團隊以後的維護成本,原則:學習

  • 假如原先設計自己不合理,那就應該是不合理的那一方去進行修改。
  • 單方修改好過雙方修改。
  • 出於長期的發展去決定。

6.不要浮誇:

對於公司項目而言,不要爲了炫技和盲目追求新技術而犧牲穩定性和易維護性,固然這不是讓你寫低效的搓代碼,而是在穩定性和易維護性知足的狀況下,儘量去提升性能。你寫出一個bug上線,基本是你leader幫你背的。。。。你leader可沒時間幫你一行代碼一行代碼看,而且有些坑是看不出來的。優化

7.樹立參照物:

去年的校招生和今年的實習生都是你的參照物,不是說鼓勵什麼比來比去的壞風氣,而是讓你督促本身,畢竟人都是有惰性的,沒有參照物是可怕的。

8.方案review:

在收到需求時,先本身設計一個或多個架構,而後去找你的導師定下方案,這樣會避免單向輸入,也能糾正不少本身自己的認知錯誤。千萬不要沒有思考就去詢問解決方案,這樣你會被鄙視的,畢竟你們時間都很寶貴。也不要作完了再去肯定是否合理。。。否則你到時候哪怕重構本身的代碼,也會讓你爆炸的。

最後,這可能不是指南,也不是指北,由於咱們每一個人都是不一樣的個體,他多是指向東南西北,最終決定你的是你本身的選擇,祝你們都能順利拿到本身滿意的offer,告辭~

相關文章
相關標籤/搜索