Pros
Company always seemed to be doing well financially, the idea of an insurance api is basic but a good one since it fills a gap until others catch on. Most people seem nice to your face. A couple of occasionally awkward happy hour events were interesting.
Cons
If you're a code masochist who wants to do things the hard way while you hammer out mundane ticketed work that is mostly already planned but never discussed outside of a pointing meeting, this place could be for you. However, you also have to be ok with dealing with very scrutinizing PRs to the point that if you follow their existing design patterns, they'll complain that you should have done it differently, but if you do it differently, they'll complain you didn't follow the current pattern. If you disagree, they will tell you that you’re being too controversial and ask that you apologize to the reviewer (also like victim blaming). It's frustrating to say the least and be prepared to write any single line of code 2 to 3 times over again during this process to try and figure out what exactly they are looking for as they will never directly tell you. On top of that, every service in their system is different so what's correct in one place is not correct in another, and even if you ask, you'll be told to figure it out or get widely different answers depending on who you talk to. They don't really want you to make waves here, that part of the job description was, in my experience, just all hot air and quite contrary to reality. They don't like anybody who disagrees with what's currently existing and wants to make improvements. You will never get to work on anything interesting (forget fun). They are set in their ways, many of which are the complete opposite from the rest of the python community making it sometimes hard to bring yourself to follow their poor habits, especially if you're an open source contributor who is used to dealing with community standards, it’s cringe worthy. Additionally, there are many code trust issues, like checking that what was just saved in the database, was in fact saved in the database, and I don't just mean as part of their massive integration tests, but actually in the running code. They will ask you for your advice on things, tell you it's a good idea and ask you to write up a ticket and put it into their "ideas" pile. I believe they do this just to try and make you feel like they value you so that you'll be more productive, but it's easy to see past that, especially when it inevitably just gets thrown into the archive a couple of days later. When you are inevitably given a ticket that cannot be completed because the system is technically not capable of doing it, you are made to feel like it's your fault for not being able to complete it. Even if you write up a body of work on what needs to be done to the system to make it possible, it's still your fault. They do not want to know about the shortcomings of their inconsistently duplicated codebase or ways to improve it, even though they ask. There is just no winning here.
