刚好待过一个大公司(上万研发人员)和一个小公司(12个研发人员)。
先说下小公司的体验，总共就十二个研发人员，包括了硬件电路设计，PCB layout，FPGA，DSP，结构工程师，嵌入式软件程序员，PC软件程序员，还有元器件库管兼焊工。小公司就是把人当成劳动力在使，根据你的能力地图，你可能会同时兼职干很多事，比如我在入职一年中，前后搞了硬件电路设计、PCB layout、FPGA，嵌入式软件程序员这四个活，偶尔还要兼职一下焊工。这四个活里面，任何一门深入学习下去都能吃喝不愁，但是你根本没机会深入下去，小公司的编制就决定了不可能做成大项目。另外，小公司还有个严重的问题，在管理上太粗放了，很少有形成条例的管理制度，完全是靠领导的心情。而且很少有小公司能做到软件工程中的全系列编制，小公司的代码有个很大的问题就是欠测试，体现在客户手里就是质量不行，之前我所待的那个公司，好几个产品，在开发部完成功能开发，然后放那儿运行几天，如果没有问题直接把工程机拿到客户现场演示。
再说一下大公司的体验。首先，规章制度和流程正规了很多，根据流程你知道自己的代码要经过几个月的锤炼，这其中至少包括以下三个过程：(1)程序员的自验证和测试用例编写。(2)组织代码检视，这里代码检视的力度一般是根据项目是否紧张来决定。(3)发布版本交由测试进行测试，测试根据交付的功能在各种奇葩且变态场景下猛测几周。整个项目的周期在前面3个过程中反复，最终到客户手里的产品质量是相当的高。
如果用修桥来类比的话，小公司造的桥是这样的
大公司造的桥是这样的
ps:图片来源于网络，侵删。
面对不同的场景，两座桥都能工作，都能解决不同的问题。小公司的程序员由于经常要面对快速出活的问题，代码质量上考虑欠缺，整个功能欠测试。而大公司的项目周期较长，代码能够得到多人的审视和走读，并且得到充足的测试场景保证，质量较高。
最后，还有一些差别。小公司的程序员干的活比较杂，懂得较多，对整个产业链的东西总能东拉西扯说一堆东西。大公司的程序员对自身的业务代码特别熟悉，也钻研的较为细致，但是离开舒适区以后，感觉自身水平跟应届生差不多，这也是大厂程序员焦虑的源泉，总感觉自己的业务做得越久，市场竞争力越弱。
—————————————————以上为原答案———————————————
我在评论里表达了先去大公司工作，再去中等规模的公司，尽量不要去小公司的观点。
这其实挺矛盾的，如果你没去过大公司，你不知道大公司好在哪儿，不好在哪儿；没去过小公司，你同样不知道小公司的优缺点。但是有一点是可以肯定的，如果你的第一家公司是一个小公司，在你觉得公司的流程或制度不合理、不正规的时候，你根本不知道正规的流程该长啥样。
个人建议第一份工作一定要去一个上规模的大公司，就像念书的时候如果有机会一定要读一个好学校一样。至少，你遇到牛人的概率要远远大于去一个小公司。遇到一个大牛，受到他的影响，你便提升了视野。近几年，万众创业特别火，从BAT出来的工程师被各个创业团队疯抢也是这个原因。
评论里有人说，他去了一个几百人的公司，这个公司的流程也不规范。其实，几百人真不算大公司，最多算一个中小规模的公司。他还提到，中途接手一个项目没有文档，代码也没有注释之类的。
我来谈谈我所在团队的做法，我们只有架构设计说明书，这份说明书里面主要讲做这个架构的目的，上一代架构有什么缺陷不能满足现有场景，为了满足某某场景，所以重写了架构，接着详细描述为什么这样能解决问题，为什么要这样做。另外，代码同样没有注释，因为现在提倡的是 代码即注释 。所在部门发现，在技能传承的过程中，如果需要一份文档才能把程序或者某个函数讲清楚，那么这份文档还需要另一份文档来指导如何看这份文档。既然那这样，我们何不如让代码把代码的问题讲清楚。
为了做到代码即注释，代码检视是重中之重。小公司的代码即便有代码检视，可能也是检一些代码逻辑、可读性、内存管理等问题。举两个我所在团队代码检视的例子：
(1)场景如下：A和B两个模块都会去修改同一个数据D，如果A和B在同一个事务内都要去改D时，以A的数据为准，也就是说，当A不去改D时，B才能去改D。这时候，按照逻辑，需要为B模块定义一个变量could_modify，当A不需要改D时,could_modify为true，B才能更改数据。但是，在代码检视过程中，could_modify的语义很快就会被推翻，因为这只表达了B能不能改，并没有把A模块的语义表达出来。最后，我们将could_modify改为priority，优先级的意思才能准确表达该语义。
(2)场景如下：A模块会向B模块发送同步消息，如果发送失败，返回failure，发送成功返回success，并得到B模块返回的数据。常规实现是这样：函数返回值为bool变量，来标示是否返回成功，另外有一个参数response来保存返回值，如果返回失败，这个response为空，如果成功，response里面保存有返回数据。在代码检视中，会很快推翻这个常规实现，因为这没有准确表达出返回值的有或者没有的概念。最后，我们使用了optional(C++ 17)。
上述两个写法，并不是最优解，只是在时间允许的范围内做出的较优解，主要目的是想让代码看起来就自带注释。这是我在以前小公司不能学到，甚至不能想象的编码方式。当然，这个过程要花费大量的时间。
任何一个公司都是一个商业组织，公司的首要目的是商业上的成功，由于项目进度的压力，程序员必须在写好代码与按时交付之间做出妥协，当我们有选择的时候，无论你在大公司还是小公司都要好好琢磨一下自己的代码。
--------------------------------------------------2018年7月31日更新----------------------------
谢谢大家的赞，也感谢大家的讨论。
说说我对现在软件开发的看法。虽然前文中用了大桥来做类比，实际上，现在的软件质量远远赶不上大桥的质量。大家用的QQ，说不请哪天就闪退、崩溃了。用播放器看个电影，看着看着也崩了，搞不好，正在用word写着文档，windosw绿屏(蓝屏)了。
事实上，很多软件是不能崩的，崩了代价就太严重，比如发射火箭、无人车控制。最近炒的很热的5G，有一个应用场景就是无人车控制，假如无人车所连接的基站崩了，或者程序跑飞了，那后果不堪设想。
由于互联网行业的繁荣，软件行业就 朝着薪资更高，质量更差的方向发展了。互联网带来了太多快餐式的一锤子买卖，比如为店铺周年庆写的代码、为双11活动写的代码、为元旦期间活动写的代码。这些代码只需要稳定运行15天，甚至运行24小时就ok。夸张点说，即便上线3分钟就崩了也无所谓，有句话不是（ 服务器提了一个问题，我们正在紧张的撰写答案。。 ）。用户就是测试人员，有问题程序员再改就行了呗。互联网的发展，带来一个负面影响，就是明知有bug，暂时定位不出来，迭代周期到了还是发布给用户，反正出问题了再改就行了。我们老是diss自己国家的各种豆腐渣工程，事实上，我们要带着写代码的心态来搞工程，那还不如豆腐渣工程。
假如，一个基站程序的代码量是50万行，而双十一时候某厂服务器代码量200万行。基站商用以后是不能崩的，崩了的话后果非常严重，而双十一服务器即便你刷新50遍都是404也没关系，至少用户不会有经济损失。前者想要项目成功就需要那些流程、测试用例、代码检视等等以保证质量。而后者，虽然复杂度更高，但是后果都可控，有没有测试用例、代码检视完全看项目经理给不给程序员时间。
不过，允许程序员把bug流出到产品中，带来了整个软件行业的繁荣。这毕竟降低了门槛，给了大多数人(包括我)机会。
最后~
关于考研的问题与本题无关，请移步这里
哪些问题是考研前不知道考研后才知道的？ - 邦彦的回答 - 知乎
https://www.
zhihu.com/question/2694
29538/answer/376169519
