Got Any Code? Interview Advice for Software Engineers.
So you’re back on the market and looking for a new job, in the software world this means a number of things are probably happening. This may include a horde of recruiters emailing and calling you like a crazed ex. You might be feeling very special at the moment, after all you’ve been told you’re ‘absolutely perfect for this role’ and ‘you’d make a brilliant fit’ at least twenty times. But, if you aren’t, perhaps you could refer a friend and receive £500! Things are great.
The only issue of course is that you still have to pass at least one interview stage to nail the job you actually want. Having recently been the person doing the grilling, I’ve decided to put together some advice to help you stand out from the crowd. If you’re into horrendous business speak you could call it ‘open source advice’. It’d be better if you didn’t.
Bring Some Code.
I put this one first because I can’t stress enough how much of an impression you can make by bringing some code you wrote at home. Yes, you may be asked to do a technical test and you might breeze through it having written some great code. Then again, you might not. Bringing some code not only compounds any skill you show at interview but could also make a company reconsider hiring you if you don’t. It also shows how keen you are and most people don’t usually bother so you get ahead without a great deal of effort.
If you are stuck for ideas about what code to take along I would highly recommend having a go at some coding katas in your chosen language(s). A coding kata is a problem to solve/ set of features you must implement along with unit tests proving each feature works. This shows how you approach solving a problem (remember maths exams? Show your workings out!) and also what a fantastic coding style you have!
When being interviewed for my current role I brought along my attempt at Roy Osherove’s String Calculator Kata. I completed it in Java, Scala and Python. The reason being my current company is inclined to use different languages and technologies to find new ways to solve problems. I felt this made my multi-language, code golf approach an apt idea. However, if you only need to do it in C#, then just do it in C#, make it relevant if you can.
You can find Osherove’s kata’s here: http://osherove.com/tdd-kata-1
Would You Like Me To Draw You A Picture?
If you’ve spent much time in industry the chances are you have had to listen to someone explain a set of requirements, or maybe the new approach to continuous integration the company is adopting. Sometimes a simple idea may go above your head a little bit because it was poorly articulated. On the flip side, a speaker may really break down a complex idea with a well thought out delivery.
As an interviewer it is very easy to get lost in a persons explanation of what they did on their last project because they haven’t explained it well or the technologies were unfamiliar. So as an interviewee what can you do about it? If in doubt, draw it out. Grab a marker and whiteboard and illustrate the environment you deployed your code to. Put pen to paper and show the interviewer the processes you used and how they fit together.
A picture says a thousand words. It also helps you remember what you want to say as you are saying it.
Know your CV
‘Ok, so what are the SOLID principles?’
‘Well.. there’s the single responsibility principle… and ermm…’
What’s on your CV is very important when applying for a job because it shows the business whether or not you have the relevant experience for the position. There’s no doubt a company will be more interested in the candidate if they have been using the desired stack for the last two years as opposed to the one that hasn’t.
What is also crucial at an interview is that when someone asks you about what you said have done, you actually know what you did. You have to know it AND be able to articulate it. If you can’t rattle off the SOLID principles with examples, then don’t put it on your CV. You will look bad.
If you worked on a really interesting project with some cool technology don’t waste the chance to show your prospective employers. Make sure you know what you did and how you did it, better yet why not draw them a picture!?
Know The Basics.
When I was a graduate engineer marking some tests we’d given to some candidates, I was fairly surprised that there were engineers at mid-level who didn’t know what a static method was. Now I know we are all inclined to forget things when we are under pressure. I fluffed a question on what the difference between a left and right join is in SQL and yes, I had SQL as a skill on my CV. I felt like a moron afterwards and it didn’t have to be that way.
Going back to knowing your CV, it’s always a good idea to brush up on the basics if you haven’t used a language or technology for a while. When I tragically failed my little SQL test I hadn’t written more than a couple of queries for at least a year. I tried to explain that to the interviewers but, it didn’t matter because excuses won’t help you make a good impression. If you need to brush up then get on with a few tutorials or a couple of coding katas.
Don’t be the person that says they are a ‘Pythonista’ but can’t slice a string during a basic test.
For The Introverts.
For years software engineers have been pigeonholed as socially awkward nerds that sit in corners tapping out code, unable to hold a real conversation. Having worked in the industry for 4 years I don’t agree with this. Yes, there are many introverts, but by and large most people in the trade are interesting people with interesting things to say. The quieter ones just need some coaxing out of their shell. By the way, any non technical folks reading this should not confuse an engineer avoiding conversation and an engineer in the middle of solving a coding problem.
So whether you are an interviewer or an interviewee, you could research the people you will be speaking to and try to find common ground. This is great for introverts and gets people talking. Maybe you’ve both attended to Leeds Code Dojo, worked with the same people/ at the same places or attended the same conventions/tech talks. You can use people’s LinkedIn profiles to find this kind of information. Some people may be put off checking other people’s LinkedIn profiles as they think it will come across as a bit ‘stalkerish’ but this isn’t Facebook. It’s a professional networking site and it’s ok. You could also see if they have a profile on their company website.
Chances are you have some great ideas to discuss and have a lot of in depth technical knowledge, don’t miss your chance to share it.
Know your own history, especially your last project or two. Refresh yourself on things you haven’t had much practice with for a while. Plan what examples you will use to showcase your skills in advance. Try and cover all the key areas you mention in your CV, either with pre-written code or a planned project diagram – even better both. Interviewing people can be a pleasure or a pain – if you make the experience interesting and relevant, you’ll stand out from the crowd.
Please feel free to share your own advice, thoughts and opinions.
We Love Data
Want to know more?
Drop us a line – we’re always happy
to chat – we promise we’ll keep the
geek speak to a minimum (unless
that’s your bag in which case we’ll