>No it wasn't. Feel free to re-read my original comment[1]
Sorry I wasn't very clear. When I said "similar to whiteboard interviews" I meant similar in the sense they are both different from the day to day job.
>is still discussing your work to an audience
This is true. But discussing is very different from performing. In my experience, standing at a white board while someone who already knows the answers to the questions they are asking tends to have a large impact on most people's ability to perform.
I've seen this in numerous interviews. The number of false negatives in this type of interview process are extremely high.
>and is still very dissimilar to the actual day-to-day work (N.B. I've never actually been an "illustrator, a graphic designer, a writer, or an architect" but I'm pretty sure their days aren't spent just sitting around discussing their portfolios).
But the key difference is that the work they are discussing is a product of their normal work environment.
Despite what we like to tell ourselves about wanting to see how people think, the vast majority of these types of interviews are going to push forward the people who can solve the problems they are presented with. So what Google style interviews really select for are people who happened to have recently studied the solutions to the types of problems presented during the interview and who excel at public performance. The end result is that we encourage job hunters to game the system by studying a subset of problems that don't represent the real day to day challenges of working as a programmer.
> It seems unlikely (though certainly possible) that our entire industry would move away from that if it didn't have major shortcomings.
The majority of programming jobs are at non-tech companies, non-tech companies don't tend to have Google style whiteboard interviews.
A large subset of the industry has moved to these types of interviews, but that's not an uncommon occurrence. It's happened several times in the past. Tech hiring is very fadish. Back when MS was the big company everyone wanted to work for, they used to ask insanely difficult brain teaser questions. By the early 2000s every tech company was asking these stupid riddles: You are a chef. If you had an infinite supply of water and a 5 quart and 3 quart pail, how would you measure exactly 4 quarts?; How many cars/gas stations/piano tuners/etc. are there in the USA? etc...
The fad was strengthened by Google because they used the same kinds of questions. This went on for a decade or so until Google decided brain teasers didn't correlate well with job performance. Word spread and companies stopped doing it (a few are behind the times and are still stuck on the last fad cycle).
Now the fad is repeating itself, but the companies are trying to emulate Google's newer brainteaser free 6 part whiteboard interview process.
The thing is, Google can afford an insane amount of false positives. Most companies can't, yet they still insist on cargo culting the Google interview without really understanding why.
>If you feel you have found a better way to hire developers than what most of the industry does
I do have what I consider a better way, but I certainly didn't invent it. I interview developers the way people interview architects, illustrators, and engineers. I look at past experience and portfolios, and I judge whether they can competently walk me through the projects in their portfolio.
If the applicant doesn't have much experience, or if their portfolio is too small (all of their work is covered by NDAs or something like that) I include a take home work sample test.
I've also had good experience pairing the applicant with a developer to work on a sample problem that neither one has seen (and isn't something we'll benefit from).
>you've motivated me to research the history of software dev interviews,
Our industry would be much better off if more people were willing to look at why we do things the way we do them.
>best of luck to you in your career and interviews.
Thanks, you too.