Oxford and Cambridge Computer Science Interviews

A Computer Science interview at Oxford or Cambridge is unlike anything you will have encountered in school. Your tutors are not checking whether you have memorised content from your A-level syllabus — they are watching how you think. They want to see whether you can take an unfamiliar problem, reason about it carefully, and make intellectual progress in real time. That means standard revision, on its own, will not prepare you. What matters is developing the habit of thinking out loud, engaging honestly with difficulty, and showing genuine curiosity about ideas that go beyond the classroom.

What to Expect in a Computer Science Oxbridge Interview

Most candidates have two or three interviews, each lasting around 20 to 30 minutes. You will typically be interviewed by two tutors, one of whom may lead the questioning while the other observes and takes notes. The questions often begin with something accessible — a logic puzzle, a short piece of pseudocode, or a mathematical problem — and then escalate in difficulty deliberately. The tutors are not trying to catch you out; they are trying to find the edge of your understanding, and then push just beyond it.

At Oxford, interviews tend to have a strong mathematical flavour, reflecting the degree's emphasis on formal reasoning, algorithms, and theoretical foundations. Cambridge interviews, particularly for the Computer Science Tripos, often probe your ability to think computationally and abstractly, with questions that reward structured problem-solving and clear logical argument. Both universities value intellectual honesty over confident bluffing — if you do not know something, saying so clearly and then attempting to reason from first principles is far more impressive than guessing.

You may be asked to work through problems on paper or a whiteboard. You might be handed a short passage or piece of code and asked to explain, critique, or extend it. The format is deliberately open-ended, because the tutors are assessing your potential to thrive in a supervision or tutorial environment — not your ability to reproduce prepared answers.

The Admissions Tests: MAT (Oxford) and TMUA / Interview Only (Cambridge)

If you are applying to Oxford Computer Science, you will sit the TMUA (Test of Mathematics for University Admission) before your interview. Oxford replaced the MAT with the TMUA from 2027 entry. The TMUA assesses mathematical reasoning at a level beyond A-level. A strong TMUA score will not guarantee an interview, but it will shape what tutors already know about you when you walk into the room. Preparing seriously for the TMUA — working through past papers, understanding where your reasoning breaks down — also builds exactly the kind of mathematical fluency that Oxford interviews demand.

Cambridge applicants may sit the Test of Mathematics for University Admissions (TMUA), though some colleges rely on the interview alone. The TMUA tests mathematical thinking and reasoning rather than curriculum knowledge, and performing well demonstrates the kind of analytical precision Cambridge tutors look for. Whether or not you sit the TMUA, your interview will carry significant weight, and the preparation approach is the same: practise reasoning carefully under pressure, not just solving familiar problem types.

How to Prepare for Your Computer Science Interview

The single most important thing you can do is practise thinking out loud. This feels unnatural at first, but it is a skill you can develop. When you work through a problem in preparation, narrate your reasoning — explain what you are trying, why you are trying it, and what you notice. Tutors are not marking your answer; they are marking your process.

Beyond that, consider the following:

• Work through MAT past papers (Oxford applicants) or TMUA practice materials (Cambridge applicants) under timed conditions, then review your reasoning — not just your answers
• Read beyond your A-level syllabus: explore topics such as computational complexity, recursion, Boolean logic, finite automata, and graph algorithms at an introductory level
• Engage with super-curricular material — books such as The Art of Problem Solving, Gödel, Escher, Bach by Douglas Hofstadter, or introductory texts on algorithms give you genuine intellectual depth to draw on
• Practise with a partner or tutor who will push back on your reasoning and ask follow-up questions
• Revisit problems you found difficult and articulate precisely where your thinking broke down

Super-curricular engagement matters because it signals genuine interest in the subject. You do not need to have built a compiler or completed a university course — but you should be able to speak with real enthusiasm about something in Computer Science that you have explored independently.

Our Computer Science interview specialists work with Oxford and Cambridge applicants on the algorithmic thinking, mathematical reasoning, and problem decomposition that both universities probe in their interviews. We're rated 4.8/5 on Trustpilot. Book a free consultation to discuss a preparation plan that covers the interview alongside the relevant admissions test for your year of entry.

Example Interview Questions for Computer Science

The following questions are representative of the kind of problems Oxford and Cambridge tutors use. They are designed to be worked through, not answered instantly.

• How would you determine whether a given number is a power of two, without using division or logarithms? Can you think of more than one method?
• If you have an unsorted list of one million integers and you need to find duplicates as efficiently as possible, what approaches might you consider? What are the trade-offs between them?
• Consider a simple recursive function that computes Fibonacci numbers. Why is it inefficient, and how would you improve it? What does this tell you about the relationship between time and space in computation?
• Can every problem that can be solved by a computer be solved in a reasonable amount of time? How would you begin to think about what "reasonable" means here?
• You have a graph representing a network of roads between cities. How would you find the shortest route between two cities? What assumptions does your method rely on, and what happens if those assumptions change?
• Is it possible to write a program that can determine, for any other program, whether that program will eventually stop running? What are the implications if the answer is no?

Three Worked Computer Science Interview Exchanges

Reading a list of sample questions only takes you so far. What actually helps is seeing how a real exchange unfolds: an interviewer asks a question, a candidate gives an answer that sounds reasonable but misses the point, and then a stronger answer shows what the tutor was actually listening for. Below are three worked exchanges on topics that come up repeatedly in Oxford and Cambridge Computer Science interviews — the quickselect algorithm, Euclid's algorithm applied to a prime-number question, and the recursion-versus-iteration trade-off. Work through the reasoning, not just the conclusion.

Exchange 1: The Quickselect Algorithm

Question: "Given an unsorted array of a million integers, how would you find the k-th smallest element? Can you do better than sorting the whole array first?"

Weak answer: "I would sort the array using quicksort or mergesort, which takes O(n log n) time, and then look at the k-th position." This is correct and will work, but it does more work than the question needs — the candidate has not noticed that fully ordering a million numbers is wasteful when only one position in that order actually matters.

Strong answer: "I would use quickselect, which is built on the same partitioning step as quicksort. Pick a pivot, partition the array so smaller elements are on one side and larger on the other, and then look at where the k-th element falls. If it falls inside the left partition, recurse only into the left partition; if it falls in the right, recurse only into the right. Unlike quicksort, I never need to recurse into both sides, so the work at each level roughly halves — n, then n/2, then n/4, and so on — which sums to O(n) on average rather than O(n log n). The worst case is still O(n²) if the pivot is chosen badly every time, for example always picking the first element of an already-sorted array, so I would pick the pivot randomly (or use a median-of-medians strategy) to make that worst case vanishingly unlikely in practice."

Why this matters: the interviewer is testing two things — whether the candidate spots that sorting the whole array is unnecessary work for this specific question, and whether they can reason about average-case versus worst-case complexity rather than quoting a single Big-O figure. A candidate who can explain why discarding one partition each round produces a decreasing geometric series of work is showing exactly the kind of algorithmic reasoning Oxford and Cambridge tutors are listening for.

Exchange 2: Euclid's Algorithm and Prime Reasoning

Question: "Prove that if a number n is not prime, it must have a factor no greater than its square root. Then explain how you would efficiently compute the greatest common divisor of two very large numbers."

Weak answer: "I'd check whether n is divisible by every integer up to n minus one, and for the greatest common divisor I would list the factors of both numbers and pick the largest one they have in common." Both parts work for small numbers but scale badly: checking every divisor up to n takes O(n) time, and factorising two large numbers is far more expensive than the problem requires.

Strong answer: "If n is not prime, then n = a × b for some a ≤ b, both greater than 1. Since a ≤ b, it follows that a² ≤ ab = n, so a ≤ √n. That means if n has no factor up to √n, it cannot have one beyond √n either, because any factor pair must include one factor at or below the square root. So trial division only needs to check divisors up to √n, cutting the search space from O(n) to O(√n). For the greatest common divisor, I would avoid factorisation entirely and use Euclid's algorithm: gcd(a, b) = gcd(b, a mod b), repeated until the remainder is zero. Each step shrinks the numbers roughly in proportion to each other, so the algorithm converges in O(log(min(a, b))) steps — the worst case occurs with consecutive Fibonacci numbers. That is exponentially faster than finding the gcd by factorising both numbers first."

Why this matters: the tutor wants the candidate to derive the √n bound themselves, from the factor-pair argument, rather than simply stating it as a known fact. The second half tests whether the candidate recognises that Euclid's algorithm sidesteps factorisation altogether — a distinction that matters because factorising large numbers is computationally expensive, while Euclid's algorithm is not, which is precisely why it underpins fast modular arithmetic in real systems.

Exchange 3: Recursion vs Iteration

Question: "You've written a recursive function to compute the n-th Fibonacci number. When would you convert it to an iterative version, and why?"

Weak answer: "Recursion is more elegant, so I'd always write it recursively" — or the opposite, "iteration is always faster, so I'd always use a loop." Both are absolute claims that avoid engaging with the actual trade-off the question is asking about.

Strong answer: "It depends on two separate issues: memory and redundant work. The naive recursive Fibonacci function recomputes the same subproblems repeatedly, so its time complexity is exponential, O(2ⁿ) — that is a problem with the algorithm, not with recursion itself, and it is fixed by memoising the results or rewriting it as a bottom-up iterative loop that builds up from the base cases, which brings it down to O(n) time and O(1) space. Separately, every recursive call adds a frame to the call stack, so a recursion depth that scales with the input size risks a stack overflow — Python's default recursion limit is around 1,000, and even languages without an explicit limit are bounded by the much smaller stack memory rather than the heap. Iteration avoids that because it uses O(1) auxiliary space regardless of how many steps it takes. I would keep the recursive version where the recursion depth is naturally bounded, such as traversing a balanced binary tree with depth O(log n), because the code is clearer and easier to prove correct by induction. I would convert to iteration, or add memoisation, whenever the depth could scale linearly with the input or the same subproblems are being recomputed."

Why this matters: this question is rarely about a syntax preference. Tutors are checking whether a candidate can separate two distinct concerns — stack depth and memory, versus redundant computation and time complexity — and choose the right tool for the specific structure of the problem rather than applying a blanket rule.

These three exchanges also illustrate just how selective Computer Science admissions actually are. According to the Department of Computer Science's own published 2023-24 admissions statistics report, Oxford's single-honours Computer Science course received 872 applications for 57 offers — an acceptance rate of around 6.5% — while across all three Computer Science degrees (Computer Science, Computer Science and Philosophy, and Mathematics and Computer Science) the department received 1,625 applications and made 148 offers, an overall rate of around 9%. This is considerably more competitive than the 20-25% figure sometimes quoted online, and it is worth preparing with the correct level of selectivity in mind for the 2026-27 admissions cycle: interviewers are not looking for a rehearsed answer, they are looking for the reasoning shown in the "strong answer" columns above.

Common Mistakes and How to Avoid Them

The most common mistake is silence. Candidates who freeze when they do not immediately know the answer give tutors nothing to work with. If you are stuck, say so — and then say what you do know, what you are uncertain about, and what you might try. Tutors can guide a candidate who is visibly thinking; they cannot help one who has gone quiet.

A second mistake is over-preparing specific answers. Candidates who have rehearsed responses to anticipated questions often sound scripted and struggle when the question takes an unexpected turn. Prepare your thinking, not your answers.

A third mistake is failing to engage with feedback during the interview itself. If a tutor suggests your approach has a problem, do not defend it out of pride — treat it as useful information and adjust. The ability to update your thinking in response to new input is precisely what the interview is designed to test.

Frequently Asked Questions about Computer Science Oxbridge Interviews

Frequently Asked Questions