Technical interviews

Why it matters

Most tech hiring processes include a test of the actual work: a coding problem, a SQL exercise, a design challenge, a case study or a teaching demo. Interviewers are not only checking for a correct answer. They are watching how you think, communicate and handle being stuck, because that is what working with you would be like. Preparing for the format removes a lot of avoidable stress.

The core idea: a typical process

Processes vary, but a common sequence is:

1. Recruiter screen (20–30 minutes): background, interest, logistics, salary range.
2. Hiring manager call: your experience and motivation.
3. Technical assessment: a take-home task, a live exercise, or both.
4. Final round: several interviews covering technical depth, collaboration and behavioural questions.
5. Offer and references.

What the technical part looks like by role:

Live exercises: think aloud

Interviewers want to follow your reasoning. A reliable routine:

1. Restate the problem in your own words.
2. Ask clarifying questions: input size, edge cases, what to return when something is missing.
3. Work an example by hand.
4. Describe a plan before writing code or designs. Start with a simple working approach; improve later.
5. Build it, talking as you go.
6. Test with your example and an edge case.
7. Discuss improvements: speed, readability, what you would change with more time.

Worked example. "Write a function that returns the most common word in a sentence."

• Restate and clarify: "Should it ignore case and punctuation? What if two words tie?" The interviewer says: ignore case, ignore punctuation, return either on a tie.
• Example: "The cat and the hat" gives "the".
• Plan: lowercase, remove punctuation, split on spaces, count with a dictionary, return the word with the highest count.

from collections import Counter
import re

def most_common_word(sentence):
    words = re.findall(r"[a-z']+", sentence.lower())
    if not words:
        return None
    return Counter(words).most_common(1)[0][0]

print(most_common_word("The cat and the hat."))   # the
print(most_common_word(""))                       # None

• Test: the example, an empty string, a sentence with punctuation.
• Improve: "If performance mattered on huge text, I would stream the words rather than load them all at once."

Even if you do not finish, this routine shows clear thinking.

Take-home tasks

• Respect the time limit. If they say 3 hours, do not spend 20. Note what you would add with more time.
• Read the brief twice and do exactly what it asks first; extras come after.
• Include a README: how to run it, your assumptions, trade-offs and next steps.
• Make it easy to review: clean structure, sensible names, a few tests or checks.
• Be cautious about take-homes that look like real unpaid client work or take days.

Behavioural questions and STAR

Questions like "Tell me about a time you disagreed with a teammate" are scored seriously. Use STAR:

• Situation: the context, in one or two sentences.
• Task: what you were responsible for.
• Action: what you did (say "I", not only "we").
• Result: the outcome, with a number if you can, and what you learned.

Prepare four or five stories from projects, jobs, volunteering or study that you can adapt to different questions.

Common mistakes

• Coding in silence. The interviewer cannot credit thinking they cannot hear.
• Jumping in without clarifying.
• Not testing your own solution.
• Overbuilding take-homes and blowing the time limit.
• Memorising answers instead of understanding them. Follow-up questions expose it.
• Being afraid to say "I don't know". Say what you would do to find out.

Quick recap

• Expect a test of real work; formats vary by role.
• Live: restate, clarify, example, plan, build, test, improve, all while thinking aloud.
• Take-home: follow the brief, respect the time limit, include a clear README.
• Behavioural: tell STAR stories with your own actions and results.

Try it

Open the Do tab to practise a take-home and a live exercise.