Make failing part of the process. Test Driven Development for example is failing first (all tests fail), then fixing it. Making prototypes is a way to fail early in the process, so when you start to make the real implementation you already tackled various mistakes. Write software in such a way that failures are expected, so that you handle them. Chaos Engineering is good example of this. Write clean code, have useful debug logging, etc. Once something fails, you'll be able to take care of it quickly as it is easy to diagnose and fix.
Even when beginners do all this, it will all be visible. But eventually you do these things with enough grace that it looks like you meant to do it.
Remember, nobody has ever written a perfect program, and you are unlikely to be the first. If a company cannot accept this, then get out!
Make failing part of the process. Test Driven Development for example is failing first (all tests fail), then fixing it. Making prototypes is a way to fail early in the process, so when you start to make the real implementation you already tackled various mistakes. Write software in such a way that failures are expected, so that you handle them. Chaos Engineering is good example of this. Write clean code, have useful debug logging, etc. Once something fails, you'll be able to take care of it quickly as it is easy to diagnose and fix.
Even when beginners do all this, it will all be visible. But eventually you do these things with enough grace that it looks like you meant to do it.
Remember, nobody has ever written a perfect program, and you are unlikely to be the first. If a company cannot accept this, then get out!
Ooo I understand. Thanks for your advice