Let's break this into parts.
Professional Development:
- You won't gain much knowledge or skill here. They hire you because you already have it, and they want to use you for it.
- They misuse and misunderstand a couple libraries & tech, so that you won't gain valuable experience with them. You'll have to learn to use them the right way if you go anywhere else later.
Creative Atmosphere:
- All creative decision making is handled by the management team. Any idea you have will likely be put off, added to the heap, and they'll sort through them as they have time. Any excitement or passion you have gets quelled by the process.
- Collaboration isn't really a thing there. Someone always goes off on their own, does a ton of work to design and plan something, usually in a google doc, and then the individual tasks get doled out to you. Some preliminary meetings may happen for like an hour. And most communication or feedback happens through low-bandwidth comments on the google doc. There's no on-going, close-knit back and forth development.
Management
- You'll be frustrated by the pedantic attention given to their project management software. There's an explicit, detailed procedure you have to follow for everything. Tasks are assigned to you outlining every step of your work that you are to follow and which are handed down by the management and product teams.
- When you're asked for input, you will also then spend an inordinate amount of time writing the aforementioned google docs describing, in detail, not only the interfaces that should be created in the solution but also all implementation details.
- They slow or deny the implementation of any technology that the CTO is not familiar or comfortable with.
Code Quality & Dev Ops
- You might expect that such tight control over the process maintains quality, but you'd be wrong.
- There is a ton of technical debt. You will wade through it in any project you work on. You'll want to refactor it, but you'll get the same answer every time that there's not enough time at the moment, they're just going to do it this way for now, and you'll circle back to it later. The result is the addition of even more poor code and technical debt: you'll have to work around the bad code, add conditions for old formats, etc. There's so much of it that, and so many committed promises encoded in it that they'll never get out from under it. You'll also likely wonder if they consider much of it as debt at all.
- This also as the added effect of elevating usually mundane implementation details to critical discussions that consume your time and give them the opportunity to reiterate the tech debt mantra of doing it later.
- The code base is not well designed at all. Nothing is fast, efficient, modular, or easy to read.
- Testing is non-existing. You'll push to production and pray your code works. And you'll get called out when it has customer facing consequences.
- They made a huge technical investment in YAML configuration files, so much so that there's a logic parser written around it so that they have their own proprietary YAML-based language. It's not easy to work in. It breaks a lot. You'll miss changes all over.
Leadership
- It's hard to tell where all the poor leadership originates. I think it was probably with one person in particular who micro-manages seemingly everything.
- They hold a TON of meetings
- They paradoxically value engineering time in that they want to minimize the cost of it, but so many technical decisions create more burdens on your time in the form of more bugs; multiple versions of code running in parallel; regular, ongoing maintenance tasks; and carefully monitoring logs.
- Software and the work that goes into it seems mostly treated as a means to an end. The mission is to achieve the end goal as quickly as possible regardless of impact on the team or their software assets.
Respect for Your Time
- Mostly, you'll likely feel like an oxen. You're there to grind away on their work, doing it their way.