Hacker News Reader

Comment by more_corn | Hacker News Reader

I had a friend at google who got so sick of people who couldn’t code his first question was “write anything in any language on the board”. About 50% of interviews ended there. I question if that was a reasonable way to start since it is a terrifying social question (what’s the hardest thing I can reasonably do that meets his unknown criteria). It is therefore probably a better test of professional confidence (though that’s really great to have too).

I went the opposite way. I got sick of adversarial interviews. (If you can do the job we’re on the same side. If you can’t you’ll be miserable here so we’re still on the same side). I started opening my interviews with “what did you have for breakfast?” To set the tone of at least everyone can answer the first question. The last guy I hired sheepishly said “I skipped breakfast” but I still counted it a pass.

View on HN

It's better to actually give a dead simple question instead of leaving them guessing. When interviewing interns, we would start off with "print all the items in an array" - besides for instantly weeding out candidates who couldn't code at all, (and there were a surprising amount), it's also a great confidence booster for them before moving on to the real question.

I had an interviewer ask me "how do you copy a file in Unix". Which was a good intro to the rest of the interview... Which was, "let's brainstorm together other ways to copy files around until we run off the end of what you know". Was a fun one.

It was too long ago to remember details, but I suppose the interview got as far as "the data link supports 16kbps, the far side doesn't have compression software, but you have to move 10e6 zeros in less than 30 seconds, how?"

"Wow how'd you pass Google's lang interview so quickly??"

for(;;){}

> write anything in any language on the board

That is a horrible question that tells more about him then the interviewee.

Why? When I read that comment I looked up and laughed, imagining what I would choose. I’d probably laugh in such an interview — and why not?

It would lead to lots of enlightening discussion.

Yeah, "no right answer" questions open up the opportunity to work together in a dialog, which simulates real work better than "test style" questions.

I also had great success hiring for IT ops by telling the person, "we use some systems you are not familiar with here, so I'm going to spend the next 10 minutes teaching you the system, and then we'll discuss how you'd diagnose it when you get your first page about it". This tests their ability to learn something new, to engage with an unfamiliar situation, but in the context of mentorship. The only problem with such an intimate technique is that when someone bombs it, they really really bomb it: There's just no hiding what's happening, as it's happening.

Because it is a question that can't provide a positive signal, only a negative one, and since the negative signal is kind of flaky. I.e. somebody "passing" this by writing some code doesn't actually give you any confidence in hiring them. It is only going to filter out people who can't code at all, and then you have to ask them a real question. But due to giving the candidates no guidance, some who actually know how to program will not just bang out something simple in as minute. They will think it is a trick question; or waste time choosing what to write rather than just do it; or start writing something far too complex for the purpose of just passing the quick filter.

It is a profoundly shit question, setting up candidates for randomly failing.

10?"FSCK GOOGLE"

20GOTO10

Reply on news.ycombinator.com