What qualities are you looking for in a developer? How do you find the kind of people you are looking for? Would you settle for less if no suitable candidate presented him/herself within a reasonable period of time?
+11
A:
In General:
- Involvement in coding outside of work
- Passion for what he/she is doing
- Ability to recognize patterns
It is a gamble accepting someone that is not right sometimes it works, sometimes it doesn't, but they are never going to be exceptional...
cgreeno
2009-01-23 23:40:12
A:
I always try to stick to the rule of doing the gruntwork of interviewing at least 6 candidates. It seems like available programming talent on the market varies over time too... with one position you interview a bunch of people and things are pretty dry... 3 months later you may get better candidates.
Our most recent hire was done after posting a listing on Dice, which yielded some good candidates in our market (phoenix, az).
codemonkey
2009-01-23 23:53:29
+5
A:
Someone who doesn't defend their ideas just because they thought of them. I hate it when people get defensive about the solution that they came up with. If someone criticizes their idea (and I think you should criticize their ideas in an interview, just to see what happens) and they get all blustery and defensive, adios bub. Defensive behavior inhibits the free flow of ideas.
Edit: Jason brought up a good related point, ability to criticize their own code. That can tie in to TDD: "How would you break this code?"
jcollum
2009-01-23 23:58:00
As long as it's constructive criticism. Even better still... a good developer should be able to sit back and criticize their own work in an honest fashion.
Jason Down
2009-01-24 01:40:33
A:
Willingness to work on a contract-to-hire, if that's possible. Best for you and best for them. I don't think there's any way to really evaluate a candidate well in an interview room. People are nervous, people might, ahem, fluff up, the truth because they need a job, so on.
jcollum
2009-01-23 23:59:55
I'm not familiar with the concept of a "contract-to-hire". What does it mean?
Seventh Element
2009-01-28 19:35:26
You hire someone on a contract and you both agree that at the end of the contract, if it all works out, there'll be an offer for a full-time job. Versus straight contract which means that there's no budget for a full time person, only a contract.
jcollum
2009-01-28 21:29:43
I really hate that idea. If you're old enough, have a family, mortgage, etc., you need the stability. More importantly, it can be abused by the employer as a bait-scam, just like many internships. You would get an eager to please slave with no intention to keep, and then just get the next guy.
Uri
2009-01-28 23:18:18
Maybe you've never been through a RIF: there's no such thing as stability. Keeping your resume current and relevant is more important. Contract-to-hire helps you because you'll feel no moral obligation to stay if it sucks. If you are in the position, doing the work, why would they hire someone new?
jcollum
2009-01-29 16:55:53
In my experience, when starting a new role you generally have an n-month trial period, during which time either party can end the agreement without prejudice. (Is that not a common practice worldwide?)
garrow
2009-02-28 01:04:59
+4
A:
I agree with Joel's (and many others) policy of slow as you grow. If you are building a strong team and a well-defined process, it will cost more in the long run to "settle" for a "good enough" candidate than it will to wait for the right team to evolve over time. This means you have to plan to concentrate work within a small team at first. Keep in mind that one really talented developer will produce more quality code in the same timeframe as three mediocre ones.
Dave Swersky
2009-01-24 01:34:55
A:
You might find some answers for similar questions if you run a search -- there were a few other fantastic questions that had some great thought.
Jas Panesar
2009-01-24 04:20:16
A:
I've interviewed plenty of people. Every time we've settled, it's come back to bite us so I am extremely hesitant to rush into a relationship like that.
jcollum's answer above is excellent. (I don't have the rep to comment or I'd do so there.) As for how to go about selecting for that practically, I think that challenging the interviewee with something demonstrably false would go a long way to seeing how they react. For example, if the person has to write some code, pick a piece of it to criticize but attack it for the wrong reasons. Does the person get defensive? Is he diplomatic? Is a vein popping in his head? You can explain or gracefully back down pretty quickly but that first flash will provide great insight.
bbrown
2009-02-28 00:09:40