How not to not get hired

After what seems to a year of solid hiring, we're finally coming up for air with a full team. We've had new people join us at pretty much every level in the company from Intern to Senior, across Design, Development, QA & Project Management. And we've seen a pretty significant number of candidates. One thing I've noticed is how oftern candidates will do something silly or ill-considered despite an otherwise good application which damaged their chance.

So, rather than providing yet another list of things you should do to get hired, here instead is a list of things you should avoid doing in order to not screw up your chances.

Do not send me a CV more than 3 pages long

It's not that I don't care. I just do not have time to read a half page of prose on a role you held 6 years ago in the middle of your 9 page CV. I have 60 other resumés to read. Your CV should have at most 2 pages of content appropriately summarised in lists and short paragraphs. Particularly for more senior candidates, who as a function of time, have more career experience to talk about, you need to be capable of summarising your skills and experience as concisely as possible.

Don't ignore the question you were asked / Don't ramble.

I have asked you something very specific. I would like you to answer that question.

• If you're not sure or don't know the answer, that's fine, we'll work around it or move on
• If you would like to subsequently segue the conversation into a related topic, great, but answer the question first
• If you didn't understand the question, ask me to clarify

But don't just go rambling off. And especially don't do it a second time, if I give you the benefit of the doubt and bring you back on topic. If you continue to ramble off then I'm going to assume you have poor communication skills.

Don't submit a broken code test

Do not just knock out a code test, hit RUN in your IDE, think "seems to work on my machine" and then throw it over the fence. I have received tests where:

• Code doesn't compile
• Tests don't run
• Packages don't restore
• Libraries are missing
• Or it only runs if you have the latest pre-alpha dev build of some unreleased framework installed on your PC

If you are submitting a code test you need to make sure that the person you send it to can run it. When you're finished I would suggest you do the following check list.

• Do a clean checkout from your repo and make sure it restores all packages & compiles
• Compile it from the command line to make sure there are no IDE dependencies or extensions needed
• Run your unit tests from the command line to make sure they pass
• Write some deployment/release notes that explain how to compile, install and run your code

Don't come unprepared?

If you've gotten to a face to face interview then you've already passed a CV Screen, Phone Interview and Code Test. So don't trip at the last hurdle by coming to an interview with the intention of winging it.

Bring a copy of your CV with you and know whats in it. If you've put something in your CV, expect me to grill you on it. If I feel like you're bullshitting me, I am going to call you out on it, grill you harder, and tell you it shouldn't be in your CV.

Be capable of explaining what your current/previous roles and projects are in a simple and concise way. If you have worked in an industry that I am unfamiliar with, then you need to be able to get your explanations across to me without having to educate me on industry subject matter. Assume you may have to take an "ELI5" approach.

Review the basics. Yes I know you are a 10-year senior developer and you can write code day-in-day-out. But I still expect you to be able to talk to me about the basics. What are Solid Principles? What is encapsulation? What is polymorphism? Can you name some software design patterns that aren't the Factory or Singleton patterns? Have you reviewed any architectural patterns? etc.

Thoughts

Don't be complacent about getting a new job. Yes, the supply and demand nature of our industry may have tilted things in favour of the candidate of late, but that doesn't mean that good companies will lower the quality bar when they're under pressure. If you want a good job in a good company, then you have to assume that they will have good standards which requires an effort from you, the candidate, to land the role you want.

~Eoin Campbell