You (Probably) Shouldn't Work at Fast Enterprises
Pros
The money is good, you get paid hourly for overtime, and you'll meet a lot of cool people and do some cool outside of work things with them. But those positives are almost weaponized because you don't want to let people that you're friends with down by not working overtime and getting things done. If you're making money for it, you might as well show camaraderie and work overtime with them. Also, the software stack is finally moving in a modern direction. C# will probably be more useful than VB.NET in your future endeavors, but you probably won't be doing cool things with coding. It's better than 5 years ago, at least. As a tech team member, you'll get pretty good at SQL (especially if you get assigned a lot of tuning issues), understand the basics of software architecture and enterprise level application management, and hone problem solving skills.
Cons
The main issue with my time spent there was the overtime. In the initial interview, I was asked if I was fine with occasional overtime (which I was), but in retrospect, "occasional" was doing a lot of heavy lifting in that sentence. About 8 months before a project starts to roll out, overtime will start to be encouraged from your project manager/team lead. And since everyone else is doing it... you'll find yourself sucked into it too. I got the whole "I can't require you to work more hours, but you should probably be working more hours" from my PM during a review, which is just terrible. You get paid your hourly rate for all overtime, yes, but if there is a necessity to work overtime across pretty much every team, then something is horribly wrong with the project structure as a whole. To compound this, the longer people stay with FAST, the higher the likelihood is that they'll be fine with working obscene amounts of overtime. This adds pressure to you as a new hire to do the same. It's easily the worst part of working for FAST. FAST does roll out mostly on time and on budget, which is definitely worthy of commendation, but the secret sauce is the after hours work of young professionals who don't know how to effectively set boundaries. Believe me, I was one of those. The software is another sore point. It's... not good. And everyone knows this at the company, but with commercial off the shelf software, you have to make some sacrifices I guess. (Side note: this isn't trying to discount some of what's in the application. The developers working at headquarters have done some pretty cool stuff, and kudos to them, but as a new hire you DEFINITELY won't be working there). As a new hire, you'll mostly be building out interfaces and filling out config for reference tables, while trying to gain enough of an understanding of the architecture to bend it to your will. It's not a good experience working with the software. For tech team specifically, the overtime issue gets worse (especially in the couple months before and after rollout). One year in, and I was easily working longer hours than my PM. Also, beginner tech team members are practically useless for the first 6 months to a year because not only do you have to learn the application and architecture, you also have to learn the solutions to site issues and get really good at frantic problem solving. To learn effectively, you have to have a really good team lead who is willing to put the work in to train you. I was lucky and had some good leads, but this is definitely not a guarantee. Tech team training mitigates this somewhat, but if new hire training is like catching water from a firehose in a teacup, tech team training is like trying to do the same at Niagara Falls.
