> Hiring bad people in engineering can cripple your services. Adding code that's hard to understand, has poor time complexity, or is over-engineered can add more technical debt that any one feature is solving for, and reworking that code can cost way more time than it originally took to write once it's part of some production service.
So use code reviews prior to merging, and prevent that code from becoming part of that production service. If they're then unwilling to incorporate that feedback into their code, it might be time to review their contract.
Edit: Assuming people are capable of reviewing each other's code.
Yes, of course. Problem is: senior supervision is a limited resource.
So even if you had perfect code review, you'd only want to hire people that produce code that actually makes it through the review with less hassle for the reviewers than it would be for the senior folks to write the code themselves.
In practice, code review is imperfect. You want to hire people with good taste and good skills.
The last place I worked, the junior engineers reviewed the interns code. There weren't enough senior engineers to review the junior engineers code, so we ended up reviewing each other's code.
I was pretty green at the time, so we just ended up with a terrible codebase after being there for a few years.
It was already bad to begin with, but that's because it seemed like what that company does is churn through junior engineers and interns at the nearby university to get their shoddy projects done.
TLDR: If you hire too many bad or junior engineers, you're going to lose control of your project since you might not have time to review all their code.
So use code reviews prior to merging, and prevent that code from becoming part of that production service. If they're then unwilling to incorporate that feedback into their code, it might be time to review their contract.
Edit: Assuming people are capable of reviewing each other's code.