The Coding Interview
There is a rich and varied job market out there for software engineers. To access it you will first have to navigate and excel at the coding interview.
Getting a new software development job can be tricky. In the past ten years or so, the rise of the coding interview has affected the way that technology companies are hiring staff. With so many engineers out there, and the risk of hiring one that is below average so dangerous, companies are using the tough method of practical, code-writing interviews to weed out potentially bad candidates.
While this sort of screening can screen out many that do not come up to the high standards of the company, it also has the downside that it may cause good candidates to be dismissed incorrectly. Why? Mainly because the practical skills that are required to excel at the coding interview are not practiced daily by software developers.
Most developers will have had little exposure to discussions about low level array and string manipulation, bit level operations or using data structures like stacks and heaps on a regular basis, and these tend to feature a lot in these coding interviews. These things do crop up from time to time, but an experienced developer will usually factor in the time required to get acquainted with the topic into estimates.
Having to be practiced and quick with responses and techniques can make the technical interview quite stressful, especially when it requires writing code on a white board. Interviewers expect syntactically correct code, even without the help of an integrated development environment (IDE).
Practice
So how is one supposed to get this kind of experience?
With the rise of the technical interview has come the rise of the interview question preparation website. There are many, with HackerRank.com and LeetCode.com being prominent examples. There are also books such as Cracking the Coding Interview that can help.
The questions found in these resources will give plenty of exposure to the types of things that come up in interviews. Many are pretty specific and may not apply to the type of interview that you are going for but there are plenty of question types to choose from.
How you handle a difficult or impossible problem may be what you are being assessed on. It is important that you are able to articulate your analysis process and design choices before and as you make them. Being able to articulate the problems with your design is something that interviewers want to see, building solutions onto the existing design, if necessary.
So it is not good enough to simply rush through all the problems on the above sites, you need to practice talking while you code, potentially out loud with a friend or mentor, and explain your solution to the questions.
Practice takes time. There is a lot to cover. HackerRank mainly provides questions that are rated easy, medium or hard. Leetcode offers tutorials about the topics and both have premium options which improve the experience, but most of the content is free.
Cracking the Coding Interview is another good source of sample problems with each class of question proceeded by an introduction that outlines a broad strategy. There is also an important chapter on how to handle design type questions which can be difficult to impress an interviewer without the correct technique. Behavioural questions, the type that are usually asked by HR, are also covered with a good strategy suggested using an experience grid.
Time
The main point of this article is that while gaining the experience required for your coding skills to shine at an interview is easily accessible using only the above resources, you need to factor in the time it takes to get this experience.
This can be difficult if you are holding down an existing full-time job and trying to cram the practice into spare hours at either side of the work day, while also balancing family and other commitments. Do not assume you will have enough time unless you prioritise.
Other things have to suffer if you are going to truly commit to improving your interview coding skills. If this is high enough priority for you then you simply have to set aside other projects (for me it was taking a break from this Blog among other things), in order to get the time to brush up on your skills.
When is a good time to start? You should start using the above resources and begin refining your answers to behavioural type questions months before attempting to look for a new job. For many of us, this is advice that we get a little too late, usually after we have already scheduled our first technical interview.
My own experience was that I was completely unprepared for the first couple of interviews I did. I found pair programming exercises difficult; it wasn’t only the lack of an IDE or the limited time. My biggest issue was having to survive without many coding libraries using just the bare resources of your programming language of choice.
The first such interview I did was on a service that did not include the JUnit libraries. I started to write tests thinking “How are you supposed to write tests without Junit?” Of course this is possible, but the first time you try to do so should not be an interview with a potential new employer.
I also struggled with open ended design questions; my mindset was that there is usually an answer that the interviewer wants to hear and the candidate’s job is to find it. These design questions are not so clearly defined, and a single question can end up taking up the majority of an interview as you explore the various design choices that need to be made.
I also performed poorly at behavioural type questions in my first attempt. While I had prepared some answers, drawing on my experience, I found that the pool of projects was too small. I kept repeating the same projects in answer to different questions.
Since then I have improved my ability to code on paper and using some of the on-line tools above. I’ve started to think about and practice answering broader design questions and I’ve gone back over my career to pick out interesting projects and problems so that they can be used to help answer behavioural questions. I wish I had started earlier.
Advice
If you are in a technical role, and even if you are not thinking about leaving any time soon, I think you owe it to yourself to start preparing for that eventual day.
The skills you can learn by practicing coding problems and challenges may not be of use daily, but it is good to have those skills in your tool set anyway.
Even if you don’t initiate a change yourself, it is possible that your company will be acquired or merge with another down the line. These stressful events can mean that jobs are lost in one or both companies, and sometimes companies resort to technical interviews, often carried out by independent third parties, to identify the candidates to keep. Best to be prepared even if this seems unlikely.
Then there are internal opportunities in your present company, whether for promotion or for the chance to work with another team or in another location. These tend to come up suddenly, perhaps without much of a window between advertisement and deadline, and the interviews are quickly scheduled. You may find yourself in a technical or HR style interview with little time available to practice. If you can try to do some preparation before it is required, it will give you confidence and lower the stress when it happens.
Here are a few tips to make sure that your interview skills are always sharp:
- practice coding problems on sites like hackerrank.com and leetcode.com
- read Cracking the Coding Interview and practice the problems with pen and paper
- keep notes on projects that you work on: challenges and solutions, difficult situations, things that you are proud of, goals that you had to stretch to receive etc.
- review the list of projects regularly
- find a mentor or friend that will help you practice both coding and HR style interviews, turning the table on each other to share the practice
- volunteer to be the interviewer for your company; experience of this will improve your own interview skills