What juniors get asked at a technical interview

How the block is structured

The technical stage usually has four parts: language questions, database questions, a problem, and a discussion of your project.

None of them expects an exhaustive answer. They're checking whether the foundations are there and whether you understand what you're saying.

Language questions

The most common concern how basic things work:

• What data types exist, how mutable differs from immutable.
• How lists and dictionaries work, why dictionary lookup is faster.
• What a function is, what happens to arguments when passed.
• What an exception is and how to handle one.
• What scope means.

What's tested: whether you memorised syntax without understanding what sits underneath. A good answer comes with an example from your own work.

Database questions

• How to select rows with a condition and sort them.
• What a join is and why it exists.
• What an index is, when it helps and when it hurts.
• How a relational database differs from a document one.

What's tested: whether you can write a simple query unaided. For a beginner, confident selection, filtering, sorting and joining two tables is enough.

General questions

• What happens when you type an address into a browser.
• How request methods differ and what response codes mean.
• What version control is and how to resolve a conflict.
• Why tests exist.

What's tested: whether you understand the context your code runs in, or live inside a single file.

The problem

Usually straightforward: reverse a string, find duplicates, count word frequency, check balanced brackets.

What's tested: not the solution but the process. Did you clarify the problem, talk through the approach, check the edge cases — empty input, a single element, all elements identical.

A flawed solution with clear reasoning scores higher than a correct answer delivered in silence.

The project discussion

Here they test the important thing: whether you really built it. The questions are simple but merciless — why this way, what was hard, what would you change.

Prepare for this block specifically. It's predictable and entirely within your control.

What juniors don't get asked

Hard algorithms, architectural subtleties, obscure language features. If those come up, it's either a probe of where your knowledge ends — "I don't know" is a fine answer — or a badly run interview.

The main advice

Don't memorise a list of questions. Prepare to explain what you built yourself. All of these topics arise naturally when you describe your own project in detail — and an account of your own work can't be memorised, only lived.