Comment by acangiano | Hacker News Reader

Comment by acangiano | Hacker News Reader

Parent Full thread

At IBM, I review hundreds of resumes and interview dozens of candidates each year (mostly students or new graduates). I used to ask tough algorithmic questions, require a small coding assignment, etc. I no longer do that.

Today, I have technical conversations like you describe. I don't need you to remember that 415 is Unsupported Media Type. But I need you to be able to discuss how REST works, the difference between 400s and 500s error codes, and maybe even REST vs GraphQL advantages and tradeoffs, if you mention the latter on your resume.

Occasionally I get a surprised "This was so nice. I was expecting a coding interview". It was a coding interview, just not the kind the candidate is used to.

You can look up specific answers on Google, but you can't quickly google your way out of a conceptual discussion, your involvement with past projects, technologies that excite you, etc.

Generally speaking, I can tell within 5 minutes who is a great candidate.

Luck might have played a part, but I have not had a single bad hire with this method so far. In fairness, I'm selective with the candidates I decide to interview, from usually large pools. For these, I also tend to review code they've written in the past if they specify a GitHub account on their resume.

I've done hundreds of interviews for candidates over the past twenty years and couldn't agree with you more. The ultra rare occurrence that someone can talk their way through and elude b/s detectors is usually caught later in the interview process anyway.

Same. Hired 12 developers so far with this method and I made only one mistake, others are all great developers.

What does "the mistake" look like?

You can't always easily tell when someone is going to be a pain to work with on an interpersonal level.

I've seen places (well, one place) that have "team meetings". You just have an informal group talk with a few members of the team, and just usually reveals a lot -- to both sides!

> In fairness, I'm selective with the candidates I decide to interview, from usually large pools.

I agree with your thoughts on interviewing, but the "real-time coding" session in my mind isn't part of the interview, it's part of the pre-interview screening process that you gloss over here.

Asking programmers to code tough problems on the phone or whiteboard is a good test of certain personality traits, but not a good test of programming skills. On the other hand, there are problems so simple that a decent programmer should consider them to be typing rather than coding, and I think they make perfectly decent initial screening tasks. FizzBuzz is the obvious example here, but I think it's too popular to be useful. I periodically hear from devs who say they get so nervous in interview situations that they can't program at all, but no type of screening is going to be perfect.

And I much prefer this kind of objective screening process to more subjective ones, which tend tend to devolve into "let's choose people with backgrounds similar to mine".

"Generally speaking, I can tell within 5 minutes who is a great candidate."

How do you validate that this is true?

Based on the performance of the people I have hired over the years. Of course, there is always the possibility that a candidate might have been great and this was not discovered by my approach, but I think this is an inherent risk.

That's why I was wondering. For companies that need to scale, a high false negative rate is inherently costly. But, if you only need to hire a small number of people that may be a cost you're willing to eat.

can I send you my resume ?

Are you based in Canada? At any rate, feel free to get in touch. Worst case scenario I can provide some tips.

Reply on news.ycombinator.com