How to read code you didn't write, fast, in an interview

Writing code gets all the attention, but reading code you have never seen is the skill that shows up again and again at work and in interviews. Teams share a file and ask what it does. They show you a failing test and ask why. They hand you a pull request and ask if you would approve it. If you have a method for this, you look senior. If you do not, you freeze. Here is the method.

Read in layers, not line by line

The instinct is to start at line one and read down. Resist it. You understand code faster by zooming out first, then in.

Layer one: the shape

What is this thing? A function, a class, a test file? What does its name suggest? For a function, read the signature first: what goes in, what comes out. That one sentence tells you most of the intent before you read any logic.

Layer two: the flow

Now read the body in plain words, top to bottom, without worrying about syntax. "It filters the list, sorts it, takes the top ten." You are building a one-line summary of what it does, not memorising how.

Layer three: one real example

Pick a concrete input and walk it through. If the list has these three items, what comes out? Tracing a single example catches misunderstandings instantly and makes you sound like you genuinely follow the code, because you do.

Then put your tester hat on

Once you can say what the code does, the valuable part begins: what is wrong, risky or missing. This is where you win an interview. Go looking, in roughly this order.

• Comparisons that look wrong for the language, like comparing text the way you would compare numbers.
• Maths that silently loses information, like dividing two whole numbers when you wanted a decimal.
• Values that could be empty or missing, and what happens when they are.
• Changing a list while looping over it, which blows up in many languages.
• Off-by-one mistakes at the start or end of a loop.
• Tests that cannot fail, or that hide their own errors.

You do not need to find all of them. Naming two real issues, each with a one-line fix, reads as strong. Naming the missing test that would have caught the bug reads as senior.

Narrate it the way an interviewer wants to hear

Put the layers together out loud and it sounds like this. "This returns a list of results and takes a user id, so it is the fetch and rank. It filters by score then sorts descending. For a new user with no history the filter yields nothing, so the interesting case is the empty one. Two things I would flag: this comparison should use the text equality method, and there is no test for the empty case." That is calm, structured and specific, and it is entirely learnable.

Why this matters beyond interviews

Most of an engineer's or tester's real life is spent reading code other people wrote, under a deadline, trying not to break it. The interview version is just a compressed rehearsal of the day job. Get good at reading in layers and you are better at both.

Practising with Wisptr

If a snippet or a test is shared on your screen in an interview, Wisptr can read it and explain what it does at the level you are interviewing for, so you can say it in your own words. It is a fast way to check your own read against a clear one while you practise, and a safety net if you get stuck on the day.