We’ve been doing a lot of hiring here recently at FMP, both in London and Dundee (and we’re still hiring!). Along the way we’ve noticed some patterns (and some anti-patterns!) and we thought it would be useful to share with the wider interwebz in the hopes that people will get something useful out of it. With the caveat that each company will hire differently and has different standards, here are some DO’s and DON’T’s from the FMP Engineering team:
DON’T apply for the wrong job.
This one should be obvious, but you’d be surprised. Target only the jobs you think you’d be a good fit for. This mistake is more common for recent graduates or people seeking a career change, since both will have a lack of experience. There’s no easy way to solve this, but it CAN be solved. You can volunteer with a charity or non-profit and create a software project for them, you can build and release your own mobile apps, create a web app just for fun and put it on a personal web site, etc, etc, etc. If you don’t have the experience, get creative. We like creative.
DON’T have any typos or errors on your CV.
Sorry guys, I know this makes us look like petty, grammar Nazis. But we’re not. If you don’t take enough care to check the spelling or check that there aren’t any errors on your CV, what’s to say you don’t have a similar disregard for your code or regular work tasks? So make sure it’s error-free. Read it out loud, ask someone to proofread it for you, etc. A CV is a first impression, it should be spotless.
DO prepare. A lot.
Lack of preparation can take many forms. Being late for the interview; not knowing much about the company; not researching the technologies we use (they’re usually on the job spec); not remembering details about your past roles/projects that are on your CV, etc. If you put in the work and prepare for an interview, it shows. We like people who prepare. It shows us that you care and that you will likely be prepared when you come into work every day.
DO ask questions.
If you’ve taken the time to prepare (see above), you should have loads of questions for the company and each of your interviewers. You should at least do this to avoid accepting a job offer from a crap company! Make a list of things that are important to you and create a list of questions based on that. Are you passionate about continuous delivery? Pair programming? TDD? Are you wild about a particular form of agile methodology? Show us what you care about.
DON’T lie.
I know, another really obvious one. But again, don’t lie. We can tell. Enough said.
Technical questions
DO use TDD
We’re a TDD company. We’re serious about it. If you are too, we’ll be a good fit. If we send you a tech test and the answer doesn’t include a battery of unit tests, this will be bad. Also, all the tests should pass!
DO keep it simple
When answering technical/coding questions, resist the urge to over-engineer. Focus on the given problem. What’s the simplest solution that can answer the problem?
DO implement what you’re asked for
Another one that seems obvious, but it’s actually very easy to get side-tracked in a coding interview. Keep focused on the task you are given. Your ability to focus is part of the interview as well.
At tech job fairs
DO prepare.
See above. You’ll make a much stronger impression if you know who will be at the fair and prep beforehand to speak to them. Do your homework!
DO be smart about how you market yourself.
Are you a developer? Great. What kind? Java? C#? Front end? Back end? Full stack? Javascript? React? Know how to sell yourself and be as specific as possible. Trust us, being “general” (i.e. ambiguous) will not work in this setting.
DO summarise what you do in a few sentences.
There are loads of people at job fairs. You need to get your spiel down to a few sentences explaining what you do and what you’re looking for. If you know which companies you’re aiming for and know what they’re looking for, this should be straightforward.
Good luck with the job hunt. And now that you’re a job seeking expert, take a look at our open positions.