Whiteboard Interviews | Hacker News Reader

Whiteboard Interviews

tbray.org

73 pointspw80 comments

Interviews don't demonstrate ability or aptitude so much as they demonstrate ability to keep a cool head under incredible pressure. It doesn't matter how soft you make the whiteboard question: you are getting lower quality signal in an in-person office interview than you will in any other venue. Interviews are incredibly hostile experiences and nothing you can do, including comfy chairs, bright, cheerful surroundings, or free drinks will change that.

We need to engage with the fact that these interview processes are just stupid. We know a number of better ways to extract signal from candidates, but we keep interviewing face-to-face for technical ability because that's how it's always been done.

A number of companies are trying to embrace work-sample challenges to boost signal from candidates. But I don't think they get it. They assign take-home work before or after an interview, and still make decisions on candidates based on an "interview loop". If you have an interview loop composed solely of people, I don't believe in your process. We had a sort of interview loop at Matasano, but the open secret was it largely didn't matter, because if your (numeric) scores on our work sample tests were solid, the burden of proof was on the interviewers to override the work sample tests.

We worked with a number of different hiring groups at Starfighter last year, some of them quite smart, and at none of them did I see a process that deliberately and meaningfully insulated itself from "I'm having a bad day and haven't eaten lunch yet and now I have to interview someone" bias, or from "I'm putting you, the candidate, in the most uncomfortable imaginable professional circumstances and expecting not only perfect recall of the intricate details of your craft but also that you recite those details in a way that demonstrates confidence and ability to get things done".

All the hiring I see is still done by by subjective X-factors; worse, each interviewer in a "loop" has a different X-factor. Where's the table-flip emoji when I need it?

A huge chunk of this stress is most people simply don't code on whiteboards most of the time. It's a skill which you can pick up fairly quickly which destroys the validity of this kind of hazing.

That's not the source of the stress of coding on a whiteboard. The source of the stress is you have to guess what the interviewer wants or you don't get to pay your bills next month.

Few people are in the situation of a single interview or they don't get to pay their bills next month. That's one kind of stress, but far from the norm.

Having conducted many interviews; there are plenty of people that lock up, but relax when you let them use a laptop even if you stay in the room.

> Few people are in the situation of a single interview or they don't get to pay their bills next month.

If this is true of the people around you, then you know folks who are very, very lucky in their life and work.

I assume we are limiting things to just software developers which tend to make above average salary's in most areas.

Anyway, some combination of cash on hand, liquid assets, credit, or just friends and family should be able to cover next months rent or something is very wrong with your finances. If you just mean need income at some point then sure most people are in that place, but any specific interview should not be all that important long term.

Further, for the vast majority of people retirement is based on personal savings. If you don't have several months savings by 30 that's a really bad sign that something is very wrong.

I say again: if all of that is true of the people you know, even in software, even making above-average salary for your area, you're very lucky.

Also, and I say this as someone currently going through the process: given the way hiring for senior to C-level roles goes in 2017, do not expect "several months" of savings alone will be enough to cover you. Most of the large companies you might like to work for (Google, Microsoft) have hiring processes which can't move much faster than six weeks, and they can stretch out to six months or more.

Most Americans don't have several months of savings regardless of age. I agree that it's a bad sign, but it has a lot more to do with the current economic climate than individual behavior.

For people who earn between $80-$100,000 a year the median 401k account at retirement is ~$255,000 http://www.financialsamurai.com/median401k-retirement-balanc...

(Note median is lower than average but means 50% of people have more) So, having a few months savings is common close to retirement age for people who make above average wages. Scale that back to mid 30's and a few months savings is still common.

A 401k is not a savings account. It's a retirement account. You're not supposed to pull from it between jobs, and there are serious financial penalties for withdrawing before you're past retirement age.

A 401k is also supposed to be able to provide you with an income resembling your at-retirement income for at least 10 years, which is obviously impossible if you only have 2.5x your at-retirement salary in it.

It's a source of stress for me. That, and someone staring at me intently without communicating to me why I need to design Tic Tac Toe or Uber.

Maybe I was lucky, but interviews were far from the most stressful or uncomfortable thing I encountered on the job. They haven't asked me about intricate details either (except one that gave me standard test with questions ranging from difficult to easy, but it still did not felt that horrible).

So, to hit it from the other side: maybe none of that matters.

For an industry practice that everbody is saying is so badly broken, people sure seem to be making it work--or sidestepping the braindamage.

For CTFs like Starfighter, or for any take-home work product exam that is objective ("Pass the tests, meet the performance requirements, etc."), the emphasis is placed on the deliverable and not on the candidate, right?

Which in turn suggests a question--is this perhaps a signal that we don't need to be hiring employees at all if we can just spec out the work correctly and the associated acceptance criteria?

> is this perhaps a signal that we don't need to be hiring employees at all if we can just spec out the work correctly and the associated acceptance criteria?

Try to get any work completed by "spec[ing it] out" on Amazon Mechanical Turk and you'll quickly find the value of employees (or at least, of using "hiring"-like processes to build a pool of known-good contractors and using them for all your work.)

> For CTFs like Starfighter

CTF?

https://en.wikipedia.org/wiki/Capture_the_flag

Just to be clear: the Starfighter CTFs are not work-sample tests.

To me white boarding is no different from public speaking. Each person's skill is at a different point in the spectrum. It has nothing to do with the skills involved for software development itself.

How do you feel about interviews for roles where it's required to keep a cool head under incredible pressure?

(This is a serious question. It describes a lot of the security incident response work I've hired for.)

If you think about professions with legitimate 'keep a cool head under incredible pressure' needs, none of them handle this with uncomfortable interviews.

Can you say more about how they do handle it? I've very little visibility into other professions' hiring practices.

(My housemate who's a middle school history teacher and I were mutually horrified last night at our respective interview experiences. He was hired to teach eighth grade after a single 45 minute Skype interview. I had just had a half-hour phone screen followed a week later by a two hour in-person interview, and I considered that quite short by my standards. I thought his process was ridiculously short; he thought mine was absurdly long.)

I'm 100% behind heavily weighting work sample tests. However, your system seems to minimize the value of non-coding skills. If the interview loop doesn't really matter, how do you answer questions like:

- Can this person communicate a technical concept to another engineer?

- Can this person communicate a technical concept to a non-engineer?

- Can they explain how the code they wrote works?

- How do they respond to technical feedback?

I'd argue that a good half of what makes up a good senior engineer is their non-technical skills. I won't claim that onsite "interview loops" do an amazing job of evaluating this, but it doesn't seem like work sample tests evaluate it at all. If your onsite loop doesn't really matter, how do you test for this?

Chatting about the output of a work sample test is a lot less pressure than a traditional interview; so it can add more signal. It's still probably more pressure than a regular work environment.

Yeah, I don't think it's possible to make interviews comfortable. They are assessments whose results have a direct impact on your livelihood. Even if the interview were "put your name in this hat; if we pick you, you get the job," we would have posts on Medium about the mathematics of optimizing your chances in the hat draw just to calm people down.

This article is a nice reminder of the truism, "don't do things in a shitty way and they won't be shitty." That is, whiteboard interviews aren't inherently terrible, it's just that a lot of interviewers ask terrible whiteboard-based questions, like asking to code in unrealistic circumstances.

But I think that also kind of highlights what DHH and others are trying to get at - a lot of programming interviews are terrible because they abuse the whiteboard, and that needs to stop.

The problem is that you have to have some way to evaluate someone's skill level relatively quickly. Take home assignments will never work. Part time work, or contracting work until you're satisfied is going to be even worse from the perspective of a job searcher. Imagine you get a new job that pays half of what your last job did and then you get dismissed at the end of 3 months and have to restart your search.

I don't understand all the fuss. Whiteboard interviews are unpleasant, sure, but I've done a lot of them and they're not that bad.

> Imagine you get a new job that pays half of what your last job did and then you get dismissed at the end of 3 months and have to restart your search.

I'd take that. You're still getting paid for your work instead of spending months searching with no income. It also gives you a chance to see who you're working with, who your boss is and the state of the code base you'll be spending the next several years of your life on. You don't get any of that in a whiteboard interview.

That form of interview would make company loose on employed applicants. It would also be expensive in case there are more applicants then positions - or you would be back to normal interviews. Also, imagine competing with multiple other people for three minths over which one will stay after three months and who will have to search again. I can easily see how toxic it all could become.

I mean, this is fine if you're unemployed already. If you've got a job already though, I'm not sure quitting that for a lower paying multi-month interview process is terribly appealing. Most of the best candidates who can pick and choose jobs won't choose to do that, so a company requiring that is going to be really limiting their options.

If you already have a job, the likelihood you're going to go through the normal hiring channels is small anyway. There's no reason you couldn't have one hiring process for those you're trying to woo away from other companies and one hiring process for those who may have faced a layoff or whose startup just collapsed.

Or you just have one that works for both and save yourself a lot of headache?

> Or you just have one that works for both

And that is?

> and save yourself a lot of headache?

Which headache are you referring to?

Little reason to pay people less during the testing phase. However, people who have a job are less interested in working for you when it's conditional which reduces the size and thus quality of your applicant pool.

I don't want a temp to hire job. If you put me in than situation, even if I take it, if a better job comes along, I'm going to leave. If I want to freelance, I'm going to charge you twice the effective hourly of my last job.

Most professions have solved it: some really tough, relatively objective, centrally-administered exam that's a strong sign of knowing some minimal competency. Then, point to the authenticated results instead of going through that at each employer.

Yep. I'm terribly confused why the programming "trade" doesn't have this.

Various orgs have attempted to build one, but they're all so easy/rote that they don't actually deliver on that "minimal competency" promise, so nobody cares about the associated credentials.

A real test of this would most likely have to involve a live, observed simulation of real work, so it'd be somewhat expensive to run the testing centers. But a credential that actually meant something would pay for itself, because it could be earned in place of other less-specific credentials that cost a whole lot more (e.g. a college degree.)

Isn't it what a college degree is supposed to represent?

I'm not saying they are what you are talking about, but that they are meant to be such objective exam.

Not really. They're correlated but colleges do not coordinate on the exact same tests for the final exams, nor even what specific classes you're expected to have. (In some ways, that's a good thing -- colleges should have variety on what specifically they teach.) So it's not objective, and it may not meet security standards -- one university may do the honor system and not bother to actively stop cheating, while others may not trust that as a mechanism.

Usually, professions have some test that you need to pass in addition to getting the degree. You have to pass the Bar exam after getting a law degree, the EIT exam after getting an engineering degree (then FE after 4 years under a PE), you have board exams after completing med or pharmacy school , there are actuary/accountancy exams after those degrees, etc.

They serve a more orthogonal role to the degree, in proving mastery of a more specific body of knowledge.

> a lot of programming interviews are terrible because they abuse the whiteboard

I think this puts the cause in the wrong place. The interviews aren't terrible because they abuse the whiteboard. The interviews are terrible because the interviewers have no idea what they're doing or why. I'll grant, if whiteboarding weren't standard, the particular form of terrible interview they did might be less stressful for candidates, but I doubt it would be any more effective.

>This article is a nice reminder of the truism, "don't do things in a shitty way and they won't be shitty."

But it has a non-trivial corollary: a tool is good, to the extent that it's hard to use it shittily (sic).

>>"Back when I was at Google, I was mostly interviewing people for “Developer Advocate” positions, and a lot of people somehow got into the process without being able to code at all. So, early on, I’d ask. “You’ve got a list of objects, write some code to select one of them at random. Any language, don’t worry about syntax, assume the built-in random function is good enough.”

That was actually a nice question: If you wanted to dive a little deeper, you could ask the candidate to sketch in unit tests. And if you’re talking to somebody super-technical, ask “Your code is in production and sometimes it’s throwing illegal-index exceptions under heavy load. What’s going on and how do you fix it?” Just because that’s a cool problem, very real-life, and most people smile when they get it."

Genuinely curious as to what the reasons for illegal-index exceptions under heavy load would be? I genuinely can't think of any reason. Perhaps the problem is under specified. Unit-testing would need to be seeded to be reproducible.

I could see it being some sort of shared memory problem, where the system is misallocating memory because it's running out of free space.

Or similarly, the application is multithreaded and the list length at `idx = randint(list.length)` time is greater than the next line `obj = list[idx]`, when you pick one of the last few indices and objects are removed.

I think the implication is that another thread is modifying the list at the same time, and there's inadequate locking.

I think you need more information about the code and what situation it's in. Illegal index presumably means trying to access part of the list that's no longer there. If it's a shared data structure, perhaps something is popping the list while another is trying to access the last element. But without anything else to go on, who knows, maybe you accidentally stored the length of the list in a data type that could overflow?

Though in the first part of the question (ignoring the next bit), is the answer anything more complex than import random; random.choice(my_list)?

I've been doing interviews pretty frequently lately. Maybe it's just the limited scope of my experience, but I've never asked anyone to code bubble-sort, nor do I know anyone who has ever asked that, nor have I ever been asked that at a job interview. The closest thing I've seen to this, probably, is generic tree-traversal questions, like find the lowest common ancestor of two nodes, or whatever. Apparently the feeling these days is that these sort of questions suck because they're not "real world" enough, and you'll never need to know about such stupid things like "nodes" and "algorithms" and "computer science" on the job.

So now I guess the trend is to ask more trendy, design-oriented questions like, "how would you design Facebook?", etc. But the problem with all this backlash to algorithm-heavy whiteboard interviews is that it ignores the reality that there are tons and tons and tons of crappy candidates out there. I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level. It's not that I am claiming that most on-the-job programming is implementing algorithms and data structures (it's obviously not), but being able to do these things indicates a certain quantifiable level of aptitude.

The trick is to present the questions in a way that isn't vulnerable to rote memorization. Don't ask someone to simply code a tree or graph traversal algorithm. Instead ask them about the most efficient way to route packets or whatever. And more importantly, tailor the interview questions to the actual experience they claim to have on their resume. If they claim to be a machine learning expert, ask them to sketch out how a multilayer-perceptron actually works. If they claim to know about the Linux kernel, ask them to design a page-cache, etc.

I agree the "you have 5 minutes to implement quick-sort now!!" is not helpful. I also hate the stupid logic-puzzle crap. But let's not completely dumb-down the whole interview process as a remedy to all this, just because "real-world" programming is more about import java.util.* rather than coding up custom radix tries.

> I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level.

If the position you're hiring for involves those things on a regular basis, fine. If not, you're probably selecting inefficiently.

The reason for the swing over into high-level questions is managers are learning that smart, often academically-inclined engineers will happily burn weeks on something they find interesting but adds value incongruent with the expenditure. The recent trend of hiring experienced engineers to be engineering managers either exposes the problem or exacerbates it.

If two candidates are equally qualified to do the job, but one demonstrated they can think through high-level designs -- I pick that one.

> the reality that there are tons and tons and tons of crappy candidates out there.

Maybe we need to start asking why that's the state of the industry right now. How did it come to this where quantity is so high and quality is so low? And how can these candidates better themselves?

Because it became cool and well paid and thus many guys decided to give it a shot, fake it till they make it. Some even succeed. Also, because many peoples confidence is much higher then skill. They get away with it because confidence tend to be confused with ability.

It's probably more related to the universal constant that 90% of everything sucks.

I absolutely hate whiteboard interviews.

I have been lucky enough to have had only one whiteboard interview in my career and I will say it was awful. Luckily I didn't really need the job as I had freelance on the side. IIRC the company was TripAdvisor... I will not name the interviewer's name but he does have a blog... sadly I think he is actually proud of his interviewing and management techniques).

I have absolutely terrible handwriting and even worse ability in penmanship layout (basically what I call consistent and appropriate spacing).

Before the interview the interviewer didn't even shake my hand and barely made eye contact with me. He looked pissed before we even started (its ironic again because the guy praises his people skills in his blog). In the interview I was asked to do a binary tree sort. I did it recursively. He wanted it to be not recursive and with an array.

At this point I was pretty nervous and my whiteboard looked like a 5 year olds scribbling. I just wanted the interview to end so I sort of just gave up.

A couple months later I ironically started a successful recruiting software company. Even more ironic the interviewer later tried to start his own startup but failed and had to go back to TripAdvisor (this was about 3 or 4 years ago).

I tried to connect on LinkedIn with him to give him some feedback... alas he did not connect.

The reason I wanted to leave him feedback (besides the sick inkling to rub in my success) is I have learned so much from my recruiting software company. I see people desperately applying for jobs everyday (we are career portals as a service. We try to make the apply process as painless as possible).

People seem to forget how uncomfortable it is to go looking for a job (probably why he went back to his old company).

Being able to communicate via whiteboard is a useful skill. I'm not good at it, but I appreciate those who are. That seems to be what this author is advocating: jotting down ideas, designs, diagrams, temporary notes. If the team depends on everyone being comfortable at a whiteboard, then it's worth testing at an interview.

I don't think that is what most people are pushing against, but rather actual whiteboard coding. Taking the whiteboard out of the picture, the task is to write code in an unrealistically broken editor. You get a partially functioning backspace but no insert, indent/outdent, search/replace, etc. And the editor restricts your typing speed to 10% of your normal capacity. On top of that, strangers are staring at you.

If whiteboard coding really leads to better hires than other forms of evaluation, I'd like to see the data.

I don't think anyone has any issue with having to physically use a marker on a whiteboard during an interview. What else would you use for a system design question?

What is insane is expecting a candidate to be able to navigate a million state modification and off-by-one gotchas using only a marker and their short-term memory.

> I don't think anyone has any issue with having to physically use a marker on a whiteboard during an interview.

I have friends whose RSI is sufficiently bad that it could be an issue.

Seriously people think whiteboard interviews are reason for diversity? I think the much bigger reason for diversity issue is that companies are reluctant to even interview if you don't have a brand name associated with your profile(a tier 1 college degree or previous exp at top tech firms). There are lots of job postings these days which state tier 1 college degree as requirement. I am from India and here the situation is if you are not from a tier 1 college you are a moron and designated to do low quality cheap work. It may not be the case in other areas like the valley, but here it seems the filter for participating in the interview has more to do with diversity than how interview is conducted.

I'm glad he does it right. Now if the people interviewing me could do it right, that would be great.

I think the optimal solution to the hiring problem requires trying out the actual relationship. It's similar to dating. Predicting the long-term success of a relationship based on a first date is sub-optimal.

A service that provides this "trial relationship" could work. When I'm looking for a new job, I could do one hour per day of real work for a few companies. After five days, both employer and prospective employee will have a better understanding of each other than a single day of interviews allows.

There's practical concerns. Companies certainly wouldn't give prospective employees full access to internal codebases or data. Companies would have to break off small tasks which could devolve into throw-away take-home assignments. Employees at the company would have to endure the annoyance of dealing with prospective hires. It might be worth it for everyone.

This is sadly rife for abuse. Why hire anyone? You can just string enough candidates along to possibly not work a full solution but it could be a first line or give you a fair number of prototypes. Granted I don't know that this could ever be viable but companies would sure try because free work > paying any amount. I think most of us understand the phrase 'you get what you pay for' and yet I've personally seen many individuals and companies believe they're getting a steal.

I feel like there are a few good ideas. I personally love the idea of work related assignments but only if the result is actually measured. If I don't get the job I know I've wasted my time and I can handle that. What I can't handle is giving me a task and completely ignoring the results. What will that signal to me about day to day operations? That you'll likely ignore the very real value I bring to your organization on a consistent basis. That's a big enough red flag for me to stop everything and walk right out the door. If I'm supposed to extend the courtesy of not wasting the interviewers time I expect at least some attempt at that same courtesy.

The issue is the dependence of code completion, google, and IDEs that writes boiler plate code for you, and companies just use stupid services like hackerrank to test algorithm implementations, which has to run and compile properly u see that environment.

Two weeks ago, a coworker and I were thinking through ways of implementing an extension to a library we've been writing for a client. We were drawing all sorts of things to come to a consensus of what to do. Through doing all of that, I finally experienced a real-life reason to whiteboard code, since after writing down psuedocode on the whiteboard explaining the implementation that we were agreeing upon, everyone on our team "got it" immediately.

I think whiteboard interviews are incredibly useful. We use them in our interviews, and they've been successful in helping us learn more about our candidates' abilities and for them to show us what they know.

In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?".

To this day I'm very suspicious when I don't get a coding task on an interview. That's generally a pretty bad sign. Best option is when I get a notebook with "my" IDE, but I also coded on whiteboards, paper, Google Docs.

Frankly, I don't know what other options are there. There should be code in the developer interview. Take-home task? GitHub account? Probation day?

> In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?".

At the end of a day of interviews for a consulting gig a number of years ago I was asked to sit in front of a workstation and type while most of the developers were watching. I asked "Type what?" and got the answer "Anything." I started typing a paragraph from my resume and after one sentence the interviewer said "Stop, that's fine. The last guy who made it through the interview couldn't do that."

It turned out to be a fun project.

On one interview they asked me what my favorite pattern was. I said "visitor", was already about to start explaining but heard a deep breath-out and "thanks God he didn't say singleton". Appeared they had it pretty high in hiring criteria.

I've written quite a bit of Java in the last year (though not in the last couple months), and a fair bit before that. I'd have a low probability of giving you a correct answer to that question without references—I have several possible approaches but I'm not 100% certain which would work without checking. Can I treat Java strings as arrays? Or is there some kind of toArray thing I need to do first? I think so but I'd have to check to be certain. Is there a string-reversing util method somewhere? Quite possibly. How do I read it one byte (glyph? Ugh, I can't remember how Java strings work and I have Go on the brain, I think) at a time if the treat-as-an-array thing doesn't work? God, I don't remember. What's string length again? size, length? Maybe even len? Assuming I figure that out, was that a property or a method, now? Hell if I know, it's not like I've written more than a dozen lines of Java outside an IDE, ever, unlike some other languages. I suppose I can use split if I have to (it's just called "split" in java, right? I can't remember for certain, of course!)

I'm sure some people memorize this stuff. Plenty of us, I'm sure, if it's not something we use ALL. THE. TIME. rely very heavily on tools, context (i.e. cheating for syntax by looking at surrounding lines) and documentation. I haven't been doing tons of specifically string manipulation in java lately, so I'd likely be screwed on this question.

I dunno, I guess by that standard I know zero of the 7-8 languages I've been paid to write over the last fifteen years or so.

I'm not saying it's a good task, I'm saying that people failed it despite we were thinking the task is trivial.

But still, I'd expect Java developer to know that Java strings are immutable and that you can't treat them as character arrays. It's totally OK to not know how toArray method is called (toCharArray). Assuming there's a kind of "reverse" method is a bad idea - even if there would have been one, it would clearly be not what we ask. Same for "I'd use StringUtils.reverse(...)" from whatever package. I won't mind if you write a.length() for array or a.length for String, this does not matter much. Knowing a difference between a byte and a char is, however, quite important in my book.

The "usual" solution is to str.toCharArray() and then iterate this array to the middle, swapping i-th and (length - i - 1)-th characters, then new String(array) with the result.

For this solution you only need to know fundamentals of the language and vaguely recall that there was some method to convert string to a character array.

Bonus points (figuratively speaking, there were no actual points) were for: writing test cases, checking the argument for not being null or showing how to swap two characters without using an additional variable.

Do you think IDE would help much? I don't think so. IDE would have helped you with the unimportant part (how was that toArray() method called exactly). But you'd need to know how to use a cycle to reverse an array. You need to know what the difference between a byte and a char is (in order not to choose the getBytes() method instead toCharArray()).

> Do you think IDE would help much? I don't think so.

It'd help quite a bit with the parts that make writing this in Java different from talking through a pseudocode implementation, yeah.

Or just let them write pseudocode instead, since you've written you don't care much about the details (aside from knowing you need to take care when manipulating strings that you're operating on the correct unit in order not to turn it into gibberish, which is a universal detail, not specific to Java). Bonus to that approach: you haven't just made your candidate incredibly self conscious over and distracted by things you apparently didn't care about to begin with, and there's also a lower chance they'll try to correctly use the language in ways you don't like and expected them to guess you don't like (e.g. using a single utility method that solves the problem immediately).

We've tried it with pseudocode. People wrote Java.

The IDE would make huge difference for me and this question. It would allow me to instantly know string api which I normally don't need. Also, it would add confidence that what I am doing is actually java.

I don't mind whiteboard in general, however expecting me to solve language specific question like this is weird - especially in language like java that is never written without IDE.

Well, yes, in an interview for a Java dev position I'd expect the candidate to be able to write code (whiteboard/paper) which at least remotely resembles Java syntax, is logically correct and does not break universal things like byte vs. char.

> It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?".

This is the kind of bias that I think an interviewer should never have, and part of what makes interviews so stressful: that your ability is called into question off of something very simple. You don't know whether the candidate knows Java or not. You only know that the result of the interview is negative, which could say just as much about the interview as it does about the candidate. Assuming "you don't really know Java, do you?" with so little evidence strikes me as disrespectful at best. Why is this considered OK?

ashark makes a lot of very good points as to why someone may know Java but stumble with this question.

Exactly. So many of the proponents of the whiteboard algorithm question industry are thoroughly convinced that they are eliminating people who will fail on the job. Of course it's impossible to verify this. The only thing you can verify is the performance of candidates that do pass your test and you subsequently hire. I'm sure there are a lot of bad hires even at the companies where they use these interview techniques. The believers are clouded by survivorship bias and confirmation bias. They get no information from those that they reject and they refuse to acknowledge the bad people that they accept.

Didn't the guy who started WhatsApp fail his facebook interview? :-)

http://www.businessinsider.com/facebook-rejected-whatsapp-co...

Here is some debunking of other commonly held misconceptions about this interview strategy:

1) The questions are not tricks -- actually every coding algorithm question that has a "naive" solution and an optimized solution requires a trick. That's why you can study for these interviews. The studying involves memorizing the catalog of tricks and identifying which one to apply based on the question. Even the simplest and most commonly used tricks (using a hash table, multiple pointers into the same array / multiple accumulators, bit shifting) are still tricks.

2) The interviewers have a large catalog of these questions so you're not going to pass by memorizing stuff. As I mentioned in #1 above, this is false. The list of tricks that need to be employed to solve these puzzles is finite and definitely less than 100. Most common interviews will probably be solved by one of the top 10 tricks.

This page has 80 solutions: http://www.geeksforgeeks.org/top-10-algorithms-in-interview-...

3) This method may have too many false negatives (when they reject a candidate who would have been a good member of the team) but it eliminates false positives (when they hire a candidate who cannot code). With enough dedication and time, anybody can train to pass these. It's not really a skill that is super useful for getting things done in a programming job.

Some people are very good at riddles but have no common sense. They do not make good members of a software development team but they are very good at these interviews.

Tricks? Algorithms? Puzzles? Riddles?

Are we still talking about string reversal task?

You write "with so little evidence" without knowing what the evidence actually was.

The string reverse question is a pretty poor one in my opinion, you'd be better off with FizzBuzz.

The smart arse answer to your question would be

new StringBuilder("my string").reverse().toString()

The question sticked as a tradition, everyone had it on the interview.

Noone ever gave the smart arse answer, by the way, but some people said "you're not looking for the library method, obviously".

Maybe I'm out there as far as this topic is concerned, but as a software engineer I enjoy whiteboard interviews. If you can't get up in front of a couple potential colleagues and talk/draw code, how are you supposed to whiteboard complex designs in meetings after you are hired, possibly to higher-ups?

But I agree there should be set parameters in an interview: ask every candidate the same open-ended design questions, stress that they just use pseudocode, keep the problem questions small (5-10 mins max), don't be a overlording interviewing jerk, etc.

> By the way I got one of those in my interview day at Google, and another at Amazon, and I blew them both.

Interesting to hear this, can't have done that badly as he got jobs at both of those companies!

Whiteboard really helps one to express his/her thought process to the other person and I'd hope it will continue to exist in the interviews.

The whole topic is about coding on the whiteboard, not just expressing the thought process.

Then the interviewer should explicitly say he wants to know your thought process too. 99% of them just say code this and let me know when you are done

Reply on news.ycombinator.com