今天聊聊小公司程序员如何进入向往的大公司这个话题,最初接触这个选题的时候,我也想了很多,这应该也是很多身处小公司的程序员朋友关心的话题。当然并不是人人都想进入大公司。
不过对刚刚毕业几年的程序员朋友来说,进入大公司锻炼还是很有吸引力的,就好比上一所好大学,是让履历更闪光的一种方式。
而且在大公司和小公司做程序员有完全不同的体验,代码标准、管理方式、发展阶段、资源等,影响着程序员们的工作内容和忙碌程度,以及最终获得的收获和感悟。不少程序员朋友表示,小公司跳入大公司太难了,为什么难呢?
归根结底因为大公司和小公司用人要求不同。对待应届生上,大公司仍然有着严苛的面试流程和要求,不一定要求应届生掌握多少编程技能,更看重应届生的学历背景和发展潜力,当然有名企实习经历,把握更大。
在社招上,大公司除了严格的工作年限要求外,在项目上要求你有成功案例,并且是该项目的主导者之一,而不是打酱油的,这也是为什么在外包公司和一些没有个人发挥空间的小公司做程序员很难符合大公司标准的原因。
明确了这些之后,我们聊聊小公司程序员从哪些方面突破,进入大公司的把握更大。
把握跳槽最佳时间
如果错过了校招,那么工作3—5年是进入大公司的最佳时间点。经过几年的经验积累,你已不同于应届生,在技术上能独当一面。这个工作年限的程序员朋友是大公司社招的主力。
如果年限再长一点,年龄偏大,技术水平如果没有同等的提高,反而更难进入大公司。
以BAT中的阿里为例,近几年社招的门槛明显提高,开发岗位一般 P6 起招。还是会看毕业院校,通常不会问太多的基础问题, 更看重技术的深度和行业经验,也会涉及架构问题、面试者的沟通能力、逻辑性、发展潜力依然是十分重要的考量。如果工作7、8年以上,就要求达到 P7 及以上了。
大公司看重年龄与自身能力的匹配度。面试工作 3 年的候选人要用工作 3 年的标准,面试工作 6 年的候选人要用工作 6 年的标准。
工作 6 年的候选人如果只能达到工作 3 年的标准,说明没有积累、培养潜力有限,大公司一般是不会要的。小公司的业务简单、挑战小,个人成长慢,可以说工作越久越难跳槽大公司。
提升学历,简历更好看
大公司对候选人的背景一般有比较高的要求,名校毕业、名企工作、履历光鲜的候选人更容易获得青睐。
虽然没有明说,但大公司在招聘中常常过滤掉没有本科及以上学历的候选人。如果你还没有本科学历,建议通过多种渠道提升下学历,最好是 211 及以上的学校。如果有可能,最好读个名校的全日制本科或研究生,这样可以回到应届生身份重新冲刺大公司。
曲线救国战略
平台对个人成长至关重要,小公司待久了可能能力会一直停留在一个尴尬的水平无法继续提升,从小公司直接跳槽到大公司还是有一定难度的。所以可以采用曲线救国的方式,比如你是在一家小公司做电商,可以先跳槽到美团、蘑菇街一类的公司,再跳槽到京东、阿里这样的大公司会更容易。
工作了多年却水平有限,实际上不一定是个人的问题,可能是毕业后进了小公司或创业公司,平台太小导致能力提升有限,但是在大公司眼里,这个人就是热情不足、潜力有限招聘要慎重。不妨中间先跳一家中等规模的公司,锻炼几年提高能力,然后再谋划进入大公司。
提升技术的深度和广度
钻研框架和类库
在小公司往往一个人做很多事情,技术的广度甚至比大公司的程序员还要好,但是很多人面试失败却败在了深度上。在面试中常常发现候选人对框架和类库的理解仅仅停留在使用阶段,甚至连使用都用不明白,对框架和类库没有深入的理解,在技术选型和方案确定上就无法做出科学的评价,也侧面说明了候选人技术热情不高。
做技术总结
无论如何,一定要养成总结技术的习惯,并且坚持下去。总结技术有很多种方式,可以写博客、公众号、技术文章。写文章时候一定要认真反思和总结,尽量输出自己的观点和感悟,通过写文章达到深入思考、融会贯通的目标。
做个人项目
开源项目是很好的学习素材,集中了很多优秀程序员和架构师的智慧,参与开源项目可以快速提升技术水平。如果没有合适的开源项目可以参与,也可以做一些个人项目。做个人项目不以盈利为目标,在公司项目里用不到的新技术都可以加入到个人项目中,反复修改代码提升项目质量,要把它当做一个提升个人技术水平的项目来做。
提升对业务的把控能力
大公司社招时一般都比较看重项目经历,交流项目已然成为面试的重点话题。
面试者在小公司要达到主导项目的水平项目一,对项目有整体的感知,了解产品经理、项目经理、测试都在做什么,要能对技术选型、架构设计、实现方案、业务流程、存在的问题有清晰而全面的认识。
做项目时候,要主动思考,发现并解决项目存在的缺陷确保业务稳定。在不断完善项目的过程中,你的能力能够大幅提升。
面试官会问一些自己平时遇到的业务场景的问题或者追问候选人项目的边界条件,来考察候选人的思考能力。这样的问题本身不难,但小公司的程序员面对的业务往往都比较简单,很难遇到面试官提到的问题,很多人这个时候就会支支吾吾答不上来。平时工作中一定要多思考业务,多问几个为什么、怎么办,有自己的思考和感悟。
提升技术技术栈
推荐一套大型互联网java程序员进阶架构师最全新的知识体系导图,对于才学基础的朋友可能用处不大,我相信对于开发多年的朋友这六大模式帮助会很大,对于这六大模式我也总结了一些架构资料和面试题锦集及答案还有完整的知识体系导图提供。(“没有时间”都是假的,也许你每天多0.01的努力,将是你以后超越无数竞争者的动力来源)
开源框架解析
![image.png](https://static.studygolang.com/190111/58d4cb531c601ba72f122b472c422e7b.png)
很多人面试阿里失败就败在原理上,只知其一,不是其二,稍微问的深入一点就答不上来了。理解原理就是理解 SSM 框架的灵魂,这也是一个程序员从体力劳动进阶到脑力劳动的门槛。
不理解原理只能做写代码的工具,理解原理才能成为真正的开发工程师。多思考、多总结、多请教,保持好奇心,多问一句是什么、为什么,才能探索到框架的奥秘。
试着去写一个简化版的 spring,实现 IOC 功能,你就会发现真 TM 难。泛型、容器、反射、注解、设计模式、重构等都会用到,通过设计框架,能够深刻地理解这些 Java 特性和框架的设计原理。如果你还没有写过框架,尝试着写一个吧,边做边思考,好好体会下框架的秘密。
架构筑基
![image.png](https://static.studygolang.com/190111/297311a259cc92bc118ef089ec7e96b2.png)
性能优化是程序员必定要考虑的。当系统架构变得复杂而庞大之后,性能方面就会下降,一名优秀的架构师,在性能优化上是必定是做的很好的。
所以性能优化专题从JVM底层原理到内存优化再到各个中间件的性能调优,比如Tomcat调优,MySQL调优等,让你洞悉性能本质,全面认识性能优化,不再只是旁观者。
高性能架构
![image.png](https://static.studygolang.com/190111/c5156cdc62ca4509d313fa38aa4280fd.png)
透彻理解高性能架构的好处和优点
必然性,适应市场需求,能够去找一些更大的平台发展,提升自己的综合技术能力和薪资。
了解从传统架构到分布式架构演变过程所带来的技术变革,将理论和实战相结合,透彻理解分布式架构及其解决方案。
从分布式架构原理,到分布式架构策略,再到分布式架构中间件,最后在加上分布式架构实战,让程序员可以在技术深度和技术广度上得到飞跃的提升,成为互联网行业所需要的T型人才。
微服务架构
![image.png](https://static.studygolang.com/190111/2567ad0cd730544769ec502d9d5376ee.png)
随着业务的发展,代码量的膨胀和团队成员的增加,传统单体式架构的弊端越来越凸显,严重制约了业务的快速创新和敏捷交付。为了解决传统单体架构面临的挑战,先后演进出了SOA服务化架构、RPC框架、分布式服务框架,最后就是当今非常流行的微服务架构。微服务化架构并非银弹,它的实施本身就会面临很多陷阱和挑战,涉及到设计、开发、测试、部署、运行和运维等各个方面,一旦使用不当,则会导致整个微服务架构改造的效果大打折扣,甚至失败。
团队协作开发
![image.png](https://static.studygolang.com/190111/9ff75931e3f0b17ef9c645f7cc3f52d8.png)
一名优秀的架构师必须有适合自己的兵器,也就是工欲善其事必先利其器,不管是小白,还是资深开发,都需要先选择好的工具。工程化专题的学习能帮助你和团队提升开发效率,让自己有更多时间来思考。
B2C商城实战
![image.png](https://static.studygolang.com/190111/2e1969c89f1cafe6421b32c8bb78dada.png)
欢迎工作一到五年的Java工程师朋友们加入Java高级架构:617912068
群内提供免费的Java架构学习资料(里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料)合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!
总结
从小公司进入向往的大公司,说难不难,说简单当然也不简单,归根结底是要提高个人实力,英雄不问出处,如果你实力足够强,就算学历背景、公司背景一般,也没有哪家大公司会拒绝你。
有疑问加站长微信联系(非本文作者)