As part of your HackCampus application, you will most likely have to complete a technical interview with one or more of the companies that would like to hire you.
We have compiled a couple of tips and resources that should help you do the best you can in these interviews.
Be prepared to answer questions about your background. You will be expected to be able to talk through your academic background, work experience, and any extra-curricular activities, highlighting relevant details, achievements, successes etc. In particular, be prepared to talk about projects that you have worked on, the biggest technical or personal challenges you have faced in these. You will almost certainly be asked this kind of question in any interview, as they reveal a lot about your interests and attitude to work.
Don't assume that just because the employer has your CV/application form, that the interviewer will know everything about you. The person interviewing you may only have glanced at your application briefly. Remember that the people interviewing you are busy engineers themselves, and have to take time out of their day to interview you. Do not be afraid to repeat information, even if it can easily be found on your CV - if anything, it is a really good signal that you are able to talk about the things you have listed on your CV.
Research the company you are interviewing for. You will often be asked why you chose to apply to them. A lot of candidates give very generic answers to questions about the company they are applying to, which could almost be applied to any company. But companies want to know whether you have done enough research to really understand what makes them different from others, what is unique to them or their problem domain, why have you chosen them over other companies. They want to be flattered (!), so think of specifics about that company that has attracted you to them. Also, what makes them different (and similar) to their competitors? What gives them their competitive edge? What more could they do to enhance this competitive edge?
Take the opportunity to 'sell' yourself. Remember that they are interviewing you because you have made it to this part of the selection process and, ‘on paper’, they are interested in you. However, the interview is an opportunity for you to 'sell' yourself to them - listen out for and don't forget to pick up on any opportunities the interviewer(s) give you to talk about your achievements/experience. Don't worry about repeatedly mentioning the same projects, as long as you are able to talk about an aspect of those projects you have not mentioned yet (eg. a specific technical challenge that you had to overcome).
Be honest and straightforward about your experience. Do not claim to know things you don't, or to embellish the experience you do have with a certain technology or skillset. The person who will interview you will most likely be more experienced in the technologies they will ask you about than you are, and will almost certainly follow up with in-depth questions that you will not be able to answer if you don't know what you're talking about. Better to say that you don’t know about something, but that you will find out, than to pretend that you do.
Think about why the interviewer is asking you the question they are asking. What answer are they trying to get from you? Try to think of the sorts of things you would want to know about someone you were hiring for that role if you were the interviewer. Think about the qualities you would want to see in a successful applicant, and the answers you would want to hear.
Take your time - don't rush your answers. Slowing things down gives you more thinking time. It is better to take a couple of seconds to prepare what you want to say, and to say it confidently, than to immediately blurt out an answer. It is very important to make sure you understand the question being asked - and, if you don't understand the question, ask for clarification.
Don't be afraid to ask for clarification. If you aren't clear about the question being asked or the answer they want, ask for clarification. Asking for clarification shows that you have considered the question. This is particularly important in a technical interview, as some questions will be intentionally very vague. Again, it is very important to make sure you understand the question being asked - take your time! (see above)
Good communication is not just about what you're saying, but how you say it. In a face-to-face interview, don’t forget that apart from verbal communication, how you communicate non-verbally is also very important. Look out for any non-verbal cues and clues the interviewer gives you, such as body language, gestures, eye-contact and any other physical cues. For example, if an interviewer is smiling and nodding, this will probably mean that you are going along the right lines in your answer - but if they are not doing this, it does not necessarily mean that you are not answering the question correctly! Don't forget to smile, and look positive during the interview. Interviews are as much about figuring out if you will be a team-mate the rest of the company will enjoy working with, as they are about finding out about your experience.
There are several different kinds of questions that you will encounter in a technical interview. You will often be asked about:
Every company and interviewer will have different priorities and preferences for how to run an interview, so it is possible that you will not encounter all of these.
You should however be prepared for all aspects of a technical interview, as they require very different skills.
Also, don't assume that just because you code a lot you are able to answer all of these easily: in the majority of interviews, you will not be able to look up anything online.
You need to prepare and know a lot of things off by heart that you would just look up in a normal working environment. Check out this "Epic List of Interview Questions", and practice some of these. (Some of them are very challenging - you are definitely not expected to know all of these!)
We highly recommend reading this article from the Stack Overflow blog. It is an extremely good introduction on how to talk about technical projects you have worked on in an engaging way.
The key points of the article are:
Another useful technique for answering behavioural / competency questions is the STAR Technique.
Interviewers will generally try to test your basic knowledge of key concepts and technologies.
Unfortunately, this is very difficult to specifically prepare for - the only real way to answer these reliably is through experience.
Some examples of questions you might hear:
Be prepared for more in-depth questions about technologies you've mentioned as strong points! Some examples:
protected? What happens when you don't use any of those?
You might be tempted to read through lecture notes to find answers to these questions - don't do this, it is almost certainly a waste of time. With these questions, interviewers are looking to scope out the limits of your knowledge, rather than getting the kind of super-detailed, formal answers that you might find in lecture notes. (And besides, it's probably been several years since your interviewer went to university!)
If you don't know the answer to a question, be upfront about it. Don't be afraid to say "I don't know". However, always try to give the impression that you know where to find a solution. In some cases it can even be beneficial to say "I don't know the details on the spot, but I'm happy to follow up with an answer by email after the interview."
If you do know a lot about what's being asked, don't be tempted to talk about every tiny little detail you do know! Make sure the interviewer is following along with you and is interested in your answer. Regularly stop to make sure that you're on the right track.
A strong knowledge of algorithms and data structures means that you are able to quickly pick the right data structure for any programming task. This is essential if you are asked to do a "whiteboard coding" task in your interview, but can also come up in many other questions. Demonstrating a strong knowledge of algorithms and data structures is an excellent way of showing that you are a good programmer, even if you don't have a lot of relevant work experience.
You should know these data structures like the back of your hand:
You should know how to write basic implementations for them, even though you will probably not be asked to implement the full data structures in an interview. (You may be asked to implement a certain operation of a data structure!)
You should also know when to use one data structure over another. For example: "Use hash maps when you need instant (constant-time!) random access."
You should know the time complexities of the following operations on all these data structures, and how to implement them:
There are also some other common algorithms you should know about, for example:
To be able to talk about time complexity means you need to know how Big O notation works. Check out this answer on Stack Overflow for lots of different ways of describing time complexity & Big O notation that should give you a strong intuition for the concept.
If you have only ever read about Big O notation, this is how you would 'pronounce' the complexity classes:
For example: "Search in an array is a linear time (O(n)) operation, except when the array is sorted. If the array is sorted, you can use a binary search, which is a logarithmic time (O(log n)) operation."
Check out the Big O Cheatsheet, which has all of the data structures and sorting algorithms you will ever need and their respective complexities.
To test your knowledge of algorithms and data structures, you may be asked to write some code for a specific algorithmic problem. This is commonly referred to as "whiteboard coding", since you will sometimes be asked to write the code by hand on a whiteboard - sometimes, you will be able to use a laptop, but don't rely on this!
This is often one of the most difficult and stressful parts of a technical interview. You will often not be able to look up anything online, so you really need to know the programming language you want to use.
You should ask if you are expected to do any whiteboard coding, ideally several days before the interview. It takes a lot of time to properly prepare for whiteboard coding questions. If you know that you won't have to code in the interview, you can spend that time preparing for other parts of the interview.
Whiteboard coding questions are sometimes direct descriptions of a general algorithmic problem. For example:
trueif a string is a palindrome.
Often, you will instead be given a longer problem description, where you have to figure out how to represent the question as an algorithmic problem. For example:
A flock of
nbirds is flying across the continent. Each bird has a type, and the different types are designated by the ID numbers
Given an array of integers where each integer describes the type of a bird in the flock, find and print the type number of the most common bird. If two or more types of birds are equally common, choose the type with the smallest ID number.
A lot of the time, the biggest challenge with these "story-based" questions is how to represent the information you're given as data structures that enable you to find the right answer.
You should always keep some general things in mind:
Don't immediately start writing code. In a lot of cases, problem descriptions are intentionally left vague, to force you to ask clarifying questions. If you don't ask these, and just start writing code, you will have wasted a lot of time and effort.
Always think out loud. The aim of whiteboard coding exercises is not working code, but an insight into how you think and tackle problems. Interviewers will often let you know if you're on the right track, or guide you along the problem. If you just keep quiet and don't manage to finish writing your algorithm, the interviewer will have learnt nothing about your ability to code. If you keep talking and explain your thinking, the interviewer might very well be convinced that you are capable of solving the problem, even if you did not manage to solve it on time.
Never assume anything. If anything is unclear, ask questions! This can help you find edge cases and some hints for a possible solution. For example:
Describe the algorithm you are about to implement. Once you're sure that you understand the problem being asked, you should give your interviewer a high-level description of your algorithm. If you do have a whiteboard available, it can be useful to draw the data structures involved, and run through the different steps of the algorithm. You will often find problems in your initial intuition, and you will be able to solve those before actually writing any code. This will save you a lot of time. (This also applies to 'real' programming!) Your interviewer will also have the opportunity to ask you some questions about the algorithm at this stage, for example its time and space complexity.
Don't worry if you don't complete the entire problem. A lot of coding interview questions are designed to be open-ended, and are (almost) impossible to complete on time. If you manage to describe the algorithm correctly and in enough detail, you shouldn't worry too much about finishing the actual coding.
Once you have really understood the question, and have described the algorithm you're going to implement, you can start coding.
Remember that usually you cannot look up anything during the interview. This means that you should know your language of choice's syntax and how to perform common operations, eg:
Use the language you are most comfortable with. Unless you are applying for a role with a specific language requirement, you are generally allowed to use any language you want. A high-level language like Python or Ruby is ideal, as their syntax is very straightforward - but as long as you're familiar with the language you want to use and its 'gotchas', you should be able to use any language, as long as it's fairly widely used (so Haskell/OCaml/Scheme unfortunately won't be a great choice...).
Practice is very important with this kind of interview question - the constraints very different from 'real' programming, and if you know your algorithms, data structures, and a couple of common tricks, you should be able to do very well.
There are plenty of sites where you can practise coding problems:
In a lot of interviews, you will be asked to design an application given a very broad specification. The challenge is to come up with a reasonable architecture for the application that will fulfil the requirements you are given.
This is a very in-depth article on systems design questions. It is unlikely that you would have to go into this much detail in most interviews, but it is good to know how to tackle all aspects of this kind of question.
Some general tips to consider:
Make sure to gather your requirements very carefully. A design is useless if it doesn't match the requirements, and it is very easy to get carried away with implementation details. Your ability to gather requirements is one of the biggest things that an interviewer will learn from this kind of question, as this is one of the most important aspects of being a successful software engineer.
Start at the highest level. Before you go into any details, you should separate your design into a small number of distinct pieces. For example, for a web app, a basic separation would be: database, application server, web frontend. A desktop app or game could be split into a model, view and controller. Starting with the high-level separation of concerns allows you to tackle each part of your system individually, and allows you (and the interviewer) go into as much detail as is relevant for each part.
Make sure you don't go into too much detail unless the interviewer wants you to. This is applies in every part of the interview, but is particularly important in this question. By going into every possible tiny detail, you show the interviewer that you are not able to communicate the big picture. If you're unsure if you should go into more detail, just ask!
There are a lot of possible follow-on questions from this kind of question, which all depend on the specific question, and the role you are applying for. For example, as a backend engineer you might be asked further details about database schemas, replication, backups, etc., while as a frontend engineer you might be asked how you would break down the application into reusable components.
Interviews are always extremely stressful. If you are well-prepared, you should be able to confidently have your best go at it. Sometimes the interviews that feel the most stressful are actually your most successful - it may just be the case that the interviewer was so impressed with your knowledge that they tried to catch you out. :)
Either way, if you feel like an interview has not gone well, just consider it a learning experience, and try again with the next one. In every interview you take, you will get a little bit better at talking about yourself and your achievements, and will know a little bit more about software engineering and computer science, until you manage to find your dream job.
Best of luck!