One of the fastest ways is to ask about something they had to "fix" (use the word "fix") at their last job, or some problem in a pet project that they just figured out. This will sound like poetic license, but really good programmers have a light that flares when they start talking about that. They immediately are back in the trenches, telling about how they couldn't figure out some nasty recursion error or some server problem that was untraceable. Usually their hands start getting animated; they loosen up.
I couldn't care less about the problem OR the eventual solution. I couldn't care less if he used an open source module to write some new code last week or if he thinks CouchDB is super amazing.
What I really want to know is how they think.
When you have a programmer who lives in code, he (or she) swim through problems like they are physical objects. They find passion in killing bugs and making code more efficient. I can hire a hundred people who can recite what the Gang of Four is or write a bubble sort. I can't hire guys who care about whether their own code can be improved.
But this is just one way. There are lots of ways to tell.
I 100% completely agree. I think asking programming trivia questions in this day and age is ridiculous because everyone now has memorized every single CareerCup question out there.
When I interviewed for previous copmanies, this is actually one of the questions I would use. "What is the hardest bug you've ever worked on?" If you take this question, and keep pressing for more and more details, and expand on that question, you can get a surprising amount of information about someone's experience and understanding. If they can't adequately answer this question, it means they haven't really been deep in code, or don't have a lot of experience, so that sets your expectations relative to the position that you're hiring for. If they claim to have a lot of experience, but can't go into too much depth, it means they're not very excited about getting their hands dirty or they don't understand what really happened, which are both bad signs to me.
I don't care if they can write up a function that can spit out the Fibonacci sequence. I can that they are smart enough to figure out relatively complex issues and can communicate this intelligently.
There's no way to figure this out from a one on one interview with that person?
I mean, a half-day programming test feels excessive. Are you worried about loosing good candidates that just don't want to deal with the headaches?
I've heard people try to justify insane hiring processes by saying "we want to filter out the people that don't want to work here. We only want people that really want it." But the best programmers -- the ones you want to hire -- are going to be in high demand by companies that look at their github, have a three minute interview, and pull the trigger.
We would only do the half day test with a subset of the candidates. A lot of people actually welcomed it - we would explain it was a way for them to also get to know us, see what we were like to work with etc.
A lot of people about to make a long term commitment to a company also want to make sure the company is right for them. So this was a good way to get to know one another.
This stuff just seems easy to figure out from a resume and asking questions. If they can talk competently in detail about cool stuff on their resume, and you yourself are smart enough to spot BS, then you know they get stuff done.
As for culture fit, again, a socially competent interviewer can size these things up reasonably quickly.
Comments
What are the key things in your experience that let you know if someone is good or not as a long term fit with your company?
Our test was not primarily just code quality.
When we brought people in we would look at:
1. Approach. Did they use e.g. an open source pre-existing module or write something themselves? Did they come up with a creative solution?
2. Culture fit. While they were in working with us, how did they interact with the team? Did they enjoy working with us and vice versa?
3. Productivity. How much did they actually get done?
One of the fastest ways is to ask about something they had to "fix" (use the word "fix") at their last job, or some problem in a pet project that they just figured out. This will sound like poetic license, but really good programmers have a light that flares when they start talking about that. They immediately are back in the trenches, telling about how they couldn't figure out some nasty recursion error or some server problem that was untraceable. Usually their hands start getting animated; they loosen up.
I couldn't care less about the problem OR the eventual solution. I couldn't care less if he used an open source module to write some new code last week or if he thinks CouchDB is super amazing.
What I really want to know is how they think.
When you have a programmer who lives in code, he (or she) swim through problems like they are physical objects. They find passion in killing bugs and making code more efficient. I can hire a hundred people who can recite what the Gang of Four is or write a bubble sort. I can't hire guys who care about whether their own code can be improved.
But this is just one way. There are lots of ways to tell.
I 100% completely agree. I think asking programming trivia questions in this day and age is ridiculous because everyone now has memorized every single CareerCup question out there.
When I interviewed for previous copmanies, this is actually one of the questions I would use. "What is the hardest bug you've ever worked on?" If you take this question, and keep pressing for more and more details, and expand on that question, you can get a surprising amount of information about someone's experience and understanding. If they can't adequately answer this question, it means they haven't really been deep in code, or don't have a lot of experience, so that sets your expectations relative to the position that you're hiring for. If they claim to have a lot of experience, but can't go into too much depth, it means they're not very excited about getting their hands dirty or they don't understand what really happened, which are both bad signs to me.
I don't care if they can write up a function that can spit out the Fibonacci sequence. I can that they are smart enough to figure out relatively complex issues and can communicate this intelligently.
There's no way to figure this out from a one on one interview with that person?
I mean, a half-day programming test feels excessive. Are you worried about loosing good candidates that just don't want to deal with the headaches?
I've heard people try to justify insane hiring processes by saying "we want to filter out the people that don't want to work here. We only want people that really want it." But the best programmers -- the ones you want to hire -- are going to be in high demand by companies that look at their github, have a three minute interview, and pull the trigger.
We would only do the half day test with a subset of the candidates. A lot of people actually welcomed it - we would explain it was a way for them to also get to know us, see what we were like to work with etc.
A lot of people about to make a long term commitment to a company also want to make sure the company is right for them. So this was a good way to get to know one another.
Which subset, and why only those people?
This stuff just seems easy to figure out from a resume and asking questions. If they can talk competently in detail about cool stuff on their resume, and you yourself are smart enough to spot BS, then you know they get stuff done.
As for culture fit, again, a socially competent interviewer can size these things up reasonably quickly.