Comment by killface | Hacker News Reader

Comment by killface | Hacker News Reader

Shitty interviewers ask:

1. Anything related to trees 2. Big-O trivia and errata 3. Reinventing the wheel 4. Bit-twiddling operations

Seriously. If I go into your interview and you ask me to reverse a string, and it's not <string>.reverse(), I'm not taking your stupid job. I don't care if you want me to know the tricks for an in-place string reverse with no temporary variables, that just shows that you don't have a clue how to interview.

Good interviewers? The best I've found so far:

1. Ask people to do real-life problems 2. No "gotcha" questions 3. Let people use the environment they'll be using for the job -- this means an IDE, the internet (including stack overflow), and any library they want.

What I want to see when I'm interviewing is whether or not you have the ability to solve a problem. I'm going to look at how you abstract and break down problems, how you solve them, and at what point you say, "I think this is done."

Yes, I expect good engineers to know when to use a tree or a list or set -- but if you're explicitly quizzing for that, you're probably filtering in more terrible developers than you're filtering out.

> Shitty interviewers ask:

Google does none of what you prescribe for "good interviews" and they have interviewing down to a science. Yes they've admitted they err on false negatives, but that is acceptable because they have little to no false positives.

From what I gather you want an easy interview. What you wrote is impractical (though I agree gotcha questions can be a bit much).

As a candidate, I get 1-hour with you and I need to accomplish the following:

1. Does your resume reflect your experience?

2. Can you code?

3. What is it like to work with you to solve a challenge?

4. Sell you on joining us.

Real life problems may fit in an hour, but may not.

There are so many resources on programming interviews that spending an hour or two during the week prior would pay off dividends in a candidates success rate.

I interviewed with Google last year and the interviewer did two of the four things listed in killface's post. I actually do not agree with killface that those four things are necessarily bad (programmers should at least be able to make really good guesses at complexity, and know about trees), but at any rate, Google definitely had no fucking idea what my capabilities are as a developer after that interview, so incompetent was the interviewer.

It was actually one of the more terrible interviews I've been a part of, and I was not disappointed by the negative result. Google certainly believes they have interviewing down to a science, but I suspect that belief is itself not scientific, and instead just the usual bullshit and collective delusion.

Reply on news.ycombinator.com