Comments on: The Best Way To Interview A Developer http://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/ For the betterment of the software craft... Mon, 21 Nov 2011 13:57:06 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: 面试开发人员的有效方法 - 博客 - 伯乐在线http://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-7643 面试开发人员的有效方法 - 博客 - 伯乐在线 Fri, 18 Nov 2011 14:14:57 +0000 http://www.skorks.com/?p=1206#comment-7643 [...] 原作者：Alan Skorkin　编译：伯乐在线 敏捷翻译 - 朱勇 [...] [...] 原作者：Alan Skorkin　编译：伯乐在线 敏捷翻译 - 朱勇 [...]

]]> By: Alan Skorkinhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-3406 Alan Skorkin Sun, 24 Jan 2010 03:36:57 +0000 http://www.skorks.com/?p=1206#comment-3406 Yeah, I can't argue with you there, most if not all companies would never allow it, so you have to come up with the best process you can working within the constraints that you've got. However this doesn't make anything I've said any less true, a company with enough vision to implement a process such as the one I suggested will not only get better people but will also save a lot more money in the long run. Most companies however are not known for forward thinking. Yeah, I can’t argue with you there, most if not all companies would never allow it, so you have to come up with the best process you can working within the constraints that you’ve got. However this doesn’t make anything I’ve said any less true, a company with enough vision to implement a process such as the one I suggested will not only get better people but will also save a lot more money in the long run. Most companies however are not known for forward thinking.

]]> By: Dave Rodenbaughhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-3391 Dave Rodenbaugh Sat, 09 Jan 2010 18:48:39 +0000 http://www.skorks.com/?p=1206#comment-3391 I'll still argue that if I have 10 candidates to vet using your method, I have to throw away 10 developer days to babysit them and check them all out. That feels incredibly inefficient. I would be willing to try that with the top two, just to check them out AFTER serious due diligence, but as valuable as your method is, it's not easily justifiable on a development schedule. (No company I've ever worked with would ever give me that kind of leeway for sure, and I've worked a spectrum of them at this point...) I’ll still argue that if I have 10 candidates to vet using your method, I have to throw away 10 developer days to babysit them and check them all out. That feels incredibly inefficient. I would be willing to try that with the top two, just to check them out AFTER serious due diligence, but as valuable as your method is, it’s not easily justifiable on a development schedule. (No company I’ve ever worked with would ever give me that kind of leeway for sure, and I’ve worked a spectrum of them at this point…)

]]> By: Alan Skorkinhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-3384 Alan Skorkin Fri, 08 Jan 2010 10:40:20 +0000 http://www.skorks.com/?p=1206#comment-3384 What you propose in your article certainly makes sense, it's basically called due diligence, even though a person looks and sounds good, you still do the hard yards and try to find out more. Having said that, I don't buy the don't have time, or don't have money excuse. If you don't find the time or money at interview time it will cost you way more down the line unless you get lucky. What you propose in your article certainly makes sense, it’s basically called due diligence, even though a person looks and sounds good, you still do the hard yards and try to find out more. Having said that, I don’t buy the don’t have time, or don’t have money excuse. If you don’t find the time or money at interview time it will cost you way more down the line unless you get lucky.

]]> By: Dave Rodenbaughhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-3378 Dave Rodenbaugh Tue, 05 Jan 2010 22:23:29 +0000 http://www.skorks.com/?p=1206#comment-3378 Most of us don't have time to try this approach and traditional questions, they don't get to the heart of the matter. I have suggestions for 21st Century Interviewing for Developers: http://www.lessonsoffailure.com/developers/stop-dumbing-world-bad-interview-questions/ Most of us don’t have time to try this approach and traditional questions, they don’t get to the heart of the matter. I have suggestions for 21st Century Interviewing for Developers: http://www.lessonsoffailure.com/developers/stop-dumbing-world-bad-interview-questions/

]]> By: Alan Skorkinhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-3067 Alan Skorkin Sun, 27 Sep 2009 03:28:31 +0000 http://www.skorks.com/?p=1206#comment-3067 Thanks for your insights, to be honest this is kind-of the process I was envisioning when I was talking about working with a person for a day (the pairing and end of day interview with a decision maker etc) :). Thanks for your insights, to be honest this is kind-of the process I was envisioning when I was talking about working with a person for a day (the pairing and end of day interview with a decision maker etc) :).

]]> By: Al Tenhundfeldhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-3065 Al Tenhundfeld Sat, 26 Sep 2009 16:05:53 +0000 http://www.skorks.com/?p=1206#comment-3065 Some responses to responses: 1) It's common for a company to request an entire day of interviews, especially if the candidate is traveling from out of area. 2) Hardware, IT support, tool familiarity -- those are nonissues. The candidate is pairing. He can use his partner's equipment, or ask his partner how to do things in the tools. 3) For defense contractors, clearance is an issue, but many candidates will already have the necessary clearance AND most teams have some code that isn't under the restrictions: infrastructure tools, etc. I've seen this idea work but not exactly how you're describing. This is a rough timeline I've seen work well for an entire day of interviewing: Morning : traditional interviews Lunch with technical leader(s) of the dev team (end process if interviewers vote for not moving forward) Afternoon : Pairing with team, at least one senior member and one junior member. (end process if team votes for not moving forward) End of day : interview with final decision maker The point of the pairing isn't to get free work. It's to see how they interact with your team, how they learn new things, and if you're lucky, how they teach others. IMO, you're not going to learn much more from 8 hours of pairing than you will from 3 hours. And except for very senior positions, I believe it's excessive to require multiple trips to your office for interviews. In an ideal world free of business constraints, you should only hire someone when your team is excited at the prospect of working with that person. Some responses to responses:
1) It’s common for a company to request an entire day of interviews, especially if the candidate is traveling from out of area.
2) Hardware, IT support, tool familiarity — those are nonissues. The candidate is pairing. He can use his partner’s equipment, or ask his partner how to do things in the tools.
3) For defense contractors, clearance is an issue, but many candidates will already have the necessary clearance AND most teams have some code that isn’t under the restrictions: infrastructure tools, etc.

I’ve seen this idea work but not exactly how you’re describing. This is a rough timeline I’ve seen work well for an entire day of interviewing:
Morning : traditional interviews
Lunch with technical leader(s) of the dev team
(end process if interviewers vote for not moving forward)
Afternoon : Pairing with team, at least one senior member and one junior member.
(end process if team votes for not moving forward)
End of day : interview with final decision maker

The point of the pairing isn’t to get free work. It’s to see how they interact with your team, how they learn new things, and if you’re lucky, how they teach others.

IMO, you’re not going to learn much more from 8 hours of pairing than you will from 3 hours. And except for very senior positions, I believe it’s excessive to require multiple trips to your office for interviews.

In an ideal world free of business constraints, you should only hire someone when your team is excited at the prospect of working with that person.

]]> By: Alan Skorkinhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-2985 Alan Skorkin Thu, 24 Sep 2009 07:53:49 +0000 http://www.skorks.com/?p=1206#comment-2985 In my book hiring good people and improving yourself as a company go hand in hand always. Especially given that one will perpetuate the other. In my book hiring good people and improving yourself as a company go hand in hand always. Especially given that one will perpetuate the other.

]]> By: Roberthttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-2980 Robert Wed, 23 Sep 2009 22:02:27 +0000 http://www.skorks.com/?p=1206#comment-2980 "You need to become the kind of company that will attract the sort of employees you want to hire" I couldn't agree more. Making your group an awesome place to work in will attract great talent. It also means you get to decide among several qualified candidates instead of a few decent ones and a bunch of poor ones. “You need to become the kind of company that will attract the sort of employees you want to hire” I couldn’t agree more. Making your group an awesome place to work in will attract great talent. It also means you get to decide among several qualified candidates instead of a few decent ones and a bunch of poor ones.

]]> By: Alan Skorkinhttp://www.skorks.com/2009/09/the-best-way-to-interview-a-developer/comment-page-1/#comment-2973 Alan Skorkin Tue, 22 Sep 2009 08:03:09 +0000 http://www.skorks.com/?p=1206#comment-2973 Thanks for sharing that. It is interesting and can let you screen a large number of people for coding skills etc. But once you get down to the last few candidates it still doesn't let you assess how well they will fit with the team, their ability to contribute meaningfully etc. I do believe it can be a step in the right direction. Thanks for sharing that. It is interesting and can let you screen a large number of people for coding skills etc. But once you get down to the last few candidates it still doesn’t let you assess how well they will fit with the team, their ability to contribute meaningfully etc.

I do believe it can be a step in the right direction.

]]>