Hacker News Reader

Comment by rootusrootus | Hacker News Reader

I would fail utterly at a real coding interview. I've been out of school too long for that crap. And also, my tolerance for it has dropped as well.

But, I'm now a dev manager so I get to sit on the other side. I've been doing interviews in the last week for a dev position and I don't subject candidates to coding. I talk with them about what they work on, one of my senior devs sits in and goes even deeper -- learning what they know without even really asking formal questions, for the most part. Past that I care more about them being smart enough and willing to learn new things, and easygoing enough to get along with the rest of the team. Hell, that's at least half of what I care about to be honest.

View on HN

I encounter people who can make pleasant conversation about programming all day... but literally can’t seem to actually program in practice. Do you see that? How does your interview check for that?

My experience has been that devs who struggle, will struggle with a simple for loop. This seems consistent with what I've heard from an Amazon bar raiser and the existence of fizz buzz. I'd be reluctant to give up this one sanity check of asking in real time a for loop question for whiteboard, or paper, psuedo code prefferably.

At one point for phone screens, I just asked people to code up strcmp. I got some amazingly bad answers.

Some of this code-screen mistrust seems to come from the flood of poorly-qualified candidates; maybe there's a more diverse pool than before, but it comes at the cost of lots of wannabes.

I interview in the same way and have never had a problem with false positives. I think you overestimate the ability of people to bullshit their way through without triggering any red flags for the interviewers.

I have not yet run into anyone who could deep-dive into the details of what they're working on and talk about the good, bad, and ugly, who turned out to be incapable of coding. Maybe I've been lucky, but I think it's pretty hard to fake that level of knowledge.

For remote developers I do deviate slightly and I actually ask them to do a little coding, but that's because it's always someone in Hyderabad and the cultural differences make a deep-dive conversation with body language a lot harder to pull off. So I ask them to whip up a demo program that scores a game of Bowling, take as long as necessary, and bring the results to the interview and show me what they did. Not much but it works (and scoring a bowling game is actually not a bad test -- not as trivial as it sounds, but doesn't take a whole evening of work just for an interview).

Great approach! What you describe is pretty close to my understanding of what a good hiring process should be like.

Honest? Smart? Positive attitude? Fun to work with? Willing to learn new stuff? Learn new stuff on your own because you like coding?

Ok. We're done. Now check references.

We'll follow that up with an audition, show up on a Saturday and pair up with team members for some random hacking, see how you handle working closely with people on a problem.

Skipping over why do you think "likes to code" is important metric when evaluating candidate for a _job_, is it common in your company to interview people on weekends?

A job as a developer is making technology do things people want. It is important to both like people and technology -- and be able to work in both seamlessly.

Whenever people are available we can see how they'd work out. Sometimes it's a Saturday, sometimes a Tuesday. I think you're reading far too much into my comment than was intended.

I actually love the idea of teaming up with some people to do some random hacking. That sounds like a super fun interview! But it also sounds really time-consuming for the team members as well as the candidate, especially if the time goes flat

Reply on news.ycombinator.com