The point is not to take a certain amount of time but rather to make sure the code meets your quality standards. Take as much time as this needs.
This is fine if you have time. But between managing people and doing some tasks yourself, it gets very difficult to give code the proper time to review.
That's a risk you have to weigh up against the cost of hiring more developers, or other ways of reducing/spreading the load.
There's no magic "I've done enough, so it's not my fault" number someone else can give you.
For interns, they might not know when to ask for review, so you might need to check in on them once a day.
Or that the feature branch is too big (break it into smaller changes).
Or it wasn't well designed before coding started and now you're doing CR & design review.
Or you're arguing about style/best practices and your team needs to establish coding standards.
Or ...
"In practice, a review of 200-400 LOC over 60 to 90 minutes should yield 70-90% defect discovery. So, if 10 defects existed in the code, a properly conducted review would find between seven and nine of them."
https://smartbear.com/learn/code-review/best-practices-for-p...
My approach is I start by giving them simple tasks to get comfortable. I have them pairing with more experienced folks to get hang of the teams approach. I engage them in discussions, making sure they have solid foundation for what they're working on. In my case for Enterprise app, that's making sure they really understand OOP, Making sure they understand interface and composition over inheritance, making sure they understand SOLID principles.
When it comes to code, I talk a lot about design. We can take a problem and solve it 5 different ways, and weigh the pros and cons. Sometimes there's no best way, and what's more important is understanding your approach and why. You might want to optimize for shorter development time, or for faster code execution, or for extensibility or for reliability and they all require different things. What is the current constraint of our situation calling for? Sometimes we can take the same code and rewrite it over and over in different ways till we are sick of it.
My goal with interns is to make sure they understand the fundamentals, and then to realize that there's truly a hundred ways to skin the cat, and not to run with the first solution they think of. I don't really like the review over software, other team members can do that, but I prefer to pair and we just talk casually and share screen while we talk about the code. If what they did needs a completely revamp, I might give them a pseudocode and send them off after discussion.
I make sure they understand that code is a small part of it. Did they capture the WHY of the code? Did they test? What type of test? unit? e2e? stress? Did they document on how to test/run their code? Did they write documentation?
Your code review must match up to your documented code guidelines, I show why our approach is in alignment with our guideline. You can't review without a guideline. The end goal is to have someone that will eventually become a very productive team member.
In the beginning, spending 2-4hrs is not far fetched for me. It all comes down to their strength and prior background. Good luck to your interns.
On my team all code is reviewed by at least two peers and I find it difficult to not review changes. Sometimes people screw up requirements (or they were unclear and the developer is unfamiliar with the existing implementation), sometimes their variable names suck, or the level of abstraction is inappropriate, or the tests say they're testing one thing but really do another.
On larger code changes this can be up to an hour or two a day (depending on how many are opeened) but I see it as an investment in the health of our codebase and avoiding technical debt.
Assume you're going to need to read all their code as you're likely going to be responsible for passing it (they're only interns). You could pair up, but make sure you still document any questions you have with the code. Systems like Bitbucket are great for commenting against the code and maintaining a record.
If it impacts your own productivity address that with your manager so they know why and how much. Give them the opportunity to direct you on how much time you should spend.
Don't fix anything or write code corrections yourself, don't waste time if it's clearly unreadable and unmaintainable. Question their code and let them figure it out themselves and you'll find you can get through reviews quickly and effectively.
And if you see some great code - acknowledge it!
How much of a concern is it to let "bad" (ugly, not in keeping with the rest of it) code into the codebase?
When reviewing code I prefer to ask questions. - Would a switch statement be better here than a nested if/else? - Would this code be better if it was split into smaller logical chunks? - Should this code be over in this library rather than here?
You give them the opportunity to think about it, justify their decision if it's 50/50, and own the changes.
These are generally questions about re-usability.
What works for us:
* specs (rudimentary ok)
* design review (saves rework)
* including test methodology and results in the merge request (saves rework)
* code review before accepting merge request
You could use build agents to automate and review (static analysis) of code upto a considerable extent!