> Actors and musicians perform in front of an audience
Some actors/musicians. Movie actors never perform in front of an audience, TV actors usually don't perform in front of an audience, studio musicians rarely perform in front of an audience - these professions have auditions (unless you're an A-list actor, but I'm sure most software companies would hire John Carmack without an "audition" so we likewise do the equivalent). But more importantly I think you missed my point, in that the audition for these professions are under very different conditions than what you'll actually be doing "on the job" (one of the bigger complaints with whiteboarding seems to be that it doesn't closely mirror the actual work).
> Interviewing an illustrator, a graphic designer, a writer, or an architect generally involves looking through a past portfolio of work with the interviewee
That'd be fine if the point of the technical interview was to determine they know how to write code, but it's not IMO. As I mentioned above it's to determine they're capable of problem solving, because that is the important part of what we do (you should also obviously make sure a candidate knows how to code before you hire them, but that's the point of the phone screen).
>Movie actors never perform in front of an audience, TV actors usually don't perform in front of an audience, studio musicians rarely perform in front of an audience - these professions have auditions
This is only true for an extremely limited definition of audience.
Movie actors most certainly perform in front of an audience. There are hundreds of people on the set. Even a small indie film has a few dozen people on set. It's the same for TV actors.
Studio musicians also have plenty of people watching over their shoulders while they perform, and they're expected to be able to do so on the spot without preparation.
>As I mentioned above it's to determine they're capable of problem solving, because that is the important part of what we do
That's the important part of nearly everyone's job. Architects, graphic designers, engineers, sales people, mechanics, plumbers.
There's nothing special about programming in this regard. We've just convinced ourselves that our industry is so special that of course we need weird hazing rituals. Everyone else seems to get along fine without treating people from new college grads to programmers with 20 years of experience like this is their first job.
Can you solve this artificial problem that I already know the answer to right now in this time boxed, needlessly adversarial situation situation while I watch over your shoulder and critique you?
It's a bit odd you responded to various parts of my comment but not the "But more importantly I think you missed my point..." portion (i.e. kind of silly for us to debate this audience straw man)
> That's the important part of nearly everyone's job. Architects, graphic designers, engineers, sales people, mechanics, plumbers.
Communication, like problem solving, is likewise an important part of nearly everyone's job, but the importance of good communication skills (as valuable as they are) are much less important to being a good software engineer or good plumber than they are to being a good reporter or trial lawyer or public relations professional.
I'm guessing, like most developers, this is your first/only profession - but it's not mine (I switched careers in my early 30s), and I can assure you not every job requires the level of problem solving we deal with on a regular basis (and no, that doesn't make us "so special", not all jobs are identical, some have more or less value in different areas, but one is not more special than another because of the importance of problem solving or communication or empathy or creativity or anything else).
>It's a bit odd you responded to various parts of my comment but not the "But more importantly I think you missed my point..." portion (i.e. kind of silly for us to debate this audience straw man)
Your argument was that almost all creative professions have auditions similar to whiteboard interviews. I pointed out that that's not true because it's only true for performance artists. You then took the discussion off topic by arguing that movie stars aren't performing in front of audiences.
Actors are expected to perform in front of an audience, programmers aren't. The ability to perform in front of an audience is difficult and rare, and is completely orthogonal to the skills required to work day to day as a programmer. Whiteboard interviews are just too far removed from anything resembling actual programming to be a work sample test. At best you're administering an ad hoc IQ test, but then you're adding an adversarial public performance aspect for no good reason. That adversarial public performance aspect is the biggest single difference between whiteboard interviews and real programming work--it's a much bigger difference than the difference between acting auditions and acting day to day.
>I'm guessing, like most developers, this is your first/only profession
I also switched careers after years in another field.
> not every job requires the level of problem solving we deal with on a regular basis
This is true. But having worked on the embedded systems side of hardware, there are many professions that do require at least the level of problem solving that programming does.
EEs (the majority of whom don't have any kind of certification unless they're working in power systems), computer engineers, and even embedded developers don't routinely go through the kinds of whiteboard problem solving tests that you're talking about. Engineers working on real time, safety critical systems are hired every day without a Google style 6 person interview interview.
The key differences are that these companies aren't trying to cargo cult the Google interview process, they don't have engineers a year or two out of college conducting the interviews, and they aren't paralyzed by the fear of unqualified candidates slipping through.
I spend a lot of time on (capital E) Engineering forums. You don't see people on those forums complaining about the industry standard interview. You don't see flame wars started every time someone even mentions interviews. I've never heard of an EE with 20 years experience being asked to solve pet problems by a 22 year old new grad. And I've never heard of an EE spending months practicing for an interview.
Clearly our interview process is broken. Perhaps it's time to look at similar industries and spend some time trying to figure out if we are really so different instead of insisting that programming is so uniquely challenging that it requires such a controversial interview process.
> Your argument was that almost all creative professions have auditions similar to whiteboard interviews
No it wasn't. Feel free to re-read my original comment[1]. My point was not that they have auditions, it's that the auditions don't closely mirror what they'll actually be doing if they get the gig (which is one of, if not the, most common complaint about whiteboarding).
However, it seems your primary concern is that the whiteboarding is done in front of an "audience" - I can sympathize with that but there's going to be an audience (by your definition of the word) regardless of the structure of the interview, i.e. your "looking through a past portfolio of work" example[2] is still discussing your work to an audience (as opposed to creating new work on the spot) 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).
> Perhaps it's time to look at similar industries and spend some time trying to figure out if we are really so different instead of insisting that programming is so uniquely challenging that it requires such a controversial interview process
Perhaps I'm mistaken (I'm by no means an expert on the history of our profession) but my understanding is whiteboarding interviews are a relatively new phenomenon (i.e. last decade or two) and presumably programming interviews prior to that were more similar to many other disciplines. It seems unlikely (though certainly possible) that our entire industry would move away from that if it didn't have major shortcomings.
If you feel you have found a better way to hire developers than what most of the industry does I would encourage you not just to use it for the interviews you conduct but also to share your thoughts and findings with others via a blog or maybe even a book. Either would certainly have more potential impact than debating the issue with me in a buried thread of a day old HN discussion. It's been an interesting discussion and you've motivated me to research the history of software dev interviews, best of luck to you in your career and interviews.
>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.
Some actors/musicians. Movie actors never perform in front of an audience, TV actors usually don't perform in front of an audience, studio musicians rarely perform in front of an audience - these professions have auditions (unless you're an A-list actor, but I'm sure most software companies would hire John Carmack without an "audition" so we likewise do the equivalent). But more importantly I think you missed my point, in that the audition for these professions are under very different conditions than what you'll actually be doing "on the job" (one of the bigger complaints with whiteboarding seems to be that it doesn't closely mirror the actual work).
> Interviewing an illustrator, a graphic designer, a writer, or an architect generally involves looking through a past portfolio of work with the interviewee
That'd be fine if the point of the technical interview was to determine they know how to write code, but it's not IMO. As I mentioned above it's to determine they're capable of problem solving, because that is the important part of what we do (you should also obviously make sure a candidate knows how to code before you hire them, but that's the point of the phone screen).