Ask HN: Do you expect interviewees to “ace” whiteboard coding exercises?

"Doing fairly well" to me is: you asked the right questions and converged on the solution, even if it took some time. Doing poorly means: you made stuff up instead of asking questions, you invented a convoluted way of solving the problem when some other data structure would have basically solved it for you, etc. It's also painful when the candidate's mental model of computation is miles away from reality.

Obviously, getting it right the first time would be great. But I'll settle for something not obviously insane.

No, I don't do them at all. Stop telling people to code on the whiteboard for god's sake

My two cents: (not hiring for a well known west coast company, but still)

This is how I rank candidates. Let's say for a common question such as lowest common ancestor in a BST.

1. if they know the solution already and tell me they know it - major points, most interview prep books include it and they came prepared and they are also honest. I let them implement it still (and add some twist of my own)

2. If they don't know the solution and still figure it out, might even score higher, but people can "act" that they know it and some interviewed will fall for it. I want to believe I catch bad actors but can't say I can catch good ones. In any case if this is a question that appears in an interview prep book, I would expect them to know it (most people don't)

3. If they don't manage to implement it correctly, this is the biggest turn off. You CAN write correct whiteboard code if you WANT. I'm not with a stopwatch. If you don't then I consider it as sloppiness (more than "you can't code")

4. How you talk and behave - most important. If you can't figure it out yourself but ask me questions, if you try a simpler problem first, if you talk and explain what you are doing, if you run your ideas with me asking what I think, if you are determined to figure it out, ask for hints and immediately understand them and get this "aha" moment of how didn't I think of it rather than oh sucks I didn't think of it. If you are excited about the solution more than the fact I gave you hints for it, then I'd like to work with you. Asking questions is so important. Also not arguing with the interviewer and being a nice person really helps. I prefer shyness to overconfidence. Arrogance is an immediate no. Asking questions leads many times to a yes. Even if you didn't ace.

Bottom line with the existence of books courses and forums that list so many interview questions (some are on algorithms that took several years to develop) so knowing the solution is likely to be known from a book means you are not tested on your academic algorithmic development skills, you are tested on implementing something you read on CtCI with a twist perhaps. If anyone reads CtCI then interviews will just become harder.

How many secretaries are there? By this reasoning, if there's one secretary, that secretary is worth millions.

I don't understand how whiteboard algorithm challenges with a curveball or brain teasers are any indication of a developer's value add. Why would you not pair program with the candidate, and give them resources that are normally available to software developers? Memories are formed or helped by relationships (see mnemonics) and when you remove all context you're getting only a narrow view. You can "see how they think" by working with actual code.

It seems like the biggest players complaining about the lack of native tech talent in the US are the ones who give the worst tech interviews.