Even the top notch devs I know can't do anything meaningful without an internet connection. Unless of course you know how to invent several layers of libraries, instantly in hours without bugs. Know the documentation of the libraries memorized to the last full stop.
In my exposure at least I know 0 devs who can do this. And I'd bet even the interviewer wouldn't be able to write any meaningful without a network connection. This isn't 1960s. By very definition almost anything today requires an internet connection.
I love this suggestion, and thank you for elaborating! FWIW, the interviews that I've talked about taking as a candidate actually used this approach. And, when I give interviews, I use this approach too.
The only thing I'm really defending here is using a 2nd stage screening process that only takes 30 minutes, before I go to the 3rd stage that takes a half day or full day. @BitL seems to be fighting the screening process, which is a necessary practicality and isn't going away.
The first stage is reading resume and glancing briefly at any side projects, which is ~5 minutes. The first stage is invisible, and filters out more people than any other stage. If anything unfair is happening, it's happening here, and there's little a candidate can do about it.
My thoughts on your outline:
A - getting rid of the whiteboard is of course optional. In my case, having graded exercises doesn't mean I stop using the whiteboard. I only provide a whiteboard for people who want one, and I don't ask people to whiteboard things better done in an IDE.
B - Yes! I do like having exercises that range from super easy to not solvable. It helps to know where people get stuck.
C - Yes! That's very helpful for language specific jobs. Personally, I also like exercises that are language agnostic, to let the candidate pick the language they're most comfortable with. I've loved doing coding quizzes in Python during interviews, and would prefer that over, say, C++.
You do not know how many good candidates are filtered out because you have bad hiring practices.
I was tricked into a code golf challenge which was a hiring test. The result was good I was surprised that slacking off could get me a nice discussion, and the company got to pitch their positions. I've never done a hacker rank thingy for hiring and probably never will, I loathed them in school. They do not tickle my mind nor can I scratch my itches with them.
I know this sentiment is shared by many high value employers I've had the pleasure to work with.
> @BitL seems to be fighting the screening process, which is a necessary practicality and isn't going away.
Dunno. Google sent me flight tickets to Mountain View on-site interview without doing any phone screen. YMMV
Maybe sometimes you would consider skipping it as well? Maybe clicking through someone's resume could prompt you to skip that process? Maybe even onsite interview or making it just a friendly chat?
What I liked was using shared Jupyter Notebook during a video call. You avoid whiteboard coding, you can see what the algorithm does immediately and fix any issues and both interviewer and candidate can have more interesting conversation, telling you if you are a good personality fit.
Bring the candidate on site for a 4 hour coding session. Provide a standard list of questions the scale in difficulty. Think:
1) Fizzbuzz
2) Reverse a string
3) Write a calculator class/script
...
100) Write an algorithm that can search compressed text without decompressing it
So you see how far and correct they can get with an IDE ... and maybe no internet connection.
Noon - Hiring Manager lunch Afternoon - 1 or 2 design interviews on the white board.
So you have done a few things here that I want to outline.
A) You got rid of the stupid whiteboard
B) You have one process that scales for experience levels!
C) You can tailor the problem set at a certain of difficulty to specific languages
This interview style ensures the developer/engineer knows how to code, and can be weighted appropriately to certain skill levels.