DEV Community: Martin

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

How to actually practise for an AI technical screen

Martin — Tue, 11 Aug 2026 12:23:33 +0000

You can be good at technical interviews and still do badly at this one. In recent times, most software engineers have applied for a job only to receive a link that takes them to a platform such as Micro1 or Karat for an initial AI technical screen.

That is the part people underestimate. An automated screen is not a harder version of a phone screen; it is a different measurement, and most of the preparation that carries you through a human interview quietly stops working. Rapport does nothing. Reading the room does nothing. The recovery move where you notice a flicker of doubt and add "well, depending on the write pattern" does nothing, because nothing flickered.

What is left is the text of what you said.

This is a practice routine for that. Not a list of questions to memorise, because memorising questions is the failure mode, but a way to rehearse that matches what the round actually measures.

First, the one thing that changes everything

Your answers are scored as a transcript.

Every piece of advice below follows from that single fact. If you internalise nothing else, internalise that a human who likes you fills in your gaps and an automated score does not. A human hears half an idea, recognises the shape of the rest, and moves on. Automated scoring reads what is there.

So the bar moves from "did you know it" to "did you say it". Those feel like the same thing from the inside. They are not.

If you want the full breakdown of what happens minute by minute, we wrote that up separately in what actually happens in an AI technical screen. This post assumes you know the format and want to get better at it.

Practise out loud. Yes, really out loud

This is the whole routine in one line, and it is the step everyone skips.

Reading a question and thinking "yeah, I know that" is not practice. It is recognition, and recognition is a much lower bar than production. The gap between knowing something and saying it cleanly, in order, in about ninety seconds, under a timer, is enormous. It is also the entire thing being measured.

Say your answers to an empty room. Record them on your phone and play them back once, which is unpleasant and worth more than an hour of reading. You will hear three things immediately:

You start sentences you do not finish.
You say "basically" and "kind of" before every technical claim.
The strongest part of your answer arrived at the very end, after the listener had already scored the beginning.

None of those are knowledge problems. They are all production problems, and they only fix with reps.

Say the mechanism, do not imply it

Experienced engineers imply mechanisms constantly, because with another engineer it is faster and implying it is a status signal. In this round it reads as a gap.

Compare:

Yeah, you would not want to do that synchronously, it would block.

That call is synchronous, so it blocks the event loop. Node handles requests on a single thread, so while that runs, every other request on that process is waiting.

The first is what you would say to a colleague. The second is what gets credit. It feels like over-explaining. It is not over-explaining, it is the answer.

A useful test while rehearsing: after each sentence, ask whether a reader with no context could tell you understood the cause, or only that you knew the conclusion. Conclusions are cheap. Causes are the thing.

Prepare four projects, not twenty answers

Most people prepare topics. Prepare projects instead.

Pick four things you genuinely worked on. For each one, be able to state three things without hesitating:

The constraint. What actually forced the decision. Not "we chose Postgres because it is reliable", but what property you could not do without.
The alternative you rejected. And why it lost. An engineer who cannot name the road not taken usually did not make a decision, they inherited one.
One number. Request volume, dataset size, latency before and after, team size. One real number does more for your credibility than a paragraph of adjectives.

Those three things answer the overwhelming majority of follow-ups, because follow-ups are mostly just "why" pointed at whatever you said last. If you have the constraint, the alternative and the number ready, you have somewhere to go every time.

Drill the why-chain

Here is the drill that changes scores fastest.

Take one of your four projects. Say your answer out loud. Then ask yourself why, and answer. Then ask why again. Then a third time.

Almost everyone hits a wall on the third why. That wall is exactly where an automated follow-up will find you, and finding it in your kitchen is considerably better than finding it in the round. You do not need to eliminate the wall, you need to know where it is, so you can say "I do not know, here is how I would find out" deliberately instead of discovering it live.

Do this on four projects and you have covered most of what a thirty minute screen can reach.

Structure every answer the same way

Under pressure, structure is what stops you rambling. Use the same shape every time:

The answer, first. One sentence. Not a preamble, not a restatement of the question.
The mechanism. Why that is the answer, stated causally.
The trade-off or the limit. When it stops being true, or what it costs.

That third part is the one that separates candidates, and it is the one people leave out because it feels like undermining yourself. It is the opposite. Naming the limit of your own answer is the clearest available signal that you have actually used the thing rather than read about it.

Here is the same question with and without it.

Q: How would you speed up a slow endpoint?

Without: I would add caching. Probably Redis in front of the database, with a sensible TTL, and that usually takes most of the load off.

With: First I would find out where the time goes, because caching a slow query hides it rather than fixing it. If it is one N+1 query then an index or a join is the fix and caching is premature. If it is genuinely expensive and read-heavy, then a cache in front, and the real question becomes invalidation: a TTL is fine for data that can be stale for a minute, and not fine for anything a user just edited, because they will refresh and see their own write missing.

Same knowledge. The second one names a constraint, rejects an alternative, and admits a limit. It also cannot be produced by memorising an answer, which is precisely why it scores.

A realistic week

If you have a screen coming up and limited time:

Day 1. Pick your four projects. Write the constraint, the rejected alternative and the number for each. Twenty minutes.
Days 2 to 4. One project per day. Say it out loud, run the three-why drill, record one answer and listen back once.
Day 5. Rehearse the answer shape on unfamiliar questions, so structure survives surprise.
Day 6. Rest. Cramming the day before produces stiff, scripted answers, which collapse on the first follow-up.

That is roughly two hours total, distributed. Distribution matters more than volume here, because you are building a speaking habit rather than loading facts.

What not to bother with

Memorising answers. They survive the first question and fall apart on the second, which is the one that counts.
Rehearsing your confidence. Confidence with nothing underneath is the single easiest thing for a follow-up to expose.
Breadth. A screen samples a few areas. Being genuinely deep in the four things you actually work with beats being shallow across twelve, every time.

The short version

Practise out loud, say the mechanism instead of implying it, know the constraint and the rejected alternative and one number for four real projects, and find your third-why wall before the round does.

None of that is about being smarter. It is about making what you already know legible to something that will not meet you halfway.

I build PracticeDepth, an AI interviewer that asks senior-level questions across sixteen topics, then drills into whatever you just said until it finds your ceiling, and tells you where you actually stand. A practice run is free and takes about twenty minutes. It is a lot less comfortable than reading a list, which is the entire point.

Every interview question has a second question behind it. Here are 7

Martin — Mon, 10 Aug 2026 16:00:42 +0000

Interviewers rarely ask for the thing they want to know. They ask for something adjacent, cheap to answer, and easy to score, and then they listen to how you got there.

That is not a trick. It is the only practical way to run the interview. The stated question has an answer that is freely available and takes an evening to memorise. The question behind it does not, because answering that one requires having been on the wrong side of it at some point.

Below are seven snippets. Nothing exotic, nothing from a puzzle site. For each one: what gets asked, what is actually being measured, and the follow-up that arrives if you answer only the surface.

Read the code before you read the commentary. It is more useful that way.

1. The method that loses its object

class Rates {
  constructor(map) { this.map = map; }
  lookup(code) { return this.map[code]; }
}

const rates = new Rates({ EUR: 1.0, USD: 1.09 });

codes.map(rates.lookup);
// TypeError: Cannot read properties of undefined (reading 'EUR')

Asked: why does this throw?

Actually asked: do you know that this is decided by the call, not by where the function was written?

The answer that scores says the binding is resolved at call time from the receiver, and map calls the function with no receiver, so inside a class body (which is strict) this is undefined rather than the global object. Then it says what to do: .map((c) => rates.lookup(c)), or bind it, or make lookup an arrow-valued field so it closes over the instance instead.

The version that only says "you lost the this context" is correct and stops one layer short of where the question was aimed.

The follow-up: and what would the arrow field cost you? (One function per instance rather than one on the prototype, which is fine at almost any scale and worth being able to say out loud.)

2. The loop that is slow on purpose, or by accident

const users = [];
for (const id of ids) {
  users.push(await fetchUser(id));
}

Asked: what is wrong with this?

Actually asked: can you tell the difference between sequential-because-it-has-to-be and sequential-by-accident?

Most people say "use Promise.all" and that is where it ends. The stronger answer notices this only matters when the calls are independent, then volunteers the cases where the loop is right: each call depends on the last one's result, or the endpoint is rate limited and firing two hundred requests at once gets you a 429 and a slower total, or you are writing rows that have to land in order.

If you do fan it out, ids.map((id) => fetchUser(id)) and not ids.map(fetchUser), because map passes the index as a second argument and plenty of functions quietly accept one.

The follow-up: two hundred ids. Still Promise.all? (No. That is a concurrency limit, and being able to say so is most of the point of the question.)

3. The `Promise.all` that leaves money on the floor

const [charge, reservation, receipt] = await Promise.all([
  chargeCard(order),
  reserveStock(order),
  sendReceipt(order),
]);

Asked: what happens if reserveStock rejects?

Actually asked: do you know what happens to the other two?

Promise.all rejects on the first rejection, but it does not cancel anything. The card charge is still in flight and will still succeed, and you have just thrown away the only reference to its result. You now have a customer who has paid for stock you never reserved, and no handle on the charge id to refund it.

The answer that lands names the state you are left in, not just the control flow. Then it says what you would do instead: allSettled when you need every outcome, sequential when a later step depends on an earlier one committing, and a compensating action for the leg that already succeeded.

The follow-up: what shows up in your logs when the other two reject afterwards? (Unhandled rejections, because Promise.all already settled and nothing is attached to them any more.)

4. The `try` block that catches nothing

try {
  processQueue();
} catch (err) {
  logger.error({ err }, "queue failed");
}

Asked: why is nothing being logged?

Actually asked: do you understand that catch is about a stack frame, not about a block of text?

processQueue is async and is not awaited, so it returns a promise and the try block completes normally. The rejection arrives later, on a frame that no longer has this handler on it. Adding await fixes it. So does .catch().

This is worth being able to say precisely, because it is the same mechanism behind a catch that misses a setTimeout callback, a rejection inside an event listener, and half the "we have logging and we still cannot see the error" incidents.

The follow-up: what does Node do with that rejection now? (Crashes the process by default since v15, which surprises people who remember the warning.)

5. The floats holding money

const total = items.reduce((sum, i) => sum + i.price, 0);

if (total === amountPaid) {
  markAsPaid(order);
}

Asked: what is the bug?

Actually asked: do you know why it happens, and do you know where it stops being theoretical?

Everyone can recite 0.1 + 0.2 !== 0.3. The interesting part is that binary floating point cannot represent tenths exactly, the error is tiny per operation, and it accumulates over a reduce. The equality check is where it surfaces, but the corruption happened earlier, which is why a tolerance comparison is a patch and not a fix.

Store minor units as integers, or use a decimal type your database actually understands, and do the arithmetic there. Say which one you would pick and why.

The follow-up: so where do you do currency conversion, and at what precision? (There is no clean answer, which is exactly why it gets asked. They want to hear you reason about rounding direction and who absorbs the difference.)

6. The timestamp with no timezone

// schema
scheduledAt  DateTime

// write
await db.reminder.create({
  data: { scheduledAt: new Date("2026-03-29T02:30:00") },
});

Asked: what could go wrong here?

Actually asked: do you know that an instant and a wall-clock time are different types of thing?

That string has no offset, so it is parsed as local time on whichever machine ran it. Your laptop and the container in Frankfurt disagree. And 02:30 on 29 March 2026 does not exist in most of Europe, because the clocks go from 02:00 straight to 03:00 that morning.

"Always store UTC" is the memorised answer and it is not always right. An instant, like when a payment settled, is UTC and converted for display. A future wall-clock commitment, like a 09:00 recurring standup, has to be stored as local time plus a zone id, because if the zone changes its rules between now and then, the UTC instant you computed is wrong and the 09:00 is still 09:00.

The follow-up: the meeting was booked before a country changed its DST rules. What is in your database now? (This is the whole question. It is why the answer is a zone id and not an offset.)

7. The check that loses a race

const existing = await db.user.findUnique({ where: { email } });
if (existing) return existing;

return db.user.create({ data: { email } });

Asked: is this safe?

Actually asked: do you know that a read and a write are two separate moments?

Two requests arrive together. Both read, both find nothing, both insert. You now have duplicate users, and everything downstream that assumed one row per email is quietly wrong. It will not reproduce locally, and it will happen the first time a client retries on a timeout.

The answer that scores does not propose a longer if. It puts a unique constraint on the column and lets the database be the thing that arbitrates, then either catches the violation and re-reads, or uses an upsert. The database is the only place with a serialisation point. Application code cannot manufacture one.

The follow-up: what does your API return to the request that lost? (The existing row and a 200, most likely. Which is the same shape as an idempotency key, and that is usually where they take it next.)

The pattern, so you can do this yourself

Read those seven again and the second question is always one of a small number of shapes.

One level down. You said what happens. Now say what makes it happen.
What you were left holding. Not the control flow, the state after the failure.
When your answer stops being true. Every rule has a boundary, and naming yours unprompted is the strongest single move available to you.
What it cost. You picked something. Something else got worse.

You can run all four against any answer you would give, on any topic, without knowing what you will be asked. Wherever you run out of road on the second or third pass, that is a gap, and finding it tonight is much cheaper than finding it on a call.

The part that reading cannot fix

Here is the uncomfortable bit, and the reason lists like this one are less useful than they look.

Recognising the second question on a page you are reading calmly is not the same skill as producing the answer out loud, in order, in one breath, eleven minutes into an interview, immediately after someone has picked one phrase out of what you just said and asked you about that specifically.

Those are different skills. Only one of them gets tested. And the gap between them is not closed by reading more, because you cannot find the edge of your own knowledge by consulting it. You find it by being asked, and then being asked again about whatever you just said.

So: pick one topic you would claim on your CV. Say your answer out loud, to the wall if necessary. Then ask yourself the four shapes above, in order, and keep going until you run out. The place you stop is your interview.

If any of the seven above went a way you did not expect, I would genuinely like to hear it in the comments.