What I Wish Every Python Developer Candidate Knew Before Walking In

Interview Insights · Python Developer

What I Wish Every Python Developer Candidate Knew Before Walking In

SECTION 01What each round is really scoring

Candidates often prepare by solving very hard problems on practice sites, then walk into a junior Python interview and stumble on a question about lists versus tuples. The mismatch is common. Each round of a typical Python interview has its own purpose, and knowing it helps you prepare the right things.

The exact process differs between companies, so treat the table below as a typical pattern rather than a rule. Ask the recruiter what the rounds are. That question alone is a sign of a prepared candidate.

Questions worth asking before the interview:

- How many rounds are there, and what is each one?
- Is the coding round live or take-home?
- Which editor or platform will I use?
- Can I choose Python for the coding round?
- Will I be asked about my own projects?
- Roughly how long is each round?

Recruiters usually answer these happily.
The answers tell you exactly what to practise.

'I am a computer science graduate who has spent the
last year mainly on Python backend work. My strongest
project is a FastAPI service for tracking library
books, with PostgreSQL and pytest tests. The part I
enjoyed most was designing the late-fee logic and
testing its edge cases. I am looking for a backend
role where I can work on APIs and data, which is why
this position interested me.'

Notice the intro ends by linking back to the role. That gives the interviewer a natural next question and keeps the conversation on ground you prepared.

SECTION 02The Python basics I check in almost every interview

There is a small set of Python fundamentals I check almost every time, because they reveal whether a candidate understands how Python behaves or only how to type it. They include mutable versus immutable types, how assignment and copying work, why dictionaries and sets are fast for lookups, what a generator is, and how exceptions should be handled.

None of these are advanced. But a candidate who explains them clearly tells me they will write fewer surprising bugs. Below are short examples I use, with the answers I hope to hear.

import copy

a = [[1, 2], [3, 4]]
b = a                   # same object
c = a.copy()            # new outer list, same inner lists
d = copy.deepcopy(a)    # new outer and inner lists

a[0].append(99)

print(b)  # [[1, 2, 99], [3, 4]]
print(c)  # [[1, 2, 99], [3, 4]]  inner list shared
print(d)  # [[1, 2], [3, 4]]      fully independent

print(a is b, a is c)  # True False

def read_large_log(path):
    """Yield one stripped line at a time, never the whole file."""
    with open(path, encoding="utf-8") as f:
        for line in f:
            yield line.rstrip("\n")


def error_lines(lines):
    return (ln for ln in lines if "ERROR" in ln)


# Works on a file much larger than memory:
# for line in error_lines(read_large_log("app.log")):
#     print(line)

nums = (n * n for n in range(5))
print(next(nums), next(nums))  # 0 1
print(list(nums))              # [4, 9, 16]  (already used values are gone)

If you can run these two snippets in your head and explain each printed line, you are ready for most fundamentals questions in a junior Python interview. Practise saying the explanations aloud, not just reading them.

SECTION 03How to use the interview room, not just survive it

The interview room has resources that many candidates ignore: the interviewer, the whiteboard or editor, and time to think. I wish more candidates used them. Asking 'can the input list be empty?' is not a weakness. Writing a quick example before coding is not slow. Running your code on a small case before saying 'done' is exactly what I want to see.

Online interviews add their own surprises. A shared editor may not autocomplete, may not run code, or may use a different Python version. If you have only ever coded in a full IDE, this can feel strange. Practise once in a plain editor before the day.

Problem: Return the first non-repeating character
in a string, or None.

Clarify first:
- Case sensitive? (assume yes)
- Empty string? (return None)

from collections import Counter

def first_unique(s):
    counts = Counter(s)
    for ch in s:
        if counts[ch] == 1:
            return ch
    return None

assert first_unique("swiss") == "w"
assert first_unique("aabb") is None
assert first_unique("") is None

Say aloud: two passes over the string, O(n) time,
extra space for the counter.

PRACTISE ONCE WITHOUT YOUR IDE

1. Open a plain text editor or an online pad.
2. Turn off autocomplete if possible.
3. Solve one easy problem fully from memory:
   imports, function, tests with assert.
4. Note what you forgot:
   - exact method names (str.isalnum? str.isalpha?)
   - import paths (from collections import Counter)
   - indentation after copy-paste
5. Check your Python version assumptions:
   match statements need 3.10+,
   dict union with | needs 3.9+.

The three assert lines at the end take ten seconds to write. They tell me you think about empty input and the 'no answer' case without being asked. That habit alone lifts many average coding rounds.

SECTION 04The night-before checklist for Python interviews

Most avoidable interview problems come from small things that nobody checked: a project that no longer runs, a forgotten detail of your own code, a webcam that fails. Use this checklist the evening before.

TECHNICAL (45 minutes)

[ ] Clone each resume project fresh and run it
      python -m venv .venv
      pip install -r requirements.txt
      pytest -q
[ ] Re-read the main function of each project
[ ] Revise: mutability, copy vs deepcopy, dict/set
      lookups, generators, exceptions, list comprehension
[ ] Solve two easy problems in a plain editor
[ ] Note the Python version you used in each project

STORIES (30 minutes)

[ ] Two-minute introduction, said aloud twice
[ ] One project decision and the option you rejected
[ ] One bug you fixed: symptom, cause, fix, test
[ ] One thing you would improve in your best project
[ ] Why this company and this role (2-3 sentences)
[ ] Three questions to ask the interviewer

SETUP (15 minutes, online interviews)

[ ] Laptop charged, charger nearby
[ ] Internet tested; phone hotspot as backup
[ ] Camera at eye level, light in front of you
[ ] Interview link and platform tested
[ ] Quiet room, notifications off
[ ] Pen and paper for working through examples
[ ] Resume open in a tab, the same version you sent

SECTION 05Small things that change how the interview feels

These habits do not need extra study. They change how calm you feel and how clearly your skill comes through.

• Arrive with your own code fresh — Re-read your project code the night before. Being unable to explain your own function is the most avoidable mistake I see.
• Say the simple solution first — Give a working simple solution, then improve it if time allows. An unfinished clever solution scores lower.
• Treat hints as help — When the interviewer gives a hint, pick it up and say how it changes your approach. That is collaboration, not failure.
• Prepare honest 'don't know' lines — Say what you do know that is related, and how you would find the answer. It keeps the conversation moving.
• End with real questions — Ask about the codebase, testing practices or what a first month of work looks like for the role. It shows real interest.

SECTION 06Interview Q&A — Python interview prep

SECTION 07Test yourself — Python interview prep quiz

SECTION 08Frequently asked questions

SECTION 09Related reads