>> How they can assume or think that two programmers going to solve the problem in "same" ... way!

It takes a lot of restraint and stepping back from being in "first-person developer mode" to understand that someone else's unique approach is quite likely valid. I purport to be able to do so but I still find it incredibly difficult to ignore my brain's initial instinct to start pointing out the supposed flaws in someone else's structure, when the simple fact is my own code for the same problem would probably be filled with the same holes - just in a different form.

Honestly, there are only a few metrics that really matter when it comes to quality code:

1. Does the code accomplish the task it's supposed to? I mean really, this is practically the only thing that really matters in most cases. Simply: if deployed, will it work?

2. Are there no glaring security problems with the implementation?

3. Does the code not excessively overuse resources (cpu, memory, network/system calls, etc.)? Real excess beyond what is reasonable, not micro-optimizing.

4. Is the code not a complete mess? No serial use of copy/paste, crazy spaghetti mess, or inability or blatant refusal to follow basic coding standards?

That's it. Deploy that shit, and move on to the next problem. ;)

This is exactly what I was thinking! The points that were written is just as what I had in mind. But I guess still your missing one important point on testing. The code should work if deployed, but at the same time, we need to have through testing for the same.

I always start with reading test cases rather than source code directly. Thats the way it should be (IMHO).

After experience with several junior developers I plan to do the following to train the next one. First, let them solve an isolated problem in our code base. At pull request step comment excessively (this is what inevitably happens with all junior developers, the PR is so huge that GitHub chokes on it). Finally, pair them with a senior developer to solve the issues raised in the PR, rather than letting them fix them alone and engage in an endless loop of commits and comments.

I agree - you very much need to learn the rules first, before you go and break them

This is really a good idea. I have seen this happen with several teams in my organization.

I've been the other side of this as part of the interview process.

One person we were interviewing solved a problem pretty much exactly opposite to the way that we (and every other candidate) had solved it.

At first glance it simply looked wrong, but after a discussion with the candidate the strengths of the solution became apparent.

Happy to say they got the job, and ultimately turned out to be one of our best hires.