I actually like the current interviewing approach... and I feel like we are a silent majority. I think whiteboarding / coding algorithm and design problems is pretty fair and reflective of engineering skill.
My favorite interview process (given by the company I currently work at) consisted of one coding prescreen that wasn't terribly difficult, one session where I simply talked with two engineers about past projects I worked on, and then one higher level architecture problem that involved pseudo-code but not some esoteric algorithms.
That interview process, I think, is way more representative of my actual day-to-day work than any algorithm interview I've done. It deemphasizes the ability to figure out / reguritate previously memorized tricky algorithms on the spot (when do you ever need to do that during the work day?) while emphasizing the ability to communicate how and why you make decisions.
Which is an incredibly important part of engineering, way more important than whatever skill whiteboard algorithm interviews test.
I'm a far bigger fan of at-home coding exercises. Yes, I know, some people get annoyed at these because they think you're asking them to do free work in their spare time. But what other way is there to test people's coding under circumstances that most adequately mirror those of an actual job. E.g. they have a (relatively) unlimited amount of time, they have access to Google, their IDE, etc.
I'd much rather see what someone can come up with, in response to some novel problem, based on a couple of days programming, than what they can hack out on a whiteboard based on thirty seconds of thinking. The former seems closer to what coders are actually required to do, day on day.
Well, constantly, actually. Although I'm thinking of designs and snippets rather than actual functions. I guess it depends on what you're asking people to whiteboard during the interview. I agree that asking people to whiteboard qsort is silly, but walking through design alternatives with occasional code snippets to illustrate implementation options is a pretty basic skill.
> based on a couple of days programming
Either your company is very well-known and very attractive to candidates, or this is going to incredibly restrict your candidate pool.
I think smaller work samples are a great idea, I think code reviews are a great idea, but asking for two days sounds like a bit much, especially early in the process.
But that's the thing -- at whiteboard interviews, they don't ask you to produce "designs and snippets". They make you write actual working classes and functions.
Fairly regularly. Like when I'm explaining to someone how something works after they've asked me about it.
I'm skeptical.
I'd also not consider it to be an engineering job. What you describe seems to me to be more like a CAD technician job at an engineering firm.
That being said we do use the method where I currently work to interview. However, the problems are not some made up situation or a test of data structures/algorithms but a set we've encountered in real life.
From what I've heard the whiteboard method isn't really popular with many companies today either but everyone is sticking to it until some other alternative which avoid false positives presents itself.
I really wish you and so many of your colleagues would spend a few weeks with engineers in the physical science engineering disciplines. What we do in this industry is a farce, with respect to engineering.