[RoyGBivCap]

I think reviewing code is a much better method.

It's a real skill you'll actually employ. You're coming at the code cold, which is actually a realistic scenario you'll encounter on the job. Your ability to catch bad ideas and prevent them from getting literally codified is a valuable skill. And all of that is worthless if you're in a state where you can see a mistake, but are too afraid to speak up; this gets tested too.

It might not be so great for newbies and people fresh out of college, but even they should be able to read the code and discuss it.

[jkaving]

I agree, and this is what we have been doing for a while at my current job (I went through the same process, so it's been done for at least 7 years).

The candidate would come to the office (when we were still doing in-person interviews) and meet a couple of the developers for a little bit of chatting. They would then be given a couple of printed pages of Java code with a few basic classes representing banking accounts with some typical methods for depositing, withdrawing, persisting to a database etc. (with all of the details stubbed out) - and they would be given these instructions:

  Read the provided Java source code files and identify any problems that you can find.
  The problems can include things such as actual bugs, design problems or code quality issues.
  You do not need to search for syntax errors - the code does compile.
  You have 15 minutes to find as many problems as you can.
 

The candidate would be left alone with the papers and a pen and would spend the next 15 minutes looking over the code by themselves.

The rest of the interview would then be spent discussing their findings. Most candidates would find the obvious problems in the logic, missing null-checks etc., while trickier things like synchronization issues were missed by quite a few. Even though we had a list of all the bugs/issues that had been put into the code, the important part wasn't for a candidate to check off as many of these as possible - the important part was the discussion about the issues that followed.

After the candidate had told us what they found, we would start hinting about the remaining issues and eventually tell about all of them. How quickly someone would pick up on an issue when it was pointed out told us quite a lot. It was a way to get a feel for how the candidate thought and reasoned about code, without the pressure of them having to actually write code with someone looking over the shoulder.

[8note]

Using whatever tools would be handy.

Throwing it through find bugs is always a good option, and should find something

[kps]

That could be interesting. I had a co-worker (at a different company, while on an open-source project) whom I highly respected because of his excellent code reviews. I think it would have to be done with an established build chain (e.g. formatters, linters, CI) so as not to degenerate into trivia and bikeshedding. I think it would be most interesting (assuming a good interviewer) if the approach under review were actually somewhat defensible.

[lytefm]

Agreed and even using the same code for different levels can work well.

The juniors spot obvious errors. The seniors also spot logical flaws and the conversation quickly moves into "how could this be done better, overall".