Having been interviewed a healthy number of times over the years along with conducting a good chunk of interviews myself, I’ve picked up on common “tactics”, rare gold and things you might say or do in an interview that will most likely get you rejected. Being on the other side of the table really does help, and as an interviewer I’ve been directly involved with placing three people in roles. All three of which are still in their jobs and doing really well, as far as I’m aware. A couple of “generic” tips first…
Come prepared with knowledge – do your research!
The most obvious of all advice you could be given – but it’s also the most important. It’s totally fine to not know every single nugget of information about your potential new employer, but if you know nothing at all it’s likely your interviewer(s) will see that as a lack of interest in the company or the role. Your future boss wants to know that you’re likely to stick around!
That said, it’s definitely possible to be too prepared – I’ve conducted a couple of “scripted” interviews where the candidates had clearly spent a lot of time coming up with answers to any question you might throw at them. While it might not sound like a bad thing, coming across like a robot in a job interview doesn’t show your personality which leaves a big question mark on the “potential to fit in with the team” point.
Another source of knowledge is your own story. Nobody knows you better than yourself, so it’s just as important to know your story as it is to know about the company you’re interviewing for. You should absolutely know your career history inside out, and if you don’t then now is a good time to nail that. This is helpful not only to validate the contents of your resumé, but to prove that you did actually do those things.
Information you might find useful to research:
- Company’s products/services – what do they do?
- Company’s client base – who do they sell to?
- News articles – has the company made any awesome achievements recently? Can you get a feel for any trends – i.e. product releases etc?
- Financials. This isn’t necessarily for interview but more due diligence – websites like companycheck.co.uk will allow you to get some basic information for free as long as there are public accounting records (i.e. a limited or PLC). I pulled out of an opportunity based on the fact I really couldn’t see how the company in question could actually pay me, based on their last four years’ accounts. When you have a family to support, it’s obviously rather important to check whether the company isn’t likely to go under anytime soon. That data should also be taken at face value – it’s obviously not possible to get a feel for how a company is run based off of a bunch of numbers.
Ensure you have eaten before your interview. Also, turn off your phone…
I know what you’re thinking. “What bloody planet is this guy on?!” I was in a conversation with a recruiter once, he was setting me up for an interview and he happened to mention that a previous candidate had apparently asked whether there was anything available to eat… during the interview! If you have a legitimate need – for example a medical requirement which means you must eat at specific times – then of course that’s fine and all you need to do is highlight this. Nobody is going to hold that against you. But you would also have your own food supply, so asking in the interview and not having anything with you would definitely be considered rude. And a sign of someone who could be ill-prepared.
On the subject of phones (and watches, actually), it’s great that you have a popular social life but it’s not going to bode well for your attempt to impress if Facebook Messenger keeps sending you notifications every five minutes! Turn it off – it’s not like you’ll be using it during the interview anyway!
Technical knowledge – tests and questions
When it comes to web developer and software engineering jobs, it would be safe to assume that you will be asked some technical questions. Of course, the interviewer(s) need to know whether the knowledge and experience you’re claiming you have is not just some fabricated nonsense to make you sound good. Those technical questions should be in line with the level you’re applying for – i.e., don’t be surprised if you have some tough questions fired in your direction if you’re applying for a senior or lead level position.
Some companies will ask you to do a written technical test and while these are a bit archaic these days they do still exist. Done properly, however, they should simply be a collection of conversation starters for the remainder of the interview rather than a pass/fail scenario. Unless you’ve got the first code question inconceivably wrong… in which case, you should probably re-evaluate why you’re there.
As an interviewee, going for senior-level/lead/management positions two of the most challenging situations I’ve been put in:
- Technical test as part of a 3-hour interview. Company was a genomics/DNA software house; I was provided with a laptop, a text editor, some JSON data and internet access. The JSON data represented elements of a DNA chain, which I had to visualise using HTML, CSS and PHP into an accurately scaled DNA “portrait” within an hour. Having never seen DNA visualised in that way before, I completed the task in 53 minutes – impressive, I thought.
- On a telephone interview, out of the blue I was asked to describe the full lifecycle of a HTTP request. I can’t recall the exact response I got, but I know the interviewer was impressed.
In both scenarios I successfully navigated the challenges by first taking a few seconds to compose myself and think before doing or saying anything. If panic sets in it could potentially be game over, but it’s essential to just give yourself a few seconds to compose yourself. Remember, they’re not looking to catch you out. They’re just trying to get a feel for what level you’re currently working at. And if you don’t know the answer – and I mean really don’t know – then it’s far better to be honest about it. If you think you might know the answer but aren’t 100% certain, again be honest. Something like, “I’m not 100% sure but I think it might be…” No developer can possibly know everything about a language or a subset of languages, no matter how good they are.
It’s also good to know the “Fizz Buzz” question. Just saying 😉
The previous project question
A lot of interviews will contain one or more questions about previous projects – how did you handle X, Y and Z situations. I’m part of a developer community surrounding the Laravel framework, and someone asked a very good question in open chat:
If you go to an interview and they ask you, “tell me about a big and complex project that you worked on and you are proud of,” what kind of thing is likely to impress? I feel like I’ve worked on a lot of CRUD apps and fairly straightforward stuff that’s not that earth shattering.
It’s a great question – largely because most projects have the same underlying functions – and it actually inspired me to write this blog post. I thought about it and came up with an answer which calls upon my experience both as an interviewer and an interviewee:
They’ll be wanting to know how you approached said project, or if you didn’t work on it alone, what you did and how you approached it. Generally speaking if you were part of the decision making process on things like tech, infrastructure and features then these are good points to talk about… and most importantly why you made those decisions. For example, if you chose Laravel they might ask if you considered any other frameworks, and why you chose Laravel. Why not CodeIgniter? If there’s something you would/could do differently it might be good to share what you would do differently… and why.
An interviewer with that kind of question is trying to work out how your mindset works when presented with a large canvas and a large challenge, but also whether you can make good decisions based on the project requirements. And while you might think “but talking about things I would do differently” is a negative thing, to an interviewer it would show that you are constructively critical of your own work and can recognise where things can be improved.
Most of the time, projects are the same things with a different skin. CRUD, e-commerce or similar. Obviously with their own complexities and challenges. But most of the time, people tend to be in the same position and don’t have anything they feel is too “wow”.
Respect previous employers and contractual obligations during your interview
I can’t emphasise enough the importance of this, and I’ve purposely written this after talking about a previous project. Increasingly true these days is the fact that most employers are turning to employment contracts to protect their intellectual property, and you may well have signed NDAs with some of them which restricts what you can and cannot talk about. Even if you don’t have an NDA, you should be courteous to a previous employer; in most cases the code that you worked on is likely to be proprietary. And if you’re thinking about bringing something up in the interview because you worked on it, and it’s super cool, and you want to talk about how you did it… if you’re not sure whether you’ll get yourself into hot water, don’t mention it at all.
As an interviewer, I most certainly don’t want to see things such as a database ERD for your current employer’s SaaS platform, or hear about how a specific system’s API works in great detail. You could be the most talented programmer in the Universe, but if you’re willing to give away confidential information then your loyalty and confidentiality is immediately compromised.
It could be the case that this leaves you with very little in way of examples you can give of previous work you’re happy to show off. In which case, invest some time in your spare time and come up with a project you can work on. It might just be the project that swings your future boss in your favor.
Expect the unexpected
If you’re a seasoned developer this should be no trouble at all, since technology has this incredibly annoying habit of completely blowing up at the worst possible time, in the worst possible way, for absolutely no reason. As I said above, catching candidates out is not the intention of the interviewer. It certainly wasn’t my intention when someone said at the start of the interview he “really loved a challenge” yet couldn’t answer the question I asked at the end, “what does a challenge look like to you?”
Similarly, the favorite question at the end of an interview a couple of colleagues and I used to ask was something along the lines of, “do you have any fun projects you’re working on outside of work?” I’ve had a couple of people completely caught out by that, a couple of “not really” answers and some really good ones. If I were asked that question now, I would talk a little about my homebrew security system using Raspberry Pi, Arduino, wireless comms and a whole bunch of sensors – not because it’s tech-related, but because it’s electronics and I’m learning something completely new and interesting.
With that particular question, it’s more a personality thing – what interests you. What makes you tick?
This is important for any interview, but in my experience you definitely want a bit of technical spiel in your question line up. Not too much that you come across as scouting for information, but enough to show that you’re interested in the company and your potential role. I normally start with the role – “what does a typical day look like”, “where do you see this role in 3-5 years”, etc. I’ll then dig in with things like, “what does your development/testing process look like?” to get a feel for how you’ll be expected to work – do they use the Gitflow pattern with Git, for example? There’s every chance that all of your questions will have been answered during your conversation and if this is the case, don’t answer with “no”. Something like, “I had a few questions lined up but I’ve had some great answers to them.” I’ll then pick two or three of the more interesting questions from my list and summise the questions and answers – it not only shows that I had questions in the first place, but that I was paying attention and understood what was being discussed.
Interviews are a two-way street. You need to make sure that it’s a place you would be happy to work in, as much as they need to make sure you’re a good fit for them and the role in question. Don’t be afraid to have a conversation – but always think about what you’re saying before you say it. While salary and benefits package are important (because everyone has bills, right?) never bring these up on the first interview unless you’re asked, and always tread carefully around your answers.
The best interviews I’ve had are ones where I could be myself, have a relaxed conversation, smile and laugh with the other people in the room.