Internship

Offer a 3 months paid internship. A paid internship that pays 80K/year (adjust up for area cost of living). (remember, you get what you pay for).

Assign them a major project, and assign them to help other teams for short periods. You'll get the feel of the candidate.

If it doesn't work out, terminate the internship.

If it does work out, offer them a job. If they don't want it, no hard feeling, thank them, and write them a rock-solid recommendation letter. They will thank you dearly, not to mention call you eventually when they're tired of doing crap for corps.

From what I understand, that's how Joel does it. (dunno about the recommendation letter, but I assume that much from Joel).

Buzz

Ultimately, the reason you have to cold-interview people for position is because you haven't created enough buzz about working in your shop, haven't made enough contacts out in programmerland, and are not leveraging your own coworkers' non-work networks.

Work with your local university and the IT/IS faculty. Have a presence at meet-the-firms. Do stuff with student IT associations. Sponsor extra-credit projects. You'll get to know the smart students. And you'll be able to cherrypick the top of the class.

Your Company

The flip side of the coin is that your company may not be such a great place to work. You need to make sure that always-connected always-moving genYers feel comfortable in your environment. The sit-in-a-cube-and-grind might pay the bills but probably can't get 23 years old Joe excited enough about your place to tell his IS457 buddies about sending in their resumes.

Do you pass the Joel Test(1)? Is your management really "Get them the tools, access, and information they need and get the hell out of the way" or does it want to manage through process and weekly one-on-one meetings? Rock stars are like air-to-air missiles: bring them close to the target, then fire and forget, watch the fireworks, and check items off the todo-list.

No? You might want to fix that before you go trying to hire the best and brightest. It would be sad for you to actually get a highly motivated, highly competent, fired-up "great hacker" only to demoralize and shackle him within 6 months and watch him leave, his eyes set on new horizons.

Skillz

By the way, age matters not. A 23 years old can have 10 years programming experience. And he might know more about Ruby on Rails, Linux, PHP, and web development in general than 2/3 of your staff, especially those who collect the hefty salary thanks to years of service and lofty seniority-generated titles. I say this as a 23+16yo.

Instead, manage him expertly, then watch him bloom into a powerhouse. Let him keep challenging himself.

Productivity

See http://www.redmonk.com/cote/2007/02/19/gaming-your-context-or-methodology-by-constraints/ for more in that vein (including the comments) Note that I am quoted in the main body, but the original reference is broken-linked (sobrady, fix it?) and I don't recall the exact context. (update: orig ref at http://redmonk.com/anne/2007/02/17/links-for-2007-02-17/">archive.org ^[1])

See also: http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/ on programmer productivity.

So, if you do get that young rock-star programmer, odds are he won't stick around unless management makes a great effort to accommodate him.

Finally, to quote someone we all know:

"A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer." -- Bill Gates

Footnotes

1) (I don't have to link I hope)

Ask them what their hobbies are. You want someone who hacks at home.

See if they have any hobby projects that demonstrate their skill. If they wrote a Web 2.0 app last weekend just for fun then that's probably the applicant you want.

Not all of us junior developers have enough time outside of work to develop pet projects (I blame the kids, no one ever blames them!).
Even people who have heard of Jeff, Joel, Scott, Scott etc are better placed than those who just code as a job. These are people who are interested in bettering themselves and are also aware of movements within the programming profession as a whole.

Give him/her a good programming problem to do ( other questions ^[1] have suggested problems to present) in the language of his/her choice, in front of a computer and not at a whiteboard. If he/she handles it well, it's not a stretch that his/her instincts are good and, once trained, he/she will adapt and turn out well.

• Ask if they code for fun? By that I mean people who do software not to pay the bills but rather because they love the art/process of building something. Home projects in their free time / Community efforts / etc.
• Mail them 2 (max 2-3 hour) problems beforehand and ask them to solve any one of them in the programming language of their choice. Ask them to walk you through 'how they went about it' during the interview. (You'll get insights into communication skills, analytical ability, ability to mine info, technical prowess real quick.. highly recommended). Even if they don't get a solution.. the thought process should give you a good idea about the candidate.
• Ask them 'Do you read?' The interested guys often have ways to read-up / keep learning about technology.. Find out if they make the effort.

first 2/3 - great. All 3 - put a sticker on them "You're hired!" :D

Always ask for a sample of their favorite code before they come to the interview. I find how a person writes his/her code to be highly revealing about their programming personality and whether they will fit into our team's style.

Things I look for when evaluating the code:

1. How they name their methods and variables.
2. Do methods have a single responsibility or do you write god methods.
3. Is there any exception handling and at what level.
4. What is the code trying to accomplish. Is it interesting?
5. Assess the overall elegance of the code.

If they get an interview - and believe me this will weed out the majority of candidates - I will ask them to justify coding decisions. At this point the programmers we want on our team will give passionate and animated responses.

Open source development experience is a bonus but anyone doing that will pass the code review stage anyway.

Asking about their personal side projects is great, but I also like to ask:

"What do you think is the most interesting thing happening in computer science right now?"

Substitute CS with programming/technology/your company's specific area if you like. Even if they aren't doing anything amazing in side projects, you can tell how well they are following the industry or theory in a broad sense.

You can tell a lot by:

1. What they choose to talk about
2. How passionate they are about it (you're asking about their interests, so they better get excited talking about it!)
3. How they keep up to date on that issue (I prefer this way of leading into what blogs, sites, magazines to read to stay current).
4. Whether they're dying to tell you 2 or 3 other topics they think are fascinating

This is related to thread " Identifying passionate programmers ^[1]".

They just need to show passion and an obvious interest in software development.

I think Jeffs article Who needs talent when you have intensity? ^[1] captures this well.

If they're that much of a rockstar, they should have some projects to show you, "real" experience or not.

Ask them about their personal coding projects. They should be enthusiastic. Ask to see some code they're proud of, get them to go through it with you.

This is a subject I have absolutely no experience with. But I thought I should show up and post the obligatory Joel on Software ^[1] blog post.

Give them code that they should struggle with and see how they ponder through it. It is the questions they ask and don't ask that tell you a lot. They want to know the answer far more than they want the job, or at least it appears that way.

In an interview we give out a rather confusing T-SQL stored procedure. Not so much to see what they know about SP's but to have them traverse logic they are probably not as familiar with. In this case the SP seemed almost pointless unless you understood it in context.

I always asked what their response would be if I gave them that code to work on (after they were done or gave up). One guy said "What the f*** is this." That really appealed to me for some reason so I hired him. He was/is exactly what I wanted.

I am not sure this would work for everyone but I tell you the thing is when you find one you know it. After numerous interviews it is a breath of fresh air.

Look for open source experience and look at the quality of his contributions. In addition, look at the longevity of his contributions -- that is, has he stuck with a project for 6+ months? Asking him to solve a few problems in the language of his choice is also a good way of seeing how he thinks. The difficult part is determining how good a worker he is, rather than how good a programmer. Looking at his open source contributions gives you an idea of his dedication, but perhaps talking to the other developers can help out with his teamwork aspects.

Hope this helps.

The best way is if you already know them from before the interview e.g. from a user group or special interest group.

Ask for their opinions on topics germane to the job description. Don't just stick to questions about code or algorithms or data structures. Ask them how they feel about Ruby on Rails and why they like it better than .NET or vice versa.

Bring up all of the buzzwords listed on their résumés; if a candidate can clearly articulate why one is better than another, then you've got somebody who isn't just a robot programmer.

As an undergraduate myself, I think that you should focus on YOUR performance in the interview. Believe it or not, we can see through BS or an unprepared, disinterested interviewer - and hold it against the company. You can't dramatically change the corporate culture, but you can compete with a good work environment.

In my experience, rock stars don't have light resumes. They have to learn somehow.

If you are an open-source company... it's easy ^[1]!

Spot on ^[1] Adam!

In my experience most of the Jr. Rockstars are kids who actually have side projects: maintains a website here and there, programs games, the likes. They don't need to be able to know how to build their own OS or compiler (that's so 80s), but that would be a plus.

I test on code comprehension. I use the same standard piece of code that I use to torture all potential developer hires. This allows me to compare and contrast. It is amazing how experience does not necessary determine whether they pass or fail.

If you or the other stakeholders in the are impatient this limits the high of the bar you can set. The more people you put though the process the more dimensions you can test on. If HR gives you 4 people to interview you can only test on about one and a half dimensions and bar of the minimum you are willing the put up with.

Why treat them any different than the 10+ programmers? I can do things on 4+ years that a lot of the veterans can't (faster, that's key) so ask me interview questions like I had a 1000+ years.