The point of whiteboarding isn't to "build" correct/functional code - it's to get an idea of your thought process and how you go about solving a problem.
It's not perfect (and there are both advantages and disadvantages to using a computer instead of a whiteboard) but when done correctly it gives a lot more useful insight than sitting there asking questions about their past the whole time.
Why is thought process relevant? Different people have different thought processes. I would estimate that recruiters would bias to hire candidates that have similar thought processes to themselves, even if that doesn't correlate well with actual work performance.
> Different people have different thought processes.
Nobody is saying otherwise. The point isn't to make sure your thought process is identical to the interviewers (good interviewers will be more impressed if it isn't), it's to make sure you have one.
That may sound silly but read Jeff Atwood's thoughts on FizzBuzz[1] to realize how many "programmers can't program." Coding exercises are used to make sure you know how to think through a problem and solve it.
> I would estimate that recruiters would bias to hire candidates...
I'm not sure if you used the wrong word or not, but technical interviews are usually done by engineers or engineering managers, not recruiters. But yes, if I were interviewing somewhere and I sufficiently solved a problem but they didn't like it just because my thought process was different I would consider that a red flag.
Imagine you were in charge of casting for your community theater's production of Hamlet. How would you decide who to cast?
I'm guessing you would find it sensible to hold auditions. Does an audition perfectly mimic what they would actually spend their time doing come showtime? No. There isn't an audience, the lighting and acoustics are different, nobody is wearing costumes, everyone is standing in the same place instead of moving around, people are reading from scripts instead of having lines memorized, etc.
The audition isn't intended to mirror a performance - it's intended to give some insight into how someone may perform. Likewise, whiteboarding isn't intended to replicate a typical day in the life of a software developer. It's intended to give a glimpse into how you solve problems.
As I said above, it's not perfect, but it's far more useful than hiring someone without any coding exercises and basing your decision just on how well they answer questions or what their background is. In fact the whole point of the post you're commenting on is to point out the foolishness of basing hiring decisions solely on having X years of experience in Y technology.
>As I said above, it's not perfect, but it's far more useful than hiring someone without any coding exercises
Whiteboarding vs no coding exercises is a false dichotomy. There are ways to test coding in a 45 minute interview that don't involve standing in front of a whiteboard, writing with a marker.
> Whiteboarding vs no coding exercises is a false dichotomy.
Sorry, it wasn't my intention to suggest those were the only two options (I was attempting to comment on the benefits of coding exercises, regardless of method).
Using a computer is certainly as good or better than a whiteboard. Though one of the bigger downsides to using a computer is there's generally this expectation you need to write "real" code that actually compiles and runs and so the focus becomes as much on writing syntactically correct code as about how you solve the problem (when only the latter has value).
At my first job this was very common. Usually it was more related to schema design and class hierarchies. But there were always white boards full of diagrams of whatever we worked on. We had folders full of digital photos of white boards as reference material.
I'll never forget how excited the lead dev was one day when he got some markers that would automatically make a digital file from whatever he drew on the white board.
In the jobs I've liked, I do. To be more precise, I solve the problem on a whiteboard, and then type out the solution at the computer. The more experience I have, the less often I encounter gotchas while typing that I missed at the whiteboard.
The distinction matters. Are you an engineer or a tech? An architect or a laborer? Often, software developers end up being both (just as carpenters often end up designing and building). In particular, if you want your developers to be both, then you should make sure they can.
Even when I'm in a discussion using the whiteboard at my current job its not like I'm up there verbalizing every thought that comes to mind as I write. And typically in these sessions I'll be completely silent for a majority of the time.
What you get isn't useful insight. It is the appearance of useful insight.
Actually, a carpenter who is asked to build a cabinet will start by asking you about what kind of cabinet you want, and a sketch on a whiteboard will work as well as anything else.
Where is it going to go? How big should it be? What's the purpose? Is it going to be built-in, or standalone? What's your budget? Do you want doors, and if so do you want glass in them? Shelves? Drawers? Some combination?
Are there exsting cabinets or furniture in the room? Do you want the style matched, or the woods matched, or both?
All of this stuff goes into the specs for the whiteboard... oh, and you don't know enough about this that "cabinetmaker" is a serious specialization, you should really have put that down as the job title and you should be looking at a portfolio of their work.
First, nobody expects a cabinetmaker to draw a to-scale, installation-quality blueprint on a whiteboard like many companies expect out of whiteboard coding exercises.
Second, a cabinetmaker's portfolio will consist of multiple photographs of completed jobs. It will likely not include detailed specifications of the jobs or records indicating what specific parts of the jobs this cabinetmaker was responsible for and what other carpenters did. It certainly will not include the ability to inspect the actual work done. This industry expects candidates to have a portfolio such that this level of inspection is possible.
Regarding your first point it's extremely rare in my experience to have an interviewer expect perfect/compiable code when whiteboarding (nearly every whiteboarding exercise I've ever done has been prefaced with the interviewer explicitly stating this). They're looking for how you go about solving a problem, they don't care about missing semicolons.
As for your second point, just because the ability to easily "inspect the actual work done" is not practical in one profession doesn't mean it shouldn't be considered in a completely different profession where it is practical.
> Regarding your first point it's extremely rare in my experience to have an interviewer expect perfect/compiable code when whiteboarding (nearly every whiteboarding exercise I've ever done has been prefaced with the interviewer explicitly stating this). They're looking for how you go about solving a problem, they don't care about missing semicolons.
The interview instructions Amazon gave me prior to my in-person interviews specifically said my whiteboard code would be judged on syntax and that I was expected to produce working code, not pseudocode. They are not the only company that has said this to me, so I do not think it is "extremely rare".
> As for your second point, just because the ability to easily "inspect the actual work done" is not practical in one profession doesn't mean it shouldn't be considered in a completely different profession where it is practical.
For a large portion of programmers, it is impractical. The only way most programmers have representative examples they can show that level of detail in is to do professional-quality work outside of their day job. Expecting them to do so is unreasonable.
Yeah exactly, was once given pencil and paper and asked to write some code. That was early on in my career, so even though i knew it was ridiculous, i didnt have enough confidence to tell them they're being idiots. At this point in my career however, i'm far more jaded about stupid interview techniques like that and will refuse to do them unless provided with a computer.
Why wouldn't you just do it? I can understand if they're nit-picking syntax but I personally ask people to write out algorithms/code on the board all the time in interviews. I don't care about the code, I want to see them think through a problem. They can use any for syntax they want, even mix and match things like brackets and indentation or how control structures are defined (for i = 1 to 10 { .. } ), or use a function outside of the current abstraction level without writing it as long as they say what they're doing.
If you can't write out an algorithm or some classes that work together without a compiler/interpreter, then you're just guess and checking as you work and not thinking through what you do ahead of time. I can't program without google, but I can write out my implementation just fine -- that's what people are interested in.
I don't really get how I'm being an idiot wanting to explore how someone solves a problem in the medium they work (code) -- I'm not a human compiler so I obviously don't care if their program compiles or is even in a real language, as long as it gets across what they are trying to do and how they would do it.
Also -- you'll need to deal with stupid people forever, the way your comment is worded it sounds like you think you're smarter and better than everyone else and are "above this silliness". When interviewing I'm jaded about people who can't interact with people who they view as "below them" -- you'd hopefully not even make it in the door for an interview if you can't politely answer a question you think is dumb. Like 90% of interactions for software developers outside of their dept are answering dumb questions...
I may need to add dumb questions to my interviews to catch this...
Edit: Also -- can you explain the code you've written/your implementation? How do you include me in your problem solving? What type of questions do you or don't you ask while doing it? Where do you start/how do you start? If the HR person is there, can you explain what you're doing to them? How do you take suggestions? How do you break down your objects (this gives soooo much information about background, I can tell a lot about a developer based on how they name their classes, like people who have worked with only activerecord style classes). I can follow up with a refactoring change (substitute this for that in this situation, decide based on a configuration file - does this require a significant redesign?)
I mean come on... it gives so much information about how someone works, I think its dumber not to ask some type of question with writing "code" - it just gives so much information about a candidate that would be hard to get one question at a time. This one question can infinitely expand and lets them interact about something they know/are comfortable with (the solution to their problem).
It's a contrived situation that involves significantly more nerves than any real life situation will. I've known more than a few programmers that were perfectly capable of doing their work, but struggled through interviews because they got nervous during the coding phase.
The reality of the situation is that contrived problems in stressful situations are going to result in a lot of false negatives. That may be fine for you since you may be avoiding some false positives, but that doesn't mean your particular method is "the only way."
But its not contrived -- its like your entire job. You're literally saying "I can't perform my primary job function when there is any pressure whatsoever". That MIGHT be acceptable if you're interviewing for an entry level job.
The only other reason I can think for being unwilling to do this is if you're incapable of working with other people - because whiteboarding out solutions with other devs is super common. Even "where do you think I should start, I'm a bit nervous and an idea to get me going would be great" is a perfectly acceptable question. The best interviews are a conversation -- if you turn it into a conversation where we're working together on the problem, it shows a lot about you still. If you take someone else's idea and run with it I think that's really cool, obviously if you need hand-holding it's suboptimal, but there is still a very positive possible outcome from saying "I have no idea where to start" if you're actually nervous.
The only ways I can think of to fail writing out code is people skills or being completely unable to program. It's not like I expect a perfect solution in the 30-60 minutes we have, analysis paralysis is just as bad as no-knock raiding the problem. There is some type of middle ground that involves a good solution that had to be done quickly -- maybe you even mention some other avenues to explore.
What if you ever have to represent my department in any capacity and someone asks you what your ideas for a problem and you just say "no, I don't do that" -- that doesn't really represent me well. I would be very surprised if being uppity about a question being "below you" ever works, you might as well just walk out the door if you're going to refuse to answer a question on "philosophical principle".
The question is just a jumping off point -- its up to you to turn it into a conversation that shows me how great of a programmer you are. If your answer is telling me how dumb my interview is, then that doesn't show me how great a programmer you are at all -- it shows me you have an attitude problem.
For people early in their career, a job interview can be one of the most stressful experiences in their entire life. I still remember every interview I've had. Writing code on a whiteboard with "everyone's eyes on you" can be extremely stressful for some people. I know brilliant coders who get absolutely paralyzed at the thought of having to present to an audience. (which is what whiteboarding during a job interview is, the social dynamics are entirely different when you're working with a co-worker on a problem)
If 99% of a coders job will be sitting at their desk cranking out code, why put some much emphasis in the hiring process on how they perform in extremely high stress social situations? The skills that make someone a great interviewee do not necessarily line up to being a great coder. If someone wants to up open their favorite IDE or VIM and show you how they code, why not let them? Personally, having dysgraphia, I would offer to open a text editor to write psuedocode rather than use a writing utensil.
Of course, every hiring situation is unique. If your developers are regularly required to present to clients, investors, or inside management stakeholders, then whiteboarding could be a valid hiring test.
> contrived problems in stressful situations are going to result in a lot of false negatives
I don't understand the concern with a "contrived" problem. You think it is better with a random spontaneous problem the interviewer thinks up on the spot?
Interviews are stressful for most people; good interviewers will take that into consideration.
If someone can't interact with colleagues to solve problems, and can only work when alone with the computer, it greatly limits the ability to work as part of a team.
Collaborative white board discussions are a pretty common part of many software development teams.
I'm not a pro at hiring, but I have a very different approach based on what ultimately ends up being useful in an employee over the longer term for us.
If you're building a garbage collector, or a high performance graph database, then by all means, ask your candidates to whiteboard algorithms for you. Fizz buzz the crap out of them. In fact hiring for that type of position must be ridiculously hard and I'm not qualified to address it.
If however you're building CRUD apps in Rails or SPAs in React, you may want to take a different approach. One that prefers maturity, discipline, and self-motivation over pure intelligence or proficiency with Haskell.
This comes from personal experience hiring very smart people who lack some of these other values. It's never worked out well in the long haul.
I also think that there are a lot of really smart people who will just suck at those algo type interview questions because it can be a bit nerveracking and as you can already see from some replies to this thread, it can be taken as offensive (even if you don't think it is). Making your candidate (more) nervous and / or defensive and you're limiting your ability to find out about their other virtues.
I agree but usually the type of questions I asked are geared towards what I'm interviewing for. Whiteboard problems are just jumping off points, from there the problem can go so many directions based off of that person, their experience, what's important to them, etc.
For a CRUD full stack app, you're right I really don't care about your ability to write a search function since SQL will do that for you just fine - in fact, for the most part algorithms are probably not even part of the interview. I may ask them to still start solving a really simple problem -- it may or may not make it all the way to code. If someone starts writing/mapping out their database first that tells me something, I can ask why they are breaking their objects where they are, etc.
I like to ask "what's important" in the context of components - I use the example of a bunch of HTML documents to frame the context. If I'm looking at 10 similar HTML documents, what can I do to find important information? (Strip out things that are the same). So if I'm doing 10 interviews, what do you think is going to be the same (user/session management if there are accounts would be an example) and what do you think will allow you to differentiate yourself? For some people, they'll think about what they're strong in and how it applies to the problem, for others they'll focus on the problem space.
At this point you've spent 15-25 minutes talking if they're a good candidate and written no code by starting with the "write code" question -- I think you could get a great 60m interview without writing any code even though you started with a "write code" problem.
My opinion on interview questions is they're just conversation starters -- if you just go down a list of questions I just don't think its a successful interview. I really like VERY open ended questions where the candidate can have a chance to tell me why they're great. I really try to only have 3 or 4 questions for the interview and hope to only get to 1 or 2.
A better analogy of what Whiteboarding can effectively used for: "On this job, you'll have to apply varnish in these certain places with very low ventilation, directly above a daycare, what techniques could you use to minimize fumes?"
