轉正指南｜實習生和試用期你要知道的那些事兒

團隊每年都會來實習生、新人，最后兩星期準備轉正串講時候都會感慨“轉正好難”，平時循規蹈矩做一些日常迭代需求，團隊也沒有給留出足夠的技術專案時間，PPT 里實在沒有可寫的東西，本文對轉正需要注意的事項做了一些梳理，供大家做參考，

轉正時候評委最在意的

實習期間的矛盾在于，大家既希望實習生可以廣泛接觸團隊的業務和技術體系，這樣在作業思維轉換和技術能力上都會有均衡的發展；又希望實習生可以 focus 在某個垂直領域，結合業務痛點深入研究，做出些個人特色的改善和突破，不少師兄在第一種思路上嘗試一兩星期后，在轉正的壓力下被迫用第二種思路培養實習生，甚至會有拔苗助長的現象，

現在回頭來看這種焦慮感下的“亮點”期望，既不現實，又沒必要，不現實是因為整個團隊在本業務深耕了幾年，實習生很難在短時間內發現比較明顯、并且可以小成本改善的問題；沒必要是因為自己作為師兄、主管參加過不少新人轉正，也做了幾次轉正評委，和大家交流下來，發現關于轉正大部分評委內心的評判依據是類似的，并不會不切實際的要求什么亮點，而更在意候選人的：

1. 技識訓本功

2. 技術思考力

這兩條乍一看沒什么特殊的，但重劍無鋒、大巧不工，在這兩個點上出問題會讓實習生的轉正會遇到評委的“刁難”，

1. 事情說的很清楚，你在其中的角色是什么？

2. 這件事情是你想做的，還是主管、師兄分配給你的？

其實這兩個問題是在核對上面的標準，不清楚角色是因為在闡述事情的時候沒有突出解決問題的程序、難點、應對之道，感覺是在侃侃而談別人做的事情，自己其實只是其中的一個普通參與者，整個闡述程序沒有提現自己的技術實力，第二個問題甚至會讓有些答辯的實習生情緒激動，代碼從頭到尾都是我寫的，不信我們來看看 commit 記錄，其實評委糾結的是候選人用了完美的方式把問題解決，兵來將擋水來土掩，更像是個團隊庇護下不錯的執行者，為什么做了這些正確的技術決策，其中的技術思考沒有體現出來，

方法論——轉正標準下的做事流程

我們經常會忽略大道至簡很多時候是因為這些道理聽起來毫無新意，甚至近乎廢話，這點不用多說，因為試圖繞過的時候總會發現處處碰釘子；還有一個原因是道理我都懂，依舊過不好這一生，很多道理需要方法論的指導才能發揮最大作用，業界也有很多成熟的方法論，比較好用的是 STAR

1. Situation: 可以理解為背景分析，做一件事情都有前因后果，分析出為什么當下需要做這件事情

2. Task: 明確整個事情的目標，既要有定性的目標，又要有定量的目標，做到整個事情是可衡量的

3. Action: 根據目標拆解出具體的、可行的執行策略和執行節奏

4. Result: 對結果復盤（總感覺應該是 Result & Review），有沒有完成既定目標，程序中有哪些技術沉淀

很多同學可能會困惑，按你這么說循規蹈矩、不需要亮點就可以轉正通過了？其實并不是這樣，轉正的程序是優中選優，自然需要候選人身上有些亮點，但我們需要的是人的特質導致做的事情出亮點，而不是參與了一個重要的專案，做的事情很重要就是有亮點，換句話說需要在看起來最平凡的事情上做出特色，體現個人技術實力和技術思考力，于無聲處聽驚雷，用個團隊最近的例子來說說我對轉正方法論的理解，事情的背景是這樣的：

團隊有個技術產品叫七巧板，可以不通過 Aone（發布系統） 發布流程將代碼片段同步到應用，很多同事利用這個特性將頁面上經常需要變化的內容做到了七巧板；同時七巧板提供了可視化的編輯界面，可以讓非技術同學通過填寫表單的方式把更新推送到應用，比如 Alibaba 首頁上的很多廣告內容是運營推送的，因為最近集團安全生產的要求，無灰度不發布，所以給新人安排了一個任務——七巧板接入 changefree（變更管控系統），

這種時候新人可以有很多做法：

我來把這個任務搞定

1. 了解七巧板發布的原理

2. 了解 changefree 接入方法

3. 設計實作架構、寫代碼

4. 配置 changefree 規則

5. 發布界面添加用戶提醒

6. 測驗

7. 通知七巧板用戶要接入 changefree，非視窗期變更要走審批流程

8. 發布

這看起來是一個無懈可擊的流程，但如果用這樣的思路做出來，作為轉正 PPT 中的一部分去講就會被評委問上面的兩個問題

這個事情沒那么簡單，讓我多想想

也可以換個思路這么做，在開始動工之前思考幾個問題

1. 整個事情的目標是什么？

2. 我的用戶是誰？

3. 他們的訴求是什么？

如果我們這樣思考了很容易發現第一種思路做事情的問題，我們的目標明顯不是七巧板接入 changefree，這是策略，我們的目標是保障七巧板發布的穩定性，做到安全生產，雖然任務交代下來是接入 changefree，這是師兄想好的應對之策，那么我們應該系統的思考一下七巧板不穩定的因素還有哪些？接入 changefree 解決的是哪個問題，其它問題嚴重性如何？當下要不要解決？最起碼可以還原師兄策略的分析程序，映射到上面 的 STAR 法則可以對背景、目標做到清晰的認知，來指導策略的設計，回到執行策略，接入 changefree 是個明確的 action，解決了安全生產的問題會不會有什么副作用？上面提到了發布界面添加用戶提醒、通知七巧板用戶要接入 changefree，非視窗期變更要走審批流程，這就是其中的一個考慮，但是否全面？我們可以從用戶的角度分析，我們的用戶是誰，他們的訴求是什么

1. 開發：經常對非功能、bug 的修改快速發布，我們做了上述的修改后開發的訴求仍舊可以得到滿足，非視窗期走審核流程雖然會讓發布程序受阻塞，但根據安全生產要求也是合理的，

2. 運營、PD：可視化修改，快速把廣告、營銷內容推送上線，看起來仍舊滿足，但仔細一分析是有問題的，因為出了常規時間的封網，很多封網是因為大促導致的，而大促期間正需要對廣告、營銷內容頻繁修改，

這樣就會發現我們的策略其實是有漏洞的，針對這部分用戶的訴求我們可以在做分析，這部分用戶修改的代碼是固定的，只是坑位的素材發生變化，風險是很低的，我們可以簡單得出一個針對策略，

1. 封網期間對代碼級別變更鎖定，可視化內容可以通過一次申請免走審核流程，或者僅僅是主管審批；

2. 發布內容接入自動化測驗保證發布質量；

雖然事情可能不會當下就去做，但可以體現個人在其中的思考，前面也提到整個的目標是安全生產，那么梳理出七巧板不穩定的因素及后續的計劃也是合情合理的事情了，并不是只有落在 Gitlab 中的代碼才能體現技術實力，做合理的決定往往是技術實力和技術思考力的綜合體現，

技術思考力

很多同學對技術思考力這個概念覺得抽象，我對技術思考力的理解是：面對一個問題的時候可以去思考：

1. 這是不是一個問題？現象的背后真正的問題是什么？

2. 這是哪個環節觸發的問題？這是哪個環節造成的問題？

3. 有哪些手段可以修復問題？有哪些方法可以根治問題？

4. 這些手段和方法的可行性、優先級是怎樣的？

5. 方案會不會帶來副作用？應該如何消弭？

才開始作業時候有個習慣幫助我很多，我經常會試圖揣測這個問題如果是我師兄、主管會怎么分析，他們會做怎樣的決定，我對每個層級的理解是 P5 解決問題、P6 發現問題、P7 定義問題，P8 可能是創造問題吧，展開一些理解大概是這樣（僅代表個人理解，不代表官方定義）：

• P5：事事有回聲，交代的事情干凈利落做完，對既定方案、流程有自己的思考；

• P6：獨當一面，可以獨立負責業務專案、改善技術流程，并且對相似問題有一套方法論；

• P7：領域專家、輻射上下游，某一類問題到自己這里終結，領域方案對上下游作業流程都有改善；

• P8：兩年后我再總結；

小結

總結而言按照 STAR 法則思考自己手頭的任務，把任務轉為，尤其要注意目標和策略的制定（很多同學容易混淆這兩個概念），然后在程序中注意多思考我們的用戶是誰，他們的訴求是什么，可以幫我們完善策略，

小技巧——預期管理

周報的重要性，一個十幾人的團隊主管很難有精力面面俱到，了解所有人每天的細節，給大家找出合適方向和機會，很難做到你有一個不錯想法的時候主管恰好找你聊聊，很多同學的周報極其敷衍，就是一周的流水賬，發送出來都是浪費自己和收件人的時間，團隊不會有人認真讀完所有人的周報，取決于周報的質量，實習生在這個問題上要比正式員工更注意一下，畢竟正是員工的考核是半年一次，還有路遙知馬力的機會，而大部分實習生的的實習期只有兩三個月，和主管的主管溝通的機會幾乎只有（雙）周報，為什么周報這么重要呢，在上面文章中也提到過向上管理，對于實習生而言最重要的是做好對主管的預期管理，在作業中很多時候我們羞于說出問題、表達個人意愿，怕老板覺得自己能力不夠或者太自大，但很多時候問題就出在主管對你、做的事情沒有預期，出現任何風險都會覺得是突如其來的刺激，如果總是出現心理預期偏差，就會懷疑你的作業能力，無法對作業進度和風險進行有效控制，所以一定要管理主管對自己的預期，做到

1. 資訊透明：程序預期
2. 風險預警：風險預期
3. 建立信任：結果預期

做到這些主管會給你安排他認為最合理的作業，也會及時幫你解決風險，可以在短暫的實習期間做出更大的價值，

如何反擊“這不就是參考了一個包嘛？”

實習生轉正、專案總結、晉升答辯，這個句式也許后面要聽數十次，每次都特別委屈，我明明做了那么多，怎么就得到一句這種評價！前面也提到了評委經常會問的兩個問題，這句話就是兩個提問的綜合體，說是反擊，首先我們要意識到一個問題，當評委問出這句話的時候，說明我們的述職程序就已經出了問題，我們最好的反擊不是針鋒相對，而是做好前期作業，讓評委問不出這句話，前面提到了 STAR，一般情況下評委問是因為我們講背景和結果用的篇幅過多，講目標分析、策略執行篇幅太少，又讓我想到團隊的一個例子：

一次大促上線第一天 PD 看到我們的會場頁面多語言表現問我，謙行，我們頁面為什么有的做阿拉伯語鏡像反轉、有的沒做，有的上面做了，有的下面做了，你們如果資源有限，是不是可以做的統一些？

面紅耳赤，和團隊一位新同學討論了一下方案，最終選定了自動構建 RTL 版本的 css 代碼解決，業界有一個 rtl-css 的包非常好用，新同學了解了一下接入方式之后，修改代碼構建器等前前后后忙活了很多，然后完成了任務，寫轉正材料時候卻犯了難，評委還沒問自己都感覺就是用了業務的一個包，沒有技術亮點呀，

遇到這種困境我們可以問自己幾個問題：

• 當下業務有很多問題，為什么這個問題要現在被解決？

• 問題有多少種可行的解決方案？如何做出選擇？

• 選的方案有什么副作用，如何應對的？

我們重新盤點了一下支持阿拉伯語、希伯來語鏡像反轉的方案

看到這里是不是感覺有些亮點了

1. 最有技術含量的 LTR 代碼識別、轉換作業確實是用業務 rtl-css 包實作，但不是有了這個包才有的方案，而是我們制訂了方案，這個包滿足我們的訴求，可以節省我們的時間才被用到；

2. 我們不僅僅是解決了構建問題，還考慮到了老代碼升級、自動構建逃生入口、開發一鍵預覽對比、更快的 RTL 判定渲染等方案，這是一個完整的、考慮周到的技術方案升級程序；

純技術難度可以作為答辯的亮點，做事情思路和執行程序也可以，從某種意義上同樣重要，候選人可以舉一反三做好后續作業中每件“小事”，這是個回擊質疑的簡單方法，僅在轉正時候用是投機取巧；而在日常作業對待每個平凡的小事都如此思考、行動，不去絞盡腦汁去挑選在聚光燈下的大事才肯用心做，那這就是個人特質，天道自酬勤，

指北——最常見的誤區

雖然不能確定上面說的是對的，但我知道怎樣肯定是錯的，也看到過太多實習生前赴后繼往深坑里跳，

沒頭沒尾的總結規劃

所有的轉正、晉升、專案等 PPT 中最后一部分都是一樣的——總結規劃，說明這是個很重要的步驟，PPT 最后需要有規劃大家都知道，但很多同學在平時做事情的時候會忽略這個環節，事情做完了就是做完了，沒有下一步的規劃，立足當下，著眼未來這反而是最能體現一個人技術思考力的部分，平時做事情、專案少了這個環節實在可惜，說到轉正 PPT，規劃總結應該是繼往開來的，而不應該是沒頭沒尾，見過不少實習生最后一頁 PPT 是類似的模板：

1. 深入了解業務，可以獨立負責 XXX

2. 學習 React、Spring boot

3. 深入理解 NodeJS、MySQL，成為領域專家

我們看選秀節目，評委問你的夢想是什么，從來不會有選手直接說：我的夢想是成為明星，你看到這樣的回答都會覺得不切合實際，大部分回答是這樣的：

1. 我有多慘、多不容易（背景 & 問題）

2. 但我多喜歡音樂/舞蹈，我希望 xxx 為我驕傲 （愿景）

3. 我要做更好的自己（升華主題，互相成就）

不是要大家學習套路，而是說沒有來龍去脈的規劃會讓人疑惑

1. 他為什么會這么想，有這樣的規劃？

2. 達到這樣的目標后會怎么樣，對團隊、業務的影響是什么？

大家可以換位思考一下，今天我們是轉正評委或者公司的老板，實習生規劃是要做 NodeJS 專家，是不是有點太遠？一個理想的模式（模式，不是模板、不是套路）應該是我當下面臨的問題是什么，我看到未來業務、團隊還有哪方面的挑戰，我能力方面還有哪些不匹配的地方，所以我想怎樣，然后希望能帶來怎樣的改變，

我只是個新人

謙遜是一種美德，但初入職場不要因此把自己姿態放的太低，無論是外包、實習生、試用期，當加入團隊的第一天就是這個團隊的一員，團隊每位同學都有幫助團隊變得更好的責任，當然這很難，從學校切換到職場，了解當下團隊的作業流程 & 業務需求已經讓人很頭大，如何有精力和能力幫助團隊？這里面有些核心的原則，也有些簡單的方法，

• 態度和決心至關重要，力量再薄弱，這個團隊可以也必然要因我而變的更好，

• 關心團隊同學在做什么，遇到了什么困難，是不是自己也似曾相識，也許自己可以做些什么，

• 不要對已有的不合理妥協，也許不是因為我很菜，而是事情本不合理，只是其他人忍受了，而我不想，

• 很多東西我不懂，但自我以后這些問題不需要再問人，

• 完善新人檔案，業務概要、開發環境 & 工具、打點 & 資料報表等，記得第一天自己的手足無措的樣子，不要讓師弟師妹再經歷一輪，

• 整理專案 README，讓專案拿到 project 地址要的東西就都有了，想象一下技術交接時候，告訴交接人：你需要的一切都在代碼 & README 資訊里面了，

Everybody matters, every step counts.

完成任務心態

很多實習的同學在實習期間對自己的作業表現很滿意，但到了轉正的時候被評委說的要哭出來，很大程度是因為把按時完成任務作為滿分的標準，有任務的時候很投入，沒有任務的時候會覺得清閑，一定要知道完成交代的任務從來不是滿分，是及格！及格不是團隊對實習生的期望，大家希望實習生可以發揮主觀能動性，自己看到問題、想出方案、甚至在某個問題上找主管索要資源，不是要大家加班，但希望大家自己覺得很充實，理想狀態是整個銀河系要去拯救的感覺 ~~

最后

轉正串講不是一場考試，也不需要我們把做過的事情羅列一遍，重要的是通過幾件事情讓評委了解自己是如何發現、分析、解決問題的，在團隊幫助下理清楚思路，相信對后續的職業生涯都會有很大的幫助，

作者 | 謙行

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/What-you-need-to-know-about-interns-and-probation.html

標籤：其他

上一篇：如何選擇好的軟體測驗技術？

下一篇：SpringBoot內置tomcat啟動程序及原理