Whiteboard coding in software developer interviews.

[[)roi(]]

Why is hiring broken? It starts at the whiteboard.
Open source extraordinaire Sahat Yalkabov has given up his search for a front end developer job after a series of technical interviews that he described to me as a “humiliating and dehumanizing process.”
Various recruiters lined up interviews for him at six different companies over the past few months. Each of his interviews revolved around scrawling algorithms on a whiteboard, in front of other developers, who stood by to render judgement on his fitness for the job.
And after each interview, he received a brisk email informing him of the company’s decision not to proceed with his candidacy, without any further explanation.
Sahat isn’t exactly an outsider. He has a computer science degree, has worked as a developer at Yahoo, and is among the most prolific open source contributors.

Sahat’s open source contribution activity on GitHub.

At a time when big tech companies are scrambling to find capable developers, why is he having so much trouble getting job offers?
The answer lies in part in with how big tech companies interview developers.
You might assume that in this high tech industry, interviewers use fancy tools to analyze the quality of code samples, or look at how widely a candidate’s code was included as a dependency in a package ecosystem like npm. That’s how an academic researcher’s work would be judged — by how many other academics cite them.
Unfortunately, interviewing practices at big tech companies aren’t that scientific. The decision of whether to hire a developer usually comes down to the candidate walking up to a whiteboard and regurgitating algorithms that haven’t changed since the 1970s, like a (classically) trained monkey.

In the last few months Twitter has been debating whiteboard interview practices; by in large the opinion is that its a flawed process, and many highly skilled developers have been rejected for failing their whiteboard tests.
Article: https://medium.freecodecamp.com/why...rts-at-the-whiteboard-34b088e5a5db#.opkf4iys1


Max Howell was the topic one those discussions, he is highly regarded developer in the open source circles and probably best known for the package management tool he developed for OSX; called homebrew. What made his story particularly interesting is that he was approach by Google to interview for a position, having acknowledged that over 90% of their engineers use homebrew and love it; in short he went for the interview and failed his whiteboard test, so Google's management declined. Shortly there after he was employed by Apple to both manage a team & lead the build of Swift's new Package Management Tool.

The argument is that this type of hazing process is an awful way to assess a developer's skills, because what developer in real life ever solves problems at the whiteboard, or what developer does so without access to the Internet, online documentation, etc.

What your view on this?

Personally I think its rubbish, as you'd never expect an architect or an accountant or a doctor to stand at a whiteboard and regurgitate algorithms that are all but meaningless ito assessing their skills; this type of process really only serves to single out those who crammed prior to interviews.

 

[Thor]

What is the alternative?

 

[Hamster]

Asking you to regurgitate algorithms - bullscht

Asking you to solve a simple problem on a white board to see if you can think on your feet or shy AF - encouraged

My 2c. Stop being a wuss and write some pseudo code.

 

[cguy]

I support whiteboard interviews - one learns a lot about the candidate in these. These days (in fact, in the last 20 years of my experience) a good interviewer doesn't care about whether or not the candidate can "get the answer", what questions they ask, how they think about the problem, and how they interact with the interviewer is of utmost importance - this is someone you're going to be working with, so make sure you can work with them.

As for the guy above, I suspect that he was booted for the reason most get booted - not because he got the question wrong, but because they decided they didn't want to work with him.

 

[etienne_marais]

For new projects/extensions I like to sit down and analyze the problem, thinking about repercussions and alternative solutions. If asked to write something on the white board on the word go I'd probably mess up as there will be more than one approach running through my head.

 

[Sinbad]

Asking you to regurgitate algorithms - bullscht

Asking you to solve a simple problem on a white board to see if you can think on your feet or shy AF - encouraged

My 2c. Stop being a wuss and write some sudo code.

Devs, not sysadmins
Pseudo code.....

 

[Hamster]

Devs, not sysadmins
Pseudo code.....

Bwhahaha!! Too much Linux for me

 

[[)roi(]]

Not so for @mxcl, he was invited for an interview only to be booted because he could invert a binary tree on a whiteboard. For those straight out of varsity I agree this is probably the way to go, but beyond that it's just ridiculous.

As to what the process should be: simple it should be no different to other disclipines e.g. assessment of past work. If you want to assess ability on a particular topic, then why even bother with a whiteboard, you could e.g. like a journalist be asked to write something for the interview, as a developer to tackle a problem & submit this in preparation for the interview; then the interview revolves around that; questions on the code, choices made, ... (this btw is what Apple does), tends to also include a review of your open source stuff.

Imagine a skilled doctor being asked to regurgitate 1st year material on a whiteboard; easy to imagine the outcome: the medical practice doing this will be considered a joke, why then is this acceptable for software development.

 

[deweyzeph]

What is the alternative?

Pretty simple. When I've been asked to interview candidates for .NET developer positions, I sit them down in front of a computer installed with Visual Studio, Microsoft SQL Server and Git, give them a description of a mini development project, and then give them 2 hours to code a solution using the actual tools they will use. Nothing beats seeing how a developer actually writes code in a real world setting.

 

[Hamster]

Pretty simple. When I've been asked to interview candidates for .NET developer positions, I sit them down in front of a computer installed with Visual Studio, Microsoft SQL Server and Git, give them a description of a mini development project, and then give them 2 hours to code a solution using the actual tools they will use. Nothing beats seeing how a developer actually writes code in a real world setting.

Whiteboard coding isn't really used to test language and coding knowledge. The real computer tests if the guy really is a c# developer, the whiteboard tests if the guy can think on his feet and for himself, what his thought process is, if he knows how to say "sorry, but I don't understand" and "I don't know".

 

[deweyzeph]

Whiteboard coding isn't really used to test language and coding knowledge. The real computer tests if the guy really is a c# developer, the whiteboard tests if the guy can think on his feet and for himself, what his thought process is, if he knows how to say "sorry, but I don't understand" and "I don't know".

When I hire I don't really care whether someone can solve problems on whiteboards. I do care very much however if they can actually write code and write it properly. I can tell immediately from seeing how someone codes in real life whether or not they can think on their feet and what their thought processes are and whether or not they are a cowboy or not. My experience has been that computer science theorists who can solve abstract problems on whiteboards don't necessarily make good developers, and vice versa.

 

[_kabal_]

How about this? Pay a candidate as a freelancer to deliver a piece of work you actually need, at an hourly rate. The candidate must give you an estimation, and deliver. This is a win win situation both parties. Sure you will throw some money away, but not as much as is possible with a potentially bad hire. Obviously there is a filter(s) before this step

 

[icyrus]

Asking a candidate to write code on a whiteboard is a great signal for a company I don't want to work for. It is an immediate interview end for me.

 

[[)roi(]]

Maybe to upend the debate a bit; for those who see merit in whiteboard coding; it would be far easier to understand your thinking if you gave an example of a white question question, and then explained shat you expect from the developer and probably more important why you think it's vital for the developer to be able to do this on the whiteboard?

 

[Hamster]

Asking a candidate to write code on a whiteboard is a great signal for a company I don't want to work for. It is an immediate interview end for me.

Aren't you the guy that walked out of a BBD interview because they did not allow you to use Google?

EDIT: apologies, not you:

Went for an practical there a few years back, and they gave me a PC with no internet connection. Looked at them and asked if they were serious.

"Yasss, because when you work you don't have internet".

 

[Hamster]

When I hire I don't really care whether someone can solve problems on whiteboards. I do care very much however if they can actually write code and write it properly. I can tell immediately from seeing how someone codes in real life whether or not they can think on their feet and what their thought processes are and whether or not they are a cowboy or not. My experience has been that computer science theorists who can solve abstract problems on whiteboards don't necessarily make good developers, and vice versa.

Fair enough, not like you need to use both. But a developer shouldn't be scared of either approach the interviewer decides on.

 

[deweyzeph]

Fair enough, not like you need to use both. But a developer shouldn't be scared of either approach the interviewer decides on.

I guess it depends on what you're trying to achieve. If I was on the cutting edge of algorithmic development like Google for example, I would be inclined to hire the best computer scientists possible, in which case this sort of thing might very well be applicable. If I was hiring for a digital agency who just requires developers churning out CMS-based websites all day long then this would be overkill.

 

[CamiKaze]

I use Psuedo Code and Chapin (if I feel it gets the message across) in all of my interviews where I explain why I use each step.

 

[Spacerat]

I tend to favour whiteboard interviews but not to write code. Only to communicate concepts. Purely because I don't use the board to write code. Why would the candidate need to? I would give the candidate dev a small assignment. Then he shows me on the board how he will tackle it. Then he can write some code on a PC. Using google is okay. Once he has done this, we have another session on the board. This time I explain concepts like DI, decorator patterns etc by way of an example. We draw classes, etc on the board. The purpose of this is to gauge his understanding and ability to grasp and follow a train of thought. And also how he interacts. The mood is very casual and relaxed to put the candidate at ease.

 

[gkm]

Asking a candidate to write code on a whiteboard is a great signal for a company I don't want to work for. It is an immediate interview end for me.

How do you show the interviewer that you can actually code?

@Droid
Also, I have spoken to doctors that did their specialist exams and they had to do pretty much the equivalent of whiteboard tests.

But I agree one has to be careful about the questions asked. "Trick" questions like inverting a tree, some people will know, while others will not know how to do it. The people that know it, will do well, while others will fail it badly. In my opinion these trick questions are not an indication of skill, rather an indication of whether the candidate has accidentally studied that algorithm. Good whiteboard questions, which require programming skill but do not require knowing a very specific algorithm, are tough to find, which is in my opinion why interviewers sometimes reach for the trick questions. Interviewers at big tech companies are also people and they make the same mistakes, often more so that at smaller companies in my opinion, because at these big companies the interviewers take part of the blame for hiring bad candidates, so they might "play it safe".