剛好待過一個大公司(上萬研發人員)和一個小公司(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
