I have been working for small companies for the past 5 years where the focus was on shipping the product fast and not necessarily on quality. I am now interviewing at big tech companies where the focus is on code quality and code scalability. I am concerned that even if I make it through the interview phase it will be hard for me to maintain my position after having bad coding practices for many years.
Why not just write better code at your current job?
A big misconception I understandably see a lot of engineers have is that in order to ship fast, you need to completely sacrifice quality. This isn't the case. There is generally an 80/20 rule when it comes to code quality where you can get 80% of the maximum quality for 20% of the total possible effort. This includes low-hanging fruit like:
These are all things that can be easily woven into your work, and it will bear time savings almost immediately. For example, if #1 isn't the standard across your team, each pull request will take days to review because it's gigantic. On the other hand, if people follow #1 and spend the extra 15-30 minutes making their pull request clean, they will save days on each review as it's easier to digest.
I was at Course Hero as their 1st Android engineer when it was just 20 engineers total. I moved extremely fast, yet I had a stellar reputation for high product and code quality.
Now I'm doing Taro which is even smaller and has to move even faster as a company. I still take the time to make sure that the code and experience are clean. Of course, I don't spend 3 weeks teasing out edge cases like I did at Instagram pushing code to 750 million+ users, but I still get 80% of the way there by covering the basic ones.
When it comes to resources, we have a ton! Check them out here (tons of examples included):
The best way to improve is from feedback, and since you're a professional SWE already, you have that. You'll get even more of that when you go from small company to big company.
Obviously, you'll learn from the code review feedback you get. But beyond that, spend 30 minutes each week looking at the code changes that sparked the most discussion (most comments/questions) on your team.
If you do this for 3 months when you join the new team, I guarantee you'll learn a ton about writing clean, reusable, and scalable code :)