On one hand, I have always looked forward to and enjoyed Aaron's writing, and was really curious about what he had to say in this post. On the other hand, this

On one hand, I have always looked forward to and enjoyed Aaron's writing, and was really curious about what he had to say in this post. On the other hand, this is a subject near and dear to my own heart, and while I appreciate a lot of his methods, I don't think his model scales well. In order for it to work the way he wants, he has to conduct the interviews himself. A few thoughts... Programming isn’t typically a job done under pressure, so seeing how people perform when nervous is pretty useless. Not my experience. Actually, quite the contrary. The single biggest difference I have ever seen (over and over again) between a good programmer and a great programmer is how they respond under pressure. Given enough time, lots of programmers can code something that works. The problem is that there are many occasions where there simply isn't enough time. Can you hit a deadline? Can you stay awake all night if you have to? Can you resolve this problem that's holding everything and everyone else up? Can you settle down that user or customer who's up in arms? Can you figure out what wrong decision was made 4 steps ago that is causing big problems now? And can you do it now? Understanding how well someone performs under pressure (and whether or not that makes them nervous) is hardly useless. I can't think of too many more things that are useful to know. So I just request a code sample and a demo and see whether it looks good. There are too many cases where this doesn't work at all. What if they've never contributed to an open source project? (Whether or not you like this has nothing to do with their skill as a programmer and is another subject). What if they're prohibited from sharing someone else's proprietary property? What if they're bound by someone else's (illogical) shop standards? What if they salvaged someone else's shitty architecture with great workaround code? If they wrote something as part of a team, which part was theirs? How much of the analysis, design, architecture, testing, and deployment did they do? For that matter, how much of the actual programming did they do? Lots of posers share something they "worked on" but could never build in a hundred years. To find out whether someone’s smart, I just have a casual conversation with them. That's it? You make judgements on the fly? Using what metrics? The idea of a learning from a casual conversation makes a lot of sense. But what is your plan? Ten people having ten conversations will come up with ten different assessments of the same candidate. Unless there is some kind of standard and a plan going into the meeting. How will you know they are smart? How will you know they can get things done? How will you know they can work with others? Without a plan to answer these questions, you're just waving your hands. I suspect OP already has a plan of attack for his casual conversations but it's hard to say because he never says anything about it. Ask them what they’ve been thinking about and probe them about it. Again, this may or may not be a good litmus test. I know programmers with IQs of 160 who have written tons of brilliant code. If I asked tham what they've been thinking about, the answer could be "who will win the Notre Dame game" or "will I get laid tonight" just as easily as it can be about something truly cerebral. Finally, I figure out whether I can work with someone just by hanging out with them for a bit. Again, you can learn a lot about someone else this way, but sooner or later, you'll need some kind of standard and metric for this method to be replicable. Before you start, you must be able to say, "This is when I will know what I need to know." Until then this is just one guy's hand waving. I’m amazed that so many companies use such silly hiring methods instead. I'm amazed that so many companies use such silly methods for so many other things as well. But there are just as many who hire very well. I know many great programmers employed and still delivering great product 15 or 20 years with the same company. The same companies that seldom make bad hires. They use a lot of OP's strategies. But they also combine these strategies into a comprehensive system that works no matter who does the hiring. I like OP's thinking. I just don't see how it will work well once his company becomes too big for him to do every interview himself. Systemitizing his methods will make it scale.