Computer Science Oxbridge Interview Questions 2026 — Model Answers

1. Home
2. Resources
3. Oxbridge Interview Questions
4. Computer Science

An Oxbridge Computer Science tutor rarely stops at a correct answer. Comparing two enormous powers without a calculator, counting passwords once the rules shift mid-question, and showing that bubble sort both terminates and gets the right answer are really questions about cost and proof, not just mechanics. Ten problems in the Computer Science pack are built around that habit, with Big-O growth rates threaded through every one of them from start to finish.

Oxford and Cambridge Computer Science interviews assess mathematical thinking and algorithmic reasoning — not programming ability. You will not be asked to write code in any specific language. Interviewers are looking for candidates who can reason about computational problems from first principles, analyse algorithms for correctness and efficiency, and engage with mathematical proofs in the same way a mathematician would. Algebraic manipulation and the formal definition of growth rate matter more here than any specific algorithm, and one question builds a counting argument that keeps changing its own rules as it goes. What is hard to rehearse alone is the part that actually gets marked: the interviewer does not stop when you produce a correct algorithm. They ask what it costs, then ask you to beat it, and the answer you gave a minute earlier has to survive being priced. Further down, one of the questions posed on this page — the k-th largest element of an unsorted array — is taken through that whole sequence, including the first answer I would have offered and the reason it does not last. The ten questions inside the Computer Science pack are a different shape: algebra and formal proof, graph sketching by hand, that evolving combinatorics problem, and two open discussion questions with no fixed answer at all, each printed with a hint before the full worked answer rather than a live back-and-forth.

What Are Oxford and Cambridge Computer Science Interviews Like?

Oxford Computer Science candidates typically have two 25–30 minute panel interviews at their applied college, with a strong emphasis on mathematical reasoning. Cambridge Computer Science candidates also have two panel interviews, reflecting the mathematical rigour of the Cambridge CS Tripos from the first year. The TMUA (Test of Mathematics for University Admission) is used by Cambridge for CS shortlisting from 2024 entry and will be used by Oxford CS from 2027 entry — Oxford CS uses the MAT (Mathematics Admissions Test) for 2026 entry. Approximately 30 students are admitted to Oxford CS alone annually (plus joint course students); Cambridge admits approximately 90 CS students per year.

What Types of Questions Appear in Computer Science Interviews?

Algebra that resolves into a proof, not a formula. The pack opens with two reciprocal equations linking two unknowns to a sum of cubes. There is no shortcut substitution; the useful move is spotting a symmetric identity, turning the pair into a single cubic, and then checking which of its roots actually correspond to real values of the two original unknowns rather than stopping at the first root you find.

Big-O from its formal definition, not its intuition. Rather than asking you to state that an algorithm runs in quadratic time, the pack asks you to prove a function sits inside a Big-O class using the actual definition — naming a constant and a threshold and showing the inequality holds beyond it, including the case where a leading coefficient could be zero. A separate question asks which of two enormous numbers, each expressed as a different power, is larger, which turns out to need the same kind of inequality-scaling rather than a calculator.

Graphs sketched by hand, checked by calculus rather than drawn from it. Three functions are set to be sketched without a calculator, with differentiation used only to confirm a feature you should already be able to locate by reasoning first. One of the three has a period that shrinks toward a single point, forcing a decision about how to draw a limit that does not exist.

One combinatorics problem that keeps changing its own constraint. A counting problem is posed, answered, and then the interviewer changes a single rule — inserting a character, moving it, switching what is being arranged — so that each follow-up rewards spotting a correspondence between the old count and the new one rather than starting again from scratch.

Two questions with no fixed right answer. One is about everything a computer's operating system is responsible for behind the scenes; the other is about what it actually means to call an algorithm iterative. Both are marked on how well you structure an answer on the spot and build on what you already know, rather than on reciting a definition.

Whether two things that look equal really behave the same. One question asks you to prove that two different-looking expressions define the same real function, then asks whether two short pieces of code computing them would agree for every input once you allow for how a real machine represents numbers. A separate question tests a candidate function against a stated algebraic property and asks you to go looking for other kinds of functions that do satisfy it.

Two full correctness proofs. The final question has two parts: proving that a coin-toss-based procedure really does produce each outcome with equal probability, then adapting one line of it for a different case; and proving that a well-known sorting method is totally correct — that it must stop, and that what it hands back really is sorted — using an argument about how many pairs are still the wrong way round.

None of this requires writing runnable code, and only two of the ten questions are open discussion with no single target answer — the rest reward the same close, step-by-step algebra and proof you would use in a Mathematics interview, aimed at problems phrased in computing terms. That suits an applicant who is already fluent in that kind of reasoning and wants it tested somewhere new, more than someone looking for coding-interview practice.

A Worked Question: The k-th Largest Element

A demonstration question, not one of the pack's own ten, run the way an interview runs it — including the answer I would give first, which loses.

What the interviewer asks next

• “What is that costing you, in terms of n and k?”
• “Try it at k = 1. Now try it at k = n/2. Does the same answer still look sensible at both ends?”
• “Suppose the numbers arrive one at a time and you cannot hold all of them. What survives?”
• “Can you beat n log k?”
• “Your new method — what is its worst case, and who gets to choose it?”
• “Make that worst case linear. Do not give me the algorithm; tell me what property the pivot would have to have.”

Working it through

My first instinct is to carry the answer with me: keep a sorted list of the k largest values seen so far, scan the array once, and for each new value compare it against the smallest entry, slotting it in and dropping the smallest whenever it wins. At the end of the scan the smallest entry in that list is the k-th largest overall. That is correct, and I would say the word correct out loud before saying anything about cost: they are separate claims.

The cost is where it dies. Slotting a value into a sorted list of length k takes up to k moves, and I may do it on every one of the n elements, so the method is O(nk). The second prompt finishes it. At k = 1 the list holds one entry, nothing shuffles, and the method is one pass — O(n), unbeatable. At k = n/2 it costs n × n/2 = n²/2, quadratic, while sorting the array outright and reading position n − k costs O(n log n) for every k. So my answer is unbeatable at one end and beaten by “just sort it” across the middle. An answer that loses to the laziest alternative over half its range is not finished.

What is wrong is the container, not the idea. I want the smallest of my k candidates in constant time and to replace it in fewer than k steps: a min-heap of size k. Its root is the smallest of the k largest so far, so each new element costs one comparison, and only those that pass pay O(log k) to evict and insert. One pass, O(n log k) time, O(k) space — and it answers the streaming prompt for free, because the method never needed the array, only k slots and the numbers going past. Worth pricing: at n = 1,000,000 and k = 10, log₂ n is about 19.93 against log₂ k at about 3.32, so the heap does a sixth of sorting’s comparison work — and since k never exceeds n it is never worse than sorting.

Then: can I beat n log k? Quickselect. Choose a pivot, partition so that everything greater than it sits above it, and count how many landed there. If exactly k − 1 did, the pivot is the answer; if more did, recurse above with k unchanged; if fewer, recurse below with k reduced by what I discarded. The partition costs about n comparisons, and unlike quicksort I descend into one side only, so if each pivot roughly halves what remains the work is n + n/2 + n/4 + … — a geometric series summing to 2n. Linear, and no sorting anywhere.

I would say the word expected before being asked for it, because the worst case is genuinely bad. If the pivot is the largest remaining element every time, each partition discards exactly one element and the work is n + (n − 1) + (n − 2) + … — the classic n(n + 1)/2 sum you get from adding the integers 1 to n, quadratic again and worse than the heap I already had. Who chooses that? Someone who knows my pivot rule and hands me an already-sorted array. Choosing the pivot at random does not make the bad case impossible; it moves it out of an adversary’s control and into chance, and the expected cost stays linear.

The last prompt is where I would say I am reasoning rather than reciting. To make the worst case linear I need a pivot guaranteed to throw away a fixed fraction of what remains, not merely to throw away something. If every step certainly discards at least three tenths, at most seven tenths survive, and spending a sub-problem of size n/5 to find such a pivot gives T(n) ≤ T(n/5) + T(7n/10) + O(n). That is linear because 1/5 + 7/10 = 9/10, less than one: the sub-problems shrink faster than the work per level accumulates. Naming the property answers the question asked; naming the algorithm that achieves it does not.

What is being tested here

No step there needed a programming language, or a fact memorised the night before. It needed the habit of pricing an idea as soon as you have it, testing it at both extremes of its parameter, naming the structure that repairs it, and being explicit about which claims are worst-case and which are expected. The wrong turn was not the problem: O(nk) was a real answer and it lost to sorting, out loud, in front of the panel. The problem would have been having nothing to say when shown k = n/2.

How to Approach an Algorithm Question Without Writing Code

State the algorithm in plain English or pseudocode. Describe the key steps, the data structure you would use, and the decision logic. Then analyse the time complexity using Big O notation: "Each element is visited once and each comparison takes constant time, so the overall complexity is O(n)." Then consider whether a better algorithm exists: "This approach is linear in time and constant in space — can we do better in time? The lower bound for comparison-based search in an unsorted array is O(n), so this is optimal." This structure — describe the algorithm, analyse its complexity, consider optimality — is what Computer Science interviewers at both Oxford and Cambridge reward. The failure mode is silence. A candidate who works the whole thing out internally and announces only the finished algorithm has given the panel nothing to mark, because what is being marked is the working. Saying a weak idea, pricing it, and discarding it in front of them is a stronger minute of interview than a correct answer arrived at quietly.

What Students Say

Frequently Asked Questions