Hiring without whiteboards

But the earlier comment wasn't talking about _traversing_ a tree, it was talking about _balancing_ it, which is a much harder problem and one I wouldn't want to do without google either.

Posting a reply for @tsion, who seems to not be able to post at the moment:

I interviewed on-site successfully at Google Seattle about a year ago, and I was given the option between writing code on a whiteboard or in a text editor on a Chromebook, being projected onto the screen in the room, so the interviewers could easily follow without awkwardly looking over my shoulder.

Of course, I picked the text editor. I can't imagine wanting to write code on a whiteboard. However, I did use the whiteboard voluntarily as a thinking and planning aid.

Unfortunately, I also heard that the text editor option was only available at certain offices at that point. I really hope coding in a text editor becomes a universally available option because it's just so much more natural. It essentially put my mind at ease and helped me think more clearly.

On a more general note, my strategy, which seemed to work well for me, was to treat the whole situation like a pair programming task. Even though the interviewer won't directly tell you what to do, they will often comment on things if you question yourself out loud enough.

That sounds better than an interview, but a written test is not representative of many types of work. In most kinds of work you'd have days to work on a topic, access to reference materials, the ability to discuss with colleagues and ask for help, etc.

Test results probably do correlate with job performance, and it may be better than an interview (not sure) but it's say it's still quite a long way from giving an accurate answer.

That's nice of you to say, though I'm not sure I earned your compliment.

Re experience - yes, if you're interviewing for someone with deep Java or ML knowledge certainly make sure the interviewer can assess that.

Logic puzzles are not perfect - I used to be really good at solving them and if I ever have to interview on them again, I'd definitely have to practice first, to get up to speed. But I do think that being able to solve them is a meta skill. If you get really good it entails that you are good at reasoning and solving complex problems, or at least a specific class. If you are good with trees you'll likely be able to answer a trie question. It doesn't mean you're just good at that, but that you can apply knowledge to new problems - which is exactly why you are hired. An equivalent real question I got in Java was how to access a private member of a class. If I knew the answer it would mean I have some random bit of trivia in my head. If I solve it using Java knowledge it means I can apply my domain expertise in a new way - that's compelling proof of problem solving skills. If I ask why would you want to do that, it indicates reflective and critical thinking skills.

A seasoned engineer in ML or Java should, imho also be able to solve puzzles. They are, in many ways, better proof of abstract thinking abilities and problem solving skills than specific knowledge. But I agree they are both important - if I want to build a search engine I prefer to have a seasoned ElasticSearch lady lead the project than an equally smart person with no background.

Re your friend, if it helps, I interviewed at a lot of companies and probably failed about 70% of interviews in the first week or two. I got much better after a few weeks, which proves your point that interviewing is also a skill. And I mean for both tech and behavior questions. That's normal, I think.

Re Google, while I don't represent the company, there are public statements that they'd rather have a false negative rate rather than false positives. It's better to say no to a great applicant (politely) than yes to a bad one. If you've ever had to let someone go, or deal with a bad team member, you know what I'm talking about. Of course there's the occasional interviewer who asks a silly question or gets something wrong. Do you never make mistakes? It's impossible to ensure everything goes perfectly in such a large company, but I can tell you, as someone who works here, that people try really hard to do a good job at it, and leave everyone with a good impression. It's the rational thing to do: if you treat people poorly 1. You're and asshole and 2. They'll hate you. Nobody likes assholes especially at Google, and I can share that I haven't met one yet. That's pretty amazing given the size. Thanks for engaging in this discussion, I really enjoy it.

Great reply. And I'd like to refute them :)

Let me foreword by saying that I am not against coding interviews in general. But, I am against the interview process as it is implemented NOW. As implemented today, the process is overweight on coding optimal solution with good coding style.

Translated to humanese: "It doesn't matter if you invented linux kernel at your last job. We can't hire you because you didn't solve this tree problem in time or had bad coding style as COMPARED TO OTHERS who don't know shit but can code puzzles on whiteboard"

What I think an ideal interview score looks like:

Score = w0(whiteboard-coding skills) + w1(algorithms) + w2(area of expertise) + w3(design) + w4*(lets work together to invent something new/passion for engineering)

As it stands, the interview process has the following weights: w0=49%, w1=49%, w2=1%, w3=1%, w4=chunk change

See what I did there? The way interviewers in these companies are hiring is by calibrating their favorite coding puzzle over a wide range of interview candidates. They simply don't account for the fact that that person might genuinely be good at something that the interviewer doesn't even know exists.

>> A seasoned engineer in ML or Java should, imho also be able to solve puzzles. They are, in many ways, better proof of abstract thinking abilities and problem solving skills than specific knowledge.

You keep asking for proof that the candidate should be awesome. Where's the proof that the interviewer can adequately judge based on the equation I gave above? The candidate could be seriously good at ML but if you send the average java coder at Google to interview them then gosh, how would they even recognize his genius? Now you'll say we have 5 rounds to eliminate biases. Buuutt, the way the hiring committee reads interview packet is, and I quote you:

"It's better to say no to a great applicant (politely) than yes to a bad one"

Which means, even if two interviewers think this awesome ML guy is GREAT, the candidate wouldn't be hired because the other 3 interviewers were incompetent and marked the candidate no hire.

What I'm trying to say is that the hiring committee based process encourages actively removing smart people and selecting the ones who solve whiteboard puzzles. The candidate could be a shit engineer in person but as long as they solve code puzzles in those 5 hours they get hired. Make sense?

Look, I'm not saying we need to eliminate coding rounds. All I'm saying is balance it out. A person who can solve a tree problem in one round surely doesn't need to be asked another stupid coding problem (which is asked just to make sure some random crackpot didn't squeeze in through the cracks). I mean, if you don't have confidence in your own interviewers that you need to keep asking those problems, what does it say about the process? That you don't trust your own interviewers? Isn't that the real problem?

You can choose to ignore all feedback I give here but then, I'd specifically call Google out and say that they're not a great engineering company until they figure out that their hiring is broken and they need to stop having their mediocre engineers keep rejecting the good ones.

Or...if you really care about working with great peers, show this answer to hiring committee and see what they think. They need someone to tell them, "Hey, why are you implementing a process that self selects mediocrity"

P.S: Why do I know it is mediocre?

1. Other companies have tried the same process and it didn't translate to anything

2. You know there are enough mediocre engineers at your workplace :)