At my work we give coding exercises to interviewees with screen-sharing and give candidates lots of time and as much interaction as they want. The questions we pose are simple and do not require years of algorithmic experience and generally don't involve coding that couldn't be done by somebody with a couple of introductory software courses. Candidates choose their own programming language and environment.
The problems can be solved naively with a straightforward solution, or much more optimally after some further considerations.
The approach is absolutely not b.s., and we observe:
* some candidates completely misunderstand the very straightforward problems posed and their solution has no hope of addressing the issue
* some candidates have a rough idea but can't write the two nested for-loops required, for example, for the naive solution to one particular problem
* some candidates don't ask for clarification or confirmation that they understand the problem correctly even when they'd benefit -- others do and make better progress
* some candidates don't consider the full range of allowed possible inputs for the problem statement and assume the happy path always ... this is plenty forgivable, but when this is suggested or pointed out, some candidates find an easy way to resolve, others jump through interminable hoops to address, and others have deficit in communication that doesn't let them discuss the issue
* when discussing perceived flaws in implementations, some understand the language used to discuss software, others have a hard time communicating or answering questions about their implementations -- e.g., when one candidate wrote a recursive function all of whose branches ended up calling the same function recursively and we asked "when will your recursive function ever stop?" in many forms, they could not see or understand the intent of our question
* some candidates misunderstand writing a solution addressing a particular test case vs a general solution
* a few candidates are able to see the more optimal solution and write a good second algorithm based on that approach
* very few candidates resort to stepping through code in their IDE, unfortunately, to see or demonstrate what happens
We've eliminated many candidates we feel would have been a poor match based on inability to understand requirements, consider all possible input situations, inability to write naive algorithms, inability to communicate effectively about interview problems. ( Note that we also let candidates continue addressing the problem as "take-home" after the interview if they show promise. )
One junior candidate we just recently hired in a South Asia office did quite well on the algorithms portion, but unfortunately did not know Linux/UNIX/macOS command-line ... and assumed she was going to fail that portion of the interview -- she'd worked only in Windows contexts before. We had pointed her to a Linux-in-the-browser site and we just asked her to Google/search for the solutions to the various fairly basic operations we asked her to perform on the command-line -- she was surprised we'd let her do that. She struggled through and found solutions, and that's exactly what we wanted to see. There's nothing that exposes a candidate's suitability more than an open environment with a problem to solve and opportunity to discuss.