Pros
People have a sense of drive. There is a close-knit culture and you will meet good people here.
Cons
Summary: I don't recommend working at Zen. Their culture is a hive-mind ego. Developers don't care about quality, just quantity. This really isn't the place for any engineer who has worked in an environment with quality control. Having worked in various businesses, some much bigger than Zen and some smaller, I have yet to encounter as many live issues as what Zen experienced week in and week out during my first few months of being there. Long version: While the company having a close-knit culture is a good thing it also has negative effects. The main disadvantage is that, as an outsider, you feel very much like an outsider. Developers and architects at Zen have their own way of doing things and that often means reinventing the wheel. They believe that many of the problems faced by Zen are unique to Zen, "legacy software is a problem unique to Zen" (an actual quote I heard in a meeting) - as if there isn't an entire world out there. I ended up spending most of my (short) time as a care and maintenance developer at Zen patching up code that had poor test coverage and implemented only as a means of getting something out the door with very little consideration for quality. They've essentially flipped the testing pyramid upside down, focusing all of their efforts on the "Integration" and "End to End" testing and often neglecting unit testing - going so far as to reinventing the term "unit testing" to their own standard of "spec testing". Be prepared to see a lot of NullReferenceException errors. The release process is a case of using a developer controlled release calendar which only serves to inform others. I've seen database releases that changed data types get deployed straight to live. Botched software releases being rolled back quietly, often due to something a simple unit test would have detected. Moving away from the development side and into the analysis side; BAs will give you just enough information to crack on with the task but not enough so that you can implement exactly what is needed. If you attempt to deliver a solution then you'll be told it's wrong because of some detail that they coincidentally forgot to share. Typically I'd expect product owners to be the ones feeding this information to the team but they really don't. Product Owners are more of a middle person who don't follow the Agile manifesto and who disrupt the team at every opportunity while they pull stories in and out of a sprint. The Best Companies to Work For award doesn't mean much since developers admitted, in private, to lying on the survey to make the business look good and, furthermore, the business spends far too much time giving advice to other businesses on how to run shop successfully.