Hacker News Reader

Comment by rawnlq | Hacker News Reader

It is possible that eclipse users are more used to relying on their IDE for auto-completion so they can't whiteboard as effectively...

View on HN

I hear stuff like this a lot, which seems to rely on whiteboard interviews expecting people to know method names. Do anyone but the worst interviewers actually _do_ this? That's a serious question, since my experience in this regard is pretty skewed. I've been doing whiteboard interviews for years now, including for a couple of years at Google, and the notion of ever expecting a candidate to remember a method name perfectly is beyond insane to me. I'm not OCRing their code and dumping it directly into a compiler: why the fuck would I care if they used size() or length() when checking how long a string is[1]?

[1] Yes yes, I'm aware that this example isn't perfect because it could mean different things depending on the language

I'd like to hope they don't!

Interviewees, however, tend to get flustered if they can't remember the method names. It's another rock on a pile that eventually leads to nervousness collapse, something that happens far too often, so after a few dozen interviews I've started stressing up-front that no, it doesn't matter, I'm not scoring you on that.

That, on its own, produced a measurable increase in average score.

What do you score on?

It all amounts to "Would I like to work with this person?", but a couple of things. Persistence, memory, ability to learn -- not trying the same thing over again if it doesn't work -- intelligence when possible, knowledge if I expect them to have it.

That's pretty vague. I use the same strategy as the sibling post, ratcheting up difficulty until the candidate fails, so I usually have a lot to go on, but the exact criteria end up changing from one interview to the next depending on what the candidate did.

Occasionally I end up with not enough data. I try to give my feedback in the form of a confidence interval, but if it's mediocre candidate combined with not-stellar signal quality... figuring out how to score them can take a while.

Yea, I know how stressful it is to read the tea leaves of what an interviewer is actually looking for, so I'm always extremely up-front about the fact that I don't care at all about certain things. Hell, I've even told people that an incorrect final answer isn't a big deal: one of my favorite strategies is incrementally racheting up the difficulty of a problem until the candidate gets stuck. The richness of the information you can gain from this process is fantastic, though again, you have to couch it in a lot of communication to the interviewee that they shouldn't get stressed about not perfectly crushing the problem.

> I've been doing whiteboard interviews for years now, including for a couple of years at Google, and the notion of ever expecting a candidate to remember a method name perfectly is beyond insane to me. I'm not OCRing their code and dumping it directly into a compiler: why the fuck would I care if they used size() or length() when checking how long a string is?

When I interviewed at Google, a major part of the rejection feedback they gave me was "we felt like you weren't worried about whether your code would really run".

FWIW, during the coding sections of Triplebyte's technical interview, you're allowed and encouraged to look up documentation, search Stack Overflow, play around in a REPL, run and test as often as you'd like, etc. It's what you'd do normally in a non-interview situation. (Not a whiteboard situation.)

Reply on news.ycombinator.com