写这篇文章的时候，正值金三银四招聘季，整个市场处于极度活跃的状态，很多程序员同学都加入了跳槽大军，自己身边也走了一些老同学，来了一些新同学。

步入职场三年来，见证了很多优秀的同学从入职到转正、到晋升，当然也观察到一些运气不那么好的同学没能顺利通过试用期考核，有的三个月试用期还没过一个月就被主管辞退，有的三个月延迟到六个月之后还是没能通过考核，最终遗憾离开，没能拿到那个珍贵的正式员工入场券，只能再次找新的工作，让自己再次陷入短暂的经济恐慌和焦虑之中。

我相信每一个能拿到offer的程序员，一定是在面试和笔试的过程中表现出来了自己的技术实力的，至少在当时是被面试官和HR认可的，那么为什么有的程序员在试用期却没能表现出真正的实力，没能让考核者再次在转正考核表上签字认同呢？

有人说面试官也有看走眼的时候，这句话有一定的道理，但是很多公司不止一个面试官来面试同一个人，所有的面试官同时看走眼的机会不是太大；其实我更赞同下面一种看法：很多被面试者都有高超的笔试和面试技巧，但是这些被面试者在进入试用期之后，并没有意识到工作时需要的技巧和面试技巧是不太一样的，很多程序员同学短期内没能快速找到技巧来应对新的工作环境，导致最终遗憾离场。

下面我根据自己的一些经验和平时的观察，总结了几点程序员快速通过试用期并成功转正的技巧，希望这些技巧能给正在试用期或者即将进入试用期的同学带来一点帮助。

主动交流和虚心请教

把我们平时关心的技术暂时放在一边，先来思考一个问题：试用期我们到底需要做什么？

试用期本质上是一个新人尝试融入一个新团队的磨合期，这个过程主要是在大量的试错和磨合，最终目的是能变成团队中的一员，真正融入新的团队，让别人感觉不到你是个新人。现代社会运作的主流模式还是依赖于团队协作，不排除有些独立开发者单兵作战能力很强，但是一旦进入公司这种集体作战的场景，学会和团队成员一起有效协作是必须通过的一项关卡。

为了能够有效的和其他成员协作，我们必须去主动和其他成员交流，比如去主动和其他成员交流一些公司的日常、团队的工作习惯。也许你上家公司使用的版本管理工具是svn，新团队用的全都是git，你对git不是很了解，这时最好的做法就是向老同事寻求帮助，比如询问同事账号如何申请，新团队的分支命名有没有特别的要求和习惯等。

主动交流的同时也别忘了保持谦逊，也许你是技术大牛，那也请你先放一放你那作为技术大牛的臭脾气，业务上你始终还是新手小白。初来团队，保持对老员工起码的尊重。老成员比新人更了解业务，新人未来还会有很多不懂的业务和技术问题需要向老员工请教，以一个谦逊和感激的姿态向老员工请教问题，相信我，未来他还会帮助你更多。

据我观察，很多同学都死在主动交流和虚心请教这一点上，其中不乏所谓的技术大牛，最惨的情况是大家相互合作的时候争吵不断，新人固执己见，老人觉得新人不知改进，最后项目延期或者Bug不断。

短期内请面向KPI编程

是的，不是面向对象编程，也不是面向工资编程，而是最俗气的也是最切合实际的面向KPI编程。试用期不是你展现多么高超的编程技巧的时候，LeetCode刷了100道算法题，毋庸置疑，算法能力肯定会精进许多，但是这个并不能成为公司同意你转正的标准，其实你在准备面试的时候也刷了不少了啊，难道不是吗？

操作系统、数据结构、算法，这些是每个程序员都应该好好学习和训练的内功，但在试用期内我们并不能在这些方面有质的飞越，我的意思是这些都是重要但不紧急的目标，当前紧急而且重要的目标是如何在三个月内完成领导交代给我们的任务，这些任务就是我们目前最重要的KPI。

面向KPI编程是说我们这三个月的重心在于多去研究公司的业务，下面要接的Task需要用到哪些我还没掌握的技术，会涉及到哪些我还不熟悉的业务，这些技术和业务应该成为我下面重点掌握的目标。

有时候，我们之前的技术习惯也要适当地做出让步，比如新团队把驼峰命名法作为基本共识，你之前习惯的匈牙利命名法是不是可以暂时让位于已有的团队习惯呢？毕竟，这些习惯问题并不是对或错的问题，它只是一个习惯而已。别忘了，我们的目标是最终写出团队一致认可的可维护的代码，完成版本的迭代和上线，那些关于命名法的争执、Tab党和空格党的圣战就让他存在于论坛和影视剧里吧。

如果将来你转正了，或者更幸运的是你晋升了，你的技术影响力已经远远超出当初作为新人时候的技术影响力，那时团队的技术习惯可能就是你的技术习惯。

直属领导的能力认证超过一切

其实做到以上两点，基本离转正不远了，但是有一点可能是很多同学会忽略的，那就是做事过于积极，导致大包大揽，很多任务不分轻重缓急，大部分都完成了，但是大部分都完成的不够出色，总结原因就是没能和直属上级做好足够的沟通，对任务的优先级排序缺乏概念。

产品经理的需求程序员是要做的，这些需求对于产品经理来说都是至关重要的，因为那关乎他们的业绩；但对于程序员来说，不是所有的需求都有同等的优先级，甚至不是所有的需求都是必须做的，因为有些需求可能通过其他技术方案早就实现了，产品经理可能并不了解。

这时候，作为试用期的程序员，对于哪些需求该做，哪些需求不该做，哪些需求先做，哪些需求后做，要有个初步的判断，实在拿捏不准的，一定要向直属领导请教，直属领导往往也是系统的技术负责人，他更能准确判断各个需求之间的优先级次序，甚至更能准确识别每个产品经理之间的利害关系，再往大的讲，直属领导对需求的把握乃至于能站在公司的立场来做出最有利的决策。

试用期的程序员，请不要擅自做一些自己拿不准的决定，因为有些错误的决定，很可能会打乱你的直属领导对于整个系统的架构和部署计划，那些错误的实现在小处可能看不出问题，放在整个架构中可能就是一个败笔。在更糟糕的问题出现之前，请让你的直属领导（往往就是你们所在系统的架构师）知道你要做什么，让他及时制止你做出一些愚蠢的事情。

试用期的工作过程，是在向直属领导完成一次能力认证的过程，也是让直属领导更好地认识自己的过程。

别忘了，最后在你的转正考核表上签字的，是你的直属领导，不是别人。他对你的看法，决定了你的去留。