Virtually every software engineer may have to be interviewed at some point in their career. For some, it’s an easy process, for most others, it’s often not. So for those who are skilled programmers but don’t know how to scale this hurdle separating you from your next job, here are a few tips.
Getting an Interview
Interviewing in itself is a skill, and the interviewing process involves some degree of subjectivity (learn to embrace these). This implies that the more interviews you take, the better you get at interviewing so the trick with interviews is that you need to get as many interviews as possible.
So how do you get invited to as many interviews as possible?
Use your Network
During the course of your career, you would have met one or two people who are working in software engineering jobs. Reach out to them and ask for interview referrals. Not only for roles in their company but for as many other companies that they know are hiring at the time. Even if your friends turn you down because they feel you are not “good enough for the role”, this feedback is actually good. You should ask these friends how you can get better and if they are truly your friends, they would point you in the right direction.
Don’t stick to only close pals. Feel free to reach out to your LinkedIn network or any social media platforms where you are connected to people in the field, roles, or jobs you admire.
Apply to jobs
Remember, you need as many interviews as you can get so, apply. Platforms such as angel.co, vanhack, caspar coding, GSH, Vettery, Hackerrank, LinkedIn, Stackoverflow… are all places that can help you get an interview. Just read the Job Description and if it matches something you want or can do, apply for it. I recommend that you don’t shy away from jobs that you “sort of” meet the requirements for. If for example, the job description lists 5 skills and you have 4 then apply. Don’t fret that you are not “good enough” for the role. Let the interview process prove or disprove that.
I ask that you apply wisdom in doing this though. Some companies have policies that prevent candidates from applying multiple times in a year so try not to apply to jobs that you are certain you are not a fit for.
Preparing for Interviews
So you’ve got a bunch of interviews coming up. How do you prepare?
Well, there are different kinds of interviews so I will try to break down preparation steps for all the stages of the interview process.
Believe it or not but any conversation you have with any recruiter is an interview and so you should treat it as such. Some companies go the extra length to have behavioral interviews towards the later stage of the interview process but most times, as casual as all conversations go, the interviewer is trying to answer a basic question. Is this candidate a good fit? I like to use the analogy of dating when dealing with these interviews. If you really like someone (in this case the company you are interviewing with) but don’t show it, the chances of dating the person will be slimmer. However, no matter how much you like the person (company), you cannot force them to date you.
So prepare for the interview by reading about the company and job description. It would help to take notes about your potential answers to questions. During these interviews, you should try to be on your best behavior, be punctual, and literally do things that would add to your case and not detract from it (such as proper lighting if it is a video call, eradicating noise, or distractions, …). When answering questions, you should literally aim to point out the things about you that make you a great fit for the job such as your skills, the things you’ve accomplished, and how much you can contribute to the growth of the company. Also, try not to let your downsides show. Some recruiters will try to bring these out but make sure your answer to every question makes you a better candidate than you would have been if you had not been asked the question.
After the conversation with the recruiter, the next interview is almost always a coding challenge. This could be a take-home assignment, a programming challenge over the phone, or an in-person programming task.
A classic take-home assignment will be a programming task that you would be asked to submit your solution to in about 24 hours to 7 days (depending on the company). Sometimes, depending on the size of the problem in question, rather than allowing you to do this exercise entirely unsupervised, you may be asked to build some aspect or all of this application with interviewers watching you. This shouldn’t change your approach greatly but most importantly, try not to fret at the extra pressure this caveat may add.
Irrespective of when you are expected to submit your solution, most of the time, you would be asked not to focus too much on the problem and that the company is looking to understand how you code,… but if you consider that this is a date that could lead to a potential relationship then you will realize that you need to showcase your skills to put your name at the top of the queue. This is where your skills come in. I implore you to actually solve the problem given, if there are bonus challenges to the problem, you should also (attempt to) solve these. Some interviewers would want to see an overengineered solution. You should try to get a feel for this (it may not be wise to ask about the interviewer’s preference outrightly). If the interviewer appears to be interested in an over-engineered solution then you should, by all means, use every programming paradigm, design pattern, and SOLID principle you have ever learned.
Programming challenges are the bane of many software engineers. There are many possible programming challenges, ranging from data structures to algorithms and other fields. So how do you prepare for these? If you have been following the rules thus far, you should know that even this also is a numbers game and practice makes perfect. In other words, you should aim to have encountered some question that is similar in some way to the question you would be asked during the interview.
Start by reading up about data structures and algorithms from your favorite computer science textbook or course (eg. Udemy). Of course, there are multiple ways to solve problems but most questions need one or two data structures to be solved efficiently. Once you understand the theory behind these data structures, you need to use them in actuality. I implore you to solve questions on platforms such as leetcode, hackerrank, codility, … No number of questions is too large. The target for all engineers (junior or senior) should be to solve or at least attempt all the easy questions on these platforms. Senior engineers should tackle the medium and hard problems after conquering the easy ones. By doing this huge number of questions, you will get accustomed to the challenges of software engineering and the solutions that work best to solve these problems in interviews.
You don’t have to wait till you have solved all the problems in this world before interviewing though. Remember, even interviews are sample problems to add to your practice list. You just need to schedule your interviews in a way that reduces the risk of failing the interview and increasing the opportunity to learn. For example, if losing an interview will not hurt you, maybe because the company is not your dream job, take the interview even when you don’t feel ready but if you really like the job, give yourself ample time to prepare.
System design interviews
Most junior engineering roles do not have system design interviews but almost every senior developer would encounter this. A classic system design interview would ask you to discuss how you would build a system. So how do you prepare for this?
Well, similar to technical interviews, practice makes perfect. You should start by reading up on real-world systems. Learn about the technologies, their strengths, the weaknesses and build your lingua because, just like in every profession, if you can’t speak like the top class, you are not in the top class. After you understand the theory, you should move on to reading about classic system design interview questions and potential solutions. I recommend reading this series of blog posts and if you can, take this course. I found both super helpful and I’m sure they would help you also. After you have read and learned about the vagaries of system design, you now need to practice. I recommend using pramp.com to schedule practice system design interviews. Beyond the good range of questions, pramp is also a great way to get interview-like scrutiny from other interviewees like yourself.
During the interview
This is the moment of truth that will tell you just how well prepared you actually were? Understand that this is just a test and just like any other test, if you prepare well, you will do just fine.
Try to relate with the interviewer like a colleague. In many cases, they are there to point you in the right direction without offering the solution to the problem (that’s your job this time around), and don’t think too much about the result. The anxiety might cause your downfall.
(That’s all I have to say about the interview itself. You can see by now that preparation is literally 80% of the work)
After the interview
Let’s write a classic if statement.
If you pass
If you passed the interview then the next conversation would probably be about negotiating salaries however, using the dating analogy, you should take this conversation seriously if you want to “date” this company.
Try to find out what the average pay for the role you are interviewing for is. Also, do your best to uncover what you think you are comfortable with and what the company is comfortable with paying. Remember, sometimes, all you need is an inlet to the company and then you will grow into higher levels so be ready to make a compromise especially if the experience is more vital to you than the pay. All in all, depending on your situation, do not settle for less, however, treat your recruiter with decency. You might end up working with him anyway so do not undermine this relationship because of a few bucks.
If you fail
Failure is useful. It tells you how not to do a thing. The same applies to interviewing. If you fail an interview, don’t go about crying. Be sure to ask for the reason for the verdict. Truth be told, there are many possible reasons. Remember that there are a million people also looking for the same job so there is the chance that you were just not the best candidate. Reflect on the interview, figure out possible ways you could have done better. If possible, ask the recruiter questions that can help unveil how you could have done better and use those tips, if given, in your next interview.
By following the steps highlighted thus far, you will find that the journey to your ideal or dream job is neither as simple nor as hard as you might think. You need only be prepared for every possible hurdle along the way.