Technical interviews test how you think, not whether you have memorised solutions. Most people prepare by grinding puzzle problems, which helps with one part and misses the rest.
What is usually assessed#
- Problem solving. Can you break a problem down and explain your thinking out loud?
- Coding fluency. Can you write working code without constant reference?
- Communication. Do you ask clarifying questions before diving in?
- Your own projects. Can you explain what you built, why, and what you would change?
- Fundamentals. Data structures, complexity, and language specifics at a reasonable level.
Candidates usually over-prepare the first two and under-prepare the middle two.
A balanced preparation plan#
Weeks 1–2: shore up the fundamentals#
- Arrays and lists, dictionaries and sets — know when each is the right choice
- Complexity basics — enough to say why one approach is slower
- Strings, loops and functions without looking up syntax
Weeks 3–5: practise problems, but out loud#
Work through problems in your language, and narrate your reasoning as you go. Silent practice does not prepare you for explaining while typing under observation — which is the actual skill being tested.
Aim for understanding a modest number of problems deeply rather than skimming hundreds.
Weeks 4–6: prepare your own projects#
For each project on your portfolio, be ready to answer:
- What does it do and who is it for?
- Why did you make that technical choice?
- What was the hardest bug and how did you find it?
- What would you change with more time?
That last question is where people most often impress or disappoint. Having a thoughtful answer signals real self-awareness.
Throughout: mock interviews#
Practise with another person, or record yourself. The gap between “I can solve this” and “I can solve this while someone watches” is real and only closes with practice.
During the interview#
- Clarify first. What are the inputs? What should happen with empty input? Are there constraints? Asking this is a positive signal, not a weakness.
- Say your plan before coding. “I will use a dictionary to count occurrences, then find the maximum.” This lets the interviewer steer you before you write fifty lines.
- Write the obvious version first. Working and slow beats clever and broken. Say “this is O(n²); once it works I will look at improving it”.
- Test it out loud. Walk a small example through your code. Interviewers notice this.
- Keep talking when stuck. Silence is the only genuinely bad outcome.
When you get stuck#
Say so, and say what you have ruled out. “I am stuck. I know a nested loop works but it is too slow, and I think there is a way to do it in one pass — I am trying to work out what to store.” That is far better than freezing, and interviewers will often give you a nudge.
Questions worth asking them#
- What does the first month look like for someone in this role?
- How does code review work here?
- What is the balance between new features and maintenance?
- What would make someone successful in this team?