Tables turned – hiring a UI developer

I find myself in an odd position. Back when I was first starting my career in technology, I was a web designer. This was circa 1995 and there weren't a whole lot of people who knew what the web was, much less why you'd need to design it. Jobs in the field were not abundant, and interesting, state-of-the-art, forward-thinking web-development jobs were as rare as unicorns. I wanted desperately to build the web, to put into practice all that I was learning, but I wasn't really ready to land one of those gigs, even had I known where to find one.

Obviously, the industry has changed a lot since then. And I now find myself in charge of hiring someone for a job that I would have traded my left arm for in 1995. Atlassian is hiring a UI designer/developer for the San Francisco office. I've been reading résumés for about two months, and much like last time, we've been coming up short.

Since this résumé meme had been going around Atlassian recently (Jeffrey, Mike, Charles, Mike again), I wanted to talk a little about the applications I've been reading and what I'd love to see instead. Think of it as me giving my unemployed, 1995-self a little advice. If I were on the outside today, trying to score this kick-ass gig at Atlassian, what would I want to do?

You've only got one shot, kid

So I'll admit this is harsh: but I've read dozens of résumés in the last two months and I've rejected 90% of them in the first 60 seconds. This job is for a User Interface designer/developer. The most important thing on your résumé is a link to your site. Heck, I don't even need to see your résumé at this stage. Just send me an email with a link in it. But here's the thing: that site had better be good.

One of the crucial qualities that I'm hiring for is a design sense that I can trust (in the Steve Jobs definition of design). So I pay particular attention to the personal sites of the candidates. Years ago, when I was applying for jobs like this, I people told me that my personal site didn't matter nearly as much as the examples I could give of work that I had done for real-world clients. However, I've been in the real world for a while now, and I know what goes into those sites. I've seen the sausage being made. So I know that client work seldom fully represents the talents of a candidate.

With your personal site, on the other hand, you have complete control. There are no obtuse clients, no deadline pressures, no recalcitrant programmers, and no technological limitations. It's just your brain and your tools. If you can't do a good job representing yourself visually in those circumstances, how are you going to do it on a real product? (There are plenty of people who don't even have a personal site, or don't think to put it on their résumés. Those folks aren't even trying.)

It's certainly not that your site has to be complex. In fact, the best portfolio site I've seen so far was one page. I wish I could show it to you, because the more I think about it the more I like it. The site is attractive, but more importantly it does a great job of presenting the most important information quickly and efficiently. You can tell the candidate was concerned first about how the site communicated. And for the record, he showcased work done for his employer that, while solid, was nowhere near as strong as the simple, clear, functional site he built for himself.

Show me some proof

OK, let's assume that we've gotten past the first test, and your personal site is clear, useful and attractive. But what should you actually show on that site? Back when I was on the other side of the table, I was concerned with cramming in as much of my work as possible. I guess I thought that number of projects I had done would prove that I was a real professional. Well, from this side of the table, things are different.

You should choose your best three projects and show only those. If you don't have three good projects, then only show me the ones in which you have full confidence. One awesome piece is better than an awesome piece matched with two poor ones. And remember, your personal site has already served as your first reference.

Show me lots of pictures. And explain exactly what you did for each piece – was this solo project, where you designed the page, built the HTML and CSS, coded up the javascript and wrote the backend code? If you worked with a team of developers, what were you responsible for? Either way is fine, but explain it at the outset and be honest.

This is also a great chance to demonstrate your knowledge of the design problem — explain the context of the project. What problem were you trying to solve? What hurdles did you overcome? You don't need much, but a few, well-written sentences can provide a wealth of information. And remember, writing is design.

Which brings me to a brief aside: another way to get your résumé on my radar is to show me your blog. By writing about the right things, your blog can demonstrate that you are enthusiastic about technology, that you understand design problems, that you think clearly and write well, and that you love web development for its own sake. An interesting blog can make up for a less-than-interesting portfolio.

Now we get to the résumé

Yep — just now. And 95% of candidates have already been rejected by this point. If you made it this far, your website has proven to me that you've got something going on. Now I want to find out exactly what you've done, where you've done it, and where your skills truly are. I've pretty much decided to call you by now, so your résumé is going to form the basis of our discussion. The general tips here are the same ones that you can get from my colleagues above, or from Rands.

But I'll add another tip — your résumé is another opportunity to show me a little design savvy. Think of it like a progressive enhancement problem. You need different media for different audiences. Sure, recruiters live and die by Word, so you'll need a .doc résumé. But even so, you can still try to make it attractive. And you'll want to be sure that you publish a plain-text version as well, something easily searchable and emailable. But hey, you've also got a website — you might as well put up an HTML version, right? And why not a PDF version?

What is a résumé except an interface for getting information about your career? So think about how it's designed. Think about typography and layout. Think about color. Think about what you should say, and what you can leave out. But most importantly, think about your audience. You have to balance the traditions and expectations of a résumé, which I might consider the most formal business communication, with the goal of getting your key message presented clearly, efficiently and attractively.

(I once helped a friend design a résumé that landed him a job at Google. The recruiter later told him that his résumé had jumped out because I had done his name as an orange headline across the top of the document. Dead simple, but it only takes a little to stand out from the thousand other boring résumés.)

Finally

So, there you go, 1995-Jonathan. That's how you can land one of those kick-ass web-design jobs. The good news is that it's all under your control. The act of applying for a job is itself a design and interaction problem, so do everything in your power to make that sing. Nail that, and you'll be well on your way.