Comment by arihant | Hacker News Reader

Comment by arihant | Hacker News Reader

Why is this approach used? I have never, in my life, have coded on a whiteboard while actually building a product. I draw, I brainstorm, I even write plain English steps, but never code.

It's extremely weird that companies are trying to act like S.H.I.E.L.D., and every interviewer thinking he is Fury. And they are almost always wrong. You're recruiting to someone to do a job, not to transform them into something. If they will likely never do something in the actual job, it is mindless testing them on something.

Founders should be aiming to hire people better than themselves. Fury is awesome for hiring Avengers, not field agents. And no Tony Stark is coding on whiteboard happily.

> It’s hard in part because you don’t have IntelliSense or syntax colouring or any of the other tools at your disposal that you normally do when writing code. I know that, and I’ll take that into account.

This is weird. In what conceivable situation would one not have access to those tools on job site? Hell, I've seen a lot of programmers quickly check API available to them in a new language before forming a mental map of it.

While the author may think he knows what he is doing. My personal guess is that he is alienating a lot of amazing people. If you test Lance Armstrong on his ability to ride a unicycle, you might miss out on him. That is essentially what you're doing with whiteboard coding.

I take it into account by asking a problem that is so simple and straightforward that you do not need google, intellisense, or any other tool to solve the problem. As I mentioned in another comment above, I have asked problems as simple as "add and subtract four numbers". A candidate who needs to use Google to determine how to add and subtract doubles in C++ will not be successful.

Now, perhaps I am alienating candidates, but first, I am very willing to accommodate any candidate who wishes to demonstrate their coding skills to me in some other way, and second, my primary goal is to prevent bad hires. If good hires go to the competition, that's too bad, but it is way more important to prevent a bad hire. What I am not willing to do is fail to test candidates on their coding ability; I have had candidates -- some with advanced degrees -- show up who had no demonstrable ability to solve practical problems.

> I have had candidates -- some with advanced degrees -- show up who had no demonstrable ability to solve practical problems.

For real? I'm assuming you imply advanced degrees for reputable university? From my experience in CMU, it is hard to imagine someone slip through the system without an extreme command on general programming.

Maybe it can happen at a research focused Masters, but someone with a BS in Computer Science from the top 5 should not flunk an interview.

Oh yes really.

I have had candidates with PhDs in computer science who had a deep understanding of static analysis of programming languages, but who did not know how many bytes were in a pointer on a 64 bit operating system, who thought that there was an algorithm for compressing any 64 bit number into a 32 bit number, who could not describe the possible consequences of a buffer overrun in C, and who had no idea whatsoever what a virtual function table was.

Now, to be fair, as Dijkstra is said to have pointed out, astronomers are not experts on telescope building. People with deep knowledge in one small area of a field are often ignorant of other areas, even closely related areas. In those cases it's even more important to get a sense for how the candidate approaches problem solving, whether they can learn on the job, and so on, because you know that they are going to be deeply in problem solving mode very quickly when faced with their first real-world problems.

I hold up myself as a case in point; I helped build the JavaScript engine that was in Internet Explorer in the 1990s, but know practically nothing about HTML, the browser DOM, CSS, and so on. If I were interviewing someone like me for a web developer position, I would have to be convinced that the candidate could learn quickly.

Not everybody goes to a top 5...

I pretty much always check the documentation when I'm doing something. (Not basic file IO and things I've done a million times, but anything I've done less than 5 times. If I do it more than that I likely have a snippet I wrote on git hub I'll start with) I just like to look at some example code as I picture what I'm going to do.

Reply on news.ycombinator.com