> We need developers who understand that the code exists to serve the business and not for its own sake. You're absolutely right about that - there is always a

> We need developers who understand that the code exists to serve the business and not for its own sake. You're absolutely right about that - there is always a balance to be achieved between delivering a feature/product on time and writing maintainable / "good" code. What would be a red flag for me as an interviewee would be to see a codebase with poor standards, and then see pull requests open with code that wasn't any better. If the quality of the code is only getting worse that makes my life as a developer pretty miserable. Nothing is perfect but in my experience the difference between working with a well thought-out and architected codebase and something that has been hacked together as proof-of-concept is immense. Fewer bugs, fewer security vulnerabilities, the ability to deliver features faster etc. I don't think that code quality is just something for developers to pat themselves on the back for - it genuinely effects business outcomes.