[pmikesell]

Thank you for writing this post. Whiteboard code interviews get a lot of hate on HN and I suspect that folks who have come to rely on them for part of their hiring signal have simply stopped posting.

I've done a lot of lower level systems work and the fact is that even with a long career and history of very successful product I get whiteboard coding interviews when I look for a job ... and it's just fine. Yes it's not the same as day to day work, but it's related, and I have to admit that I find them kind of fun.

Maybe there are 2 types of "programming jobs": 1) you will have to implement data structures and algorithms, or 2) everything will be provided for you in a language or framework. For job type 2) CS is not needed - it's not a computer science related position ... it's "frameworking". I'm guessing that a lot of the whiteboard hate comes from type 2) people applying for type 1) jobs, OR type 2) companies asking type 1) questions.

For more history around whiteboard coding, there's the excellent "Why Can't Programmers Program" post: https://blog.codinghorror.com/why-cant-programmers-program/

I would like to actually figure out what is the bet way to do interviewing for coding positions but it's super hard to actually have these kinds of discussions on HN now without people getting upset at even suggesting whiteboard coding interviews.

[creato]

> Thank you for writing this post. Whiteboard code interviews get a lot of hate on HN and I suspect that folks who have come to rely on them for part of their hiring signal have simply stopped posting.

It seems like there's a population of engineers that is perpetually interviewing. I think the people that post significantly about this are people that are struggling with frequent interviews, and correctly or not, lash out at whiteboarding as why they are having trouble.

Maybe there's some large pool of otherwise qualified people that just can't pass interviews and are being passed over because of it, but I really doubt this is significant.

My personal opinion: I don't mind white board interviews. I'd do a take home test, but I would prefer a traditional interview. And being a short term contractor (also comes up frequently in these threads) as an interview process is obviously impractical.

[bfung]

The pay in software engineering, esp. in the bay area, is very high. Companies here never have enough engineers for one reason or other - the situation makes current engineers always looking for higher pay regardless of their skill level, and people not in the industry wanting to be in the high pay field.

[skwb]

You forgot to mention the permutation of companies "wanting" 2), but using the search strategy optimized for 1) approach due to:

- poor HR communication

- poor ability of hiring managers to know what the job entails

- hiring managers past experience hiring primarily for 1), but assuming projects that now need 2)

[onlyrealcuzzo]

As a hiring manager, I agree wholeheartedly with the root comment.

I love whiteboard interviews. Really. I do.

The problem is -- most start-ups are terrible at them. And most people interviewing at FAANG don't understand the reason those companies ask these types of questions.

Top tech companies ask hard interview questions for a few reasons.

They're not necessarily trying to hire the best people. They're trying to ensure the people that they do hire aren't incompetent. Hardly anyone incompetent is going to pass Google's interview process. Period.

Why are they so focused on not hiring incompetent people? It's not easy to fire people for being incompetent (or even worse -- toxic).

So if they're just trying to not hire incompetent people, why are the algorithms questions MUCH harder than the problems you face on an average day?

Two reasons. One, they have so many people interviewing, why would they not set the bar arbitrarily high? Two, the amount of people willing to cram and do almost anything for the job means they HAVE to set the bar high.

Now let's talk about the beef with start-up whiteboard interviews. Most of these interviewers have never been formally trained. They're just winging it. They ask questions that don't lend themselves well to a whiteboard. And they don't know what to look for during the interview!

A good whiteboard question does not rely on a trick or an obscure data structure. It doesn't have any gotchas that if you "get it" make it much easier.

A good question is slightly difficult to solve, but has many possible ways to solve it -- each with it's own trade offs. Ideally, none of them are much easier or harder than the others.

It's MUCH more impressive if a candidate can come up with 2-4 ways to solve a hard LeetCode easy problem or an easy LeetCode medium problem -- then for a candidate to happen to know the right combination of obscure knowledge to solve 1 LeetCode hard problem.

If you have 2-3 whiteboard interviews, and a candidate can come up with 2-4 totally different ways to solve the problem, and he materialize those thoughts into code -- there's a very slim chance s/he's bad.

The ideal candidate can discuss the tradeoffs of different solutions, and ask clarifying questions about the usage to figure out an optimal solution.

When you get to performance tweaks for edge cases, can the candidate weigh the pros and cons of adding the complexity for a certain gain.

Is it worth it to add some complexity to class to take an algorithm from 2n to n? Maybe. It depends on a lot of things...

I once worked with a guy who would ask a question that could be solved in O(N) time and O(N) space somewhat easily. But the question could also be solved in O(N) time and O(1) space IFF you knew some (discreet) discreet math. Almost everyone who didn't get the O(1) space solution he would say was a no hire.

Probably less than 10% of the engineers I've worked with have taken discreet math...

Another guy would ask a question that MOST candidates couldn't even comprehend, let alone come up with a solution. Most of the people that solved it would solve it O(n!) Or O(n^3). Occasionally, people would solve it O(n^2). But there is an O(n) solution. And that's what he was looking for. Literally NO ONE ever got it.

These are not good interview questions!