Interview Preparation
From personal experience, I know that programming interviews can be quite stressful. You will be off your game because it is a much more different environment than you are probably used to. Many programmers are accustomed to programming alone and focusing on just typing. However, in an interview, you will have to code with someone who is watching you and talking to you. In my first few interviews, I was a nervous wreck and I fumbled through easy problems. However, in later interviews, I became more accustomed to the process and became more comfortable with the interviewer. As you do more interviews in your life, you will be less nervous and become more confident in your abilities. The more prepared you are, the more likely your chances of success in the interview room. In this section, you will find a small guide to rocking the interview!
Resume
Resumes are key to getting any interview in the first place and your resume should be able to show off your abilities and talent. Some of the key tips I have for tech companies:
- Have either one or two pages exactly
- GPA doesn't matter unless it's low
- Your school is not very important
- Github with interesting side projects show your abilities
- ACM / TopCoder / Programming Contests show your abilities
- Put relevant work experience (e.g. marketing at a tech company will not matter when applying for a technical role)
Before the Interview
Preparation is the most important thing you can do for interviews. You can be as charming and confident as you want, but if you cannot solve their problems, your application will quickly be discarded. When you are given a problem, there is a chance you have solved or read about a solution to the problem. Hence, the more prepared you are, the more likely you can come up with a solution. The sections in this handbook that come up the most are: everything in Data Structures, Advanced Recursion and Binary Search. If you cover those topics, you should be set for most interviews. However, if you are interviewing for higher end companies, you may need to cover much more material. In some interviews, you will be asked to code your solution, therefore I suggest you become very familiar with a language. You should be proficient enough to know how to do input/output, use the standard library and how to debug properly. Java is a good language to use as it has many built in data structures and has stack traces for debugging.
There are two types of interviews I have encountered: phone/Skype interviews and in person. If given a choice, in person is always preferable. When you doing an in person interview, you are able to communicate better with your interviewer and build a rapport. You will also be able to show your thought process on paper which is easier to do than via phone or Skype. Additionally, depending on the company, if they fly you down to their headquarters for the interview, you'll get a free trip!
If the company you are interviewing for is a startup, you can dress casually. Otherwise, if the company is more corporate, then you may want to dress a little more formally.
During the Interview - Part 1: Behavioural
The interview usually starts with introductions and then the interviewer will usually ask you about projects you've worked on as well as past places you have worked. A common question is: what was the hardest part about that project and how did you solve it. (If you do not already have a personal project, then I highly recommend starting one. If personal projects do not interest you, then this field may not be for you. Hackathons are a good way of starting projects as you are able to focus a large chunk of your time on a single project). During this first part of the interview, try to build a better rapport with the interviewer. You should be passionate about the work you have done and hopefully your interviewer is equally passionate about their own work and be able to relate to you. Essentially, in this part of the interview, you need to convince your interviewer that you are a likeable person and that they can work with you.
Like any normal interview, try to maintain eye contact and good posture. Ask the interviewer some questions about their position and projects they are working on. Listen and be interested in to what they have to say.
During the Interview - Part 2: Technical
The second part of the interview usually consists of technical problems. If you are expected to code the solution, you should expect a medium to difficult problem (30-45 min) and possibly an easy problem (5-10 minutes). However, if you are interviewing for a large tech company (Facebook or Google) you should expect 2 - 4 medium to difficult problems that you will need to solve. If you are not coding, then you should expect 3-4 problems where you will need to describe the solution.
Step 1 - Analyzing the Problem (1 - 2 minutes)
When given the problem, make sure you read through the problem carefully and that you understand the specifications. Ask your interviewer for clarification if you are unsure of anything.
Step 2 - Find a solution (5 - 10 minutes)
Now that you understand the problem, ask yourself if you've seen this problem before or any similar problem. If you have, then you should also remember a solution or similar solution and you're in luck! However, if you don't remember the solution or have not seen the problem before, then you will need to think out the solution. First, start with the naive solution which is usually a bruteforce method. An inefficient solution is better then no solution. Once you have that, start working towards a more optimal solution. You should be thinking aloud and letting the interviewer see your thought process. You should write down your solutions on paper so that it can be more clear to the interviewer what you are trying to do. You should be able to explain why your solution is more efficient than another and why it works. If your solution is wrong, the interviewer may stop you and you should quickly find the mistake and determine why it is wrong. Keep going as far as you can without letting the interviewer help you. If you are stuck, the interviewer will likely drop a hint and you should be able to pick up from that. Once you have the best solution, you should be confident enough to prove that it is optimal. However, if the interviewer asks if you can do better, then it is more than likely that there is a better solution.
Step 3 - Start coding (10 - 20 minutes)
Now that you have a solution, you need to prove to the interviewer that you can implement it. If you are proficient enough, you should be able to code and debug easily enough. You should comment your code and name your variables properly so your interviewer knows whats going on.
End Interview
Hopefully, you have time left before the interview (otherwise, you took too long for the technical part). Ask your interviewer about projects at the company to get a feel of what will interest you. Ask them any other questions you have about the position like any other interview. When you leave, thank the interviewer for their time, put on a smile and shake their hand. Ultimately, the outcome of the interview is determined by the amount of rapport you built with the interviewer, how capable you were at the technical problems and how enthusiastic you are. If all goes well, you will get the job, or you will get a second round of interviews meaning you get to repeat the same process with another interviewer! Good luck!