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.
How do you think that? I think myself a decently productive engineer and I always loathed the fact that I have to study for most of my interviews. Study things that I have almost never used in my actual engineering career. In a situation nothing like actual engineering work.
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.
How is whiteboard coding reflective of engineer skill? At what time, during any job you've had, have you needed to instantly write code on a whiteboard, in front of peers, in a matter of minutes. Almost by definition, it's not reflective of engineering as actually practiced in a job.
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.
> At what time, during any job you've had, have you needed to instantly write code on a whiteboard, in front of peers, in a matter of minutes.
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.
Although I'm thinking of designs and snippets rather than actual functions.
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.
You regularly have to instantly write code for a problem from undergrad CS coursework on a whiteboard, and for which you haven't necessarily been involved in working on, in a constrained time with your job hanging in the balance?
No. You just changed the question. Even most whiteboard interviews don't meet your newly narrowed criteria. I just meant to state that I regularly write code on a whiteboard in my real work. You could argue it's time constrained too. At least as much as it would be in an interview.
?? it's not something that's hard to do, it's like the foundation of my career. I use the principles all the time. my whiteboard /verbal / code solutions are based on that.
Using the principles all the time is different from regularly reimplementing CS textbook trivia under conditions in which your job is on the line. Where do you work, that you have to constantly re-invent the wheel over and over again under such constraints? I'd consider such a job to be hell. Not hard, just tedious and uninteresting to the point of pain.
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.
The current approach has a huge false negative rate. It keeps out the bad apples but hugely favors marking a lot of good/great apples bad as well. The time invested to study for these interviews is quite onerous in itself. So, I'll say I'm not a fan of the approach.
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.
It is reflective of skills at internalizing and applying undergrad (and sometimes graduate) level academic trivia in a familiar context. The interview process you and other "silent majority" members think is effective at measuring engineering skill is not, actually.
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.
I like it... because I'm good at it, so it's easy for me. However, I get no idea of what working at the company is like (beyond what can be gained from asking directly), and the company gains no information about my suitability for that particular job, since they're assessing me on exactly the same criteria as every other job.
