(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Tuesday, June 12, 2007

Shanti Braford asked:

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.

Any ideas?

Metapundit nailed it: Moneyball: The Art of Winning an Unfair Game is the story of how the Athletics changed baseball by exploiting the discrepancies between how how much the market would value players and how much the players contributed to winning games.

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:


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.

p.s. I regularly receive requests for my résumé. I expect more requests now that I’ve officially announced that I am no longer working on my start up and am ready for the next chapter in my career. But it’s amazing how few people ask me to send a portfolio, or links to recent work, or source code samples.



Comments on “Portfolios:
I wish I had posted on this myself - I've always thought it's the way a programmer should market themselves.

Impressive that you've got one already; I've never made one because nobody's ever asked for it.
Thank you, Bill.

Please feel free to post your portfolio here when you're done, even if you aren't looking for a job at the moment.

And to anybody else reading this, if you have one, please post a link even if you aren't looking. It can be helpful for both employers and job hunters to get a feel for what a portfolio looks like.

Thanks, and for everyone who is actively looking, good luck with your search!
I totally agree.

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...

Good luck, Dave!
I've always thought it's the way a programmer should market themselves.

Of course, that depends on how you define what you do. If you facilitate, analyze, communicate, and so forth, a portfolio may not be appropriate.

But if facilitation, analysis, communication, and good old-fashioned design, coding and debugging are tools you use to build software, then a portfolio shows off your results.

Portfolios are ideal for people who wish to emphasize their results.
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...
You know what, this strikes me as similar in some ways to the sabremetric movement in baseball.

Nice call, metapundit! I loved Moneyball: The Art of Winning an Unfair Game as well, it resonated with what I was working on at the time.

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" :)
I'm curious to know the software you used to create your resume.

I like certain parts of the layout, but was wondering if you struggled with your decision to put most of the content in the right column, thus reducing page real estate.

It's rare to see use of 'space' in a resume layout, so it was refreshing.
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.

Just saying. You could change the whole game.
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.
I used iWork, of course. Doesn't everybody?

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.
Further thoughts:

- 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.
Thanks for your thoughtful comments, DaveH.

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.

Let the rest of the decision take place in the face to face meeting.
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.

Best regards,

Thank you for replying to my comment here, Reginald.

It sounds like I'm not the only one without a portfolio! (though my resume is pretty extensive, but not nearly the same thing)

I'll use yours as a bit of a rough template of what to include in mine. Cheers!

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /