Was a good place to work. Too much bureaucracy
Pros
It's been a couple - PTO was solid - Pension, if you plan to stay here for a long time (I didn't) - Had two great managers, and worked with a lot of great people. This is highly variable at such a large company, but I feel I was lucky. - Very stable employment
Cons
- 401k was paltry - Pension was useless to me. I was not going to stay with the company long enough to vest. - Raises and salary are very stingy. - May work in aging tech that is not applicable anywhere else. - So much bureaucracy on the software side. Ultimately, I left for several reasons: 1. Pay. Even after multiple raises and a promotion, I was making less than market value. 2. Two words: Change Management. The sheer amount of process behind releasing software is maddening. There were efforts to improve this before I left, but it's not uncommon for something to take several months to make it to production. I simply could not deal with the hoops we had to jump through just to release something. There were "Release Engineers" (I can't remember the exact name) whose sole job was to help navigate State Farm's software release process, and a Change Advisory Board (CAB) full of some people who don't really contribute much other than adding even more steps to an already bloated process. The icing on the cake here was a member of a Devops team refused to be flexible at all during a first time deployment due to a mistake on some form. We were ultimately able to release that night due to a bug in State Farm's proprietary deployment software that allowed us to bypass a step. 3. Many upper level "Architects" haven't written code in 10+ years. These are the people, who haven't written a line of code since COBOL was the dominant language, responsible for making architecture decisions. 4. Very real possibility to work in old or proprietary tech that will not be transferable to anywhere else. When I started out, I worked primarily in Spring and Thymeleaf. By the time I left, SF had purchased some obscure Oracle product with its own DSL that was entirely database driven. Due to the above points, I was teetering on the edge of leaving, but as someone who enjoys writing software, I want to write software. When there was adoption of the Oracle product, writing any customizations required architectural approval. They basically wanted software developers that didn't write software. Shortly after the training and project started with this Oracle product, I left.
