Pros
Disclaimer: I left FAST over 3 years ago so things may have changed since. Giving my retrospect after leaving and now working in big tech. - Decent compensation relative to low cost of living markets, and decent pay compared to entry level big tech positions if you are on a high cost of living site due to COLA; (e.g. MA, NY, HI, New Zealand, Finland—maybe more but it was generally frowned upon to share this knowledge). - Generally easy work but can be a bit mindless - Great opportunity to develop soft skills (not modern technical knowledge) - Pre-pandemic: many covered get togethers (dinners, lunches, happy hours, fun activities like rafting, camping, go karting with the team) - AGM (annual general meeting): covered few days of travel for a company conference each year (some past AGMS were in Mexico, Bahamas, Vegas, Orlando etc). Hotels and flights are covered (for you and a plus one). - Mostly great people (most of the folks I've met, I consider family to this day) - Paid overtime (OT also adds to your PTO balance) - 1 month sabbatical after 4 years of service (independent of regular PTO) - Paid medical and dental - Solid job if you want a ‘tech’ job without being a strong developer
Cons
General Cons: - Project based work; bad if you want to have a family or own property long term - Limited career and pay progression. Structure is flat; as a lead you won't get pay bumps; salary adjustments are based on performance/growth compared to your prior year. Alternatively, if you manage to become a director—IIRC, this is a 6 figure bump in salary. - Compensation is composed of base pay and relocation factor. If you don’t agree to relocation, you either lose the relocation factor portion of your salary which would likely put you below market average in pay (assuming there is enough work for the project) otherwise you lose your job. - COLA does not apply to non-engineering & non-project management positions (such as office admins) even if you live in a high cost of living area - Long hours (but depends on your project and site). I found this to be because deadlines and go-live dates are pre-determined by project management in advance rather than following an actual agile approach of adjusting targets as development progresses and complexities are better understood. The company prides itself in ‘always delivering on time and on budget’ (at the expense of its developers). Deadlines don’t change unless the client agrees to it (so it doesn’t get labeled as being ‘not on time’ or delayed). - Can’t choose project; You will be expected to move regularly and may have limited notice for when you need to move - Toxic culture. I confirm some of the negative sentiments mentioned here already: Bro culture and alcohol—may be shamed if you don’t drink. Harassment issues, had former trainers and interns complain about harassment from engineers, even had complaints about a former architect I worked with who left for another tech company. Tech & Conversion developers, (not all) but in general seem to come off as hostile towards subsystem developers. Technical Cons: - Limited transferable skills in general but depends on your site; if you are ambitious and aiming for big tech, your best bet is to leave by year 2. If you don't do side projects with modern stacks and frameworks nor leetcode regularly, you will have a tougher time finding another job post FAST as an engineer. - Code was split between ‘site’ (specific to your project), ‘core’ or ‘architecture’ (only engineers at HQ can touch core and arch) which limited the scope of your ability to implement or change functionality if you are a non-HQ developer. - No automated testing meant development was prone to bugs and regression and required tedious manual testing by the developers (projects do not have QE or SDET teams) - Version control is proprietary and didn’t have merge functionality thus prevented multiple developers from touching the same piece of code. It also didn’t have commit messages so no inline code history on the IDE which made adding verbose comments to code valuable. - Naming conventions were Hungarian notation and resulted in too long variables - No linting or prettier tools or configuration were used to standardize code - Typically, no freedom to use language or tools of choice. Everything built is expected to run on the existing stack. - Tech team: always on call - The software stack at the time wasn’t tested to be hostable on cloud platforms like Azure and AWS—IIRC we didn’t land a contract with a big client because we couldn’t guarantee it could run on Azure. Hopefully this has changed since. Also hoping there is R&D being to for leveraging Kubernetes and Containers which could guarantee the stack could run pretty much anywhere