DEV Community: Martin

JavaScript interview questions: can you run the interpreter in your head?

Martin — Mon, 26 Oct 2026 12:17:00 +0000

Ask someone to define a closure and you'll get the same three sentences everyone gets from a guide they read once. Ask them what a loop full of var and setTimeout actually prints, and you find out whether they've been burned by it.

The six questions below aren't really six separate topics. JavaScript has no compiler standing between you and the runtime, so almost everything senior candidates get asked is a version of the same test: can you predict what actually happens when this code runs, not what you meant it to do.

Candidates who can hold that model in their head answer all six. Candidates who memorized definitions answer the first half and then start guessing. If you'd rather work through the topic than read about it, the JavaScript track covers the same ground one idea at a time.

Question 1: what logs first, the timeout or the promise?

This is one of the oldest tricks in a JavaScript round and it still works, because most people learn 'async code runs after sync code' as a slogan rather than as a mechanism with parts you can name.

console.log("1");
setTimeout(() => console.log("2"), 0);
Promise.resolve().then(() => console.log("3"));
console.log("4");

// logs: 1, 4, 3, 2

A promise callback is a microtask. setTimeout, even at 0ms, is a macrotask, and the whole microtask queue drains before the next macrotask runs.

Why does the promise log before the zero-millisecond timeout?

Junior answer: Promises are just faster than setTimeout, so they get to run first even when both are scheduled at roughly the same time.

Senior answer: There's one call stack, and it runs to completion before anything queued gets a turn. Once it's empty, the microtask queue (promise callbacks, including everything after an await) drains completely before the event loop even looks at the next macrotask (timers, I/O, UI events). Nothing about speed is involved: setTimeout(fn, 0) doesn't mean 'run now', it means 'join the macrotask queue', and that queue is checked only after every microtask has run.

The follow-up is usually what happens if a promise chain keeps scheduling more microtasks off the back of each other: the macrotask queue never gets a turn, the browser can't paint, and the tab looks hung with nothing in the code technically wrong.

Worth saying without being asked: await doesn't pause the language, it desugars to a .then. Every await point is a microtask boundary, which is why a loop full of sequential await calls runs one after another even though nothing looks blocking, and why wrapping independent calls in Promise.all instead of awaiting each in turn is the fix people reach for once they've actually seen the ordering.

Question 2: fix the loop that logs the wrong number three times

This one shows up as a live task almost as often as it shows up as a question, because writing the fix proves you understand the bug better than describing it does.

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// logs 3, 3, 3

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// logs 0, 1, 2

Same loop, same closure, different binding underneath.

Why does switching var to let fix it, mechanically?

Junior answer: let is block-scoped, so it works properly inside a loop and var doesn't.

Senior answer: var has one function-scoped binding for the whole loop, so all three timeouts close over the same variable, and by the time any of them run the loop has already finished with i at 3. let creates a fresh binding for every iteration, so each closure captures its own i, frozen at the value it had that pass. Block scoping is true but it's not the mechanism, the per-iteration binding is.

If they mention memory here, that's a natural moment to ask when closures cause leaks. A closure keeps its captured scope reachable for as long as the closure itself is, which is the same fact behind this bug and behind a real leak in a long-lived app.

Question 3: why is this undefined inside the callback?

A method that works fine when you call it directly and breaks the moment it's passed as a reference. This is the bug that teaches people what this actually means, usually the hard way, the first time it happens in real code.

class Counter {
  count = 0;
  increment() { this.count++; }
}

const counter = new Counter();
button.addEventListener("click", counter.increment);
// this is undefined when the handler fires

The method left the object it belonged to the moment it was passed as a value.

this is set by how a function is called, not by where it's written. counter.increment() and counter.increment passed to addEventListener are the same function, but only the first one calls it as counter's method. The second hands the browser a bare function, and when the click fires, nothing about that call mentions counter, so this is undefined inside a class method (or the global object outside strict mode). The fix is binding in the constructor, wrapping the call in an arrow function, or writing increment as an arrow class field in the first place.

Why does an arrow method behave differently from a normal method under inheritance?

Junior answer: Arrow functions don't have their own this, so they just use whatever this is in the surrounding scope, which fixes the binding problem.

Senior answer: That's true, and it's also why arrow methods don't participate in the prototype chain the way normal methods do. An arrow class field is created fresh per instance, in the constructor, with this captured at that moment, so a subclass can't override it through the prototype the way it overrides a regular method. You've traded a real inheritance bug for a real memory cost: every instance now carries its own copy of the function instead of sharing one off the prototype.

This is the question where naming the trade-off matters more than picking a side. Arrow fields are the right default for event handlers precisely because they can't be overridden out from under you; that's also exactly why they're the wrong choice for anything meant to be extended.

Question 4: what does the caller see after this function runs?

A function mutates something it was handed. The question is whether the person calling it knows that, and whether the candidate does.

function addItem(cart, item) {
  cart.items.push(item);
  return cart;
}

const original = { items: [] };
const result = addItem(original, "book");
result === original; // true, and original.items now has one item too

Objects are passed by reference, so the function and the caller share one array.

Primitives are copied on assignment or on a function call. Objects and arrays are not, what gets copied is the reference, so the function and the caller are looking at the same underlying structure the whole time. Anyone who's surprised by that has usually only ever seen it go wrong once it's three functions deep, which is exactly why interviewers ask it directly instead of waiting for it to come up.

Does spreading an object make a deep copy?

Junior answer: Yes, spreading creates a new object, so changes to the copy don't touch the original.

Senior answer: Spread copies one level. Top-level keys get new slots, but if any of those values are themselves objects or arrays, the copy and the original point at the exact same nested structure. const copy = { ...state }; copy.user.name = 'x' changes state.user.name too, because user was never copied, only referenced again. JSON.parse(JSON.stringify(x)) goes deeper but drops functions and Dates and undefined and breaks on anything circular. structuredClone is the honest built-in answer for a real deep copy, and it still can't clone a function.

Question 5: where does a class method actually live?

class reads as a different language feature from everything above it, and that's the point of the question: it isn't one. It compiles down to the same prototype chain that's been there since the beginning.

Every object has an internal link to another object it falls back to when a property lookup misses, and that chain keeps going until it hits null. A method defined in a class body lives once, on the prototype, shared by every instance, which is different from an arrow class field: those get copied per instance, as question 3 covered. Looking a method up on an instance walks the chain until it finds increment on Counter.prototype, and every instance sees the same function.

extends wires one prototype's fallback to another, so a subclass instance's lookup chain runs through the child's methods, then the parent's, then Object.prototype.
super.method() calls the parent's version explicitly, which you need the moment you override something but still want the original behavior inside the new one.
Modifying a built-in prototype (adding a method to Array.prototype, say) changes every array in the program, including ones from libraries that never expected it, and collides with anything the spec adds under the same name later. It's a real technique and also a real way to make a codebase unpredictable.

Two that show up before the real questions start

== vs ===. === skips coercion entirely. == runs a set of rules first, and a couple of the results surprise people who only use it by habit: null == undefined is true, but null == 0 is false, and NaN never equals anything, including itself, which is why you check for it with Number.isNaN rather than a comparison.
Hoisting and the temporal dead zone. var, let, const and function declarations are all hoisted, but they don't behave the same once you're inside that hoisted space. var initializes to undefined immediately, so reading it early just gives you undefined. let and const are hoisted but sit in the temporal dead zone until their declaration line actually executes, and reading them before that throws a ReferenceError. That's deliberate: it catches use-before-initialization as an error instead of letting it silently return undefined.

The live task: write a debounce

Most rounds have one small keyboard moment, and for JavaScript it's usually this one, or throttle's sibling version of it. What's being scored isn't whether the syntax lands. It's the order you build it in.

Say the problem before touching the keyboard: a rapid-fire event is triggering expensive work on every call, and you want it to run once, after things go quiet.
Reach for a closure holding a single timer id. It's the same mechanism as question 2, and saying that out loud is a good sign, not a distraction.
Clear the pending timer on every call, then schedule a new one. That line is the whole mechanism. Throttle is the same shape with a boolean guard and a fixed interval instead of a reset.
Decide what happens to this and the arguments the wrapped function was called with. Forwarding them with apply, or a rest parameter and an arrow function, is what makes the debounced version actually interchangeable with the original.
Say which one fits which case. A search box wants debounce, since it's waiting for a pause. A scroll handler wants throttle, since it wants steady progress rather than silence followed by a burst.

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

The closure over timer is what lets each call see, and cancel, the one before it.

The implementation is a few lines. The narration is the part that's hard to rehearse alone, because the follow-up is the interview, and the follow-up here is almost always how you'd add a leading-edge option or cancel a pending call.

Question 6: what's keeping this object alive?

A closing question that sounds abstract and isn't. Every long-lived JavaScript app leaks eventually, and the question is whether a candidate can point at where.

Garbage collection is reachability-based: an object is kept as long as something reachable from a root still points to it, and reclaimed once nothing does. Setting a variable to null doesn't free anything by itself, it just removes one path to the object, and if another reference exists elsewhere, nothing changes. The usual leaks in a real app are forgotten event listeners, timers that outlive what they were scheduled for, closures retaining a large object they only needed briefly, and DOM nodes removed from the page but still referenced from JavaScript, which keeps the whole detached subtree alive.

How does a WeakMap avoid a leak a Map would cause?

Junior answer: A WeakMap is basically a faster Map for when your keys are objects.

Senior answer: A WeakMap holds its keys weakly, so an entry doesn't count as a reason to keep the key alive. If you're caching computed data per DOM node in a regular Map, that map keeps every node reachable for as long as the map exists, even after the node's been removed from the page, which is a slow leak with a completely ordinary-looking cause. The same cache in a WeakMap lets the node and its cached value get collected together the moment nothing else references the node. WeakRef solves a narrower version of the same problem, holding a reference to a value without being a reason it survives, and it comes up far less often.

If they ask you to point at a real leak in a heap snapshot

Trigger the suspected action twice, take a snapshot each time, and compare. Growth in the count of a specific constructor between the two, especially a detached DOM tree still showing up, is the signal. The retainers panel answers the actual question: not that something leaked, but what's still holding onto it, which is usually a listener or a closure named right there in the chain.

Common questions

How much of this overlaps with a React round?

More than it looks like on paper. Stale closures inside useEffect, an event handler losing this, async ordering inside a component: all of it is React sitting directly on top of the mechanisms above, not a separate topic.

Do generators and Proxy come up?

Occasionally, and almost never as 'implement one'. The realistic version is naming a use case: a generator for a lazy or infinite sequence, or paging through an API without loading it all at once; a Proxy for validation or a reactivity system that needs to notice when a property is read or written. Knowing what each one is for is worth more than the syntax.

I mostly write TypeScript at work. Does plain JavaScript still get asked?

Yes, because types are erased at compile time and none of this is a type-system question. A TypeScript round checks a different layer entirely, and it assumes the runtime layer underneath it is already solid.

Is it fine to say I'd reach for lodash's debounce instead of writing one?

In real code, yes, and saying so is a normal engineering answer. In the interview, they're not asking whether you'd use the library, they're using the exercise to see the closure-and-timer model in your hands, so build it anyway and mention the library as what you'd actually ship.

Reading the mechanics is the easy half. What actually gets scored is narrating the runtime out loud while someone follows up on whatever you just said. Run a JavaScript interview at your level. Practise a JavaScript interview

Python interview questions: the ones a backend round actually asks

Martin — Fri, 23 Oct 2026 08:32:00 +0000

Most Python interview lists are written for people learning the language. A backend round isn't that. It assumes you can write Python and goes looking for the places where Python's convenience quietly costs you something in production.

The questions below have one thing in common: each has an easy answer that's correct and a second layer that decides the round. The easy answer is the doorway, and interviewers use these particular questions precisely because the doorway is so well known that it tells them nothing on its own.

If you'd rather work through the topic than read about it, the Python track covers the same ground one idea at a time.

Question 1: what does the GIL actually stop you doing?

Everyone has heard that Python has a global interpreter lock and that threads are therefore useless. Half of that is right, and the half that's wrong is the half that matters when you're deciding how to make a slow endpoint faster.

You have a slow endpoint. Would threads help?

Junior answer: Probably not, because of the GIL. Python can only really run one thread at a time, so threading doesn't give you a speedup. You'd need multiprocessing.

Senior answer: It depends what it's slow on. The lock is held while interpreting bytecode, so two threads never execute Python code at the same time, and a CPU-bound handler gets nothing from threads. But the lock is released around blocking I/O, so if the endpoint is waiting on a database, an HTTP call or the disk, threads overlap that waiting perfectly well. So: I'd measure where the time goes first. I/O-bound, threads or asyncio. CPU-bound, move the work to processes, or into a library like NumPy that drops the lock in its C code, or out of the request entirely onto a queue.

The natural follow-up is what multiprocessing costs you, and the honest answer is: real memory per process, and everything you send between them has to be picklable, which rules out more objects than people expect.

Worth knowing rather than claiming: recent CPython versions ship a build with the lock removed, and it's a genuinely large change to the runtime. Saying it exists is a good signal. Saying your service would get faster by switching to it is a claim you'd have to defend, and single-threaded code on that build isn't automatically quicker.

Question 2: why does this function remember the last call?

The most-asked Python gotcha, and still worth asking, because the mechanism behind it explains a whole category of surprises.

def add_item(item, basket=[]):
    basket.append(item)
    return basket

add_item("apple") # ['apple']
add_item("pear") # ['apple', 'pear'] <- the same list

The default is created once, when the function is defined, not each time it's called.

A def statement runs once. Its defaults are evaluated at that moment and stored on the function object, so every call that doesn't pass the argument shares one list. The fix is basket=None and if basket is None: basket = [] inside the body.

Where else does that same rule bite?

Junior answer: Mostly with lists and dictionaries as defaults. As long as you use None instead, you're fine.

Senior answer: Anywhere an expression is evaluated once at definition time and then reused. Default arguments are the famous one, but class attributes behave the same way: a list assigned in the class body is shared by every instance, which is why dataclasses make you use field(default_factory=list) instead of a bare list. The same thing bites with decorators that build state at import time. The rule worth carrying is that class and def bodies run once, at import, and anything mutable created there is shared for the life of the process.

Question 3: async, threads or processes?

The question a backend round almost always reaches, because it's the one where a wrong mental model shows up directly in production behaviour.

@app.get("/report")
async def report():
    data = requests.get("https://slow-api.example.com").json() # blocking
    return summarize(data)

An async endpoint making a blocking call: every other request on that worker waits, however many of them there are.

An event loop runs on one thread. A coroutine that blocks doesn't yield, so nothing else on that loop runs until it returns, including requests that have nothing to do with it. It's the same failure as blocking the event loop in Node.js, and the fix is the same shape: use an async client so the wait is awaited, or push the blocking call off the loop with asyncio.to_thread or a run-in-executor call.

asyncio for lots of concurrent I/O in one process: thousands of open connections, where a thread each would be wasteful. It costs you a whole parallel ecosystem of libraries, because one blocking call in the wrong place undoes it.
Threads for I/O when the code is already synchronous. Simpler, and fine at the scale most services actually run at.
Processes for CPU-bound work, with real memory cost and pickling at the boundary.
A task queue when the work doesn't need to finish inside the request at all. Frequently the right answer, and the one candidates forget to offer.

Question 4: this endpoint loads a million rows into memory

Generators are a first-year topic that turns into a senior one the moment the question is about a real dataset instead of a toy.

rows = [transform(r) for r in cursor.fetchall()] # whole table in memory
rows = (transform(r) for r in cursor) # one row at a time

Two characters of difference, and an entirely different memory profile.

When would you not use a generator here?

Junior answer: Generators are more memory efficient, so I'd use one wherever I'm iterating over something large. There's not much reason not to.

Senior answer: When you need the data more than once, or need its length, or need random access, because a generator is consumed and gone. And when laziness moves work somewhere it can't fail safely: if the generator is still pulling rows while the request is being serialised, the database transaction and connection have to stay open that whole time, and an exception now surfaces halfway through a response you've already started writing. For a streaming export that's the right trade. For something the caller retries, I'd rather page explicitly and know each chunk is finished.

A good follow-up to expect: what happens if you call the generator function and never iterate it. Nothing does, the body hasn't run yet, which is also why a bug inside it can show up nowhere near the line that created it.

Question 5: the ORM query that gets slower as the data grows

This one isn't really a Python question, which is exactly why it separates backend candidates from people who know the language.

for order in Order.objects.all(): # 1 query
    print(order.customer.name) # 1 more query per order

The N+1: the loop looks like attribute access and is actually a round trip each time.

Lazy loading is the ORM's best feature and its sharpest edge. Attribute access issues a query, so a loop over a hundred orders is a hundred and one queries, each fast in isolation, and the endpoint gets slower in production as the table grows while staying fine on your laptop's seeded data. The fix is to tell the ORM what you're going to need: a join for a single related row, a second batched query for a collection. In Django that's select_related and prefetch_related; in SQLAlchemy, joinedload and selectinload.

What makes the answer senior is saying how you'd catch it rather than how you'd fix it, because you'll write this bug again. Log query counts per request in development, assert on the count in a test for the endpoints that matter, and watch the count in production rather than only the latency. Database interview questions for backend engineers goes further into what the database itself is doing with these.

Two smaller ones that come first

is versus ==. == asks whether two objects are equal, is asks whether they're the same object. They agree often enough by accident to be dangerous: small integers and short strings are cached by the interpreter, so a is b can be True for 256 and False for 257 with nothing else changed. Use is for None, True and False, and == for values.
Type hints. They're not enforced at runtime. The interpreter ignores them, a type checker reads them before the code ever runs, and passing a string where the annotation says int fails nowhere until something downstream breaks. Pydantic and FastAPI are the exception people are thinking of when they disagree: those validate at runtime, deliberately, because the data came from outside.

The live task: write a retry decorator

If there's a keyboard moment in a Python backend round, it's usually a decorator, and retry is the most common one. It's short, it uses closures, and it has an opinionated second half that most candidates skip.

Say what you're building before typing: a wrapper that calls the function, and on a failure waits and tries again up to a limit.
Reach for a closure over the arguments, and functools.wraps on the inner function, so the wrapped function keeps its name and docstring instead of becoming a nameless wrapper in every traceback.
Forward *args and **kwargs unchanged, so the decorated function stays interchangeable with the original.
Back off between attempts rather than retrying immediately, because a service that just failed under load is exactly the one you shouldn't hit three more times in a row.
Catch the exceptions you can retry, not every exception. Retrying a timeout is sensible, retrying a 400 is a bug that hides a bug.
Say the limit out loud: retries are only safe if the operation is idempotent. This is the sentence that separates the answer from the implementation.

import functools, time

def retry(attempts=3, delay=0.5, exceptions=(TimeoutError,)):
    def decorator(fn):
        @functools.wraps(fn)
        def wrapper(*args, **kwargs):
            for attempt in range(attempts):
                try:
                    return fn(*args, **kwargs)
                except exceptions:
                    if attempt == attempts - 1:
                        raise
                    time.sleep(delay * 2 ** attempt)
        return wrapper
    return decorator

Three nested functions, because the decorator takes arguments. Re-raising on the last attempt is what keeps the failure visible.

Expect to be asked what happens when every caller retries a struggling service at once, and whether you'd add jitter. And expect the version of this question that's really about trade-offs: would you write this, or take the dependency that already does it properly.

Question 6: what keeps an object alive?

The closing question in a lot of senior Python rounds, and the one people are least ready for, because Python's memory management is usually invisible until a long-running worker starts growing.

CPython counts references. When the count of things pointing at an object drops to zero, it's freed immediately, which is why the memory behaviour is mostly predictable. Cycles are the exception: two objects referring to each other keep each other's counts above zero forever, so a separate cycle collector runs periodically to find groups that only reference each other. That's why a parent holding children that hold the parent is a real leak shape, and why a cache that never evicts is a leak with no cycle in it at all.

Where would you look if a worker's memory grows all day?

Junior answer: Probably a memory leak somewhere. I'd restart the workers periodically and look for anything obviously holding data, like a big list that keeps growing.

Senior answer: First I'd separate growth from a leak: memory that plateaus is usually fragmentation or a pool, while a straight line up is something accumulating. Then I'd look at the usual suspects in order: module-level caches and anything decorated with lru_cache on a method, which keeps every instance it was ever called on alive; long-lived containers keyed by request data; and objects with references from a closure or a registry nobody remembers registering. tracemalloc gives you allocations by line between two snapshots, which answers where it came from. Restarting workers is a real mitigation, and I'd still want the snapshot before I shipped the restart as the fix.

weakref is the tidy answer when something needs to observe an object without keeping it alive: caches keyed by object, parent pointers, and registries of live instances.

Common questions

Do I need to know Django or FastAPI specifics?

Know the one on the job description well enough to explain what it does for you: how a request becomes a handler, where validation happens, and how it talks to the database. Framework trivia is rarely the question. Framework behaviour under load usually is.

Is asyncio expected for a backend Python role?

You're expected to know what it's for and when it's the wrong tool, which is most of the value of the question. Deep asyncio internals only come up when the job is already built on it.

How much algorithm practice do I need for a Python interview?

It depends entirely on the company, and it's worth asking the recruiter. Product companies with an algorithm stage expect it. For most backend roles the round looks like this article: the language's behaviour, the data layer, and what happens in production. The technical interview prep guide covers the shape the rest of the round takes.

Will I be asked about packaging and dependencies?

Often, as a short practical question rather than a deep one: how you pin dependencies, what a lock file is for, and how the environment in CI matches production. Naming the tool you actually use and why is enough.

Does this overlap with a general backend round?

Heavily. Questions 3, 5 and 6 are backend questions that happen to be asked in Python, which is why those answers travel with you if you switch languages. The Python-specific half is questions 1, 2 and 4, plus the decorator.

Reading these is the easy half. The hard half is saying one out loud and holding up when the next question goes after the weakest part of your answer. Run a Python interview at your level. Practise a Python interview

How to pass a software engineering technical interview

Martin — Tue, 20 Oct 2026 10:07:00 +0000

Most engineers who fail a technical interview could have done the job. That gap, between being able to do the work and being able to demonstrate it in forty minutes under time pressure, is what this guide is about.

There is a specific kind of frustration in getting rejected from a role you know you could have done. You wrote the code they asked about last quarter. You have shipped the thing they are hiring for. And still the email arrives, three days later, saying they have decided to move forward with other candidates.

It usually isn't a knowledge problem. It's a demonstration problem. Interviews are a lossy channel, and the engineers who do well are the ones who have learned to push signal through it.

First, work out which round you are actually in

Candidates lose a surprising amount of ground by preparing for the wrong thing. A take-home rewards polish and tests. A live coding round rewards narration and recovery. A system design round barely cares whether your code compiles. And an AI screen, now the first filter at a growing number of companies, rewards something different again.

Before you prepare, get specific about the format. Ask the recruiter directly: how long, live or asynchronous, human or automated, coding or discussion, and what the interviewer will be looking at afterwards. Recruiters answer this question honestly almost every time, and almost nobody asks it.

Recruiter screen. Not technical, but it sets your level. Say the level you want out loud, early.
Automated or AI screen. A recorded or transcribed technical conversation, scored after the fact. See how AI technical screens actually work.
Live coding. Someone watches you write code. Narration and recovery matter as much as the solution.
Technical deep dive. A conversation about what you know and what you have built. This is where seniority gets decided.
System design. Usually senior and above. Judged on how you reason about scale, failure and trade-offs.
Behavioural or hiring manager. Ownership, conflict, judgement. Rarely the thing that sinks a strong technical candidate, but it can.

The second question decides the interview

Here is the pattern that shows up in almost every technical conversation. You are asked something reasonable. You answer it correctly. Then the interviewer asks a follow-up that goes one layer deeper into the exact thing you just said.

That follow-up is the interview. The first question is a doorway. The second one is the measurement, because it is generated from your own words, which means you cannot have rehearsed it and you cannot dodge it with a memorised paragraph.

So the useful preparation question is not "what will they ask me". It's "when I answer, what will they ask next, and can I go there". Read your own answers back and hunt for the words you used without being able to unpack them. Those are the words the follow-up will land on.

A test you can run on yourself tonight

Pick any topic you would claim on your CV. Explain it out loud for sixty seconds. Then ask yourself "why" about the last sentence you said, and answer that. Then do it again. Most people hit a wall on the third layer. That wall is exactly where an interviewer will find you.

What a strong answer is actually made of

Strong answers are not longer. Very often they are shorter. What they contain that weaker answers don't is a second layer: the mechanism underneath the definition, the condition where it breaks, and the trade-off you accepted.

Why do you use an index on that column?

Junior answer: Because it makes the query faster. Without an index the database has to scan the whole table.

Senior answer: That query filters on user_id and sorts by created_at, so it was doing a sequential scan plus a sort on about two million rows. A composite index on the two columns lets it seek and read in order, which took p95 from around 400ms to under 20ms. The cost is a slower write path and a few hundred megabytes, which was worth it here because the table is read far more than it is written.

Both answers are correct. Only one tells the interviewer that you have actually watched a query plan change.

The senior version does four things: it names the specific situation, it says what was happening underneath, it quantifies the effect, and it volunteers the cost. You can build that shape into any answer you give.

Lead with the answer in one sentence. Do not narrate your way toward it.
Say what is happening one level down, in the runtime, the database, the network, the browser.
Name the condition where your answer stops being right.
Say what you would measure to know.

Four sentences. It fits inside a normal answer, it works for almost any technical question, and it moves you out of the group that recites definitions.

Talk about trade-offs without hedging

"It depends" is the correct answer to a lot of interview questions and the worst possible way to say it. Hedging reads as evasion, and it is the most common way experienced candidates get scored down.

The fix is to commit first and qualify second. Pick the option you would actually ship, say why, then name the condition that would change your mind. "I'd start with the boring relational option, because the access patterns are simple and I get transactions for free. If write volume went past what one primary can take, I'd revisit it, and the thing I'd watch is replication lag." That is the same nuance, delivered as a decision instead of a shrug.

When you genuinely don't know

Everyone gets asked something they cannot answer. The difference between candidates is almost entirely in what happens in the next thirty seconds.

Do not go quiet, and do not bluff. Bluffing is the fastest way to lose an interviewer, because the follow-up will find you and now they are also questioning everything you said before. Instead, say what you do know, reason out loud from it, and be explicit about where your certainty stops.

Something like: "I have not used that directly. From how the surrounding thing works, I would expect it to behave roughly like this, and I would check that by trying this. Where I'd be least confident is here." You are showing them how you handle unfamiliar territory, which is a large part of what they are trying to find out.

The interviewer is not deciding whether you know everything. They are deciding whether they would be comfortable handing you something unfamiliar on a Tuesday and walking away.

A preparation plan that fits around a job

Most published prep advice assumes you have unlimited evenings. Here is a version that assumes you have about four hours a week and an actual life.

If you have four weeks

Week one: inventory. Write down every technology on your CV and rate your honest confidence one to five. Anything you rated three that you would be asked about is your target list, not the fives and not the ones.
Week two: depth on the target list. For each item, work down three layers of "why" until you hit the wall, then read until the wall moves. Two items an evening is plenty.
Week three: out loud, under follow-ups. Reading does not transfer to speaking. Practise answering with someone or something that pushes back on what you actually said.
Week four: format rehearsal. Run the specific round you are facing, end to end, at full length, with no pausing to look things up.

If you have one week

Cut weeks one and two to a single evening of honest inventory, and spend everything else on speaking. The bottleneck for experienced engineers is almost never knowing, it's retrieving under pressure and shaping the answer, and that only improves by doing it out loud.

The one habit worth more than the rest

Answer out loud, to something that asks you a real follow-up, and then look at what you actually said. Silent reading feels like progress and is the least transferable form of practice there is.

Practice that transfers, and practice that doesn't

Grinding algorithm puzzles transfers to interviews that are algorithm puzzles. If you are facing a senior deep dive about the systems you have built, five hundred puzzle problems will not help you, and a lot of engineers discover this the expensive way.

Match the practice to the round. If the round is a conversation, practise conversation. If it is a whiteboard design, draw and defend designs. If it is a live coding session, write code while narrating, because the narration is genuinely half the assessment and it is awkward the first three times you try it.

On the day

Test your microphone on a recording, not in your head. Bad audio costs you points you will never see deducted.
Have water, and use the pause it buys you.
Take two seconds before answering. Silence feels much longer to you than to them.
If you realise mid-answer that you were wrong, say so immediately and correct it. Self-correction reads as strength, right up until it arrives too late to look voluntary.
Ask what they are worried about with your profile, near the end. The answer is useful, and the willingness to ask reads well.

The honest summary

You pass technical interviews by being able to go one layer deeper than the answer you just gave, on the topics you actually claim. Not by memorising questions, and not by knowing more things. Find your walls before an interviewer does, and move them.

Common questions

How long should I prepare for a technical interview?

For most working engineers, two to four weeks at a few hours a week is enough, provided the time goes on speaking rather than reading. If you are switching stacks or levels, give it longer.

Do I need to grind algorithm problems?

Only if you are facing algorithm rounds, which is mostly large product companies and new-grad pipelines. For senior screens built around your own experience, that time is better spent on depth in the technologies you claim.

What if I go blank in the interview?

Say so, out loud, and start from something adjacent that you do know. Interviewers are far more tolerant of a visible recovery than of a long silence or a confident guess that unravels.

Is it bad to say I don't know?

No, as long as it is followed by reasoning rather than a full stop. The failure mode is not admitting a gap, it is having nothing to say about how you would close it.

The fastest way to find your walls is to be asked follow-ups on your own answers. Run a practice interview at your level and see where the second question lands. Try a practice interview

The same question, answered by a junior and a senior: eight examples

Martin — Wed, 09 Sep 2026 09:50:00 +0000

Seniority in an interview is not measured by how much you say. Every answer below is correct. Only one of each pair gets you the offer, and the difference is smaller and more learnable than most people expect.

When engineers ask what a senior answer sounds like, they usually get told to be more confident, or to talk about impact. That advice is not wrong but it is unusably vague.

Here is something more concrete. In pair after pair below, the senior answer differs in the same four ways: it names the mechanism underneath, it points at a specific situation rather than the general case, it volunteers the cost, and it says what it would measure. Nothing else. Once you can see it, you can do it.

1. JavaScript closures

What is a closure?

Junior answer: A closure is a function that remembers the variables from the scope where it was defined, so it can still use them later even after that function has returned.

Senior answer: It is a function together with a reference to the scope it was created in, so the variables it captured stay alive on the heap instead of dying with the call. That is what makes module patterns and hooks work, and it is also the classic memory leak: hold a closure over something large in a long-lived handler and it is never collected. It also explains the loop bug people hit with var, since one shared binding gets captured instead of one per iteration.

The follow-up here is almost always the loop bug or the leak. If you volunteered both, you have already answered it.

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// 3, 3, 3 -- one binding of i, shared by all three closures

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// 0, 1, 2 -- let creates a fresh binding per iteration

The version of this that gets shown in interviews. Knowing that it prints 3, 3, 3 is table stakes; being able to say why in terms of bindings is the answer.

2. React re-renders

How would you fix a slow React page?

Junior answer: I would wrap the expensive components in memo and use useMemo and useCallback so they do not re-render unnecessarily.

Senior answer: First I would find out whether it is actually a render problem. The profiler tells you whether you are re-rendering too often, rendering too much at once, or blocking on something that is not React at all. On the last page I did this for, it was a context holding a new object every render, so every consumer re-rendered on every keystroke. Splitting the context fixed it. I reach for memo after measuring, because sprinkling it everywhere adds comparison cost and a lot of stale-closure bugs for people who do not read the dependency arrays.

The junior answer invites 'and what does memo compare?'. The senior one has already moved the conversation to diagnosis, which is where they wanted to be.

3. The Node event loop

Why is Node considered good for I/O heavy work?

Junior answer: Because it is non-blocking and asynchronous, so it can handle many requests at once without waiting for each one to finish.

Senior answer: Because the I/O is handled off the main thread and the callbacks come back to a single loop, so thousands of connections cost you very little while they are just waiting. The flip side is that anything CPU bound on that thread stops everything. I have watched a synchronous JSON parse of a large payload add hundreds of milliseconds to every concurrent request on the process, which does not show up in local testing at all. That work belongs in a worker or a different service.

The senior answer contains its own failure mode, which is exactly what the next question was going to be.

4. Database indexes

When would you add an index?

Junior answer: When a query is slow, or on columns you filter and join on, to avoid scanning the whole table.

Senior answer: When the plan shows a scan or a sort that the query does not need, and the table is big enough for it to matter. The order of the columns is the part people miss: an index on a filter column plus a sort column only helps if the leading column is the one you filter on. And the cost is real, every write maintains every index, so on a write-heavy table I have removed indexes to speed things up. I would look at the plan before and after rather than guessing.

Composite column order is the standard follow-up, and it filters out a lot of people who have only read about indexes.

5. REST and retries

What does idempotent mean and why does it matter?

Junior answer: It means making the same request more than once has the same effect as making it once. GET, PUT and DELETE are idempotent, POST is not.

Senior answer: It means the caller can safely retry, which matters because at some point they will. A network timeout does not tell you whether the write happened, so any client with retries will eventually double-submit. For payments we took an idempotency key from the client, stored it with the result on first use, and returned that stored result on a repeat. The interesting part is the race between two concurrent retries, which needs a unique constraint rather than a check-then-insert, because check-then-insert loses that race under load.

Naming the concurrent-retry race is the single strongest signal in this answer. It is what someone who has actually shipped this says.

6. Caching

How do you decide what to cache?

Junior answer: Data that is read often and does not change much, with a TTL so it stays reasonably fresh. Redis in front of the database usually.

Senior answer: I start from how wrong the data is allowed to be, because that decides everything else. Something a user just edited needs to be right immediately, so that is invalidation on write, not a TTL. A dashboard aggregate can be a minute stale and nobody notices, so that is a TTL and it is simple. Where I am careful is the stampede, since when a hot key expires every request goes to the database at once, which is a fun outage. Either you serve stale while one request refreshes, or you lock the refresh.

Cache stampede is the follow-up. It is also the thing that turns a caching layer into an incident, which is why it gets asked.

7. Testing

What is your testing strategy?

Junior answer: Unit tests for functions, integration tests for how the pieces fit, and end to end for the critical user flows. Aim for good coverage.

Senior answer: I want most of my confidence coming from tests that exercise real boundaries, so integration tests over the actual database rather than a mocked one, because most of the bugs I have shipped lived in that boundary. Unit tests for genuine logic, and a very small number of end to end tests over the flows that lose money if they break, because those are slow and flaky and a suite people ignore is worse than no suite. Coverage percentage I mostly do not care about, it is easy to hit eighty percent while testing nothing that matters.

Pushing back on coverage as a metric, with a reason, reads as experience. Doing it without a reason reads as contrarianism.

8. Storing passwords

How do you store user passwords?

Junior answer: Hashed and salted, never in plain text. Using bcrypt rather than something like MD5 or SHA-256.

Senior answer: With a deliberately slow, memory-hard hash, so bcrypt or argon2, with the work factor tuned to what the login path can afford and revisited as hardware gets cheaper. The point of slowness is that offline cracking after a dump is the real threat model, not the hash itself. Salts are per user and stored with the hash, that is what stops one rainbow table covering everyone. I would also make the failure path constant time, because a login that is measurably faster for unknown users leaks which accounts exist.

The timing side channel is not obscure trivia. It is the marker of someone who thinks about attackers rather than about checklists.

What all eight have in common

Read the senior column again and the pattern is repetitive, almost formulaic.

A mechanism. Not what it does, what is happening underneath that makes it do that.
A specific instance."On the last page I did this for" beats "generally you would", every time.
A volunteered cost. Every choice loses something. Saying what you gave up is the clearest seniority signal there is.
Something measurable. What you would look at to know if you were right.

Notice what is absent. No extra length. No jargon the junior answer lacked. No claim to have worked somewhere impressive. Several senior answers are barely longer than their junior counterpart, and one is shorter.

Interviewers are not listening for the definition. They are listening for whether you have been on the other side of the definition when it went wrong.

How to convert your own answers

Take an answer you would give today and run it through four questions. What is happening one level down. When did I actually see this. What did it cost. How would I know. If you cannot answer the second one for a topic on your CV, that topic is a risk, and it is better to find that out tonight than in the interview.

The uncomfortable part is that you cannot do this by reading. You find your walls by being asked, out loud, and then being asked again about whatever you just said. That is the whole reason the follow-up question exists, and it is the thing worth practising.

Common questions

What if I have not worked on systems big enough to have these stories?

Use the scale you actually had and be honest about it. A specific story about a small system reads far better than a vague story about a large one, and interviewers can tell the difference immediately.

Should I volunteer the trade-off even if they did not ask?

Yes. It is the highest-value sentence in most answers, and it usually steers the follow-up onto ground you have already thought about.

Does this apply to junior interviews too?

The mechanism and the measurement parts do. Nobody expects a junior to have production war stories, but explaining what is happening underneath is available to anyone at any level.

Reading the difference is easy. Producing it under a follow-up is the hard part, and it is the only part that counts. Run a practice interview and see which column your answers land in. Test your answers

How senior engineers pass hard technical interviews and land big offers

Martin — Fri, 04 Sep 2026 11:44:00 +0000

Two engineers with the same years and the same stack sit the same loop. One gets a mid-level offer, one gets senior with a materially larger package. The gap is rarely knowledge, and it is almost never luck.

The level decision is usually made from a handful of moments across the loop, and the same moments come up every time. Once you know which ones they are, they are practisable.

None of what follows is about sounding impressive. Most of it is about being more specific than the person interviewing you expected.

They answer the question that was asked

It sounds trivial. It is the most common gap between a good engineer and a good interview.

Asked how something works, a mid-level candidate frequently describes a project where they used it. Asked how they would approach a problem, they describe how their previous team did it. Both are relevant and neither is an answer. Senior candidates answer the question directly in one sentence, then use the project as evidence.

The one-sentence rule

Whatever the question, your first sentence should be a direct answer to it. Context, history and caveats go after. Interviewers form an impression in the first fifteen seconds of an answer, and a preamble spends all of them.

They scope before they solve

Given an open-ended problem, less experienced candidates start solving. Senior candidates spend the first minute deciding what problem they are solving: who uses it, what the volumes are, what is explicitly out of scope.

This reads as senior because it is the thing senior engineers actually do at work. Half the value of an experienced engineer is refusing to build the wrong thing efficiently. An interviewer who watches you narrow a vague problem into a specific one has seen the skill demonstrated rather than claimed.

They volunteer the cost

This is the highest-value habit on the list and the easiest to adopt today.

Every technical decision loses something. Candidates who present only the upside sound like they are selling. Candidates who name the downside before being asked sound like they have lived with the decision. It also steers the follow-up onto ground you have already thought about, which is a real tactical advantage on top of the signal.

Why did you choose that message queue?

Junior answer: It is reliable and scales well, it integrates with everything we were already using, and the team had experience with it so we could move quickly.

Senior answer: Mostly because we already ran it and the operational knowledge was there, which for a team of four mattered more than any feature comparison. The cost is that it is heavier than the problem needed, we were using a fraction of it, and the ordering guarantees we relied on only hold per partition, which caught us out once. If I were starting again at that size I would probably have used something simpler and revisited when the volume justified it.

The second answer includes a mistake and is stronger for it. Interviewers read self-criticism as calibration, not weakness.

They have numbers

"It was quite slow, so we optimised it and it got a lot better" and "p95 was about 800ms, we found it was N+1 queries in the serialiser, and it came down to roughly 90ms" describe the same work. Only one of them is evidence.

You do not need exact figures and nobody is checking. Approximate numbers, offered confidently, are the difference between a story and a claim. Before an interview, go through your two or three main projects and attach rough numbers: traffic, data size, team size, latency, how long it took.

They handle pushback without folding or digging in

At some point an interviewer will disagree with you, sometimes about something you got right. This is deliberate, and both obvious responses are wrong.

Folding immediately suggests the position was never reasoned. Refusing to move suggests you would be difficult to work with, which is a much more expensive conclusion. The senior move is to restate why you chose it, engage with the specific counter-argument, and then either hold with a reason or concede with a reason. "That is a better point than mine, because your version handles the failure case and mine does not" is a strong sentence to be able to say out loud.

They are precise about what they did not do

Experienced interviewers listen for the boundary between what you did and what happened around you. Vague ownership is the fastest way to get downlevelled, because it invites the assumption that you were adjacent to the work rather than doing it.

Say which part was yours plainly. "I owned the ingestion side, another engineer did the query layer, and the migration plan was mine" is far stronger than a we-shaped answer, and it makes everything else you claim more credible.

They know their own edges

Nobody expects a senior engineer to know everything, and pretending to is disqualifying in a way that not knowing is not.

The strong pattern is: state what you do know, reason from it, and mark exactly where your certainty stops. That last part is what makes the rest of your answers trustworthy. An engineer who never signals uncertainty gives the interviewer no way to calibrate anything they said.

Interviewers are not looking for someone with no gaps. They are looking for someone whose confidence tracks their actual knowledge.

The part that decides the number

The offer is set by the level, and the level is usually argued for in a debrief conversation you are not in. Someone has to make the case, and they can only use what you gave them.

That is why specificity matters so much more than polish. "They were solid" loses the argument. "They caught the duplicate-write problem before I asked, and they had a real reason for the storage choice" wins it. Your job in the interview is to hand your advocate concrete sentences.

State the level you are targeting to the recruiter early, before the loop is built.
Give at least one story where you owned a decision, not just an implementation.
Give at least one where something went wrong and you say what you learned.
Make sure every interviewer hears at least one number.
Ask, near the end, what would make them hesitate. It is useful, and the willingness to ask reads well.

What this does not require

It does not require a FAANG background, a large team, or a system with millions of users. A specific story about a small system consistently beats a vague story about a large one, and interviewers can tell the difference instantly.

What it does require is having gone one layer deeper on the things you claim, which you can find out about yourself in an evening. The junior and senior answers to eight common questions are a concrete version of the same gap.

Common questions

Can I ask for a higher level than the one I was screened for?

Yes, and it is much easier before the loop is scheduled than after. Say the target level to the recruiter and ask what evidence the panel will want for it.

Does years of experience decide the level?

It sets expectations and rarely decides. Ownership, judgement and the ability to defend decisions move the level far more than the date on your CV.

Is it risky to admit something went wrong?

The opposite, provided you say what changed as a result. A candidate with no failures either has not owned much or is not being straight.

Every habit here shows up under follow-up pressure, which is exactly what a practice interview reproduces. Run one at senior level and see which of them you actually do. Practise at senior level

The follow-up question is the interview

Martin — Tue, 01 Sep 2026 11:00:00 +0000

You can prepare an answer. You cannot prepare the question that comes after it, because it is assembled from the exact words you just used. That is the whole design, and it is why memorising answers stops working above a certain level.

Watch a good technical interviewer and the pattern is always the same. They ask something broad. You answer. Then they pick one phrase out of your answer and ask about that. Then they do it again.

Three questions in, you are somewhere no preparation could have anticipated, discussing a specific thing you personally raised. That is not a hostile technique. It is the only reliable way to tell the difference between someone who has read about a thing and someone who has used it.

Why interviewers do this

Because first answers are cheap. Anyone can learn what a database index is, what a closure is, what eventual consistency means. Definitions are freely available and memorising them takes an evening.

What is not freely available is the second layer: why it works that way, what it costs, when it stops being true. That knowledge mostly comes from having been burned, and it is exactly what the follow-up is fishing for. An interviewer who only asked first questions would learn almost nothing about you.

The first question tests what you have read. The second tests what you have done.

How the drilling actually works

Follow-ups come in a small number of recognisable shapes. Once you can name them, they stop being a surprise.

The definition probe. You used a term. Now define it precisely. Triggered by any word you said without unpacking.
The mechanism probe. You said what happens. Now say why it happens, one level down.
The boundary probe. When does this stop being true? What would break it?
The cost probe. What did that choice lose you? Everything trades something.
The alternative probe. Why not the other approach? Testing whether you chose or defaulted.
The scale probe. What changes at a hundred times the volume?

You can rehearse against all six without knowing the topic. Take any answer you would give and ask yourself each of them in turn. Wherever you run out of road, that is a gap, and it is much cheaper to find it now.

Where the drill usually lands

There is a reliable pattern to which phrase gets picked. Interviewers drill on the words that carry the most meaning per syllable, because those are where a candidate is most likely to be borrowing language rather than describing understanding.

If you say a system is eventually consistent, expect to be asked what a user sees during the window. If you say you added a cache, expect invalidation. If you say you used a queue, expect what happens when consumers fall behind. If you say something is thread-safe, expect to be asked what makes it so. These are not obscure follow-ups. They are the obvious next question, which is precisely why they get asked.

The audit worth doing before any interview

Read your own prepared answers and underline every noun phrase you would not want to be asked to unpack. That underlined list is your interview. Nothing else on the page matters nearly as much.

Four things to do when the drill lands

1. Slow down rather than speed up

The instinct under pressure is to talk faster and cover more ground, hoping something lands. It reliably makes things worse, because more surface means more things to drill into. Take two seconds and answer the specific thing asked.

2. Answer the narrow question, not the broad one

A follow-up is deliberately narrow. Retreating to the general topic is a visible dodge, and interviewers read it as one. If you are asked what happens to in-flight requests during a deploy, talk about in-flight requests, not about your deployment philosophy.

3. Say where your certainty ends

"I know it holds the lock for the duration of the transaction. What I am less sure about is whether that is per row or escalates, and I would check that before relying on it." That sentence costs nothing and buys a lot, because it tells the interviewer your confidence is calibrated. Once they believe that, everything else you said gets more weight, not less.

4. Never invent a mechanism

This is the one genuinely unrecoverable move. If you make up how something works and the interviewer knows, the round is effectively over, and worse, everything you said earlier is now suspect. Reasoning aloud from what you do know sounds completely different from bluffing, and interviewers can tell the two apart easily.

What a good recovery sounds like

You mentioned the index made it faster. Why is a B-tree index faster for a range query than a hash index?

Junior answer: Because B-trees are the standard index type and they are optimised for lookups, so the database can find the rows much more efficiently than scanning. Hash indexes are older and generally slower for most queries.

Senior answer: Because a B-tree keeps keys in sorted order, so a range query seeks to the start and then walks sequentially. A hash index scatters keys by hash, so there is no ordering to walk and a range means checking everything. Where I am less certain is the exact page-level behaviour, but the ordering property is the part that matters for the range case.

The second answer contains an admission of uncertainty and is much stronger. The first is confidently wrong about hash indexes, and the interviewer now doubts the original claim too.

How to practise for an unpredictable question

You cannot rehearse the specific follow-up. You can absolutely build the depth it lands on, and you can practise the shape of a good response.

List every technology you would claim in an interview.
For each, write the answer you would give to the obvious first question.
Run the six probes above against that answer. Definition, mechanism, boundary, cost, alternative, scale.
Note where you run out. That is the real preparation list, and it is usually short.
Close those gaps by reading until you could answer two layers past them, then say it out loud once.

The out-loud part is not optional. Knowing something and being able to produce it under pressure, in order, in a sentence, are different skills, and only one of them gets tested. This is also why AI screens feel so much harder than they look: the follow-ups arrive without social brakes, so the drill goes one layer further than a polite human would push.

Common questions

How deep do interviewers actually go?

Usually until you stop being able to add anything, which is the point. Reaching the end of your knowledge is expected. How you handle arriving there is what gets scored.

Is it a bad sign if they keep drilling?

Normally the opposite. Interviewers drill hardest where they think there is something to find. A round with no follow-ups often means they stopped being curious.

What if I contradict something I said earlier?

Correct it immediately and out loud. A visible correction reads as rigour. Hoping nobody noticed does not work, and being caught later is much worse.

There is only one way to find out where your follow-ups run out, and it is to be asked. Run a practice interview and watch where the second question lands. Find your gaps

How to talk about trade-offs without sounding like you are hedging

Martin — Fri, 28 Aug 2026 12:50:00 +0000

Nuance is the thing that gets you levelled up, and hedging is the thing that gets you levelled down. They sound almost identical from the outside, and the difference is entirely structural.

Ask a junior engineer whether to use SQL or NoSQL and you get an answer. Ask a senior engineer and you often get "well, it depends", which is correct, and delivered badly it costs them the round.

The problem is not the nuance. It is the order. Hedging leads with the uncertainty and never arrives at a decision. Judgement leads with the decision and then shows the uncertainty around it. Same knowledge, opposite impression.

Why hedging reads badly

An interviewer is trying to answer one question: would I trust this person to make a call without me in the room. A candidate who lists options without choosing has actively failed to demonstrate the thing being assessed, no matter how well they understand the options.

There is a second, less obvious cost. Refusing to commit removes the interviewer's ability to go deeper. They cannot probe a decision you did not make, so the conversation stays shallow, and shallow conversations produce mid-level scores by default.

A candidate who says it depends and stops has told the interviewer nothing except that they know it is complicated. Everyone at this level knows it is complicated.

The four-part structure

This works for almost any technical choice you will be asked about, and it takes about twenty seconds to deliver.

Commit. Name what you would actually ship. One sentence, no preamble.
Justify. Give the specific reason, tied to the constraints in the question rather than to general virtue.
Cost. Say what you are giving up. Every choice loses something and naming it is the seniority signal.
Trigger. State the condition that would change your mind, and ideally what you would watch for it.

Notice that all the nuance from "it depends" is present. It is simply arranged behind a decision instead of in place of one.

Would you use a relational database or a document store for this?

Junior answer: It really depends on the use case. Relational is good for structured data with relationships and transactions, document stores are better for flexible schemas and horizontal scaling. There are trade-offs both ways, so it depends what matters most for the product.

Senior answer: I would start relational. The data here is clearly relational, orders belong to users and contain items, and I want transactions when money is involved rather than reinventing them. What I give up is schema flexibility, so every shape change is a migration, and that is a real cost on a fast-moving product. I would revisit if we hit write volume one primary cannot take, and the thing I would watch is write latency at peak rather than total row count.

The first answer is a textbook. The second is a decision, and the interviewer can now push on it, which is exactly what you want.

Getting the justification right

Most weak justifications are weak because they are general. "It scales better" is not a reason, it is a property. The strong version ties the choice to something in the question.

Weak: it is more performant. Strong: the read path is a hundred to one against writes here, so I optimise for reads.
Weak: it is more maintainable. Strong: this team is four people with no dedicated operations, so I want the option that is boring to run at 3am.
Weak: it is industry standard. Strong: we already run it, and the operational knowledge is worth more here than any feature difference.
Weak: it is more flexible. Strong: the requirements changed twice in the last quarter, so I want the shape that survives a third change.

Team size, existing stack, deadline pressure and operational maturity are all legitimate reasons and they are the ones real engineers actually use. Interviewers recognise them immediately as the voice of someone who has shipped.

Naming the cost is the whole move

If you take one habit from this piece, take this one. Candidates who present only the upside sound like they are selling something. Candidates who name the downside unprompted sound like they have lived with the consequence.

It is also tactically useful. The cost you name is usually the thing the interviewer was about to probe, so volunteering it moves the conversation onto ground you have already thought through, and it makes the rest of the answer more credible by demonstrating you are not overselling.

The sentence to practise

"What that costs me is X." Attach it to every technical decision you describe for a week and it becomes automatic. It is the single highest-return phrase in a senior interview.

When you genuinely need more information

Sometimes the honest answer really is that you cannot choose yet. That is fine, and there is a way to say it that still demonstrates judgement.

Name the specific fact that would decide it, say what you would pick under each branch, and then commit to a default. "The deciding factor is whether these writes need to be transactional across entities. If they do, relational, no question. If they genuinely do not, the document store buys us real flexibility. Without knowing, I default to relational, because that mistake is cheaper to unwind." You have shown the analysis and still made a call.

Handling the pushback

Commit to something and the interviewer will very likely argue with it. That is a good sign. It means there is now something to push on.

Two failure modes, both common. Folding instantly suggests the position was never reasoned. Refusing to move suggests you would be exhausting to work with, which is the more expensive conclusion of the two. What works is engaging with the specific counter-argument, and then holding or conceding with a stated reason.

"You are right that this breaks if the write volume is much higher than I assumed. If that is the constraint, I would go the other way" is a strong sentence. It shows the original position had conditions attached, which is what having judgement means. The same instinct is what system design rounds spend most of their time measuring.

Common questions

What if I commit to something and it is wrong?

You will find out, and adjusting cleanly in front of the interviewer scores better than never having committed. A wrong-but-reasoned position with a stated trigger is far more informative than a survey of options.

Does this apply when I genuinely have no experience with either option?

Yes, with the uncertainty stated. Reason from properties you do understand, pick the one you could operate, and say plainly which parts you would need to verify.

Is it arrogant to be this decisive?

Not when the cost and the trigger are attached. Arrogance is an unconditional claim. This structure is explicitly conditional, it just leads with the conclusion.

Trade-off reasoning only shows up when something pushes back on your answer. Run an architecture-flavoured session and see whether your decisions survive the second question. Practise defending decisions

React interview questions seniors actually get asked

Martin — Tue, 25 Aug 2026 14:51:00 +0000

Senior React interviews are rarely about API surface. They circle a handful of areas where a candidate either understands the rendering model or is pattern-matching, and the follow-ups find out which within about two minutes.

Nobody senior gets asked to list the lifecycle methods. What they get asked is why a page re-renders more than it should, why an effect fired twice, and why the app feels slow when every request is fast.

Here are the areas those questions come from, and what a strong answer contains.

What actually causes a re-render

The most common senior React question in any form, and the one that most reliably separates candidates.

A component re-renders when its state changes, when its parent re-renders, or when a context it consumes changes. That is the whole list. The part people get wrong is the second one: a child re-renders because its parent did, regardless of whether its props changed at all. Props are not an input to the decision, they are only an input to what the render produces.

Why is this component re-rendering when its props have not changed?

Junior answer: Because something in its props is changing identity between renders, so React sees a new value and re-renders it. Wrapping it in memo and memoising the props usually fixes it.

Senior answer: By default it re-renders because its parent did, and props do not come into it. Identity only matters once you wrap it in memo, at which point a new object or function prop defeats the comparison, which is why memo so often changes nothing. Before reaching for memo I would find out why the parent is rendering that often, since that is usually the actual bug. On the last one of these I looked at, a context was holding a new object every render, so every consumer rendered on every keystroke.

The follow-up is always what memo actually compares. Answer one gets stuck there.

Effects, and why they are the biggest source of bugs

Expect at least one effect question. The strong framing is that an effect is for synchronising with something outside React: a subscription, a timer, an imperative browser API. Most of the time, a bug that arrives with an effect is a sign the work did not belong in one.

Derived state in an effect. Computing state from props inside an effect causes an extra render and a frame of stale UI. Compute it during render instead.
The stale closure. An effect captures the values from the render it ran in. Miss a dependency and it quietly reads an old value forever, which is the single most common React bug in production code.
Missing cleanup. Subscriptions, intervals and in-flight requests need a cleanup function, or you get leaks and out-of-order responses overwriting newer ones.
Fetching in an effect without cancellation. Two quick navigations and the slower response wins. Interviewers ask about this specifically.

If you can explain why an effect that fetches needs to handle its own obsolescence, you are well past the median candidate.

Keys

Looks like a beginner topic, is not. Everyone knows keys should be stable and not the array index. Far fewer can say what actually goes wrong.

Keys tell React which element in the new list corresponds to which element in the old one. With index keys, deleting the first item means every element shifts, so React reuses the wrong instances: state stays attached to the wrong row, inputs keep the wrong value, animations play on the wrong element. The list still looks right until the components hold state, at which point the bug is bizarre and hard to trace.

{rows.map((row, i) => (
  <EditableRow key={i} row={row} /> // index key: identity shifts on delete
))}

{rows.map((row) => (
  <EditableRow key={row.id} row={row} /> // stable identity survives reorder
))}

The bug that makes this concrete: remove the first row and the text input's value follows the wrong item, because index keys made React reuse the wrong instance.

Where state should live

Architecture questions in a React interview are usually really state-ownership questions. Expect some version of how you would structure state in a large application.

The answer that reads as senior starts by separating server state from client state. Data that lives in a database and is cached in the browser has completely different needs from whether a dropdown is open: it needs revalidation, deduplication and staleness handling, none of which a general state container gives you. Once you say that out loud, the question of which global state library to use mostly evaporates, which is exactly the point being tested.

Then colocate the rest. State should live at the lowest common ancestor of the components that use it, and lifting everything to the top is a performance and maintenance problem disguised as tidiness.

Performance, properly

The weak answer to any performance question is a list of memoisation hooks. The strong answer starts with diagnosis, because the three causes have different fixes and applying the wrong one wastes a sprint.

Rendering too often: a context or a parent updating more than it should. Fix the source, then memoise if it still matters.
Rendering too much at once: a large list. Virtualise it. No amount of memoisation helps here.
Not a React problem at all: a slow request, a large bundle, an expensive synchronous computation blocking the main thread.

Mention that memoisation is not free, since every memo adds a comparison and a dependency array that can be wrong, and you have said something most candidates do not.

The question behind the question

When an interviewer asks about performance, they usually want to know whether you measure. Saying which tool you would open and what you would look for first is worth more than any list of optimisations.

Rendering on the server

Increasingly standard in senior frontend rounds, and a place where a lot of otherwise strong candidates are vague.

Be able to say plainly what runs where, what hydration actually is and why a mismatch happens, and why moving data fetching to the server changes the waterfall problem. The interesting follow-up is usually about anything time or locale dependent, since a date formatted with the server's timezone and then re-rendered in the browser's is the classic mismatch, and explaining that specific case demonstrates real experience.

How to prepare

Take a component you have written and answer three questions about it. When does it re-render. What would happen if this effect's dependency array were wrong. Where would this fall over with ten thousand rows.

That exercise finds gaps faster than any question list, because it produces the layer underneath the answer, which is where the follow-up will land.

Common questions

Do I need to know class components?

Enough to work in a codebase that has them, and to talk about migration. Nobody senior is being tested on lifecycle trivia.

How much state library knowledge is expected?

Less than people think. What is expected is the reasoning about which state is server state, which is local, and why that distinction decides the tooling.

Are React internals fair game?

Reconciliation and the rendering model, yes, because they explain behaviour you hit in practice. Fiber implementation details, rarely, and an interviewer who leads with them is testing something other than your ability to do the job.

The fastest way to find out whether your React answers hold up is to be followed up on them. Run a React-focused interview at your level. Practise a React interview

Node.js interview deep dive: what they are really testing

Martin — Mon, 24 Aug 2026 06:19:00 +0000

Almost every senior Node question is the same question wearing a different hat: do you understand that there is one thread doing your work, and do you know what happens when you block it.

Node interviews look varied and are not. Streams, timers, clustering, memory, async error handling: pull on any of them and you end up at the event loop, which is why interviewers use them as entry points.

The event loop, said properly

The definition everyone gives is that Node is non-blocking and asynchronous. True, and it does not demonstrate anything. The useful version explains the division of labour.

Your JavaScript runs on one thread. Input and output does not: it is handed to the operating system or to a thread pool, and when it completes, the callback is queued back onto that single thread. That is why thousands of idle connections cost almost nothing, and it is also why one expensive synchronous function stops every other request on that process, not just the one it belongs to.

What happens if a request handler does something CPU-heavy?

Junior answer: It will be slower and could block other requests, so you should avoid heavy computation in Node and move it to a background job or a different service.

Senior answer: It stalls the whole process for its duration, because there is one thread running JavaScript, so every other in-flight request waits behind it even though they are doing nothing. It also never shows up in local testing where you are the only user. I have watched a synchronous parse of a large payload add a few hundred milliseconds to every concurrent request. The fix is a worker thread if it is genuinely CPU work, or streaming it if the size is the problem.

Naming the concurrency effect, and the fact that it hides locally, is what makes this an operator's answer.

Where the ordering questions come from

Expect at least one question about what runs before what. The point is not trivia, it is whether you know microtasks and macrotasks are different queues.

A resolved promise callback runs before a timer that was already due, because the microtask queue is drained completely between each phase. The practically important consequence is that a recursive chain of promise callbacks can starve the loop entirely, and the process will look alive while serving nothing. That consequence is the answer worth having, more than the ordering itself.

Streams and backpressure

The most reliable senior discriminator in a Node interview, because it is the thing you only learn by having run out of memory in production.

Reading a large file into memory and sending it works fine until the file is large or ten users do it at once. Streaming processes it in chunks. But the question interviewers actually care about is what happens when the consumer is slower than the producer, and the answer is that without backpressure the chunks queue in memory until the process dies.

// No backpressure: 'data' keeps firing regardless of whether res can keep up
source.on("data", (chunk) => {
  res.write(chunk);
});

// Backpressure honoured: pipeline pauses the source when the sink is full
await pipeline(source, transform, res);

The difference is not style. The first version buffers the entire response in memory when the client is slow; the second stops reading until the socket drains.

Say the words 'the writable returns false and you wait for drain', or simply use the pipeline helper and explain what it does for you, and you have answered a question most candidates talk around.

Async error handling

A favourite because there are several ways to lose an error silently, and each one is a real production incident someone has had.

An async function called without await. The promise rejects with nobody listening. The request has already returned 200.
Throwing inside a callback. Nothing up the stack catches it, because the stack it was called from is long gone.
A try/catch around a promise you did not await. It catches nothing and looks like it does, which is worse than no handler.
An error event on a stream with no listener. In Node this is not silent, it is fatal, which surprises people.

The strong closing point is what you do at the boundary: an unhandled rejection handler that logs and exits, with a supervisor restarting the process, because a process in an unknown state serving traffic is worse than a process that died cleanly.

Memory leaks

Usually asked as a debugging scenario rather than a definition: memory climbs over hours, what do you do.

The reasoning matters more than the tooling. Long-lived references are the cause: a module-level cache with no eviction, listeners added per request and never removed, closures held by a timer that outlives what it captured. Take two heap snapshots under load, compare, and look at what grew. Saying that you would compare snapshots rather than guess is most of the signal here.

Scaling a Node process

One process uses one core, so scaling means multiple processes, whether through the cluster module, a process manager or separate containers behind a load balancer.

The follow-up is what breaks when you go from one process to several, and it is always state. In-memory sessions, in-memory caches, in-memory rate limit counters and scheduled jobs all quietly assume there is exactly one of you. Naming that class of bug before being asked is a strong senior signal, and it is the same instinct system design rounds are testing.

The sentence that carries most Node answers

"There is one thread running my JavaScript, so the question is always what I am doing to it and for how long." Almost every Node follow-up can be reasoned from there.

Common questions

Do I need to know libuv internals?

No. You need the model: one JS thread, I/O offloaded, callbacks queued back. Internals only matter when they explain observable behaviour, like why file I/O uses a thread pool and network I/O generally does not.

Is the event loop question not a bit basic?

The question is basic. The follow-ups are not, and they are where the round is decided. Most candidates give a definition and cannot describe the consequences.

How much of this changes with worker threads?

It gives you a way to move CPU work off the main thread, so the model still holds, you just have more than one thread and a message boundary to reason about.

These questions all have a second layer, and that is where the round is decided. Run a Node-focused interview and find out where yours stops. Practise a Node.js interview

Database interview questions for backend engineers

Martin — Wed, 19 Aug 2026 11:21:00 +0000

The database section is where senior backend interviews get decided, because it is the hardest area to fake. You either have read a query plan or you have not, and the follow-ups find out quickly.

Almost everyone can write a join. Far fewer can say why the query is slow, what the index is doing, or what happens when two of these run at the same time. That gap is what the round is measuring.

Indexes, past the definition

The opening question is usually some form of when would you add an index. The definitional answer, that it avoids scanning the table, is table stakes. Three things separate a senior answer.

Column order in a composite index. An index on the filter column plus the sort column only helps if the leading column is the one you filter on. Reverse them and it is close to useless for that query. This is the single most common follow-up in the whole area.
The write cost. Every insert and update maintains every index on the table. On write-heavy tables, removing an index can be the optimisation.
Selectivity. An index on a boolean that is true for most rows will often be ignored, because scanning is cheaper than jumping around. Interviewers like this one because it shows you know the planner makes a decision.

The strongest habit is to talk about the plan rather than about intentions. "I would look at the plan, see whether it is a scan and a sort, add the index, and confirm the plan changed" is a different level of answer from "I would add an index on the where clause".

The N+1 query problem

Universal, because every ORM makes it easy and it is invisible in development where the list has four rows.

Be able to describe both the mechanism and the detection. One query fetches the list, then accessing a related field on each row issues another query, so a hundred rows becomes a hundred and one round trips. Each is fast, the total is not, and it degrades linearly with data you do not control. The tell in production is a request whose latency scales with page size while every individual query looks healthy.

An endpoint got slower as data grew. How would you find out why?

Junior answer: I would check the slow query log and add indexes to the columns being filtered on, and probably add caching if it is read heavy.

Senior answer: First I would look at whether one query is slow or many queries are being issued, because those have completely different fixes and the second one hides from a slow query log. If the count scales with the number of rows returned, it is N+1 and the fix is eager loading, not an index. If it is one slow query, then the plan tells me whether it is a scan, a sort or a bad join order. Caching I would consider last, since caching a query I have not understood usually just moves the problem and adds an invalidation bug.

Distinguishing one-slow-query from many-fast-queries is the whole diagnosis, and it is where most candidates skip straight to a fix.

Transactions and isolation

Expect at least one. The trap is reciting the four ACID letters, which demonstrates reading rather than experience.

What earns credit is being able to describe a concrete anomaly. Two requests read the same balance, both subtract from it, and one update is lost. Or a report reads a row twice inside one transaction and gets different values because another transaction committed in between. Then say which isolation level prevents which, and why nobody runs everything at the strictest level: it costs throughput and increases the chance of deadlocks and aborts.

The practical follow-up is usually about the read-then-write pattern. Reading a value in application code and writing a computed result back is a race unless the database is enforcing it, which is why a unique constraint, a conditional update or a select for update is the actual fix rather than checking first.

Locking and deadlocks

Asked as a scenario more often than a definition: your writes intermittently fail with a deadlock error, what is happening.

Two transactions taking the same locks in different orders is the classic cause, and the practical fix is to make the order consistent, keep transactions short, and not do slow work such as an external API call while holding a lock. Mentioning that last one tends to land, because it is the version of this bug that people actually ship.

Schema and migrations

Increasingly common in senior rounds, because it is where database knowledge meets operational judgement.

Normalise until you have a reason not to, and be able to name your reason for denormalising rather than presenting it as a default. Then the migration question: how do you change a schema without downtime.

Add the new column or table, nullable, deploying nothing that requires it.
Deploy code that writes both old and new.
Backfill in batches, not one large statement that locks the table.
Deploy code that reads the new path.
Stop writing the old one, then drop it in a later release.

That expand-and-contract shape is the answer, and knowing that a naive index creation can lock writes for the duration on a large table is the follow-up worth having ready.

Connection pooling

Quietly one of the most useful things to understand, and one of the least discussed in preparation material.

Connections are expensive and databases cap them, so applications hold a pool. The interview-relevant part is what happens when the pool is exhausted: requests queue, latency climbs everywhere at once, and it looks exactly like the database being slow while the database is comfortable. Being able to describe that misdiagnosis is a strong signal, because most people have chased it in the wrong direction at least once.

The habit that carries this whole area

Talk about evidence, not intentions. Reading a plan, comparing query counts, checking pool saturation. Candidates who say what they would look at outscore candidates who say what they would change.

Every one of these topics has a second layer, and the second layer is what gets asked. If you can only give the definition, that is worth knowing before the interview rather than during it, which is the audit worth running on yourself.

Common questions

How much SQL should I be able to write live?

Joins, aggregation with grouping, and usually a window function or a subquery. Perfect syntax is rarely the point; being able to explain what the query makes the database do is.

Do I need to know a specific database?

Know one properly and you can reason about the others. Interviewers care much more about depth in one than familiarity with four.

Is NoSQL knowledge expected?

Enough to say when you would choose it and what you give up. The strongest answer starts from access patterns, not from the label on the technology.

Database rounds are decided by the follow-up, not the first answer. Run a database-focused interview and see how far yours goes. Practise a database interview

Security questions every senior backend engineer should handle

Martin — Sun, 16 Aug 2026 14:57:00 +0000

You are not being interviewed as a security engineer. You are being checked for one habit: whether, while describing a system, you notice who could abuse it.

Security questions rarely arrive labelled. They show up as follow-ups inside an ordinary technical conversation, and the ones that matter come back to a single instinct: treating input as hostile and asking who this trusts and why.

Authentication and authorisation are different questions

Everyone can define the difference. The interesting part is that authentication bugs are rare and authorisation bugs are everywhere, because authentication is one well-tested code path and authorisation is a decision at every single endpoint.

The specific failure worth naming is trusting an identifier from the client. An endpoint that fetches a record by an id in the URL, checks that the caller is logged in, and returns it, is broken: the caller is authenticated and has no right to that record. Being able to describe that in one breath is more valuable than any definition.

Password storage

A near-guaranteed question, and one where a good answer takes fifteen seconds.

How do you store user passwords?

Junior answer: Hashed and salted, never plain text, using bcrypt rather than something like MD5 or SHA-256 because those are too fast and not designed for passwords.

Senior answer: A deliberately slow, memory-hard hash, so bcrypt or argon2, with the work factor tuned to what the login path can afford and raised as hardware gets cheaper. The slowness is the point, because the real threat is offline cracking after a dump rather than anything at login time. Salts are per user and stored alongside the hash, which is what stops one precomputed table covering every account. I would also keep the failure path constant time, since a login that returns measurably faster for an unknown email leaks which accounts exist.

The timing side channel is the follow-up. Volunteering it moves you into a different category of candidate.

Sessions and tokens

Expect a discussion of stateless tokens versus server-side sessions, and expect it to be a trade-off question rather than a right-answer question.

Stateless tokens avoid a lookup on every request, which is why they scale nicely. What they cost you is instant revocation: until it expires, a stolen token is valid, and there is no server-side record to delete. That is the whole trade, and the mature answer is a short access token plus a refresh token, with a deny list only on the paths where the risk justifies the round trip.

Never accept the algorithm from the token itself. Pin it server side.
Verify signature, issuer, audience and expiry, not just that it decodes.
The payload is readable by anyone holding it. Signed does not mean private.
Store it somewhere script cannot read it if you can, which usually means an httpOnly cookie rather than local storage.

Injection, and why parameterisation is the answer

Still asked, still worth answering precisely, because most candidates say escaping when the actual answer is separation.

A parameterised query does not clean the input, it sends the query and the data separately, so the database never parses user text as SQL. That distinction matters, because escaping is a filter that can be wrong and separation is structural. The same reasoning covers shell commands and any other interpreter: pass arguments, do not build strings.

// injectable: the value becomes part of the parsed statement
db.query("SELECT * FROM users WHERE email = '" + email + "'");

// parameterised: the value is never parsed as SQL
db.query("SELECT * FROM users WHERE email = $1", [email]);

The first version concatenates user input into the statement. The second sends the statement and the value on separate channels, so nothing in the value can change the query's structure.

XSS and CSRF, and why people mix them up

Worth being able to separate cleanly, because candidates routinely give the mitigation for one when asked about the other.

Cross-site scripting is untrusted content becoming executable in your page, and the defence is contextual output encoding plus a content security policy. Cross-site request forgery is another site causing the browser to make an authenticated request to yours, and the defence is a token the other site cannot read plus same-site cookies. One is about what runs in your page, the other is about who caused a request. If you have XSS, your CSRF defences are irrelevant, since the attacker is already running inside your origin, and saying that shows you understand the relationship rather than the labels.

Secrets

Usually asked practically: where do your credentials live. The expected answer is injected at runtime from a secret manager or the platform's environment, never committed, with rotation possible without a code change.

The follow-up worth preparing is what you do when a secret leaks. Rotate first, then work out the exposure, and assume anything committed to a repository is compromised permanently regardless of whether the commit was later removed. That last point is the one interviewers listen for.

Rate limiting and abuse

Increasingly common, particularly for anything with a login form or an expensive endpoint.

The reasoning to show is what you are limiting on and why. Per IP is easy and weak, since attackers rotate addresses and shared networks hurt real users. Per account protects against credential stuffing against one target. Both, at different thresholds, is usually the honest answer. The good follow-up is where the counter lives once you run several processes, which lands you back on shared state, the same problem scaling a Node process runs into.

What is actually being scored

Not a checklist. Interviewers are listening for whether you volunteer the abuse case unprompted, the same way you would volunteer a trade-off. Someone who says which endpoint they would attack first, in their own design, has demonstrated the instinct the round is looking for.

Common questions

How much security is expected from a normal backend role?

The common classes and a threat-model instinct. Nobody expects exploit development. Everybody expects you to notice that user input reaches a query.

Should I memorise the OWASP Top Ten?

Know the categories and be able to describe two or three properly. Reciting ten labels with no mechanism behind them is transparent and scores badly.

What if I have never worked on anything security sensitive?

Say so and reason from the systems you have built. Naming where you would be worried about your own past work is a strong, honest answer.

Security questions are almost entirely follow-up territory, which is where a definition stops helping. Run a security-focused interview and see where yours ends. Practise a security interview

AI engineering interview questions: retrieval, evaluation and everything that breaks

Martin — Fri, 14 Aug 2026 08:37:00 +0000

The field is young enough that nobody has ten years of experience, so interviewers weight engineering judgement heavily over tool familiarity. The questions are less about what you have used and more about how you would know it was working.

Almost every candidate has now built something with a language model. That means the demo no longer differentiates anyone, and interviews have moved to the parts that are hard: making retrieval actually relevant, knowing whether a change made things worse, and handling text you did not write.

Retrieval, past the diagram

Everyone can draw the pipeline: embed the documents, embed the question, find the nearest, put them in the context. Interviewers have seen it. The questions are all about what makes it work badly.

Chunking. Too small and a chunk loses the context that made it meaningful. Too large and the relevant sentence is diluted by everything around it. There is no universal size, and saying so with a reason is better than naming one.
Semantic search missing exact matches. Nearest-neighbour search is poor at identifiers, error codes and product names, which is why hybrid retrieval with a keyword component so often beats pure embeddings in practice.
Retrieving the wrong thing confidently. Similarity is not relevance. Something always comes back, whether or not anything useful exists.
Stale content. The index is a copy. What happens when the source changes is an operational question people forget to answer.

Users say the answers are often wrong. How would you debug that?

Junior answer: I would improve the instructions to the model, try a larger model, and adjust the temperature to make it more accurate and less prone to making things up.

Senior answer: First I would find out whether retrieval or generation is failing, because they need opposite fixes and guessing wastes a week. I would take a sample of the bad answers and look at what was actually retrieved. If the right passage was never retrieved, no amount of instruction tuning will help and the work is in chunking or hybrid search. If the right passage was retrieved and the answer still contradicted it, that is a generation and grounding problem. Before changing anything I would build a small set of question and expected-answer pairs, so I can tell whether the next change helped or just moved the failures somewhere I was not looking.

Splitting retrieval failure from generation failure is the single most useful diagnostic in this area, and most candidates skip straight to the model.

Evaluation, which is the real interview

If there is one topic that separates people who have shipped this from people who have prototyped it, this is it. Non-deterministic output means you cannot rely on the usual assertion-based safety net, and the temptation is to test by trying a few things and feeling good about them.

What a strong answer describes is a fixed evaluation set built from real failures, run on every change, with results compared rather than eyeballed. Then the honest caveats: automated judging is itself unreliable and needs spot-checking, and an evaluation set drifts away from real usage unless you keep feeding production failures back into it.

Say that you would add every reported bad answer to the set as a regression case and you have described the practice that actually keeps these systems from decaying.

Getting structured output reliably

A practical question because it is what most production integrations need. The model produces text; your code needs a shape it can rely on.

The expected answer has three parts: constrain the output where the platform supports it, validate against a schema on the way in rather than trusting it, and have a defined path when validation fails. That last part is where the follow-up goes. Retrying forever is a cost and rate-limit incident waiting to happen, so a bounded retry and then a fallback is the answer that shows you have run this in production.

The framing that lands

Treat model output as untrusted input, exactly like a request body from the internet. Validate it, bound it, and never let it reach anything consequential unchecked. That single sentence answers a surprising number of questions in this area.

Untrusted text and injection

Increasingly asked, and the answers separate people quickly.

The core problem is that instructions and data arrive through the same channel, so text from a document, a web page or a user message can contain something that reads as an instruction. There is no complete fix through wording alone, and a candidate who claims otherwise has not thought about it hard.

What actually reduces risk is architectural: keep untrusted content clearly separated from your own instructions, do not grant the system capabilities it does not need, require confirmation before anything consequential or irreversible, and validate any tool call before executing it. The mindset here is the same one a security round tests, applied to a component that is non-deterministic.

Cost and latency

Frequently the most practical section, and the one where product-minded engineers do well.

Cost scales with tokens, so long context is a per-request bill, not a one-off design choice. Latency scales with output length in particular, which is why streaming exists and why it changes perceived speed far more than raw model speed. The senior framing is routing: not every request needs the most capable option, and using a cheaper path for the easy majority is usually the largest available win.

Fine-tuning versus retrieval versus better instructions

A judgement question, and the wrong answer is reaching for fine-tuning first.

The distinction to draw is between knowledge and behaviour. If the system needs facts it does not have, that is retrieval, and fine-tuning is an expensive way to bake in something that will be stale next month. If it needs a consistent format or style, that is a case for tuning, once you have exhausted cheaper options. Being explicit that you would start with the cheapest reversible change is the signal.

Common questions

Do I need to know specific frameworks?

Much less than you would think. The field moves fast enough that interviewers weight reasoning about retrieval quality, evaluation and failure handling well above tool familiarity.

Is machine learning theory expected?

For an AI engineering role, usually not. Embeddings and why similarity is not relevance, yes. Gradient descent, rarely, unless the role is actually a modelling role.

How do I show experience if my project was small?

Talk about what went wrong and what you measured. A small project with a real evaluation set and a documented failure mode is stronger evidence than a large one with neither.

This area is almost entirely judgement under follow-up, which is exactly what a focused practice round exposes. Practise an AI engineering interview