5 Ways to Bomb A Web Development Job Interview

Casey Kinsey; Co-Founder, HeapSort

Got a job interview coming up and want to make sure you don’t make it past the first round? The following are my top 5 tips to fail with flying colors based on my experience on both sides of the table.

1. Believe that resumes should be machine readable

That template from Resume.com will do. It’s in an organized format. Just hydrate all the data structures and POST it to all the endpoints.

Your first fuck-up begins before you ever walk in the room, in a word processor tucked sneakily behind windows arranged to make you look busy at your current job.

A web developer’s resume should not be in a format compatible with a sales manager’s resume.

Using a generic catch-all resume format or template is going to leave you with some big holes in your CV. You work in an industry that changes by the second, and you have to demonstrate your ability to ride out that storm over time. A work history and references aren’t enough.

You need a project portfolio. You need code samples. You need to list your publications, even including quality blog posts you’ve written. This is an academic / creative field sprinkled with business. Your resume should be a tasteful amalgam of elements you’d see on the CVs of engineers, artists, journalists, and professors. And, most importantly, it isn’t going to fit on one page.

To get you started, here’s a format that’s worked well for me over the years. The Resume folder on my computer contains 5 documents:

• Cover letter
• Overview (Summary of skills, Education, Work History, References)
• Publications
• Case Studies
• Code Samples

I keep each of these documents updated and combine the relevant pieces of each to form my resume for every position I’ve applied to.

That’s right, captain Don’t-Repeat-Yourself. You should create a separate implementation for each job application. Unfortunately we can’t automate every single part of our careers via a command line.

That said, we do think the JSON Resume format is pretty cool and plan on supporting it with HeapSort once it gets finalized. But that doesn’t mean
you can just slap down a printout of object notation on the hiring mangers desk and expect a callback.

2. Don’t research your potential employer

You’re here to code. It’s what you know–it’s what you do. It’s what they will pay you to do. What do they do? Sell paper or something? Who cares–you build software.

Walking into an interview thinking you’ll cruise by just on your engineering skills without any insight in the employer’s industry won’t get you very far.

Even if you’re convinced that the role will be totally insulated from needing specific domain knowledge, any other potential candidate who does understand the business has an immediate and immense advantage over you.

I met someone on a business trip who had a background in software engineering, but was working as a pretty successful business analyst and consultant. He told me that every time he prepared for an interview he would look up the hiring manager, find a conference where they were speaking, fly there, and attend the discussion.

Afterwards he made sure to shake their hand, and then–here’s the kicker–raise a point which challenged their position.

Overkill? Maybe. He also told me he got every job he wanted badly enough to apply for. I truly believe it.

So maybe you don’t necessarily need to go that far, but you damn sure can do some research and understand the business before you walk in the room.

There will be plenty of applicants who only do the bare minimum. They’ll get a look like this:

3. Let the resume/portfolio do all the talking

Your portfolio speaks for itself. So what if there’s nothing listed from 2008-2010 on your resume. One look at your portfolio and you’re hired.

There are a couple of things that can appear on your resume you need to be prepared to defend, and you don’t want to be caught off guard should you be asked about them. Plan ahead, and rehearse your answers.

I interviewed against a developer once who spent 10 years working for AOL. Working on login screens.

10 years. Login screens.

I can’t speak for the interviewer, but personally I immediately imagined a day at work for him (we’ll call him Todd) to go something like this:

“Hey Todd, want to grab some lunch?”

“No thanks man, this password field is really kicking my ass.”

Software development is a high turnover industry. Developers average somewhere between 1 and 2 years on the job. So if your resume says you spent many years in the same position, for the same company, this can actually work against you.

If you have a long stretch with no visible progress as far as position is concerned, the most important thing to do is to prove that you progressed over that period–you may not have been promoted, but maybe you changed specializations. Case studies come in very handy in this situation, as you can give real examples of your progress over time.

It’s likely more important to have a defense prepared for a gap in employment. This is a case where your portfolio, case studies, and/or publications can work for you, but you have to be able to tell the story.

Show that you worked on freelance projects, or wrote about software. Demonstrate other skills you worked on (even in another industry). Whatever you do, don’t leave it at, “yeah, I was having trouble finding work.”

Anyone can find themselves in a position where its hard to find work. Some people are able to make something out of that situation, and some are not. You need to prove you’re in the former group.

4. Over-commit to all the things

You’re a smooth talker. You can BS your way through a screening or high level technical interview. Of course you have all of the experience they are looking for.

Never will I forget an interview I had at age 19 for a consulting position I was probably unqualified for. I had nailed the part with the business side, and now a second party on the call was going to ask me some technical questions. We started with pretty basic web development stuff. It was easy. I had this.

“What about other skills? Do you have networking experience?”

I had physically run CAT-5 cables for my high school’s network and keyed in static IP addresses of a spreadsheet. It was easy. I had this.

“Oh yes, absolutely.”

“Great, so then you can tell me what the purpose of a subnet mask is?”

Well, I just got nut-checked over the phone. I knew what a subnet mask looked like. I knew if you didn’t type in the correct one from the spreadsheet it didn’t work. It’s combinations of 255 and 0 right? You put a 0 at the end?

“Well… I.. Uh… I think I might have spoken too soon on that.”

A seeming eternity passes. I can hear the chirps of crickets beginning to evolve over generations of time.

“… I don’t have any more questions.”

Never commit to a skill you don’t have. One of two things will happen:

• You’ll endure a stretch of extreme embarrassment that will sting for a decade.
• They’ll buy it and you’ll look like an asshole later when they hold you to it.

Good interview questions are designed to weed out BS, and if you throw bullshit at a bullshit detector you’re gonna have a bad time.

5. Blur the line between opinionated and didactic

No you don’t use that framework. You built your own framework. That open source project with 5000 contributors did it wrong. “Pretty impressive, ” they’ll say. Yeah. That’s what they’ll say.

Developers are notoriously opinionated. Especially in Open Source software development, where the idea that there is one and only one correct way to accomplish something is actually the very antithesis of everything you do. In fact, I’d be leery of any developer who isn’t opinionated about the specifics of their job.

But there’s a line between opinionated and downright egotistical which, when crossed, will earn your one-pager resume a direct trip to the trashcan for any remotely seasoned engineering manager.

Ego destroys software teams. It leads to unnecessary conflict and dysfunction. When I evaluate a candidate, it’s one of the first things I look for.

I once worked with a guy with no prior work history who wrote a CSS compressor. It compressed CSS after validating them with a custom ruleset (his roll-your-own, modified version of the CSS parsing specification published by Google and used by Google Chrome.)

I found this out when I filed a bug against his compressor because it was throwing out valid CSS rules that, when uncompressed, rendered correctly in all of our target browsers. Perplexed, I asked him why he had modified the specification. He replied, quite confidently, “Google doesn’t parse CSS correctly.”

He was clearly satisfied hearing himself say this, expecting me to be impressed as well. All I could think was “our company paid this guy to reinvent the CSS specification…? Incorrectly?”

Unless you’re in the business of reinventing the CSS specification, you shouldn’t be paying someone to reinvent the CSS specification. And I don’t think many developers would try to, but this is a great example of why managers don’t want to bring big egos onto their team.

–

So there you have it. Follow these 5 tips and you’ll be on your way to long-term unemployment in no time! If you don’t want to follow these tips and would like to create a better resume, consider creating one on HeapSort