My last company did interviews like this - I was always disgusted at the way most of the team would sit around and just find things to pick on in the person's code. Dumb stuff too. It became an excuse for a lot of the engineers to just make fun of someone who had successfully completed the program, but didn't take the time to JavaDoc everything and follow the same code style best practices we did. Things you can easily address with a bit of training and code review, and that maybe they already do when they're not trying to interview for a lot of jobs while still in school. Sad, really.
The way to handle this is to _write down your grading criteria ahead of time_. If it's not important enough to be front of mind when designing the challenge, it's not important enough to bring up when evaluating the output of a candidate you've really liked so far.
Not saying this approach was correct, but given a choice, what type of interview would you prefer? Hackerrank? In person, programming challenges, smaller take-home assignment, other?
As both an interviewer and interviewee I prefer in-person. Where you simply meet 1:1 with a few people - some talk to you about fit / experiences and some sit and work with you on a problem. Ideally, you would do the second in a work environment you're used to on a real computer instead of a whiteboard, and I haven't had a chance to do that before. I've seen a few poor performers slip through this before, but I do feel it gives a lot more room for people who just misinterpret what you're going for initially because there's more room for immediate feedback [1]. I've also had some disastrous experiences working with people who were amazing coders but were terrible and sitting down and talking through a problem with someone - I'd rather have a mediocre coder I can talk to. It gives the interviewee a finite time bound, and the company is spending equal manpower resources of their own (instead of giving you a 5-hour problem that you might secretly spend more on, when maybe they already are leaning towards a no but wanted to give you a final chance before ghosting). The downside here is it depends a lot on the consistency and skill of the interviewers, but I believe with good culture and training you can make most people good at this.
[1] edit: Also, I think you can tell a lot about how qualified someone is by how they clarify the problem and how they communicate their thinking - not just the code they arrive at.
I prefer a small take-home project with a follow-up meeting to go over it. The follow-up meeting to discuss the project is crucial though, as I get to asses if I think the critique of the code is reasonable and I can make more in depth comments about the project (what was good, bad, areas I might improve if I had more time, etc) not the typical thumbs up/down with no clue as to why that is typical of companies these days.
A very small-scale assignment with a work/difficulty level on the order of magnitude of an Advent of Code single day challenge seems reasonable. And a follow-up discussion afterwards is crucial to ensuring that the interviewer has put an appropriate amount of effort into actually reviewing the interviewee's code so that it wasn't all just a waste of time.
