DEV Community: Peakblick

Django select_related vs prefetch_related (With Examples)

Peakblick — Tue, 13 Oct 2026 06:36:40 +0000

Both exist to fix the same thing — the N+1 query problem — but they work on different kinds of relationships. The whole decision comes down to one question: is the relationship single-valued (a ForeignKey) or multi-valued (a ManyToMany)?

The problem they solve: N+1 queries

Say each Book has a ForeignKey to Author. This innocent loop quietly runs one query for the books, then one more per book to fetch its author:

books = Book.objects.all()
for book in books:
    print(book.author.name)   # a new DB query every iteration

100 books → 101 queries. That's the N+1 problem, and it's the single most common Django performance bug. select_related and prefetch_related both collapse those extra queries — they just do it differently.

select_related — for ForeignKey and OneToOne

select_related follows a single-valued relationship (ForeignKey, OneToOne) by doing a SQL JOIN and pulling the related object in the same query:

books = Book.objects.select_related('author')
for book in books:
    print(book.author.name)   # no extra queries — author came via the JOIN

101 queries become 1. Because it's a database join, it only works when each row has exactly one related row — that's why it's for ForeignKey and OneToOne, the "forward" single object.

prefetch_related — for ManyToMany and reverse ForeignKey

A JOIN can't efficiently fetch a multi-valued relationship (many rows per object), so prefetch_related takes a different approach: it runs a second query for all the related objects, then stitches them together in Python.

authors = Author.objects.prefetch_related('books')
for author in authors:
    for book in author.books.all():   # no extra query per author
        print(book.title)

That's 2 queries total (one for authors, one for all their books) instead of one-per-author. Use it for ManyToMany fields and for reverse ForeignKey access (the "many" side).

The rule

This is the whole thing to remember:

select_related   -> single-valued (ForeignKey, OneToOne)   -> SQL JOIN, 1 query
prefetch_related -> multi-valued  (ManyToMany, reverse FK) -> separate query, joined in Python

Put another way: if you'd follow the relationship to one object (book.author), use select_related. If you'd follow it to a set of objects (author.books.all()), use prefetch_related.

Combining them

Real queries often need both, and they chain cleanly:

# each book's author (FK) AND each book's tags (M2M), minimal queries
books = Book.objects.select_related('author').prefetch_related('tags')

You can also span relationships with __ — select_related('author__publisher') joins two levels of ForeignKey in one query, and prefetch_related('author__books') prefetches across them.

Common gotchas

Wrong tool, no error: using prefetch_related on a ForeignKey works but runs an extra query you didn't need — select_related is strictly better there. Using select_related on a ManyToMany raises an error, because you can't JOIN a multi-valued relation into one row.
Filtering after prefetch re-queries: calling .filter() on a prefetched set hits the DB again. To filter the prefetched data, use a Prefetch object with a queryset instead.
Only prefetch what you use: prefetching a relation you never touch just wastes a query and memory.

The N+1 problem and these two methods are a staple of Django interviews — see the full Django interview questions and the SQL questions on joins and query performance.

Prepping for a Django interview? Peakblick runs mock interviews on a timer and scores every answer 1–10 with feedback — so you find the weak spots before the real thing. Free to try, no card.

Nested Loops in a Python List Comprehension

Peakblick — Mon, 12 Oct 2026 20:40:49 +0000

You can put more than one for in a list comprehension to get the effect of nested loops — but the order of those for clauses trips almost everyone up the first time. Here's how it actually works, with the one rule that makes it click.

The basic idea: same order as nested loops

A comprehension with two for clauses behaves exactly like two nested for loops, and — this is the whole trick — the clauses read left to right in the same order you'd write the loops: outer loop first, inner loop second.

pairs = [(x, y) for x in range(3) for y in range(3)]
# [(0,0), (0,1), (0,2), (1,0), (1,1), (1,2), (2,0), (2,1), (2,2)]

That single line is identical to:

pairs = []
for x in range(3):        # outer  -> first for-clause
    for y in range(3):    # inner  -> second for-clause
        pairs.append((x, y))

So the mental model is simple: copy the loops top to bottom, then the expression ((x, y)) goes at the front. The inner loop runs fully for each step of the outer one, just like real nested loops.

The one mistake everyone makes: the order

The instinct is to write the clauses "inside out," but Python reads them outside in. Each clause can only use variables defined by a clause to its left. So this fails:

# WRONG — 'row' is used before it's defined
flat = [n for n in row for row in matrix]
# NameError: name 'row' is not defined

The fix is to put the clauses in loop order — outer (row) first, then inner (n):

# RIGHT
flat = [n for row in matrix for n in row]

If you ever get a NameError in a comprehension, it's almost always this: a later variable used in an earlier clause. Reorder them the way you'd nest the loops.

Flattening a list of lists

That last example is the most common real use of nested loops in a comprehension — turning a list of lists into one flat list:

matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
flat = [n for row in matrix for n in row]
# [1, 2, 3, 4, 5, 6, 7, 8, 9]

Read it as "for each row in the matrix, for each n in that row, take n." Outer first, inner second — same rule.

Nested comprehensions (a list of lists)

This is a different thing, and it's worth not confusing the two. Nested for clauses flatten; a comprehension inside another comprehension builds structure — a list of lists.

# build a 2x3 grid
grid = [[col for col in range(3)] for row in range(2)]
# [[0, 1, 2], [0, 1, 2]]

Here the inner [col for col in range(3)] produces one row, and the outer comprehension repeats it. A classic use is transposing a matrix (swapping rows and columns):

matrix = [[1, 2, 3], [4, 5, 6]]
transposed = [[row[i] for row in matrix] for i in range(len(matrix[0]))]
# [[1, 4], [2, 5], [3, 6]]

Rule of thumb: multiple for clauses in one comprehension → a flat list; a comprehension nested in brackets → a list of lists.

Adding a condition

You can filter with if after the for clauses, and the condition can use any variable defined to its left:

# all pairs where the two numbers differ
pairs = [(x, y) for x in range(3) for y in range(3) if x != y]
# [(0,1), (0,2), (1,0), (1,2), (2,0), (2,1)]

Multiple conditions just chain: ... if x != y if x + y > 1 keeps only pairs that pass both.

When to stop and just write the loop

Comprehensions are great until they aren't readable. One or two for clauses to flatten or pair up values is clean Python. Three clauses, or a nested comprehension with conditions inside conditions, is usually the moment to write the plain nested loops instead — they're easier to read, debug, and change. The goal is clarity, not fitting everything on one line.

Quick reference:

[expr for a in outer for b in inner]        # nested loops, flat result
[expr for a in outer for b in inner if c]   # with a filter
[[expr for b in inner] for a in outer]      # nested comprehension -> list of lists

Nested comprehensions and the for-clause order come up constantly in Python interviews — see the Python interview questions for the data-model ideas behind them.

Prepping for a Python interview? Peakblick runs mock interviews on a timer and scores every answer 1–10 with feedback — so you find the weak spots before the real thing. Free to try, no card.

Python Interview Questions (With Model Answers)

Peakblick — Sat, 10 Oct 2026 09:53:32 +0000

These are the core-language Python questions that actually come up — grouped by topic, each with a short model answer and a note on what the interviewer is really checking. Python questions reward understanding the data model: most "gotchas" are the same few ideas (mutability, references, evaluation time) wearing different hats.

The tell on Python questions is whether you can explain why, not just what. "A tuple is immutable" is recall; "a tuple is immutable, which is why it can be a dict key and a list can't" is understanding. For each answer below, notice the pattern: name the mechanism, give the one consequence that matters, then stop.

The data model

What's the difference between mutable and immutable types?

A mutable object can be changed in place after creation; an immutable one can't. Lists, dicts and sets are mutable; ints, floats, strings, tuples and frozensets are immutable. It matters for three everyday reasons: only immutable objects can be dictionary keys or set members (they need a stable hash), immutable objects are safe to share without worrying someone mutates them under you, and "modifying" a string actually creates a new one. Most Python surprises trace back to this one distinction.

What they're testing: that you connect mutability to hashing, sharing, and the gotchas below.

List vs tuple — when would you use each?

A list is a mutable, ordered collection you grow and change; a tuple is an immutable, ordered collection you fix once. Use a list for a homogeneous sequence you'll modify (a queue of tasks); use a tuple for a fixed record whose shape has meaning (a coordinate (x, y), a row returned from a query). The practical payoffs of the tuple: it can be a dict key, it signals "this won't change," and it's slightly lighter.

What they're testing: that you pick by mutability and intent, not just "tuple is a faster list."

`is` vs `==` — what's the difference?

== checks equality (do these have the same value?); is checks identity (are these the exact same object in memory?). You almost always want ==. The one firm rule: compare to None with is (if x is None), because None is a singleton. A classic trap: small integers and short strings are cached, so is sometimes looks like it works for values — relying on that is a bug waiting to happen.

What they're testing: that you know identity vs equality, and the is None convention.

Shallow copy vs deep copy?

A shallow copy duplicates the outer object but shares the nested objects inside it; a deep copy recursively duplicates everything. So if you shallow-copy a list of lists and mutate an inner list, the change shows up in both copies — because they point at the same inner list. Use copy.deepcopy() when you need true independence, and know it's slower. This is just the mutability rule again: copying the container doesn't copy what it references.

What they're testing: that you understand references, and when a shallow copy quietly bites you.

Functions

What do `*args` and `**kwargs` do?

*args collects extra positional arguments into a tuple; **kwargs collects extra keyword arguments into a dict. They let a function accept any number of arguments, and — used at the call site — unpack a sequence or dict back into arguments (f(*my_list), f(**my_dict)). The everyday use is writing wrappers and decorators that pass arguments through without knowing them: def wrapper(*args, **kwargs): return func(*args, **kwargs).

What they're testing: that you can write flexible, pass-through function signatures.

What is a decorator?

A decorator is a function that takes another function and returns a new one that wraps it — a clean way to add behaviour (logging, timing, caching, access checks) around a function without touching its body. @decorator above a definition is just sugar for func = decorator(func). The reason they feel magical and then obvious: functions in Python are ordinary objects you can pass around and return, so wrapping one is nothing special.

What they're testing: that you grasp functions-as-objects, which is the whole idea behind decorators.

Why is a mutable default argument a bug?

Because default arguments are evaluated once, when the function is defined — not on each call. So def add(x, items=[]) shares one list across every call that uses the default, and it accumulates between calls, which is almost never what you want. The fix is the standard idiom: default to None and create the list inside — def add(x, items=None): items = items or []. It's the single most common Python gotcha in interviews.

What they're testing: that you know default arguments are evaluated at definition time, not call time.

Iterators & generators

What is a generator, and why use one?

A generator is a function that uses yield to produce values lazily, one at a time, instead of building and returning a whole list. Each yield hands back a value and pauses, resuming where it left off on the next request. The win is memory: you can iterate over a billion-line file or an infinite sequence without ever holding it all in RAM. Reach for one whenever you're processing a large or streaming sequence and don't need every item at once.

What they're testing: that you see generators as a memory optimisation for sequences, not just "fancy loops."

What's the difference between an iterable and an iterator?

An iterable is anything you can loop over — it can produce an iterator (a list, a string, a dict). An iterator is the object that actually does the walking: it remembers its position and hands you the next item via next(), raising StopIteration when it's done. A for loop quietly calls iter() on the iterable to get an iterator, then next() until it's exhausted. A list is iterable but not its own iterator; a generator is both.

What they're testing: that you know the protocol a for loop actually runs under the hood.

List comprehension vs generator expression?

Same syntax, different brackets, different behaviour. [x*2 for x in data] builds the whole list in memory immediately. (x*2 for x in data) creates a generator that produces values lazily, one at a time. Use the list comprehension when you need the full list (you'll index it, reuse it, or it's small); use the generator expression when you're just going to iterate once over something large — it keeps memory flat.

What they're testing: that you choose eager vs lazy evaluation on purpose, by size and reuse.

Concurrency & resources

What is the GIL, and what does it mean for threads?

The Global Interpreter Lock is a mutex in CPython that lets only one thread execute Python bytecode at a time. The consequence: threads don't give you true parallelism for CPU-bound work — two threads crunching numbers run effectively one at a time. But threads still help for I/O-bound work (network, disk), because the GIL is released while waiting. So the rule is: threads for I/O-bound, multiprocessing (separate processes, separate GILs) or native extensions for CPU-bound.

What they're testing: that you know the GIL's real-world rule — threads for I/O, processes for CPU.

What is a context manager, and when would you write one?

A context manager is the object behind the with statement: it runs setup on entry and — crucially — guaranteed cleanup on exit, even if an exception is raised. with open(f) as file: closes the file no matter what. You write your own (with __enter__/__exit__, or the @contextmanager decorator) whenever you have a resource that must be released — a lock, a database connection, a temporary change to state — and you don't want to rely on remembering to clean it up.

What they're testing: that you reach for with for guaranteed cleanup, not manual try/finally everywhere.

How does Python manage memory?

Primarily with reference counting: every object tracks how many references point to it, and it's freed the instant that count hits zero. On top of that, a cyclic garbage collector handles the case reference counting can't — objects that reference each other in a cycle, which would otherwise never reach zero. You rarely manage memory by hand; the thing worth knowing is that holding a reference (in a long-lived list, a cache, a closure) is what keeps an object alive.

What they're testing: that you understand reference counting and what actually causes a "leak" in Python.

How to actually answer these

Almost every Python question above reduces to one of a few core ideas — mutability, references, when code is evaluated. The strongest candidates don't memorise each gotcha; they explain it from the principle: "default arguments evaluate once at definition, so a mutable default is shared — that's the same reason this bug and that one happen." Showing the underlying model beats reciting a list of tricks.

Two habits that quietly raise your score: give the consequence, not just the definition (a tuple is immutable → so it can be a dict key), and mention the standard idiom where there is one (is None, items=None defaults, with for cleanup) — it signals you've written real Python. Prepping the whole stack? Pair this with the Python backend, SQL, and system design questions.

Rehearse these out loud, scored. Peakblick asks you Python questions like these on a timer and scores every answer 1–10 with feedback — so you find the weak spots before the real interview. Free to try, no card.

REST API Interview Questions (With Model Answers)

Peakblick — Thu, 08 Oct 2026 14:21:18 +0000

These are the REST API questions that actually come up in backend and full-stack interviews — grouped by topic, each with a short model answer and a note on what the interviewer is really checking. API questions reward clarity: they tell an interviewer whether you've designed one or just consumed one.

The giveaway on API questions is whether you reach for the HTTP mechanism or hand-wave. "You'd use a POST" is weaker than "POST, because creating a resource isn't idempotent and shouldn't be cached." For each answer below, notice the pattern: name the mechanism, give the one rule that matters, then stop.

HTTP methods & status codes

What's the difference between GET, POST, PUT, PATCH and DELETE?

They map to intent. GET reads (and must have no side effects). POST creates a new resource or triggers an action. PUT replaces a resource entirely. PATCH updates part of one. DELETE removes it. The property that matters is idempotency: GET, PUT and DELETE are idempotent (calling them twice leaves the same state), POST is not (two POSTs create two resources). That's why a retried POST can double-create and a retried PUT can't.

What they're testing: that you pick a verb by its semantics and idempotency, not habit.

Which status codes do you use, and when?

The families first: 2xx success, 4xx the client's fault, 5xx the server's fault. The ones you should name without thinking: 200 OK, 201 Created (with the new resource), 204 No Content (a successful DELETE), 400 Bad Request (malformed), 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not allowed), 404 Not Found, 409 Conflict, 422 Unprocessable (validation failed), 429 Too Many Requests, and 500 for an unhandled server error. The classic mistake is returning 200 with an error in the body — the status code is the result.

What they're testing: that you use the status line to carry meaning, especially the 401-vs-403 distinction.

REST design

What actually makes an API "RESTful"?

REST is a set of constraints, and the ones interviewers care about are: resources identified by URLs, standard HTTP verbs for actions on them, and — the big one — statelessness: every request carries everything the server needs, so the server keeps no per-client session between calls. Statelessness is what lets you put any server behind a load balancer and scale horizontally. A representation (usually JSON) is what you actually send over the wire.

What they're testing: that you tie "RESTful" to statelessness and scaling, not just "it returns JSON."

How do you design resource URLs?

Nouns, not verbs, and plural collections: /users, /users/42, /users/42/orders. The HTTP method is the verb, so GET /users/42 — never GET /getUser?id=42. Nest to show a relationship (/users/42/orders) but don't nest more than a level or two, or URLs get unwieldy. Use query parameters for filtering, sorting and pagination (/orders?status=open&sort=-created), not for identity.

What they're testing: that the URL names the resource and the method names the action — the core REST idea.

PUT vs PATCH — what's the difference?

PUT replaces the whole resource — you send the complete representation, and anything you leave out is cleared. PATCH applies a partial update — you send only the fields that change. Practically, PATCH is what you usually want for an "edit"; PUT is for a full overwrite. The subtlety interviewers like: PUT is idempotent (sending the same full body twice is fine), while a carelessly-designed PATCH (say, "increment by 1") may not be.

What they're testing: that you know partial vs full update, and the idempotency corner.

Versioning, pagination & errors

How do you version an API?

You version so you can change the contract without breaking existing clients. The common approaches: a URL prefix (/v1/users) — simplest and most visible; a header or media type (Accept: application/vnd.api+json;version=1) — cleaner URLs but less obvious. URL versioning wins most interviews for being explicit. The real point is that any breaking change — removing a field, renaming one, changing a type — needs a new version; additive changes don't.

What they're testing: that you protect existing clients and know what counts as a breaking change.

How do you paginate a large collection?

Two options. Offset pagination (?limit=20&offset=40) is simple but gets slow on deep pages and can skip or repeat rows if the data changes between requests. Cursor (keyset) pagination (?limit=20&after=<id>) passes a pointer to the last item you saw and queries "the next 20 after this" — it stays fast at any depth and is stable under inserts. Use offset for small admin tables, cursor for large or live feeds.

What they're testing: that you know offset breaks down at scale and cursor is the fix.

How should an API return errors?

With the right status code and a consistent, machine-readable body — a stable error code, a human-readable message, and ideally which field failed: { "error": "validation_failed", "message": "...", "field": "email" }. Consistency is the whole point: a client should be able to handle every error the same way. Don't leak internals (stack traces, SQL) in the message, and don't return 200 for a failure.

What they're testing: that your errors are predictable and safe for a client to program against.

Auth, caching & reliability

How do you authenticate a REST API?

Pick by use case. API keys for server-to-server — simple, long-lived, carried in a header. JWT (bearer tokens) for user sessions in a stateless API — the token is signed and self-contained, so the server verifies it without a lookup, which fits REST's statelessness. OAuth 2.0 when a third party acts on a user's behalf ("sign in with Google," granting another app access). Whatever you choose, it's HTTPS-only and the credential goes in the Authorization header, never the URL.

What they're testing: that you match the auth method to the scenario and never put secrets in a URL.

REST vs GraphQL — when would you use each?

REST exposes resources at fixed endpoints; GraphQL exposes one endpoint and lets the client ask for exactly the fields it wants. GraphQL shines when clients need very different shapes of data and you want to avoid over-fetching or many round-trips — typically rich frontends. REST wins on simplicity, caching (HTTP caching is built in), and tooling, and is usually the right default for a straightforward resource API. The honest answer: REST unless you have the specific over-fetching / many-clients problem GraphQL solves.

What they're testing: that you don't pick GraphQL for hype — you justify it with a concrete fetching problem.

What is idempotency, and how do you make an unsafe endpoint safe to retry?

An operation is idempotent if doing it twice has the same effect as once. It matters because clients retry on timeouts, and a timeout doesn't tell you whether the first call succeeded — so a non-idempotent "create order" or "charge card" can run twice. The fix is an idempotency key: the client sends a unique ID in a header, the server records it, and a repeat with the same key returns the original result instead of acting again. Any state-changing POST that can be retried needs this.

What they're testing: that you design for retries and at-least-once delivery, not a perfect network.

How does HTTP caching work for an API?

Two mechanisms. Cache-Control headers tell clients and proxies how long a response may be reused (max-age), which is great for data that rarely changes. ETag plus If-None-Match does conditional requests: the server sends a version tag, the client sends it back, and the server replies 304 Not Modified with no body if nothing changed — saving bandwidth. Caching is one of REST's real advantages over RPC-style APIs, and it only works cleanly because GET is safe and idempotent.

What they're testing: that you can cut load with HTTP's own caching, and know it depends on safe methods.

How to actually answer these

The strongest API answers are short and mechanical: name the verb or status code, give the one rule (idempotency, statelessness, the breaking-change line), and stop. Resist listing every status code you know — the interviewer is checking judgement, not recall. If you're unsure of an exact code, reason from the family: "it's a client error, so 4xx, and since it's a validation failure specifically, 422."

Two habits that quietly raise your score: tie every choice to a property (why POST and not PUT? because create isn't idempotent), and mention statelessness unprompted when scaling comes up — it signals you've actually run an API in production. Prepping the whole backend stack? Pair this with the SQL, Python backend, and system design questions.

Rehearse these out loud, scored. Peakblick asks you REST API questions like these on a timer and scores every answer 1–10 with feedback — so you find the weak spots before the real interview. Free to try, no card.

System Design Interview Questions (With Model Answers)

Peakblick — Tue, 06 Oct 2026 18:34:08 +0000

These are the system design questions that actually come up — grouped by topic, each with a short model answer and a note on what the interviewer is really checking. System design rewards judgement over facts: there's rarely one right answer, only trade-offs you can name and defend.

The trap in a system design round is treating it like trivia. The interviewer isn't checking whether you've memorised what a load balancer is — they're checking whether you can reason about scale, spot the bottleneck, and make a call while naming what it costs. For each answer below, notice the pattern: name the mechanism, give the one trade-off that matters, then say when you'd actually reach for it.

Scaling fundamentals

What's the difference between vertical and horizontal scaling?

Vertical scaling (scaling up) means a bigger machine — more CPU, RAM, disk. It's simple and needs no code changes, but it has a hard ceiling and a single point of failure. Horizontal scaling (scaling out) means more machines behind a load balancer. It scales much further and adds redundancy, but it forces you to deal with distributed-system problems: shared state, consistency, and coordination. Short version: scale up until it's too expensive or too risky, then scale out.

What they're testing: that you know scaling out buys you headroom at the cost of complexity, not for free.

Latency vs throughput — what's the difference?

Latency is how long one request takes; throughput is how many requests you handle per second. They're related but not the same — you can raise throughput by adding workers while a single request stays just as slow, and you can cut latency without touching throughput. Know which one the problem is about: a slow page is a latency problem, a system falling over under load is a throughput problem.

What they're testing: that you reach for the right lever instead of "make it faster" in general.

A service is getting too much traffic. How do you think about handling it?

Measure first — find the actual bottleneck instead of guessing. Then work the usual order: cache what's read often and changes rarely; scale the stateless parts horizontally behind a load balancer; move slow or spiky work off the request path into a queue; and only then scale the database, which is usually the hardest piece to scale. The instinct interviewers want is "find the bottleneck, then apply the cheapest fix that moves it," not "add servers everywhere."

What they're testing: a systematic approach, and knowing the database is usually the real constraint.

Caching & data

What is caching, and where would you add it?

A cache stores the result of expensive work close to where it's needed, so you skip the work next time. You add it wherever reads dominate and the data tolerates being slightly stale — a database query layer, rendered pages, a CDN for static assets, or in-memory (Redis/Memcached) for hot keys. The win is latency and load; the cost is a second copy of the truth that can drift.

What they're testing: that you see caching as a read optimisation with a staleness price, not a free speed-up.

Why is cache invalidation hard?

Because a cache is a copy, and the moment the source changes, the copy is wrong — you have to decide when to throw it away without knowing in advance when the data will change. The common strategies are TTL (expire after N seconds — simple, but serves stale data in that window) and explicit invalidation on write (fresh, but easy to miss a path and leak stale data forever). There's no clean answer, which is why it's the classic "two hard things in computer science" joke.

What they're testing: that you understand the real cost of a cache is correctness, not just the extra moving part.

SQL vs NoSQL — when would you choose each?

Reach for SQL (a relational database) by default: you get strong consistency, transactions, flexible queries and joins, and decades of tooling — ideal when your data is related and correctness matters, like anything with money or accounts. Reach for NoSQL when you have a specific scale or shape problem SQL handles badly: massive write throughput, a flexible/changing schema, or simple key-value access patterns at scale. The honest answer in most interviews is "SQL unless I can name the specific reason it won't work."

What they're testing: that you don't pick NoSQL for hype — you justify it with a concrete constraint.

What is sharding, and what's the hard part?

Sharding splits one dataset across multiple databases by some key (user ID, region) so no single machine holds — or serves — all of it. That's how you scale writes past one box. The hard part is choosing the shard key: a bad one creates hot shards (one machine does most of the work) and makes cross-shard queries and joins painful or impossible. Resharding later is a major operation, so the key is a decision you want to get right early.

What they're testing: that you know sharding scales writes but the shard key is where it lives or dies.

What does replication give you, and what's the trade-off?

Replication keeps copies of your data on multiple machines. It buys you two things: read scaling (spread reads across replicas) and availability (if one node dies, another has the data). The trade-off is consistency: with asynchronous replication, a replica can lag behind the primary, so a read right after a write might return stale data. You're trading "always perfectly up to date" for "more reads and survives failures."

What they're testing: that you connect replication to the consistency lag it introduces, not just "backups."

What does the CAP theorem actually force you to choose?

CAP says that when a network partition happens — some nodes can't talk to others — a distributed system has to pick: stay consistent (reject or block requests it can't confirm, so no one sees wrong data) or stay available (keep answering, accepting that different nodes might briefly disagree). You don't get both during a partition. The useful framing isn't "CA vs CP vs AP" trivia — it's "when the network splits, would I rather return an error or risk a stale answer?", and that depends on whether you're moving money or showing a feed.

What they're testing: that you can turn CAP into a real product decision, not recite three letters.

Communication & scale

What does a load balancer do?

It sits in front of a pool of identical servers and spreads incoming requests across them, so no single server is overwhelmed and the pool can grow or shrink freely. It also does health checks — stop sending traffic to a server that's down — which is half the reason it exists. For it to work, your servers generally need to be stateless (any server can handle any request), which is why "where does the session live?" is the follow-up question.

What they're testing: that you connect load balancing to statelessness, not just "it shares the load."

When would you use a message queue?

When work doesn't need to happen inside the request. A queue lets you accept a request, drop a job on the queue, respond immediately, and process it later with separate workers — think sending email, generating a report, processing an upload. It buys you three things: a faster response, resilience to spikes (the queue absorbs the burst), and decoupling (the producer doesn't care who consumes). The cost is that the work is now asynchronous, so you design for "eventually done" and for retries.

What they're testing: that you move slow or spiky work off the request path on purpose, and handle the async consequences.

How would you rate-limit an API?

Track requests per client (by API key or IP) over a time window and reject once they exceed the limit, usually with a 429 Too Many Requests. The common algorithm is a token bucket — each client has a bucket that refills at a steady rate and each request spends a token — which allows short bursts while capping the sustained rate. In a multi-server setup the counter has to live somewhere shared, like Redis, so the limit holds across the whole fleet rather than per server.

What they're testing: that you remember the limit has to be enforced globally, not per instance.

What's a CDN for?

A CDN caches your static content — images, CSS, JS, video — on servers spread around the world, so a user in Tokyo is served from a nearby edge instead of your origin in Virginia. That cuts latency dramatically and takes load off your servers. The trade-off is the usual cache one: you have to handle invalidation (cache-busting filenames or purges) when the content changes.

What they're testing: that you push static, geographically-shared content to the edge and know how you'd update it.

Reliability & approach

What is idempotency, and why does it matter in a distributed system?

An operation is idempotent if doing it twice has the same effect as doing it once. It matters because in a distributed system, requests get retried — a network timeout doesn't tell you whether the first attempt succeeded. If "charge this card" isn't idempotent, a retry double-charges. The fix is an idempotency key: the client sends a unique ID with the request, and the server records it so a repeat with the same key is recognised and ignored. Any operation that changes state and can be retried needs this.

What they're testing: that you design for retries and at-least-once delivery, not a perfect network.

How do you approach an open-ended "design X" question?

Don't start drawing boxes. Start by scoping: ask about the requirements and scale — how many users, read-heavy or write-heavy, what has to be consistent, what can be eventual. Sketch the core data model and the main API, then the high-level components (clients, load balancer, services, database, cache, queue). Then find the bottleneck for the given scale and go deep on one or two pieces — how you'd cache, shard, or queue — naming the trade-off at each step. The interviewer is grading the conversation, not a finished diagram.

What they're testing: that you drive the problem — scope, structure, then depth — instead of memorising one architecture.

How to actually answer these

System design is the round where candidates most often sink themselves by saying too much. The strong move is the opposite: scope before you build, name the trade-off instead of claiming a choice is just "better," and admit what you don't know rather than bluff — "I'd need to check the real numbers, but my instinct is to shard by user ID because our access pattern is per-user" reads far better than a confident wrong architecture.

Three habits that quietly raise your score: always ask about scale first (the right design for 1,000 users is wrong for 100 million); say the trade-off out loud for every choice; and drive the conversation — a good system design answer is a discussion you lead, not a monologue. Prepping the backend stack too? Pair this with the SQL, Python backend, and Django questions.

Rehearse these out loud, scored. Peakblick asks you system design questions like these on a timer and scores every answer 1–10 with feedback — so you find the weak spots before the real interview. Free to try, no card.

How We Built Our Own AI Interview Grader (No GPT)

Peakblick — Mon, 05 Oct 2026 18:48:43 +0000

Most "AI interview" tools are a thin wrapper around GPT. We did the opposite — we trained our own generative model, from scratch, to run the whole interview: ask the questions, grade your answers, and explain them. Here's how it works, what went wrong on the way, and why the harder road was worth it.

When you finish an answer in Peakblick, something has to decide: did that actually cover what the question was testing, or did it just sound confident? Doing that well — on a timer, for every answer, consistently — is the whole product. Everything else is a frontend. So we spent our time on the thing that's actually hard: the model that runs the conversation and judges what you say.

Why not just call GPT?

It's the obvious shortcut, and plenty of "AI interview" products take it: forward your answer to a big API, ask it to score, print the result. We didn't, for three reasons.

Consistency. A grader built on someone else's API quietly changes every time that model is updated. The same answer can score a 6 one week and an 8 the next, and you have no way to know why. For a tool whose entire job is to give you a trustworthy read on where you stand, that drift is disqualifying.

Cost. Grading every answer of every mock interview through a frontier API doesn't scale to something people use daily without the price landing back on the user. We wanted practice to be cheap enough to do constantly.

Independence. We wanted a system we own, can measure end to end, and can improve on our own schedule — not rent from a provider who can change the terms, the price, or the behaviour overnight. A side effect we like: your answers are handled entirely by our own model and never shipped off to a third party.

So we trained one ourselves — a compact, from-scratch generative model, with no distillation from GPT or any other external model. Every improvement is ours, and so was every problem. That constraint made what came next much harder, and much more interesting.

One generative model, the whole interview

Peakblick runs on a single model we built and trained. It is fully generative — the same model that generates the questions also generates a model answer and writes your feedback. There's no external API anywhere in the loop, and nothing hard-coded from a question bank: it produces the interview the way a good interviewer improvises one, shaped by the role, seniority and topics you picked.

That matters because a real interview isn't a quiz with fixed answers. A strong senior backend question looks nothing like a junior one on the same topic, and a good interviewer reads your answer and decides what's worth probing next. We wanted a model that behaves like that — not one that reads lines off a card.

Generating the questions

The first job is asking well. Given a role and level, the model plans the ground to cover and then generates each question fresh — phrased naturally, pitched at the right difficulty, and varied so you're not drilling the same three prompts every session. Generating questions is the part a generative model is genuinely great at, and it's where the "no fixed bank" promise pays off: the space of questions is effectively unlimited, so practice stays useful past the first few runs.

The hard part: judging without hallucinating

Asking is the easy half. The hard half is judgement — and it's where most of our work went.

A compact model asked to grade cold can do exactly what a nervous candidate does: sound fluent and confident while being wrong. Early versions of our grader had a specific, dangerous failure mode — faced with an answer that was actually incorrect, the model would sometimes write a confident, well-structured explanation of why it was right. It talked itself into approving bad answers. And that's the one failure a grader can't have: tell someone a wrong answer was good, and you've done worse than not grading at all. You've taught them the wrong thing right before the real interview.

Getting that reliable — not just good on average, but trustworthy on the answers that matter — was the real engineering problem behind Peakblick.

Our approach: let the model answer first

The fix that made judgement reliable is simple, and it plays directly to what a generative model is best at. Before it ever looks at your answer, the model writes its own ideal answer to that exact question — what a strong response should actually cover, generated fresh for this question rather than pulled from a list.

Only then does it read your answer, and measure it against that reference: point by point, what you covered, what you touched lightly, what you missed, and where you said something that contradicts a key idea. Grounding the grade in the model's own generated answer — instead of asking it to pass judgement out of thin air — is what turned a shaky grader into one we trust. The model is doing what it's good at (writing a strong answer, then comparing) instead of conjuring a verdict from nothing. It's the same reason a human grader with the model solution in front of them is fairer than one marking from memory.

A score you can read, not a mystery number

Because the grade is built up point by point, the final 1–10 isn't a vibe — it's the sum of concrete judgements you can see. A 6 means something specific: these points landed, this one was thin, that one was missing. That's what lets the feedback be useful instead of generic. "Good effort, keep practising" helps no one; "you explained the mechanism but missed the one trade-off the interviewer was really after" is something you can actually fix before Monday.

Feedback that's specific, not generic

Feedback is only worth anything if it names the real gap. Ours is grounded — tied to what the question was actually testing and to the model answer it laid out — so it tells you exactly where you fell short and why it mattered, instead of hand-waving. It never pads with invented criticism or "good effort, keep practising" filler.

Every line points at something concrete you can fix: the trade-off you skipped, the edge case you didn't mention, the term you reached for that wasn't quite right. That specificity is the whole difference between feedback you nod along to and feedback you actually act on — and acting on it, before the real interview, is the entire point.

Teaching it the whole stack

A grader is only as good as what it knows. A model can't fairly judge an answer about database indexes, or Git internals, or how a framework handles requests, if it doesn't deeply understand those things itself. So a large and ongoing part of the work isn't the model's wiring at all — it's its education.

We train it on a broad, carefully-sourced body of real technical material across the stack: multiple languages, the frameworks people actually ship with, databases and SQL, system design, version control, and the fundamentals underneath all of it. As we widen that knowledge, the grading gets fairer and holds up across more of the topics a real interview might wander into. The architecture stays the same; the knowledge keeps growing — and that's a dial we can keep turning for as long as the product lives.

What this means — and what's next

The headline isn't "we use AI." Everyone does. It's that the thing running your interview is a generative model we built, own, measure, and keep improving — not a wrapper whose behaviour we can't see or steer. That ownership is why we can promise consistency, keep practice cheap, and keep raising the ceiling instead of waiting for someone else's roadmap.

Next, we're broadening both ends: more topics and seniorities on the question side, and deeper knowledge on the grading side — including interviews that dig into real code. The goal is simple and a little ambitious: an interviewer in your pocket that's good enough to make the real one feel easy.

Try it on your own answers. Peakblick asks you real interview questions on a timer and scores every answer 1–10 with specific feedback — so you find the weak spots before the real thing. Free to try, no card.

Git Interview Questions (With Model Answers)

Peakblick — Sat, 03 Oct 2026 20:02:15 +0000

Git questions look like trivia, but they're really testing one thing: do you have a mental model of what Git is doing, or do you memorise commands and hope? An interviewer can tell the difference in one sentence. "Rebase rewrites history" is a memorised fact; "rebase replays your commits as new commits with new hashes, which is why you never do it to shared branches" is a model.

Below are the questions that come up in almost every developer interview, grouped by topic. Each has a short model answer, a command example where it helps, and a note on what the interviewer is really checking. Notice the pattern in every answer: name the mechanism, give the one rule or trade-off that matters, then stop.

A quick foundation that makes the rest click: a branch is just a movable pointer to a commit, a commit is a snapshot plus a parent link, and HEAD points to "where you are now". Almost every answer below is a consequence of those three facts.

Core concepts

What's the difference between `git fetch` and `git pull`?

fetch downloads the latest commits and refs from the remote but doesn't touch your working branch — it updates your remote-tracking refs (origin/main) so you can inspect what changed first. pull is fetch plus an automatic merge (or rebase) of those changes into your current branch.

git fetch origin            # safe: just updates origin/*, nothing merged
git log HEAD..origin/main   # see what you'd be pulling in
git pull                    # fetch + merge (or --rebase) into your branch

So fetch is the look-before-you-leap option; pull is the convenience that can surprise you with an unexpected merge commit. Many teams set git config pull.rebase true to keep history linear.

What they're testing: that you understand local vs. remote state, not just the two commands.

What is the staging area (the index)?

It's an intermediate layer between your working directory and the repository. git add moves changes into staging; git commit records exactly what's staged — not what's in your working directory. That extra step is what lets you craft a commit: stage only some files, or even part of a file with git add -p, instead of committing everything at once.

Git's three "trees" are the working directory, the index (staging), and HEAD (the last commit). Nearly every confusing Git command makes sense once you ask "which of the three trees does this touch?"

What they're testing: the three-tree model — the foundation for reset, diff, and clean commits.

Merge vs. rebase — what's the difference, and the rule?

merge combines two branches with a merge commit, keeping history exactly as it happened (non-linear, but truthful). rebase replays your commits on top of another branch, producing a clean linear history — but it creates new commits with new hashes; the originals are abandoned.

git checkout feature
git rebase main       # replay feature's commits on top of main
# vs
git merge main        # create a merge commit joining the two

The golden rule: rebase your own local, unpushed work to tidy it up; never rebase a branch others have already pulled. Rewriting shared history forces everyone else to reconcile commits that no longer exist in your branch.

What they're testing: whether you understand history rewriting and the one rule that keeps a team sane.

What is `HEAD`, and what's a "detached HEAD"?

HEAD is a pointer to your current location — normally it points at a branch, which points at a commit. A detached HEAD is when HEAD points directly at a commit instead of a branch, which happens when you git checkout <commit-hash> or a tag. You can look around and even commit, but those commits aren't on any branch — if you walk away, they're hard to find again.

git checkout a1b2c3d     # detached: HEAD -> commit, not a branch
git switch -c fix-here   # rescue: make a branch so commits aren't lost

What they're testing: that you really grasp "a branch is a pointer" — detached HEAD is the edge case that proves it.

Branching & merging

What is a fast-forward merge?

When the branch you're merging into hasn't diverged — your target is strictly behind the branch you're merging — Git doesn't need a merge commit; it just moves the branch pointer forward. That's a fast-forward. If the branches have diverged, Git has to create a real merge commit. Use git merge --no-ff when you want a merge commit even on a fast-forward, to keep feature branches visible in history.

What they're testing: the pointer model of branches, again.

How do you resolve a merge conflict?

When two branches change the same lines, Git marks the conflict in the file:

<<<<<<< HEAD
your version
=======
their version
>>>>>>> feature

You open the file, edit it into the result you actually want, delete the markers, then stage and continue:

git add resolved_file.py
git commit                 # or: git rebase --continue

The tooling doesn't decide for you — resolving a conflict is a human judgement about what the code should be. git merge --abort backs out entirely if you want to start over.

What they're testing: that you've actually done this, not just read about it.

What does `git cherry-pick` do, and when would you use it?

It applies the changes from a specific commit onto your current branch, as a new commit. Useful for pulling one bug-fix commit from another branch without merging the whole thing — a hotfix that needs to go to both main and a release branch.

git cherry-pick a1b2c3d

The trade-off: it duplicates the change as a new commit, so overusing it creates divergent copies that are annoying to reconcile later.

What they're testing: that you can move a single change around deliberately, not just merge whole branches.

Undoing things

`git revert` vs. `git reset` — when do you use each?

revert creates a new commit that undoes a previous one, leaving history intact — safe for anything already pushed. reset moves the branch pointer backwards, rewriting history — for local, unpushed work only.

git revert a1b2c3d       # public, safe: adds an "undo" commit
git reset --hard HEAD~1  # private: discards the last commit entirely

The rule mirrors rebase: revert what's public, reset what's private. Using reset on a pushed branch and force-pushing is how you ruin a teammate's afternoon.

What they're testing: the difference between a safe undo and a destructive one.

What do `--soft`, `--mixed` and `--hard` do on `git reset`?

All three move HEAD to the commit you name; they differ in how much they touch afterwards — which maps straight onto the three trees:

Flag	Moves HEAD	Index (staging)	Working dir
`--soft`	✅	kept (staged)	kept
`--mixed` (default)	✅	reset (unstaged)	kept
`--hard`	✅	reset	discarded

So --soft is for re-committing (e.g. squashing the last few commits into one), --mixed un-stages, and --hard is the one that loses work — reach for it deliberately.

What they're testing: precision, and awareness that --hard is destructive.

What does `git stash` do?

It shelves your uncommitted changes and reverts your working directory to a clean state, so you can switch context — jump to a branch for an urgent fix — without committing half-done work.

git stash            # shelve changes, clean working dir
git switch main      # do the urgent thing
git switch -         # back to your branch
git stash pop        # reapply your shelved changes

It's a workflow convenience, not part of history.

What they're testing: everyday fluency, not theory.

You ran `git reset --hard` and lost commits. Can you get them back?

Usually yes — with git reflog. The reflog records every move HEAD makes, even ones that aren't reachable from any branch anymore. Find the commit you were on and reset back to it.

git reflog                 # find the lost commit's hash
git reset --hard a1b2c3d   # or: git branch rescue a1b2c3d

This is a great answer to give unprompted — it shows you know Git rarely really deletes anything until garbage collection runs.

What they're testing: depth — most people don't know the reflog exists, and it's the safety net for every "destructive" command above.

Real-world workflow

How do you find which commit introduced a bug?

git bisect. You mark a known-good commit and a known-bad one; Git checks out the midpoint, you test it and mark it, and it binary-searches to the first bad commit in log-n steps instead of checking every commit.

git bisect start
git bisect bad                 # current commit is broken
git bisect good v1.2.0         # this old tag worked
# test each checkout, mark good/bad... or automate:
git bisect run pytest tests/test_thing.py
git bisect reset

What they're testing: knowing the right tool exists — and that it's a binary search, not a linear hunt.

How do you change the most recent commit?

git commit --amend — to fix the message or add a file you forgot. But amending rewrites that commit's hash, so only amend commits you haven't pushed. Amending a pushed commit forces everyone to reconcile a rewritten history — the same shared-history trap as rebase and reset.

git add forgotten_file.py
git commit --amend --no-edit   # fold it into the last commit, keep the message

What they're testing: that you know "change the last commit" means rewriting it, with all that implies.

You committed a file that shouldn't be tracked (say, `.env`). What now?

Add it to .gitignore and stop tracking it — note that .gitignore alone won't untrack a file that's already committed:

echo ".env" >> .gitignore
git rm --cached .env
git commit -m "Stop tracking .env"

And if it was a secret and it's already been pushed, it's now in the history forever: rotate the secret. Removing it from the current tree doesn't remove it from past commits — you'd need a history rewrite with git filter-repo or BFG, and even then anyone who already pulled still has it. The honest answer in an interview is "rotate first, clean history second".

What they're testing: security awareness, and the gotcha that .gitignore doesn't untrack.

How to actually answer these

The difference between a pass and a fail on Git questions is showing a model, not reciting flags. Say what the command does to the repo — pointers, history, the three trees — name the one rule that matters (rebase/reset only what's private), and stop.

Three things that quietly raise your score:

Reach for the mechanism, not the memorised command. "I'd move the branch pointer back and keep the changes staged" beats blanking on whether that's --soft or --mixed.
Volunteer the safety net. Mentioning the reflog, or "I'd rotate the secret first", signals real experience.
If you forget an exact flag, describe the effect and say you'd check the docs. That reads far better than a confident wrong flag.

Rehearse these out loud, scored. Peakblick asks you Git questions like these on a timer and scores every answer 1–10 with feedback — so you find the weak spots before the real interview. Free to try, no card.

Django Interview Questions (With Model Answers)

Peakblick — Sun, 27 Sep 2026 21:55:58 +0000

These are the Django questions that actually come up for backend and full-stack roles — grouped by topic, each with a short model answer and a note on what the interviewer is really checking.

Django interviews reward a mental model over trivia. Interviewers want to hear that you understand why the framework does something. For each answer below, notice the pattern: name the mechanism, give the one trade-off that matters, then stop.

Models & the ORM

QuerySets are lazy — when does one actually hit the database?

A QuerySet doesn't run a query when you create or filter it — only when it's evaluated: iterating it, calling list(), len(), bool(), or slicing with a step. That laziness lets you chain .filter() calls into a single query. The flip side: if you re-use the same QuerySet in a loop or template it can re-run, so cache it with list() when you'll touch it more than once.

What they're testing: whether you understand lazy evaluation — the root of most Django performance surprises.

`select_related` vs `prefetch_related` (the N+1 problem)

The N+1 problem is looping over a queryset and hitting the DB once per row for a related object — 1 + N queries. select_related fixes it for FK / one-to-one with a SQL JOIN (one query). prefetch_related handles many-to-many and reverse FKs with a second query that Python joins in memory. Reach for them whenever a loop or template touches related data.

What they're testing: whether you can spot and fix the most common ORM bug.

What's the difference between `null=True` and `blank=True`?

null is database-level — the column may store NULL. blank is validation-level — forms and DRF serializers allow the field to be empty. They're independent. For text fields the convention is blank=True without null=True, so "empty" is an empty string rather than two different empty states (NULL and '').

What they're testing: that you know the database layer and the validation layer are separate.

What does `on_delete` do on a `ForeignKey`?

It decides what happens to a row when the object it points to is deleted: CASCADE deletes the children too, PROTECT blocks the delete, SET_NULL nulls the FK (needs null=True), plus SET_DEFAULT and DO_NOTHING. It's a deliberate data-integrity choice — CASCADE on the wrong relation can wipe data you meant to keep.

What they're testing: that you think about referential integrity when you model data.

Views, URLs & requests

What is middleware, and does the order matter?

Middleware is a chain of hooks that wrap every request and response — sessions, auth, CSRF, security headers. Order matters: the request phase runs top-to-bottom through MIDDLEWARE, the response phase bottom-to-top. So authentication must sit before anything that relies on request.user.

What they're testing: a mental model of the request pipeline.

Function-based vs class-based views — which and when?

FBVs are explicit and easy to read — good when the logic is one-off. CBVs use inheritance and mixins to reuse standard patterns (ListView, DetailView, generic CRUD), so you write less for common cases, but the flow is spread across the class hierarchy. Rule: FBV when the logic is unique, CBV when it's a standard pattern.

What they're testing: judgment about reuse vs. readability, not dogma.

How does Django protect against CSRF?

Django issues a per-session CSRF token. Unsafe methods (POST/PUT/DELETE) must send it back — a hidden form field or the X-CSRFToken header — and CsrfViewMiddleware rejects a mismatch. An API authenticated by a token or JWT in the Authorization header (not cookies) isn't vulnerable to cookie CSRF, which is why DRF token endpoints are often CSRF-exempt.

What they're testing: security awareness and the difference between cookie and header auth.

Django specifics you'll be asked

What's the difference between a project and an app?

A project is the whole site — settings, root URLs, config. An app is a self-contained, reusable module for one feature (say accounts or billing). One project contains many apps; a well-designed app does one thing and could drop into another project.

What they're testing: whether you organise a codebase, not just make it work.

What are migrations, and how do `makemigrations` and `migrate` differ?

Migrations are version control for your DB schema. makemigrations reads model changes and writes migration files — the plan. migrate applies them to the database — the execution. You commit migration files to git so the whole team's schema stays in sync.

What they're testing: that you understand the real schema-change workflow.

Django signals — when would you use them, and when avoid them?

Signals let decoupled code react to events like post_save — e.g. creating a profile when a user is created. Good for genuinely cross-cutting reactions. But they hide control flow: a save in one place silently triggers code elsewhere, which makes bugs hard to trace. If the logic clearly belongs in a model's save() or a service function, call it directly.

What they're testing: that you weigh decoupling against traceability.

Production & performance

A Django view is slow. How do you speed it up?

Measure first — the Django Debug Toolbar or a query count shows where the time goes. Then, in order: kill N+1 with select_related/prefetch_related, fetch fewer columns with only()/values(), add a DB index on filtered/ordered columns, and only then cache if it's read-heavy. Don't reach for Redis before you've cut the queries.

What they're testing: a systematic process, not a memorised list of fixes.

How do you handle concurrent updates safely?

Wrap the read-modify-write in a transaction and use select_for_update() to lock the rows, so two requests can't both read the old value and overwrite each other — a race condition. For "create only once", a unique constraint plus get_or_create is often simpler than locking.

What they're testing: awareness of concurrency, not just single-request thinking.

How to actually answer these

The difference between a pass and a fail on Django questions is showing a mental model. Say what the framework does and why, name the one trade-off, and stop. If you're unsure of an exact API, describe the mechanism instead of freezing on the name. If you tend to blank under pressure, that's a separate, fixable skill.

I built Peakblick, where you rehearse questions like these on a timer and an AI scores every answer 1–10 with feedback. Free to try.

SQL Interview Questions (With Model Answers)

Peakblick — Sat, 26 Sep 2026 17:54:21 +0000

These are the SQL questions that actually come up in backend, data, and full-stack interviews — grouped by topic, each with a short model answer and a note on what the interviewer is really checking.

SQL questions reward precision. Interviewers can tell in one sentence whether you understand what a query does or you're pattern-matching keywords. For each answer below, notice the shape of a strong response: name the mechanism, give the one trade-off that matters, then stop.

Core SQL

What's the difference between `WHERE` and `HAVING`?

WHERE filters rows before they're grouped; HAVING filters after aggregation, so it can reference aggregate functions like COUNT(*) or SUM(x). Rule of thumb: filter individual rows with WHERE, filter groups with HAVING. Putting a plain row condition in HAVING still works but is slower, because you aggregate rows you could have dropped earlier.

What they're testing: that you understand the logical order of a query, not just the syntax.

How do aggregate functions handle `NULL`?

Aggregates like SUM, AVG, MIN and MAX ignore NULLs. The catch is COUNT: COUNT(*) counts every row, but COUNT(column) counts only rows where that column is not null — so AVG(col) divides by the number of non-null values, a common source of "wrong" averages.

What they're testing: awareness that NULL means "unknown" and silently changes results.

How would you filter rows within a range, or against a list of values?

Use BETWEEN for an inclusive range — WHERE age BETWEEN 18 AND 30 — and IN for a discrete set — WHERE status IN ('open', 'pending'). Watch out: NOT IN with a list containing NULL returns no rows.

What they're testing: fluency with everyday filtering, plus the NULL gotcha.

Joins & aggregation

Explain `INNER JOIN` vs `LEFT JOIN`.

An INNER JOIN returns only rows that match in both tables. A LEFT JOIN returns every row from the left table, filling NULLs where the right has no match. Frequent bug: a WHERE on the right table's column after a LEFT JOIN quietly turns it back into an inner join — put that condition in the ON clause.

What they're testing: whether you can reason about which rows survive, and spot the left-join trap.

How do you combine values from multiple rows into one per group?

Use GROUP BY with a string-aggregation function — STRING_AGG(name, ', ') in PostgreSQL, GROUP_CONCAT in MySQL. Every non-aggregated column in the SELECT must appear in the GROUP BY.

What they're testing: that aggregation isn't only COUNT/SUM, and the GROUP BY rule.

What is a window function, and when would you use one?

A window function computes across related rows without collapsing them — you keep every row and add a computed column. Classic uses: a running total (SUM(...) OVER (ORDER BY date)) or ranking within a group (ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)).

What they're testing: a level above basic aggregation — this often separates mid from senior.

Performance

What is a database index, and when would you avoid one?

An index is a separate structure (usually a B-tree) that speeds reads by avoiding a full scan. The trade-off is slower writes and extra storage. Avoid one on a small table, or a column written far more than it's read.

What they're testing: that you weigh read speed against write cost.

A query is slow. How do you approach it?

Measure first — run EXPLAIN and read the plan. Usual culprits: a sequential scan where an index should be used, a missing index on a join/filter column, or returning more rows than needed. Fix the specific cause, then re-check the plan.

What they're testing: a systematic process, and knowing EXPLAIN exists.

How would you efficiently insert or update a large number of rows?

Batch them into a single transaction instead of one statement per row — that avoids per-row commit overhead. For very large loads, use the bulk path (COPY in PostgreSQL, LOAD DATA in MySQL), upsert with INSERT ... ON CONFLICT, and consider dropping non-critical indexes during the load.

What they're testing: that you think about round-trips and transactions.

Design & transactions

What does ACID mean?

Atomicity (all-or-nothing), Consistency (valid state to valid state), Isolation (concurrent transactions don't see each other's half-finished work), Durability (committed data survives a crash). Isolation comes up most in practice — it's why you wrap a money transfer in a transaction.

What they're testing: connecting the acronym to a real reason you'd use a transaction.

What is normalization, and when would you denormalize?

Normalization stores each fact once, avoiding update anomalies. You denormalize (deliberately duplicating data) when read performance matters more than write simplicity — a reporting table or a cached count. The trade-off is keeping the duplicate in sync.

What they're testing: that you see normalization as a trade-off, not a rule.
The gap between a pass and a fail on SQL questions is rarely the facts — it's precision. State what the query does, name the one trade-off or gotcha that matters, and stop. If you blank under pressure, that's a separate, fixable skill.

I built Peakblick, where you practice questions like these on a timer and an AI scores every answer 1–10 with feedback. Free to try.

Python Backend Interview Questions (With Model Answers)

Peakblick — Wed, 23 Sep 2026 12:08:14 +0000

These are the questions that actually come up for mid-level Python backend roles — grouped by topic, each with a short model answer and a note on what the interviewer is really testing.

Memorising answers won't get you the offer; interviewers can tell. Use these to check your understanding and, more importantly, to rehearse saying them out loud. For each one, notice the pattern of a strong answer: state the mechanism, give the trade-off, then stop.

Python core

What is a decorator, and when would you use one?

A decorator is a callable that takes a function and returns a new function wrapping it, so you can add behaviour without changing the original body. Common uses: caching, access checks, logging, timing, retries. In practice you write @decorator above the function; underneath it's just fn = decorator(fn).

What they're testing: whether you understand functions as first-class objects — not just the syntax.

What is the GIL and when does it actually matter?

The Global Interpreter Lock lets only one thread execute Python bytecode at a time, so threads don't give you true parallelism for CPU-bound work. It rarely hurts I/O-bound work (the lock is released during I/O), so threads are still fine for network calls. For CPU-bound parallelism, use multiprocessing or a native/extension path.

What they're testing: that you know when threads help (I/O) versus when to reach for processes (CPU).

Generator vs list — why use `yield`?

A list holds all items in memory at once; a generator produces them lazily, one at a time, so it uses near-constant memory and can stream huge or infinite sequences. Trade-off: you can only iterate a generator once, and you can't index it. Use generators for large pipelines, lists when you need random access or to reuse the data.

What they're testing: memory awareness and knowing the trade-off, not just the definition.

Why are mutable default arguments dangerous?

A default like def f(x, items=[]) is evaluated once at definition time, so the same list is shared across every call — mutating it leaks state between calls. The fix is items=None then items = items or [] inside the function.

What they're testing: a classic gotcha that shows you understand when Python evaluates defaults.

Django & frameworks

`select_related` vs `prefetch_related` (and the N+1 problem)

The N+1 problem is when you load a list, then hit the DB once per item for a related object — 1 + N queries. select_related fixes it for foreign-key / one-to-one by doing a SQL JOIN (one query). prefetch_related handles many-to-many / reverse FKs with a second query that Python joins in memory. Reach for them whenever you loop over a queryset touching related data.

What they're testing: whether you can spot and fix the most common ORM performance bug.

What happens when a request hits your Django app?

The WSGI/ASGI server hands the request to Django, which runs it through the middleware stack, resolves the URL to a view, the view does its work (often via the ORM), returns a response, and middleware runs again on the way out. Naming middleware, URL resolution, view, and response is enough to show you understand the flow.

What they're testing: a mental model of the framework, not memorised internals.

Databases & APIs

What is a database index, and when would you avoid one?

An index is a separate structure (usually a B-tree) that speeds up reads by avoiding a full table scan. The trade-off is slower writes and extra storage, since every insert/update maintains the index. Avoid one on a small table or on a column that's written far more than it's read. Short version: index for read-heavy lookups, skip it when writes dominate.

What they're testing: that you weigh read speed against write cost, not just "indexes make things fast".

What does idempotency mean in a REST API?

An idempotent request produces the same result no matter how many times it's sent. GET, PUT and DELETE should be idempotent; POST usually isn't. It matters for retries — if a client retries after a timeout, an idempotent endpoint won't create duplicates. For non-idempotent creates, an idempotency key is the common fix.

What they're testing: API design maturity and thinking about failure/retries.

An endpoint is slow. How do you approach it?

Measure first — find whether it's the DB, the code, or an external call. The usual culprits for a Python backend: N+1 queries (fix with select_related/prefetch_related), a missing index, or fetching more data than needed. Then consider caching the result if it's read-heavy and can tolerate slight staleness. Name the order — measure, fix the query, then cache — rather than jumping to "add Redis".

What they're testing: a systematic debugging process, not a memorised list of fixes.

How to actually answer these

The difference between a pass and a fail here is rarely the facts — it's delivery. Open with the mechanism, name the trade-off out loud, and stop when you've answered. If you don't know something, say what you'd expect and why instead of bluffing. If you tend to blank under pressure, that's a separate, fixable skill.

I built Peakblick, where you rehearse questions like these on a timer and an AI scores every answer 1–10 with feedback. Free to try.

Why You Freeze in Technical Interviews (and the Drill That Fixes It)

Peakblick — Mon, 21 Sep 2026 18:41:40 +0000

If you go blank in interviews even though you know the material, the problem isn't knowledge — it's that you've never practiced performing under a clock while talking. That's a separate skill, and it's fixable with reps.

You've solved the problems. You've read the docs. Then the interviewer asks something you'd nail on your own machine, and your mind goes empty. This is one of the most common — and most misunderstood — reasons strong engineers fail interviews. The good news: the fix has nothing to do with studying more.

What freezing actually is

Solving a problem alone and answering it out loud in front of a stranger, on a timer, are two different skills. When you code alone, your working memory is free to think. In an interview, a big chunk of that memory is spent on things that have nothing to do with the problem: watching the clock, worrying about how you sound, wondering what they're thinking. There's less capacity left for the actual answer — so you blank.

That's why the freeze feels so unfair. You do know it. You've just never trained your brain to retrieve it while under that specific load.

Why more studying doesn't help

Grinding more problems trains the wrong muscle. It makes you better at solving silently — which you're already good at. It does nothing for the thing that's actually failing: retrieving and explaining under pressure. You can double your problem count and still freeze, because you never rehearsed the conditions of the interview itself.

The 20-minute drill that fixes it

Recreate the pressure, on purpose, until it stops being novel:

Talk the entire time. Narrate your thinking out loud, even alone. It feels deeply unnatural at first — that discomfort is exactly the skill you're building.
Put a real clock on it. 20–30 minutes, no pausing to look things up. The pressure is the point; that's the variable you're bad at, not the topic.
Record it or get it scored, then review. Watch or read it back. You'll immediately hear the rambling, the skipped trade-offs, the "umm" spirals you can't feel in the moment.

Do this three or four times and the interview stops feeling like an ambush. The retrieval-under-pressure path is now worn in.

What to fix when you review

From scoring hundreds of answers, the same handful of habits separate a "pass" from a "fail":

Structure before detail. Open with the shape of your answer — "there are basically three approaches; I'd go with X because…" — then fill in. Interviewers grade signal, and structure is signal.
Name the trade-off out loud. "This is O(n) time but costs memory; if the input's bounded I'd do the other one." Saying the trade-off scores higher than a correct answer with no reasoning.
Admit the unknown. "I haven't used that directly, but based on X I'd expect Y" beats a confident wrong answer every time. Bluffing is the fastest fail.
Answer the question that was asked. Restate it in one line before you start — a huge share of low scores are just off-target.
Land the plane. End with a one-sentence conclusion instead of trailing off. A clear close changes how the whole answer is remembered.

Good vs. weak answer, same question

Question: "What's a database index and when would you avoid one?"

Weak: "An index makes queries faster because it's like a lookup table and the database uses it to find rows quicker so reads are faster…" (correct-ish, but no structure, no trade-off, no close.)

Strong: "An index is a separate data structure that speeds up reads by avoiding a full scan — usually a B-tree. The trade-off is slower writes and extra storage, since every insert updates the index. So I'd avoid one on a small table, or a column that's written far more than it's read. Short version: index for read-heavy lookups, skip it when writes dominate." (Structure → trade-off → when-not → close.)

Same knowledge. The second one just performs it — which is the exact skill the drill builds.

I built Peakblick to run this drill without a partner: it interviews you for a specific role, on a timer, and scores every answer 1–10 with feedback. Free to try.

DEV Community: Peakblick

Django select_related vs prefetch_related (With Examples)

The problem they solve: N+1 queries

select_related — for ForeignKey and OneToOne

prefetch_related — for ManyToMany and reverse ForeignKey

The rule

Combining them

Common gotchas

Nested Loops in a Python List Comprehension

The basic idea: same order as nested loops

The one mistake everyone makes: the order

Flattening a list of lists

Nested comprehensions (a list of lists)

Adding a condition

When to stop and just write the loop

Python Interview Questions (With Model Answers)

The data model

What's the difference between mutable and immutable types?

List vs tuple — when would you use each?

is vs == — what's the difference?

Shallow copy vs deep copy?

Functions

What do *args and **kwargs do?

What is a decorator?

Why is a mutable default argument a bug?

Iterators & generators

What is a generator, and why use one?

What's the difference between an iterable and an iterator?

List comprehension vs generator expression?

Concurrency & resources

What is the GIL, and what does it mean for threads?

What is a context manager, and when would you write one?

How does Python manage memory?

How to actually answer these

REST API Interview Questions (With Model Answers)

HTTP methods & status codes

What's the difference between GET, POST, PUT, PATCH and DELETE?

Which status codes do you use, and when?

REST design

What actually makes an API "RESTful"?

How do you design resource URLs?

PUT vs PATCH — what's the difference?

Versioning, pagination & errors

How do you version an API?

How do you paginate a large collection?

How should an API return errors?

Auth, caching & reliability

How do you authenticate a REST API?

REST vs GraphQL — when would you use each?

What is idempotency, and how do you make an unsafe endpoint safe to retry?

How does HTTP caching work for an API?

How to actually answer these

System Design Interview Questions (With Model Answers)

Scaling fundamentals

What's the difference between vertical and horizontal scaling?

Latency vs throughput — what's the difference?

A service is getting too much traffic. How do you think about handling it?

Caching & data

What is caching, and where would you add it?

Why is cache invalidation hard?

SQL vs NoSQL — when would you choose each?

What is sharding, and what's the hard part?

What does replication give you, and what's the trade-off?

What does the CAP theorem actually force you to choose?

Communication & scale

What does a load balancer do?

When would you use a message queue?

How would you rate-limit an API?

What's a CDN for?

Reliability & approach

What is idempotency, and why does it matter in a distributed system?

How do you approach an open-ended "design X" question?

How to actually answer these

How We Built Our Own AI Interview Grader (No GPT)

Why not just call GPT?

One generative model, the whole interview

Generating the questions

The hard part: judging without hallucinating

Our approach: let the model answer first

A score you can read, not a mystery number

`is` vs `==` — what's the difference?

What do `*args` and `**kwargs` do?

What's the difference between `git fetch` and `git pull`?

What is `HEAD`, and what's a "detached HEAD"?

What does `git cherry-pick` do, and when would you use it?

`git revert` vs. `git reset` — when do you use each?

What do `--soft`, `--mixed` and `--hard` do on `git reset`?

What does `git stash` do?

You ran `git reset --hard` and lost commits. Can you get them back?

You committed a file that shouldn't be tracked (say, `.env`). What now?

`select_related` vs `prefetch_related` (the N+1 problem)

What's the difference between `null=True` and `blank=True`?

What does `on_delete` do on a `ForeignKey`?

What are migrations, and how do `makemigrations` and `migrate` differ?

What's the difference between `WHERE` and `HAVING`?

How do aggregate functions handle `NULL`?

Explain `INNER JOIN` vs `LEFT JOIN`.

Generator vs list — why use `yield`?

`select_related` vs `prefetch_related` (and the N+1 problem)