Hacker News Reader

Comment by brightball | Hacker News Reader

Interviewing programmers is easy. Get them to talk about something they've done that they were proud of and let them explain how they did it into the deep details.

Good programmers really enjoy talking about the details of the technology and how they solved challenging problems. You'll be able to see them geek out a little bit and see that they really enjoyed getting to do it.

Outside of baseline, core competence, that is the litmus test for hiring good programmers because it shows level of interest. Level of interest leads to continuous learning, which is essential to this field. Unless you have some ego-driven reason why you want to believe that YOUR stuff is too complicated for them to learn of course...but that's usually more of a reflection on you than them.

I realized this about 5 years ago and I've not made a single bad hire with the approach since. 100% success rate at this time.

View on HN

I've tried this in the past when hiring for a startup in two different ways: one with having the entire interview based around simply discussing past projects and gauging the level of interest; the other combining this type of discussion with a coding problems or two.

The result: the correlation between passion and competence is not 1.

Initially I wanted to give them the benefit of the doubt and hire primarily on talk alone, however I found that some people are passionate and interested yet can't code very well. After having to fire folks because of it, I decided to actually make them write code during the interview. Sure enough, I discovered a few candidates who could talk the talk, but when faced with an actual problem* couldn't actually solve it.

* When I give interview problems I like to actually give problems that I have faced in my job.

So you found work sample tests were an effective predictor? This matches industrial research.

And admittedly, that's true. I suppose I shouldn't have let that come off as a purist "only ask this" situation. You need some technical problem that they can solve based on the skills you need and the skills you can judge. For those types of problems, I tend to focus on watching HOW they get to a solution and why rather than pure syntax.

I shouldn't have represented my original comment as the only thing necessary. Getting a mainframe guy to geek out on me for an Android position is probably not going to be all that beneficial.

Being able to talk about past projects is not passion, it is simple professionalism. How can you work in a field for long without being able to talk intelligently about it.

I also don't find testing for actual coding skills to be a problem as most candidates don't make it to the interview if they don't have some sort of portfolio of code samples.

A portfolio of code samples is not always available. Juniors often don't have code samples; neither do people who have only really worked on proprietary projects. I don't like to discount potential good developers just because they spend their free time doing things other than coding.

> spend their free time doing things other than coding

This is a valid point. A good work/life balance is critical. But to counter it, don't you want to look at candidates who _want_ to get hired, so they've spent a little extra time writing something for potential employers to look at?

A developer who gives up at "I don't have code samples" isn't someone I would want to hire.

If they didn't want to get hired, they wouldn't have applied for the job. Assuming that "I don't have code samples" is equivalent to "I don't care" is a silly assumption, and one that I've found is completely false in reality. Some of the developers I've hired have years of experience but no code samples, and after hiring them I discovered I had made the right choice. They just have other priorities on the side (children are often a big one).

Code is art and artists have portfolios. Not having at least a minimal portfolio shows a lack of professionalism.

Would you hire a graphic artist, a writer, a painter, etc. without previewing their work first.

>Good programmers really enjoy talking about the details of the technology and how they solved challenging problems. You'll be able to see them geek out a little bit and see that they really enjoyed getting to do it.

I've had this at several companies. I think I've always gotten past this litmus test in one of the interviews, be it on the phone, via Skype, or in person. The problem, for me personally, is the inevitable followup interview consisting of "go to the board and scribble out a function that does X", and then of course "after you're done, I'll add important details and I expect you to be able to modify the function to accommodate as if you were using a text editor".

I admit it, I fail at the "get in front of the board" problems. I'm downright terrible at them. I have no problem with the conversational interviews. I'm not bad at presenting tech to my peers at meetings and book clubs, but in an interview environment I'll freeze up and, at best, come up with a very inefficient implementation. I hate it and it has probably cost me opportunities at places where the rest of the interview felt like it went great.

Yes I know what the Big O is, I know what the Big O of the optimal implementation would be. I can talk all about hashes, final, static, or whatever you think you'll trip me up on. But when I'm up there writing code, every little mistake psyches me out more and more, especially I can't just hit "backspace" to fix it.

At my previous job, after the phone interview they sent me a programming project to implement in a day or two. After submitting it, they had me go to an interview and talk about the solution with a group of engineers, followed by a short conversational interview. That project was my first time writing ruby and I got the position and have great recommendations since leaving the place.

Makes me wish that recommendations held more sway, or that more companies would do more of this "here's a task, send us the solution when you're done with it" type of thing. Dishonest candidates would easily be exposed when they're forced to discuss the solution in depth.

Of course, upon walking out of the building, all the answers magically pop into my head...

Industrial psychology has been over this ground many times.

Prove they are generally smart, do a work sample test representing the work they'd actually be doing, for a kicker test their integrity. You'll have > 50% wins.

http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...

I love shit like this. Thanks for the link.

Curiously, how would you go about testing a programmer for integrity?

A good resume is a trick. A trick designed to get an interviewer to ask about something on it. Because every item is something that you can talk about with passion and detail for as long as you want or need.

> Good programmers really enjoy talking about the details of the technology and how they solved challenging problems.

Bad programmers also enjoy talking about that. They can make it sound like it was an awesome project.

You can't tell until you actually look at their code and realize it's all a spaghetti mess.

In my experiences this is generally not true, bad programmers cannot talk the talk.

I've found the problem is sometimes missing good candidates because that particular one found you intimidating in some way. You can try to mitigate this some by having multiple interviewers to try to find someone on your team they can relate to. But really even this tends to work in your favor, because if they don't click with anyone on your team they probably won't do well even if they are good.

I'm defining bad as someone who knows how to write code but has been doing it "wrong" for so long and they're not really willing to unlearn their bad practices.

> Good programmers really enjoy talking about the details of the technology and how they solved challenging problems.

I don't really enjoy talking about anything and usually do so as a necessity. I guess I don't fit in with the extrovert engineers people are looking for. I also contend that not being able to talk well about how you did something doesn't mean that you aren't good at it. Talking about doing something you are good at is a different skill. Being be able to communicate is important sure. Is it the number one thing you're looking for? And candidates have to be happy about the ordeal too?

Actually, effective and reliable communication is the number one thing most all companies are looking for in engineers. No one wants a developer that is resistant to daily peer cooperation. A developer that can't clearly explain their decisions to their stakeholders is just about useless. A line item about communication is almost always present on a dev job listing's requirements, much more common than any stack/language flavor of the month.

Code is easy, being able to communicate is not. We engineers love to loathe non-tech people who talk too much while producing nothing tangible. Even more though, effective engineers loathe their peers that don't talk enough.

Isn't there something you've done in your career that you take enough pride in that you'd enjoy explaining it to people who would appreciate it (not including that time you gamed an interview)?

I don't enjoy doing anything with other people, but it's a necessity given that we need jobs to survive. I could be happy just hacking on something in a basement and never talking to a soul if I could. I can wear a smile if you need me to, but I definitely wont mean it. Sorry.

That's what I mean though. Talk about something you hacked on in a basement.

My problem, prior to my current position, was that I wasn't allowed to explain these things to people.

what about new grad? most of them only have school projects/assignments that involve the fundamentals, so I can see how the "coding interview" is a decent method here

A new grad should certainly be able to talk about their many school projects. Took an OS class and wrote a micro-kernel? I'd LOVE to hear about it! You enjoyed algorithms class? Let's talk about that!

New grads are different. For that you're usually hiring more for an entry level position with the expectation that there will be a lot of on the job learning.

Reply on news.ycombinator.com