What Junior Python Developers Get Wrong Talking to Interviewers

RECITING SYNTAX — READ AS AN INTERVIEWER:

Interviewer: "How would you remove
duplicates from a list?"

Candidate: "I'd use set()."

Interviewer: "What about the order of the
list?"

Candidate: [pause] "Um, set doesn't preserve
order. There's... OrderedDict?"

Interviewer: "What's the trade-off?"

Candidate: [pause] "I'm not sure."

What I notice:
- The first answer is a one-liner: "set()."
- The follow-ups expose the gaps: order,
  trade-offs.
- The candidate knows the function, not the
  semantics.

What it signals:
❌ Memorized the answer
❌ Doesn't know what set() does to order
❌ Can't reason about trade-offs
❌ Tutorial-level depth

What I do next:
- I ask: "What would you use if order
  mattered?"
- If they can reason about dict.fromkeys or
  a loop, they recover.
- If they can't, the depth score drops.

The strong answer:
"Depends on whether order matters. If it
doesn't, set() is O(n) and simplest. If it
does, dict.fromkeys() preserves insertion
order since Python 3.7 and is also O(n). If
you need to preserve order and handle
unhashable items, a loop with a seen list is
O(n²) — slower, but works for dicts. So the
choice is: set() for speed, dict.fromkeys()
for order, loop for unhashable."

Why it works:
✅ The problem is defined: order matters?
✅ Three approaches, with complexity
✅ The trade-off is named
✅ The choice depends on the requirement

DESCRIBING THE PROJECT — READ AS AN
INTERVIEWER:

Interviewer: "Tell me about a project you
built."

Candidate: "We built a Flask app with
authentication and a dashboard. We used
SQLAlchemy and deployed on Heroku. We had
a team of three."

Interviewer: "What did you write?"

Candidate: [pause] "I worked on the backend.
We all contributed to different parts."

What I notice:
- "We" appears six times, "I" never.
- "I worked on the backend" is vague.
- The candidate can't name a specific piece
  they wrote.

What it signals:
❌ Passenger on the project, not the driver
❌ Can't describe their own code
❌ No ownership story
❌ Tutorial-level depth

What I do next:
- I ask: "What's one function you wrote,
  and why?"
- If they can name it and explain the why,
  they recover.
- If they can't, the ownership score drops.

The strong answer:
"I wrote the auth layer. The team used a
shared session table, but I chose JWT with
short-lived tokens and a refresh endpoint
because the dashboard was going to be a SPA
and sessions would have required sticky
load balancers. The trade-off was token
revocation — JWTs can't be revoked easily,
so I added a short TTL and a refresh
rotation. That's the piece I'd defend."

Why it works:
✅ "I wrote the auth layer" — specific
✅ The decision and the why
✅ The trade-off: token revocation
✅ The piece they'd defend

THE RECITATION — READ AS AN INTERVIEWER:

Interviewer: "What's the difference between
a list and a tuple?"

Candidate: "Lists are mutable, tuples are
immutable."

Interviewer: "When would you use a tuple
instead of a list?"

Candidate: [pause] "When you want it to be
immutable?"

What I notice:
- The first answer is textbook.
- The follow-up is circular: "use a tuple
  when you want immutability" is just
  restating the definition.
- The candidate can't reason about a use
  case.

What it signals:
❌ Memorized the definition
❌ Can't apply it to a real decision
❌ No reasoning about the trade-off
❌ Tutorial-level depth

What I do next:
- I ask: "Have you used a tuple as a dict
  key?"
- If they say "yes, tuples are hashable,
  lists aren't," they recover.
- If they can't, the depth score drops.

The strong answer:
"Beyond immutability, the practical reason
is hashability. A tuple can be a dict key or
a set member; a list can't. So if I'm
building a cache keyed by coordinates, I'd
use a tuple. I also use tuples for
fixed-shape data — like a row from a query —
because the immutability signals 'don't
modify this.' A list is for a collection I'll
grow or change."

Why it works:
✅ The practical reason: hashability
✅ A real use case: cache keyed by
  coordinates
✅ A second use case: fixed-shape data
✅ The choice depends on the requirement

THE BLUFF — READ AS AN INTERVIEWER:

Interviewer: "How does the GIL work in
Python?"

Candidate: "The GIL is... a lock. It makes
Python slower. It's why you need
multiprocessing instead of threading. I've
definitely dealt with it."

Interviewer: "What exactly does it lock?"

Candidate: [pause] "The... interpreter? I
think. I've read about it."

What I notice:
- The candidate claims experience: "I've
  definitely dealt with it."
- The follow-up exposes the gap: they
  can't say what the GIL locks.
- The bluff turns a knowledge gap into a
  trust gap.

What it signals:
❌ Bluffed instead of admitting the gap
❌ No mental model of the GIL
❌ The trust gap is now bigger than the
  knowledge gap
❌ Every other claim is now suspect

What I do next:
- I ask: "What do you actually know about
  concurrency in Python?"
- If they can reason about threads vs.
  processes, they recover.
- If they bluff again, the interview is
  over.

The honest recovery:
"I know the GIL is a lock that prevents
multiple threads from executing Python
bytecode at the same time, which means
threading doesn't help for CPU-bound work.
I'd use multiprocessing for CPU-bound and
threading or asyncio for I/O-bound. The part
I'm less sure about is the exact mechanics
of when the GIL is released — I know it
happens periodically and on I/O, but I'd
verify the details before relying on them."

Why it works:
✅ The honest gap: mechanics of release
✅ The reasoning: CPU-bound vs. I/O-bound
✅ The action: verify before relying
✅ The trust gap is closed by honesty

DEFINITION QUESTION — ANSWER WITH
REASONING:

Interviewer: "What's the difference between
a list and a tuple?"

WHAT YOU SAY:
"Sure. The headline difference is
mutability — lists are mutable, tuples are
immutable. But the practical reason I reach
for a tuple is hashability: a tuple can be
a dict key or a set member, a list can't.

So the choice depends on the use case. If
I'm building a cache keyed by coordinates,
I'd use a tuple — (lat, lon) — because it's
hashable. If I'm building a collection I'll
grow or change, I'd use a list.

The trade-off is flexibility vs. safety. A
list is more flexible; a tuple signals 'this
is fixed-shape data, don't modify it.' In
my last project, I used tuples for database
rows and lists for the results of a query,
because the row shape was fixed and the
result set was dynamic.

Does that answer your question, or do you
want me to go deeper on the hashability
part?"

What it signals:
✅ Definition: mutability and hashability
✅ Use case: cache key, fixed-shape data
✅ Trade-off: flexibility vs. safety
✅ Real example: database rows vs. results
✅ Collaboration: "does that answer?"

Why it works:
- The definition is the door, not the room
- The use case proves you've applied it
- The trade-off proves you understand it
- The example makes it memorable

PROJECT QUESTION — ANSWER WITH OWNERSHIP:

Interviewer: "Tell me about a project you
built."

WHAT YOU SAY:
"Sure. I'll focus on my part, because the
team was three people.

I wrote the auth layer. The team's plan was
to use Flask-Login with server-side sessions,
but I pushed for JWT with short-lived tokens
and a refresh endpoint instead.

The reason was architectural: the dashboard
was going to be a SPA, and sessions would
have required sticky load balancers or a
shared session store. JWT is stateless, so
it scales horizontally without either.

The trade-off was token revocation — JWTs
can't be revoked easily. I accepted that by
adding a short TTL (15 minutes) and a refresh
rotation. If a token is compromised, the
window is 15 minutes, not indefinite.

The result: the SPA scaled without sticky
sessions, and we handled about 500
concurrent users on a single instance.

What I'd do differently: I'd add a
revocation list for the refresh tokens
earlier. We added it in month three, after a
security review flagged it."

What it signals:
✅ Ownership: "I wrote the auth layer"
✅ Decision: JWT over sessions, with a why
✅ Trade-off: token revocation, mitigated
✅ Number: 500 concurrent users
✅ Reflection: revocation list earlier

Why it works:
- "I wrote" is specific, not "we built"
- The decision has a reason
- The trade-off is honest and mitigated
- The number proves it worked
- The reflection shows growth

Junior Python Interview Checklist:

FOR EACH CONCEPT:
☐ Define it in your own words, not the
  textbook
☐ Name the trade-off: speed, memory,
  readability, safety
☐ Give one real example from your work
☐ Say "it depends" and then say what it
  depends on

FOR EACH PROJECT:
☐ Name what you wrote, specifically
☐ Name one decision and the why
☐ Name the trade-off you accepted
☐ Name one number: users, requests, time
☐ Name what you'd do differently

FOR EACH GAP:
☐ Say "I haven't used that" honestly
☐ Reason from first principles
☐ Name what you'd do to learn it

RED FLAGS IN YOUR OWN ANSWERS:
❌ "I'd use set()" with no follow-up
❌ "We built" with no "I"
❌ "I've definitely dealt with it" without
  detail
❌ Guessing instead of admitting a gap
❌ No trade-off, no example, no number
❌ The answer is a definition, not a
  demonstration

THE REASONING TEST:
For each question, ask yourself:
1. "Can I name the trade-off?"
2. "Can I give a real example?"
3. "Can I say 'it depends' and then say
  what it depends on?"

If any answer is no, that's the concept to
practice before the interview.

30-DAY JUNIOR PYTHON PLAN:

Week 1 — Concepts
☐ Pick 10 core Python concepts
☐ For each, write a definition in your own
  words
☐ Write the trade-off it involves
☐ Write one real example

Week 2 — Projects
☐ Pick 2 projects from your resume
☐ Write what you specifically wrote
☐ Write one decision and the why
☐ Write the trade-off and one number
☐ Practice each in under 2 minutes

Week 3 — Gaps
☐ Write 5 things you don't know well
☐ Practice the honest answer: "I haven't
  used that, but here's how I'd reason
  about it"
☐ Write the reasoning for each
☐ Record and listen for bluffing

Week 4 — Mock interviews
☐ Have a peer ask 10 questions: 5 concepts,
  3 projects, 2 gaps
☐ Use the three-part answer: problem,
  approach + trade-off, example
☐ If you pause or bluff, that's the concept
  to practice
☐ Re-run the mock until no pauses

Signs it's working:
✅ You define the problem before the
  solution
✅ Every answer has a trade-off
✅ Every project has an "I wrote"
✅ Every number is specific
✅ You never bluff a gap
✅ The interviewer asks "tell me more"
  instead of "let's move on"