This illustrates something that many people in many disciplines, definitely including developers, do wrong in interviews: it's not just you interviewing with th

This illustrates something that many people in many disciplines, definitely including developers, do wrong in interviews: it's not just you interviewing with the company, it's the company interviewing with you. Just as you're asked probing questions about your technical skills, ask meaningful questions about the company's technical practices. Don't just let them interview you for fit, try and determine if they'd fit with you. It's legitimate to get a good offer and say "no, this is a place I wouldn't like to be." OP describes the tech stack of the company as interesting, which is great, but things like "PRs stay open for long periods with no review" and "extensive review is required before many changes" are things that can be learned by an inquisitive interviewee. And, as others have pointed out, gain respect before you try to make dramatic changes. Unless you're hired to make drastic change, your job is probably not to make drastic change. Especially if you lack domain knowledge (this was OP's first step into payments -- a technical area with complex business/legal requirements). Especially if you're more junior and haven't been around the block enough times to get a nose for what thins are more risky. 6 months is a long evaluation time, but a short time to get comfortable with a new codebase and stack, it's good to provide positive feedback but it's also easy to not be able to see _why_ things are they way they are, early on as one learns about a codebase. Sometimes things are crap because bad decisions, sometimes things are crap because tech debt... and sometimes things that look like crap actualy aren't, see https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-....