程序員如何快速通過試用期?程序員轉正申請書要怎么寫?寫這篇文章的時候，正值金三銀四招聘季，整個市場處于極度活躍的狀態，很多程序員同學都加入了跳槽大軍，自己身邊也走了一些老同學，來了一些新同學。
步入職場三年來，見證了很多優秀的同學從入職到轉正、到晉升，當然也觀察到一些運氣不那么好的同學沒能順利通過試用期考核，有的三個月試用期還沒過一個月就被主管辭退，有的三個月延遲到六個月之后還是沒能通過考核，最終遺憾離開，沒能拿到那個珍貴的正式員工入場券，只能再次找新的工作，讓自己再次陷入短暫的經濟恐慌和焦慮之中。
我相信每一個能拿到offer的程序員，一定是在面試和筆試的過程中表現出來了自己的技術實力的，至少在當時是被面試官和HR認可的，那么為什么有的程序員在試用期卻沒能表現出真正的實力，沒能讓考核者再次在轉正考核表上簽字認同呢？
有人說面試官也有看走眼的時候，這句話有一定的道理，但是很多公司不止一個面試官來面試同一個人，所有的面試官同時看走眼的機會不是太大；其實我更贊同下面一種看法：很多被面試者都有高超的筆試和面試技巧，但是這些被面試者在進入試用期之后，并沒有意識到工作時需要的技巧和面試技巧是不太一樣的，很多程序員同學短期內沒能快速找到技巧來應對新的工作環境，導致最終遺憾離場。
下面我根據自己的一些經驗和平時的觀察，總結了幾點程序員快速通過試用期并成功轉正的技巧，希望這些技巧能給正在試用期或者即將進入試用期的同學帶來一點幫助。
把我們平時關心的技術暫時放在一邊，先來思考一個問題：試用期我們到底需要做什么？ 試用期本質上是一個新人嘗試融入一個新團隊的磨合期，這個過程主要是在大量的試錯和磨合，最終目的是能變成團隊中的一員，真正融入新的團隊，讓別人感覺不到你是個新人。現代社會運作的主流模式還是依賴于團隊協作，不排除有些獨立開發者單兵作戰能力很強，但是一旦進入公司這種集體作戰的場景，學會和團隊成員一起有效協作是必須通過的一項關卡。 為了能夠有效的和其他成員協作，我們必須去主動和其他成員交流，比如去主動和其他成員交流一些公司的日常、團隊的工作習慣。也許你上家公司使用的版本管理工具是svn，新團隊用的全都是git，你對git不是很了解，這時最好的做法就是向老同事尋求幫助，比如詢問同事賬號如何申請，新團隊的分支命名有沒有特別的要求和習慣等。 主動交流的同時也別忘了保持謙遜，也許你是技術大牛，那也請你先放一放你那作為技術大牛的臭脾氣，業務上你始終還是新手小白。初來團隊，保持對老員工起碼的尊重。老成員比新人更了解業務，新人未來還會有很多不懂的業務和技術問題需要向老員工請教，以一個謙遜和感激的姿態向老員工請教問題，相信我，未來他還會幫助你更多。 據我觀察，很多同學都死在主動交流和虛心請教這一點上，其中不乏所謂的技術大牛，最慘的情況是大家相互合作的時候爭吵不斷，新人固執己見，老人覺得新人不知改進，最后項目延期或者Bug不斷。 是的，不是面向對象編程，也不是面向工資編程，而是最俗氣的也是最切合實際的面向KPI編程。試用期不是你展現多么高超的編程技巧的時候，LeetCode刷了100道算法題，毋庸置疑，算法能力肯定會精進許多，但是這個并不能成為公司同意你轉正的標準，其實你在準備面試的時候也刷了不少了啊，難道不是嗎？ 操作系統、數據結構、算法，這些是每個程序員都應該好好學習和訓練的內功，但在試用期內我們并不能在這些方面有質的飛越，我的意思是這些都是重要但不緊急的目標，當前緊急而且重要的目標是如何在三個月內完成領導交代給我們的任務，這些任務就是我們目前最重要的KPI。 面向KPI編程是說我們這三個月的重心在于多去研究公司的業務，下面要接的Task需要用到哪些我還沒掌握的技術，會涉及到哪些我還不熟悉的業務，這些技術和業務應該成為我下面重點掌握的目標。 有時候，我們之前的技術習慣也要適當地做出讓步，比如新團隊把駝峰命名法作為基本共識，你之前習慣的匈牙利命名法是不是可以暫時讓位于已有的團隊習慣呢？畢竟，這些習慣問題并不是對或錯的問題，它只是一個習慣而已。別忘了，我們的目標是最終寫出團隊一致認可的可維護的代碼，完成版本的迭代和上線，那些關于命名法的爭執、Tab黨和空格黨的圣戰就讓他存在于論壇和影視劇里吧。 如果將來你轉正了，或者更幸運的是你晉升了，你的技術影響力已經遠遠超出當初作為新人時候的技術影響力，那時團隊的技術習慣可能就是你的技術習慣。 其實做到以上兩點，基本離轉正不遠了，但是有一點可能是很多同學會忽略的，那就是做事過于積極，導致大包大攬，很多任務不分輕重緩急，大部分都完成了，但是大部分都完成的不夠出色，總結原因就是沒能和直屬上級做好足夠的溝通，對任務的優先級排序缺乏概念。 產品經理的需求程序員是要做的，這些需求對于產品經理來說都是至關重要的，因為那關乎他們的業績；但對于程序員來說，不是所有的需求都有同等的優先級，甚至不是所有的需求都是必須做的，因為有些需求可能通過其他技術方案早就實現了，產品經理可能并不了解。 這時候，作為試用期的程序員，對于哪些需求該做，哪些需求不該做，哪些需求先做，哪些需求后做，要有個初步的判斷，實在拿捏不準的，一定要向直屬領導請教，直屬領導往往也是系統的技術負責人，他更能準確判斷各個需求之間的優先級次序，甚至更能準確識別每個產品經理之間的利害關系，再往大的講，直屬領導對需求的把握乃至于能站在公司的立場來做出最有利的決策。 試用期的程序員，請不要擅自做一些自己拿不準的決定，因為有些錯誤的決定，很可能會打亂你的直屬領導對于整個系統的架構和部署計劃，那些錯誤的實現在小處可能看不出問題，放在整個架構中可能就是一個敗筆。在更糟糕的問題出現之前，請讓你的直屬領導（往往就是你們所在系統的架構師）知道你要做什么，讓他及時制止你做出一些愚蠢的事情。 試用期的工作過程，是在向直屬領導完成一次能力認證的過程，也是讓直屬領導更好地認識自己的過程。 別忘了，最后在你的轉正考核表上簽字的，是你的直屬領導，不是別人。他對你的看法，決定了你的去留。
