The best programmer (I estimate he is the 10x at least) that I know, has no SO profile, no tumblr, no twitter. Pretty sure, he has not committed any patches to open source projects in recent years. He comes at work, gets more done in 5 hours than a team of 4-5 people, then he leaves to go home to his family. He is the one who can handle 100k project with ease (and probably 1million project). His knowledge of code and the ability to travel move up/down abstraction chain is astounding, he knows more about my source code than me, and he only has glanced on it a few times.

If he was looking for a new job, he would not be able to show the closed source he is working on, as it is a large embedded project.

Granted this is an edge case, but there are programmers like him out there.

He has made tons of cash, built amazing stuff. Run and sold a start up and is currently running a small company. He has enough cash to retire, but he is one of the folks to whom retirement doesn't mean not working. He doesn't have a blog, his idea of social network is probably his linkedin profile, nothing more. And he doesn't harp and tweet about every single discovery he is making every two hours(which is pretty common today). He just works like crazy, gets work done, makes his money as silently as he can.

There are a lot of folks like these, but they are hidden, they keep to themselves. Make enough money doing what they like. And are generally at places they want to work at. You can't really interview such people. Because they choose you, you don't get to choose them.

So clearly common interviewing techniques are not for guys like these. And most of these guys don't work at big Web giants.

I think when Jeff Atwood says "portfolio" he means not just things you'd put on your resume, but source code and publicly available articles you've written, and for some reason a twitter account.

But not just "I developed that closed source project, over there." That's what everyone has on their resume.

-- Ninja Edit---

Actually I just looked at Jeff's other article, and apparently what he calls a "portfolio", is what I call a well written resume.

Where/when you worked should be just a company name and a date. That's it. It should be followed by a very brief description of what you did there.

So OP's resume would contain something like:

- Lumera (2002-2006):

I was solely responsible for version 1.0 of the software and led the team that did version 2.0.

How exactly is he going to put up an online portfolio, or a link to a website, when he works in embedded software/hardware. Not everything programming related is done for the web!

Besides, your link that you have provided means nothing since I can't see your source code... unless you are going for a job as a front end coder of course.

I'd hope that not having a portfolio isn't a deal breaker in Jeff's hiring approach. My co-worker would be able to give any interviewer a very interesting and detailed discussion about past projects.

But if a candidate with the skills for the job really wants it very much, then merely not having any dusty code laying around readily at had should do absolutely nothing to prevent them from being able to deliver a sample, given a few days' notice.

For my part, when they asked for sample code, I said, "Hey, I usually leave my work at work, but if you give me a day I can whip something up for you." And I spent the evening grinding out code, and was able to deliver a tarball the next day.

#2. Hard. Very good programmers will often be very busy and never get a chance to open source any of their work.

I have so many open source things I'd like to work on, but I am full time employed and when I am done with work I go running, reading books, eating out, anything other than sitting in front of a computer. And I think I'm a better programmer for it.

This is why I find claims that this proves "passion" about programming very dubious.

Now I do happen to have a source forge profile, from an old job that paid me to work on an open source but not free product. It was a critical piece of infrastructure and my job was to do some very tricky things to it.

Every time I've given people a link to my profile and my patches or commit history on that project, they realize they in no way shape or form have the time or energy to grok this huge, old and complex C++ code base, to be able to evaluate my changes to it. Oops!

I end up giving them trivial python scripts I've written in an afternoon.

Also, a twitter account is definite positive? Really?

#3. Yes! As a candidate ask lots of questions and carefully listen to the answers. It's not just you who is auditioning for them!

#4. Who doesn't do this?

#5. Oh boy. If that only worked. I've worked often with contractors who have been very impressive. We almost often make then a great offer to join our team as full time employees. They always easily decline with a smile.

Because they are happy being hired guns, and don't want to go back to being employees.

Now suppose a candidate is willing and able to do this, but what happens when some other company makes them a great offer which doesn't require a week long contracting gig first?

I've been given great offers hours after walking out of the first in-person interview. Unless I am passionately, madly in love with the idea of working for your company, I will not bother. I would bother if I had no other offers, but are you hiring the best then?

And what if the candidate is looking to switch jobs, but professional ethics prevent him from slacking at this current time intensive job? Would they do your contracting thing? What if they don't, but they are in fact far and away the best developer?

I've been in that exact siltation, I've taken vacation days to do in-person interviews. But I would not take a week long contracting job just to get to the face to face interview.

#6. Unless sales is part of the job I wouldn't want "pitching". Personal chemistry with the team you'd be joining is important, but pitching does not have to be part of that evaluation.

Note that he proposes the audition project to be "a regular consulting gig with an hourly rate", spent on-site doing real work.

You don't have time to earn money doing real work? Then why are you applying?

And even for a "truly good" professional who has his pick of a dozen offers, I could see this as a good idea, since they have just as much reason to be interested in the company's "real" work environment than the company has to be interested in their "real" work performance.

False dichotomy. I'm already earning money doing real work. I'm not applying so that you can cut into my family time. I'm applying because I want work that's more interesting or more money or who knows what. If you really want to know, ask, instead of assuming ;)

EDIT: Clarifying the "more interesting work" expression.

Apart from the money, such a "audition project" could help you a great deal in deciding whether this company actually meets your expectations.

You're of course right in that it will be difficult to do it like that for someone who already has a fulltime job.

I think the audition project is a good idea for people who don't have restrictions like the above, but should not be used to reject those for whom it doesn't make sense.

But if it's short and interesting, it usually falls into "I don't care" and stays there.

I think it's about balance, an who you are talking to. If i were hiring a young programmer without that much prior experience, having some hobby projects for a portfolio, that seems to be a nice fit, but i want some confirmation, the idea of an audition project seems very nice to me.

And to take an extreme example, if you are hiring Peter Norvig (lucky you), you won't even think about that audition project.

I never hired anybody, just seems the way i would do things. Also on my first computing gig, i had an audition project, and i found it very nice. I was young and happy to prove myself (still am :))

Having visited the Google SF campus once (and knowing a number of Googlers), I picked up on a certain monoculture. This makes me question whether you were objectively picking out good and bad candidates, versus intuitively deciding whether someone will fit in the Google clique.

That can be shockingly important. You can be a great developer, but still not a good fit for a company. As an example, I saw several employees top-out at relatively low points at MSFT but then go to Google and have heard back that they have done shockingly well. I would bet that the reverse is also true.

Some of the best interviewers I've had on my loops were people who had a great grasp of whether a person was not only smart, but whether they would be successful long-term (e.g. if this entire division got killed, would they still do great work elsewhere in the company?).

While I can't characterize hire/no-hire decisions for old legal reasons, I can certainly say that many of the people who struggled at MSFT but excelled at Google favored closed-door remote-work style hacking over personal interaction code-design. One style is not necessarily better than the other, but for people who can only work in one mode or the other, they will find themselves career-limited in the long term if they go someplace that does not fit with their work style.

Which I thing is also very important. Imagine making your current colleagues work with someone that just does not fit! everybody might become miserable.

Also, one point I did not see mentioned, and have not seen in any interview I have taken is code reading. If I were looking for a colleague to work in my project, I would give him two or three pages of code from my system which I think are "interesting" and ask him to tell me what it does and some other stuff he observes.

It is most likely that reading the current code is something he/she will be doing at least in the beginning, I would like to make shure she knows how to read code (extra points if it is a language she does not write in, but can grasp the idea of what happens).

  > a certain monoculture