While Google, Microsoft, Facebook, etc have an ongoing War for Talent, I wonder if another company could develop a system for developers who most Get Stuff Done, ship code, etc. (as in Joel’s “Smart & Gets Stuff Done” goal of hiring)

Looking at resumes only measures this trait so much. 2-minute academic coding problems usually measure IQ as opposed to brute coding that is more likely to be done in the wild.

Good companies can exploit the discrepancy between what the IT market values, like résumé buzzwords, and the metrics that strongly correlate to producing software, like portfolio pieces.

Well yes, as a matter of fact, I do have an idea:

Portfolios.

For example, this is my teaser portfolio. I also carry a physical portfolio to meetings with employers (the photos aren’t that impressive, but this is something I show in a face to face meeting, not something I use to justify meeting with me).

Quite simply, hire people who can show you evidence of their Smarts and ability to Get Stuff Done™. Of course, the big companies will seize everyone with IQs off the charts, GPAs through the roof, and all the other obvious traits. So you’re looking for people who are “false negatives” by the standard tests, people who don’t get an offer from Google, maybe they don’t even get an interview, but they’re great anyway.

Of course, a portfolio is not the only thing. Readers, please don’t write and say, “but you also need to ask them to write FizzBuzz,” or “what about Monopoly,” or “a degree from a good school shows they can handle doing the stuff they hate as well as the stuff they love.” I believe you! Test those things as well!!

I’m just saying, look for portfolios. Ask for them. Right in jour job ad, if you like.

I'm actually quitting a systems engineering job to focus more exclusively on software. All my work to date is 'owned' and has been custom software, so its behind closed doors. I'll be taking two months off to develop a website, create a portfolio, and make myself more marketable for the kinds of jobs I'm interested in. I'm incredibly excited about the chance to pursue my own interests over the next few months...

You know what, this strikes me as similar in some ways to the sabremetric movement in baseball. Everybody's probably heard about this ("Moneyball", the book about the Oakland Athletic's GM seems to have brought baseball statistical analysis to pop culture).

Anyways, sabremetrics is the sophisticated application of statistical techniques to data in order to try to quantify athletic attributes like defense or answer questions like "how much does stealing bases help a team achieve it's goal (winning games: answer - not that much)". Very simply though - and the Moneyball approach - is a focus on outcomes rather than talents. To broadly generalize: previously the approach to evaluating talent was more scouting/evaluation driven - "Kid X can throw 100 mph and runs really smoothly. He's a great athlete - let's draft him." Now there is more of a focus on measurable outcomes - "Kid Y is short and fat, but he struck out 100 guys and only walked 10 in a college league that has a very strong level of comptetition. We should draft him."

In some ways moving to portfolio evaluation seems like this move away from intangibles ("He went to Cal Tech and in the interview figured out how to get the the chicken, the corn, the fox and the farmer across the river in 30 seconds. Hire this man!") to "He went to a minor State U but he's contributed prominently to 2 open source projects and based on his blog is learning and applying new languages and techniques all the time. We should hire this guy." There still isn't anything you can quantify, but the focus shifts from "is the dev talented?" to "has the dev written sofware sucessfully?" That seems like a good switch to me...

That being said, it's similar but not entirely the same thing as whether to request portfolios for interviews. Good interviewers can extract the same information out of an interrogative conversation by emphasizing results rather than behaviours.

The benefit of the portfolio for the interviewee is that it steers the conversation in that direction, unless the interviewer is oblivious to its significance.

So! I was thinking about this while eating my ham and cheese wrap at lunch.

Thought 1: The body of the portfolio should consist of a series of case studies, roughly of the form "requirements, process, solution, takeway". This way, you can tell a story around the piece of code, show how you grew at each step of your journey, and/or how you helped your employer with a business problem.

Thought 2: At least some of the source should be public; none of this is particularly verifiable. If you only have employer-owned code, you should do like daveh and generate some. Even a few simple, but nifty, things can show your talents.

This source should be linked from the case studies.

Thought 3: How the crap many case studies should you have? I could imagine 5-15 for myself.

Thought 4: Nice metaphor, metapundit. One caveat: if the guy "gets things done" but does so with some godawfully ugly, insecure PHP, I don't want him. So, process matters some too.

Thought 5: Best way to generate this? I might have to learn LaTeX so I can turn one source file into PDF and HTML. Then I can write a case study titled "recursion" :)

Another thought: There's probably a market for programmerportfolio.com . If you could build the de facto portfolio software for programmers, you could start hosting their portfolios, and then you could start marketing the people who wanted to be marketed from your website.

The body of the portfolio should consist of a series of case studies, roughly of the form "requirements, process, solution, takeway".

And indeed, the world of business includes a document of this type, called, strangely enough, "case studies."

I like them as well. I recommend the portfolio for job hunting at this moment in history. They are so rare that they will get attention. And you ought to get an interview if you have what the employer wants. Once in the interview, you can go through the case study interactively.

You lose with the portfolio if there's someone who looks at the results and thinks, "Yeah, so what?" and who also would have given you an interview if you had more detail about the whys and benefits.

I suspect that will be rare, but I could be wrong. You only lose with the case studies if someone finds them too long, or (unfortunate, but always a possibility) they see some red flag in what you've written. That happens sometimes, people look at your stuff with an eye to making the submission pile shorter rather than seeking out diamonds in the coal seam.

With regard to white space, I found the printed pages easier to read with that layout. That might not be so if you're primarily looking at them on a small monitor, but in my experience people are still slinging dead trees around.

I do not think there is a magical law about conserving pages by cramming them full of hard-to-read type.

I also didn't worry about the number of pages: there're arguments about not exceeding so many pages, but is that really about the number of pages to flip or is it about the total number of words?

Then again, I may be guilty of too many words as well as too many pages.

One tantalizing connection between this post and this one: big companies are mass-producing hiring decisions. Perhaps looking through a candidate's portfolio requires the same kind of mental effort as listening to a customer's needs when building a house.

- Web-based portfolio projects are good, because they lessen the hiring managers time to evaluate them for interest. Applications that need to be installed will lessen the impact of your portfolio by turning away potential viewers.

- Blogging your thoughts about the soft (work environment, team communication, development philosophy) and hard (language/library details, dev tool overviews, underlying math and algorithm theory) aspects of software can serve as a two-way filter, helping you find an enjoyable, accomplished group of people to work with.

- As much as possible, steer clear of a 'I belong to THIS language/os/dev philosophy group' mentality. True maturity in this profession has to transcend the limitations of current technology and the hype of social trends. For added impact, demonstrate the ability to work in the space BETWEEN languages, using each language for what it is most suited.

- Demonstrate how you view efficient prioritization of a task... what sequence and emphasis do you put on architecture, development speed, performance, interface, etc. Help the people reading your site/portfolio understand what your view of good software is.

Getting back to what employers look for, going into a lot of depth does add some filtering. I'm honestly not sure if that's great. We humans tend to form very quick, superficial judgments of people, and that is actually bad for an employer, especially if they are trying to find a diamond in the rough.

For example, if someone blogs about how Java is the greatest language in the world, and how it is the epitome of OO, it is easy for me to make certain assumptions about the author. However, if I were talking to them, I would ask a few questions, and I might discover that they had never heard of Lisp, Haskell, Scheme, or Ruby. Under the circumstances, their judgment is correct.

For this reason, as an employer I try not to form snap judgments too quickly. The big question when I am first scanning someone is, should we bring them in for an interview. I don't want to make the mistake of using their blog as a substitute for the interview.

The flip side of that leads to my brief portfolio suggestion (and it's only a suggestion). I believe in giving employers the information they need to determine whether to ask you in for an interview, and no more.

Hi Reginald! That was an interesting post. I first created a web portfolio years ago, and it was an act of desperation, since, being a fresh university drop out without any professional experience, I kind of suspected that most employers wouldn't be thrilled by my resume. Had I possessed a nice degree and a nice resume at that time, I possibly wouldn't have bothered. But, I must say, it worked nice, got me some on-site interviews and at least one of my managers told me later that the portfolio was a significant factor in the decision of hiring me. So I kept updating it every now and then with the real stuff I did at work, now it's become probably overstuffed, not as nicely balanced as yours. It's here.

I am terribly sorry to hear that your start up didn't work out. I'm sure things will go well for you though.