This page is aimed at applicants preparing for computer science interviews at Cambridge, Oxford, and Imperial. Below are two full mock interviews that I have created, with accompanying hint and answer sheets. The advice in this page is relevant for most STEM subjects, however the interview questions are specifically targeted towards computer science applicants.

Before looking at these interviews, please read the rest of this page to help you make the most of the questions.

Don’t look at them until you are ready to answer them in interview conditions!

These interviews are intentionally challenging, and you are not expected to complete all of the questions within the allotted time. The focus is less on how many questions you answer and more on how you approach and respond to unfamiliar problems.

If you share these interview questions, please credit this website page.

Interview 1

Questions, Hints, Answers

Contains 1 computer science question (split up into 4 parts).
Can be treated as a pre-reading interview (the first 2 pages are pre-reading).
Expected to take around 40 mins.

Interview 2

Questions, Hints, Answers

Contains 3 maths-based questions.
Knowledge of mathematical induction is required.
Expected to take around 35 mins.

Using These Questions

These interview questions are designed to closely resemble the types of questions you might receive in an interview. You will gain the most out of these questions by completing them in mock interview conditions.

Find an interviewer. If possible, try to find someone to interview you; learning to speak your thoughts out loud in front of another person is a vital interview skill. Your interviewer should ideally be someone older than you from a computer science or maths background, such as a teacher or a university student / graduate. Failing this, try asking peers from your school or other computer science applicants.

Ask your interviewer to prepare. Ask your interviewer to prepare in advance of the interview by looking through the question, hint, and answer sheets. You will benefit the most out of these questions if the interviewer understands the questions well, and is able to guide you towards the solution. The hint sheets are specifically designed for interviewers to refer to during the interview, as they provide tips and guidance for them to drop in case you get stuck.

Record the interview. I recommend requesting your interviewer’s permission to record the interview, so you can watch it back at a later date. This can help you understand what you look like from an interviewer’s perspective. If you cannot find anyone to interview you, try recording yourself answering these questions whilst speaking your thoughts out loud, as if you were in a real interview.

Setup full interview conditions. Mock interviews are a great way to mentally prepare yourself for taking real university interviews. Try setting up full interview conditions: put up a clock timer, sit in a room alone with just you and the interviewer (or conduct the interview online), give yourself scrap paper or a drawing tablet to work out your ideas on, and remove all other distractions.

Don’t worry if you don’t finish. You are not expected to finish all parts of all interviews in the time: many successful candidates do not! If you are on a question for a disproportionate amount of time, the interviewer should move on and then come back to the question at the end if you have time. It is better to attempt all parts of the interview, than to complete only half the interview and not look at the remaining questions.

Treat the interview as if it were real. Given that this isn’t a real interview, it might be tempting to break the illusion of the interview if you get stuck (especially if you are being interviewed by a friend or peer). However, a large part of the interview is seeing how you react when you are stuck on a problem – you’ll get the most out of the interview if you commit to it as if it were real.

Interview Preparation Advice

If there is one thing you should take away from this page, it’s that university interviews are primarily a test of how you think rather than what you know. At university, the existing knowledge you have will likely be covered very quickly during the course. Interviewers are usually more interested in testing how quickly you can pick up new concepts (for when you get to the parts of the course that you don’t understand).

What does this mean in practice? University interviews are designed to quickly push you to the point where you don’t immediately know how to answer the question, as this is where the interviewers will learn the most about you. So when you reach this point, the most important thing to remember is not to panic, and to approach the problem calmly and methodically. Everything in the interview before this point is usually just buildup.

The aim of the interview is not to prove that you are smart, but to prove that you are teachable. This is an important shift in mindset, as trying to show off in interviews often comes off badly. Obviously a base level of technical ability is expected from you, but admissions offers are also looking to see if you are: pleasant to interact with, open to new ideas and concepts, and responsive to guidance and criticism – vital skills that can only really be tested during interviews.

Treat the interview like a conversation: tell the interviewers what you are thinking, bounce ideas off them, and discuss tradeoffs to different approaches to the problem. This helps you come across as genuinely passionate, and as someone the interviewer would enjoy teaching at university.

What To Practice?

The two most important things to focus on are your maths and basic programming skills. I would recommend being comfortable with at least all of the A level maths course (or equivalent for your country). Skills such as geometry, graph sketching, logical reasoning, vectors, series, probability, and combinatorics might be required in your interview.

Even though interviews generally don’t require specific programming knowledge, having basic programming experience provides you a strong foundation for solving interview problems. Learning the basics of a programming language such as Python (including integer operations, variables, if-statements, for-loops, while-loops, functions, IO input/outputs, and basic data structures such as tuples and classes) should be more than sufficient.

I would also recommend revising mathematical induction and recursive functions (both from mathematics and programming), as these topics commonly appear in interviews. I found this video to be a useful introduction to recursive programming.

If you have revised these topics and are still looking for more things to practice, I would look into logic and proofs (the TMUA notes provide a good starting point). As well as: registers and basic assembly language, stacks, queues, stack machines, graphs, trees, linear search, binary search, insertion sort, merge sort, quick sort, and hashing. You shouldn’t be expected to know any of these topics before your interview, but they may provide some useful foundational knowledge that you can apply during your interview.

The next step is to practice answering interview questions; I have linked some resources at the bottom of the page which can be used as practice questions. Try answering these questions as if you were in an interview: speak your thoughts out loud, discuss tradeoffs to different approaches, and justify any decisions you make. The more practice the better! Try to find a variety of different interview questions as you never know what may come up.

What To Do If You Are Stuck?

You are expected to get stuck on problems during your interview, so what steps can you take to get yourself unstuck?

The most important thing you can do is to listen to your interviewer. They are there to help guide you through the problem, and are looking to see you succeed rather than testing to see if you fail. Part of the interview is evaluating how well you respond to feedback and guidance, so make sure you keep an open conversation with your interviewer.

This isn’t to say blindly follow whatever your interviewer tells you – if they say something you don’t understand then try asking more questions and explore the approach with them before committing to it. If you think their idea is wrong, or that your approach is better, you can discuss this with them (even better if you can explain the trade-offs to the different approaches). However, don’t act confrontationally, and be open to new ideas. If you have an interesting conversation with the interviewer comparing different solutions to the problem, this should be viewed positively even if you do end up going with their approach.

In order to prompt useful conversations with the interviewer, try speaking your thoughts out loud even if you haven’t fully thought them through. Interviewers often latch onto ideas that are heading in the right direction.

In interviews you are usually given a piece of paper or a drawing tablet to sketch out solutions. I would also recommend using this to sketch out ideas, as it is often easier for interviewers to understand your approach when it is written down compared to spoken verbally. Sketching out verbal problems diagramatically and writing down formulae that might be relevant to the problem at hand can help you find connections you otherwise wouldn’t see.

All in all, communication with your interviewer is key. Don’t be afraid of asking clarifying questions, stating obvious facts, and discussing possible solutions with the interviewer – these are things that interviewers are actively looking for.

Approaching Unfamiliar Problems

Interviewers often pose problems in unfamiliar contexts, and expect you to apply knowledge you have in other areas to solve the question. When approaching problems like this, I would recommend using the following strategy:

Read the questions twice. There is nothing worse than incorrectly assuming you know what the question is asking and immediately going down the wrong route.
Be clear about any assumptions you are making. For example, if a question is ambiguous or doesn’t define something properly, you can make reasonable assumptions about what the question means as long as you check these assumptions with the interviewer.
If possible, try working through small examples to better understand the problem.
If you are struggling to see a solution, try finding an easier form of the problem to complete.
If the question is recursive in nature, are there any patterns in the smaller examples that repeat in larger problems?
List out several possible approaches to the problem, and state facts and knowledge you have from other areas that might be relevant.
Try to discuss tradeoffs to the different approaches, and select one to try out.
Once you have worked through your solution, try it on some examples to make sure it works.

Example Problem

Lets give an example of this approach on the following interview question (used in Imperial computer science interviews a few years ago):

A building has 100 floors. One of the floors is the highest floor an egg can be dropped from without breaking. If an egg is dropped from above that floor, it will break. If it is dropped from that floor or below, it will be completely undamaged and you can drop the egg again. Given two eggs, find the highest floor an egg can be dropped from without breaking, with as few drops as possible.

First lets read the problem twice and understand what it is saying. The question is slightly ambiguous so lets state our assumptions: we assume that we want to find the fewest number of drops required in the worst case (rather than the average case). That is, we are looking for the smallest value \( n \) which guarantees that we find the right floor with \( n \) or fewer egg drops.

For simplicity, lets call the first egg “A”, and when this breaks we swap to the second egg “B”. Our next step is to work through some small examples: the obvious step to making this problem smaller is to reduce the number of floors.

If there were only one floor, we wouldn’t actually need to drop any eggs! The problem says that one of these floors is the highest floor that an egg can be dropped without breaking – since there is only one floor, this must be the right floor!
With two floors, we need to drop egg A from the second floor to see if it breaks. If it does the answer is the first floor, and if it doesn’t then the answer is the second floor.
With three floors things start to get a bit more tricky. Lets drop egg A on the second floor, and if it doesn’t break then drop it again on the third floor. This tells us the answer with only two egg drops, which must be the right answer as we cannot find the answer with only one egg drop.
With four floors… it becomes less obvious which strategy to test. We could test all of them, but lets simplify the problem again to see if another solution falls out.

Lets assume that instead of two eggs, we only had one egg to drop. The answer here is much more simple: we would need to drop the egg at every floor, starting at the second floor, in order to find the answer. We couldn’t risk skipping any floors as if the egg breaks we have no way to know which floor is the right floor. Hence, the number of egg drops required to test \( n \) floors is \( n - 1 \) (as we start at the second floor).

This gives us an interesting insight: for the full “two egg” problem, we want to reduce the number of potentially correct floors as much as possible with the egg A before it breaks, as the remaining floors would need to be searched linearly with egg B.

Lets list out some different approaches to the problem:

“100 floors” is rather arbitrary, lets try and come up with a general solution for \( n \) floors, and then substitute in 100 for \( n \).
The “one egg” problem requires us to look through every floor, which reminds us of a linear search.
Perhaps the full “two egg” problem requires a more complex search like a binary search?
This problem might be recursive, which we can solve using recursive functions.

Unfortunately the binary search approach doesn’t work: if we test the 50th floor followed by the 75th floor and the eggs break on both floors, we run out of eggs! However this approach appears to be along the right lines: if egg A doesn’t break then we want to jump up some number of floors and repeat the experiment to quickly search through the remaining floors.

Lets say we drop egg A on floor \( n \) – this gives us two cases:

Case 1: The egg breaks. In which case we have to search the remaining \( n - 1 \) floors linearly (\( n - 2 \) drops required).
Case 2: The egg doesn’t break. This allows us to repeat the same experiment again some number of floors up as we still have both eggs.

This sounds vaguely recursive as Case 2 repeats the same function, but starting at a higher floor. Lets define \( f(n) \) as the number of potentially correct floors under egg A’s drop, and \( g(n) \) as the number of floors we go up if egg A doesn’t break.

Starting at floor \( n \), we get the following cases for \( f(n) \):

Case 1: Egg A breaks and we need \( n - 2 \) drops (derived above).

Case 2: If egg A doesn’t break then we know that floors \( 1 \rightarrow n \) are safe. Hence, if we go up \( g(n) \) floors and drop egg A again, the number of potential floors is \( g(n) \) (as we have already eliminated floors \( 1 \rightarrow n \)). So, by repeating this function with \( g(n) \) potentially correct floors under A, the number of drops required is: \( f(g(n)) \).

Remembering that to drop egg A in the first place we need another \( 1 \) drop, we get the following formula:

\( f(n) = 1 + [ \text{CASE 1}: (n - 2) \text{ or CASE 2}: f(g(n)) ] \)

So for CASE 2 what floor do we want to pick (what should \( g(n) \) be)?

Lets run through two different ways this experiment could play out. In Scenario 1, egg A breaks on the first drop and we need \( n - 2 \) searches for the the remaining floors. In Scenario 2, egg A doesn’t break and we go up \( g(n) \) floors and repeat the experiment, but in the second experiment egg A does now break.

Our intuition says that no matter which scenario plays out, the worst case number of drops should be equal.

Scenario 1: \( 1 + n - 2 \)

\( 1 \) for egg A (which breaks), \( n - 2 \) for the egg B (linear search)

Scenario 2: \( 1 + f(g(n)) \) ⇒ \( 1 + 1 + (g(n) - 2) \)

\( 1 \) for egg A (which doesn’t break), \( 1 \) for egg A again (which does break), \( g(n) - 2 \) for egg B (linear search of \(g(n) - 1 \) floors between floor \( n \) and floor \( n + g(n) \)).

To find the optimal value for \( g(n) \) we can then set these equal:

\[ \begin{flalign} & \hspace{3mm} 1 + (n - 2) = 2 + (g(n) - 2) && \\[2mm] & \hspace{2mm} \therefore \, g(n) = n - 1 && \end{flalign} \]

Hence, every time egg A doesn’t break, we want to jump up \( n - 1 \) floors!

However, what should the starting value for \( n \) be? This should be the value such that if we repeat this pattern we cover all 100 floors. I.e. \( n + (n - 1) + (n - 2) + \ldots + 1 = 100 \):

\[ \begin{flalign} & \hspace{3mm} \frac{n(n + 1)}{2} = 100 && \\[2mm] & \hspace{3mm} \Rightarrow n^2 + n - 200 = 0 && \\[2mm] & \hspace{3mm} \Rightarrow n = 13.65\ldots && \end{flalign} \]

By taking the positive result and rounded up, we are left with a final answer of 14: we require at most 14 egg drops to find the correct floor using this method. This answer turns out to be optimal, but proving this can be tricky so we will leave that for now.

Lets use an example to test our strategy, where the correct floor is \( 38 \):

First egg drop from floor \( 14 \): doesn’t break
First egg drop from floor \( 14 + 13 = 27 \): doesn’t break
First egg drop from floor \( 14 + 13 + 12 = 39 \): does break
Second egg linear search from floors \( 28 \rightarrow 37 \) inclusive (\( 10 \) drops required)
The remaining floor (floor \( 38 \)) must be the correct floor (no drop required)

Total drops = \( 1 + 1 + 1 + 10 = 13 \) (which is less than our cap of \( 14 \)). Intuitively we can see that our strategy looks correct no matter which floor is the correct answer.

This was my approach to the tackling the question blind… but what was the point of this example? Here are some key takeaways that are worth keeping in mind:

Rabbit holes are ok. It is alright to go down the wrong path; interviewers will still gain useful insights into your problem-solving ability, even if the path doesn’t eventually lead to the solution.

For the sake of brevity I showed my more direct approach to the solution, but when initially attempting this problem I went down the wrong route (solving recursive functions and modifying the binary search algorithm). There is no need to panic if you realise you went down the wrong route, as long as you recognise this and work with the interviewer to correct your track. Interviewers are smart enough not to judge your problem-solving ability entirely around whether you picked the right path at the beginning or not.

However, by following the structured approach I mentioned earlier, I was able to clearly lay out my thoughts and list potential avenues to solve the problem. This provides opportunities for the interviewer to guide me towards the correct solution – which they wouldn’t have been able to do had I jumped straight in.

Show your intent. It is more important to show your general problem-solving approach, than it is to perfectly structure your solution. For example, including CASE statements in functions isn’t mathematically correct, but they can be useful in interviews to show your thought process. If the maths is important, you can always come back and clean it up later once you have shown them your full solution.

State the obvious: Some of my insights (such as that we want to eliminate as many floors with egg A before we get to egg B) sound obvious, but it is worth spelling these out explicitly to the interviewer. Many people are worried that stating obvious facts may make them look stupid, but these statements are often sign-posts that interviewers are looking for to make sure you are on the right track.

More often than not, spelling out these obvious insights helps you clarify your approach with the interviewer, and makes the next steps clearer. For example, this insight reminded me of binary search (an algorithm which cuts down the remaining options as quickly as possible by jumping to different positions), which ended up motivating my final solution.

Understand Your Interview Type

Be aware that colleges conduct interviews differently to each other. Some colleges ask a mix of personal statement, computer science, and mathematics questions, while other colleges might focus entirely on maths questions, and some colleges have pre-reading material to review before the interview.

Colleges should hopefully tell you the type of interview they will be conducting when you are invited to interview, but if not then try reaching out to current students or the college’s admissions team for more information.

FAQs

What Should I Wear?

If your interview invite doesn’t specify, then casual formal attire should be perfectly suitable. There is generally no expectation to wear formal clothing such as a suit and tie unless explicitly stated.

How Will The Interview Begin?

Interviewers don’t have long to interview you, so they will jump straight into questions after a quick introduction. The first few problems are likely to be easy, warmup puzzles, but they will ramp up quickly.

How Many People Will Interview Me?

This may be listed on your interview invite, but if not there are typically two interviewers per interview. It it is common for only one interviewer to take the lead on any given question, with the other interviewer observing silently.

How Many Interviews Will I Have?

It will definitely specify this on your interview invite. Most colleges do one or two 20-30 minute interviews.

How Should I Prepare for Online Interviews

Other than practicing online mock interviews, my biggest tip would be to get used to the “drawing” mechanism they will ask you to use. This could be a graphics tablet, drawing with a mouse, or holding up written paper to your camera (they should tell you before the interview). It can be difficult enough to explain your ideas in-person with a sheet of paper, so its worth practicing how to explain your ideas with this added layer of complexity.

Will They Ask Why I Chose This College?

Almost certainly not, they care much more about your passion and talent for your chosen subject. The majority of your questions will be purely technical or based on your personal statement.

Should I Research The Interviewers In Advance?

There is absolutely no benefit to researching your interviewers in advance: you almost certainly won’t get a chance to talk to them about their areas of expertise, and it won’t give you any advantage to bring it up during the interview.

Should I Ask Questions At the End Of The Interview?

Only ask if you have a genuine question: these questions are unlikely to count for or against you. Interviewers have many people to go through, so try not to ask questions just for the sake of it (especially ones that can be Googled beforehand).

Further Resources

The CSAT exam (section B) contains interesting questions, which can be used as mock interview questions.
Oxford have released some sample compsci interview questions here.
The Cam CS Admissions Discord server contains lots of good resources in #interview-prep and #resources.
Interview tips and a mock interview by Churchill’s computer science Director of Studies: Dr. John Fawcett.
Queens’ computer science mock interview.
Sidney Sussex computer science mock interview.
The Cambridge computer science website also links other useful preparation material.

Contact Me

If you find any mistakes or ambiguities in either the questions, hints, or answers, please let me know at @theduckmaster. on Discord, or at dylan.moss2001@gmail.com by email.

If you have any further questions, or would just like to let me know that you found these resources useful, please don’t hesitate to contact me!