Tech Jobs Are Not Performances, So Why Do We Audition?

I went to see an orchestra perform Beethoven's Fifth last night, and it reminded me about what bothers me about typical tech interviews. If you want to be in an orchestra, you need to audition. That makes sense because an audition is close to what the job actually is—a performance. This also makes sense for actors, comedians, dancers, etc.

Programming is not a performance

A typical tech job is not a performance. For one, there is no audience. And, unlike a performance, we make tons of small mistakes and corrections along the way. Imagine a band performing a song like we usually program—it'd be a mess and not very entertaining (or very entertaining if you think of it as avant-garde).

I've known this for a while. In fact, when I get asked for interview advice, I usually say this directly: "Treat it like you are a violinist trying out for the orchestra. Practice, practice, practice. Ask your recruiter what kind of code you'd typically have to write during the interview (algorithmic, UI, a full-stack app), and practice that. Practice the tools/IDE, frameworks, language, etc. Think of it more like performing a piece."

Now, to be clear, I'm not a big fan of this kind of interview. But, often as job-seekers, we don't have the ability to change this—especially if there's a specific job we want. I had a 22+ year career, wrote a book about iOS development, and had many public artifacts of my work, but I got my last job by passing several "auditions" that I practiced for. I personally don't intend to ever do that again, but I wanted this specific job, and this was the only way to get it.

Instead, let's try portfolio review

What I think would be better is a portfolio review. This is what you'd do if you hired an artist, craftsperson, or other professional where the job is to produce works. Portfolios give us insight into what the person could make given typical conditions and not under time constraints with every mistyped keystroke interpreted as a short-coming.

We already know this. When hiring consultants to do tech work, it's the norm to look at portfolios, and not to do a tech screen. When I was consulting, I prepared a website with a description of my credentials and links to my work. I was never asked to live-code to get a consulting gig.

The problem is that not everyone has a job that produces public works. Even if the product is public, we need to see the code, since that's the part a programmer makes. There is some privilege in being able to have time to create these works.

But, I don't think it needs to be a huge piece—it's likely that an interviewer could only spend 20-30 minutes looking at it. The important thing is that the work conveys a positive answer to the question: "can this person do the job?".

I wrote about portfolio-based interviews back in 2011.

If you don’t have a public project, and are thinking of preparing a portfolio piece, it doesn’t have to be a giant project. I think something with a dozen or so code files is about the right size to review. If you are showing me something much larger, then point out a part that I should focus on.

I'm kind of surprised that this hasn't become more common by now, as it did seem like it was happening organically. GitHub links have been common for a while. StackOverflow introduced Developer Stories in 2016, which are focussed on showcasing your work. I have never seen one as part of an application.

Bonus: They could be blind

When orchestras started using blind auditions, gender balance improved:

Using a screen to conceal candidates from the jury during preliminary auditions increased the likelihood that a female musician would advance to the next round by 11 percentage points. During the final round, “blind” auditions increased the likelihood of female musicians being selected by 30%.

We could probably do our current tech interviews blind using a voice changer over a screen sharing service, but it would be awkward. A portfolio review is easy to do blind.

In fact, tech conferences that use anonymized proposals, often result in a more balanced speaker group. See !!Con:

Proposals will be anonymized to avoid bias. Although we ask for your name, email address, and so on in the proposal submission form, only one or two organizers who serve as anonymizers will actually see this information, and they won’t review your proposal. The rest of the organizing team will review your proposal without knowing who you are.

Here are the speakers that resulted from that process.

A blind process won't guarantee a balanced result, but I believe we have enough evidence to believe it would improve balance.

What Employers Could Do

If an employer wanted to move to a portfolio review, I'd suggest something like the following

1. Explain it clearly in the job posting
2. Make it clear that the piece does not have to be big
3. Ask for code and writing samples (blogs, StackOverflow answers, etc)
4. Give some idea of the judging criteria
5. Offer to pay applicants to create the portfolio piece if they don't have one. I would say to do this on self-reported need. Perhaps after passing a resume screen
6. Do it blind
7. Create a rubric that takes many attributes into account (not just "algorithm implementation"). Examples: documentation, tests, consistent code style, reasonable abstractions, correct use of language/framework idioms.
8. Train the judges and have each portfolio scored by many people

And for their current employees—give them time to create public works (open-source, blogs, etc).

I’d love to hear any any experiences on both sides of a code portfolio review. What worked, what didn’t. If you have something like a code portfolio prepared, I’d love to see a link.