The HackCampus guide to technical interviews

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.

General tips

The technical interview

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!)

Talking about your experience and past projects

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.

General programming / software engineering knowledge

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:

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.

Algorithms and data structures

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.

Whiteboard coding

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.

Types of coding questions

Whiteboard coding questions are sometimes direct descriptions of a general algorithmic problem. For example:

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 n birds is flying across the continent. Each bird has a type, and the different types are designated by the ID numbers 1, 2, 3, 4, and 5.

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.

(This question is taken from HackerRank)

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.

Finding a solution

You should always keep some general things in mind:

Writing code

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:

Systems design / architecture

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.

For example:

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:

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.

Don't panic!

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!