Top 30 Intermediate Backend Dev Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   In which event loop phase do the majority of completed I/O callbacks, such as a finished network read, actually execute?

   • aThe check phase, alongside setImmediate callbacks
   • bThe close callbacks phase, after the loop drains
   • cThe timers phase, right after expired setTimeout callbacks
   • dThe poll phase, which retrieves and runs I/O completions
   Show the answer

   Answer: d · The poll phase, which retrieves and runs I/O completions

   The poll phase retrieves new I/O events and executes most of their callbacks. The timers phase only handles elapsed setTimeout/setInterval, not I/O completion.

   Read the full bite: Order of the Node.js event loop phases

2. Question 2 of 30

   What mechanism triggers FastAPI to automatically validate and parse an incoming JSON request body against a schema?

   • aSetting the response_model argument on the route decorator
   • bUsing a Pydantic model as the type hint for a route parameter
   • cAdding an explicit validate decorator to the route handler
   • dManually calling json.loads on request.body inside the route function
   Show the answer

   Answer: b · Using a Pydantic model as the type hint for a route parameter

   FastAPI inspects function signature type hints at runtime, so using a Pydantic model as a parameter type hint automatically triggers request parsing and validation. Manually calling json.loads inside the route is a red flag that ignores this declarative mechanism, and response_model governs response serialization, not request validation.

   Read the full bite: How does FastAPI leverage Pydantic for request validation and serialization?

3. Question 3 of 30

   When a developer wants to abstract over a third-party type, which difference between Go interfaces and Rust traits is most significant?

   • aGo requires the third-party type's author to explicitly declare interface satisfaction, while Rust traits are satisfied automatically by matching method signatures.
   • bRust allows any consumer crate to implement a foreign trait for a foreign type without modification, making it more loosely coupled than Go.
   • cGo interfaces use nominal typing checked only at compile time with no runtime overhead, whereas Rust dyn Trait relies on runtime type information.
   • dGo lets a consumer define an interface that the third-party type implicitly satisfies, while Rust requires an explicit impl block to bind the trait to the type.
   Show the answer

   Answer: d · Go lets a consumer define an interface that the third-party type implicitly satisfies, while Rust requires an explicit impl block to bind the trait to the type.

   Go uses structural typing, so a consumer can define an interface that an existing third-party type automatically satisfies without any declaration; Rust uses nominal typing, requiring an explicit impl block. Distractor A reverses these exact mechanics, reflecting the common misconceptions that Go needs explicit declarations and that Rust traits are implicit.

   Read the full bite: Compare Go interfaces with Rust traits

4. Question 4 of 30

   When both are scheduled from inside a completed fs I/O callback, which runs first and why?

   • asetTimeout(fn, 0), because timers always precede check
   • bThey run simultaneously since both mean zero delay
   • csetImmediate, because the check phase follows poll in the same iteration
   • dprocess.nextTick, because it is also a macrotask
   Show the answer

   Answer: c · setImmediate, because the check phase follows poll in the same iteration

   From within an I/O callback the loop is in poll, so the next phase is check, making setImmediate fire before the timers phase comes around again. setTimeout(0) waits for the next iteration.

   Read the full bite: nextTick vs setImmediate vs setTimeout(fn, 0)

5. Question 5 of 30

   When building an async execution-time decorator for FastAPI, why is omitting functools.wraps on the inner wrapper considered a red flag?

   • aIt causes the wrapper to run synchronously, blocking the event loop during high-concurrency requests.
   • bIt strips the original function's metadata, which breaks FastAPI's OpenAPI schema generation and dependency injection.
   • cIt makes FastAPI treat the endpoint as synchronous, offloading it to a thread pool and skewing the timer.
   • dIt prevents the decorator from awaiting the original coroutine, leading to unhandled runtime warnings.
   Show the answer

   Answer: b · It strips the original function's metadata, which breaks FastAPI's OpenAPI schema generation and dependency injection.

   functools.wraps preserves the original function's name, signature, and metadata, which FastAPI relies on to generate OpenAPI docs and resolve dependencies; omitting it exposes the wrapper's metadata instead. Distractor A is wrong because wraps has no effect on whether code runs synchronously or blocks the event loop.

   Read the full bite: Write an async decorator that logs execution time for FastAPI

6. Question 6 of 30

   When is it appropriate to intentionally violate 3NF by duplicating a customer name in an orders table?

   • aWhen preventing transitive dependencies is the top priority
   • bWhen the orders table currently contains non-atomic repeating groups
   • cWhen read latency is critical and avoiding joins outweighs update anomaly risks
   • dWhen ensuring every attribute depends on the full primary key
   Show the answer

   Answer: c · When read latency is critical and avoiding joins outweighs update anomaly risks

   Intentionally violating 3NF trades update anomaly risk for faster reads by eliminating joins, which is appropriate in read-heavy workloads. The most tempting distractor confuses the goal of normalization—preventing transitive dependencies—with a reason to denormalize.

   Read the full bite: Describe 1NF, 2NF, 3NF, normalization's purpose, and its performance trade-off.

7. Question 7 of 30

   Why does wrapping a heavy synchronous computation in an async function fail to keep a Node server responsive?

   • aThe computation is still synchronous and never yields the single JS thread
   • bPromises lower the priority of CPU work in the loop
   • cAsync functions run on a separate OS thread automatically
   • dThe garbage collector preempts long Promises
   Show the answer

   Answer: a · The computation is still synchronous and never yields the single JS thread

   async/await only helps when there is an awaited asynchronous boundary; a synchronous CPU loop still occupies the single thread, blocking the event loop. Worker Threads provide real parallelism.

   Read the full bite: Offloading CPU-bound work with Worker Threads

8. Question 8 of 30

   Which implementation correctly minimizes total latency when a FastAPI endpoint must fetch data from two independent external APIs?

   • aInside an async def endpoint, pass two httpx.AsyncClient coroutines to asyncio.gather and await the result.
   • bInside an async def endpoint, pass two synchronous requests.get calls to asyncio.gather and await the result.
   • cInside an async def endpoint, await an httpx.AsyncClient call to the first API, then await a second call to the other API.
   • dInside an async def endpoint, run two synchronous requests.get calls concurrently using threading.Thread.
   Show the answer

   Answer: a · Inside an async def endpoint, pass two httpx.AsyncClient coroutines to asyncio.gather and await the result.

   asyncio.gather with an async HTTP client schedules both I/O-bound coroutines concurrently on the event loop, reducing total latency to roughly the slower call. Option C is tempting because it uses async/await correctly, but sequential awaiting means the second request cannot start until the first finishes, so latencies add up.

   Read the full bite: How do you structure concurrent API calls with asyncio.gather in FastAPI?

9. Question 9 of 30

   Which statement best captures the mechanical cost of maintaining multiple indexes on a write-heavy table?

   • aEach write requires updating only the indexes whose key columns changed, minimizing I/O for unrelated indexes
   • bThe database uses binary search trees for indexes, causing frequent full-tree rebalancing on every insert
   • cEvery table write typically triggers random I/O to update each index's B-Tree, plus node splits and log overhead
   • dIndexes are stored as hash maps, so range queries require full table scans but writes remain cheap
   Show the answer

   Answer: c · Every table write typically triggers random I/O to update each index's B-Tree, plus node splits and log overhead

   The card explains that every write likely updates every index, causing extra random I/O, node splits, and WAL overhead. Option B reflects the common misconception that binary search trees are the classic disk structure, while D confuses hash indexes with the standard B-Tree approach.

   Read the full bite: Explain database indexes, the classic data structure, and write-heavy trade-offs

10. Question 10 of 30

    When the Orders table may contain NULL user_ids, which statement correctly explains the safest way to find users who never placed an order?

    • aNOT IN is safe because SQL treats NULL as false in subquery comparisons.
    • bNOT EXISTS is preferred because it is immune to NULLs in the subquery and avoids duplicate rows.
    • cINNER JOIN with a not-equal condition can return users who have no matching orders.
    • dLEFT JOIN with IS NULL is safest because it automatically removes duplicate users from the result.
    Show the answer

    Answer: b · NOT EXISTS is preferred because it is immune to NULLs in the subquery and avoids duplicate rows.

    NOT EXISTS handles NULL values safely and stops at the first match per user, avoiding duplicate rows. Option D is tempting because LEFT JOIN is a common pattern, but it can inflate results when a user has multiple orders unless you add DISTINCT or GROUP BY.

    Read the full bite: Find users who never placed an order and explain JOIN choice

11. Question 11 of 30

    What core problem does committing package-lock.json solve that package.json alone cannot?

    • aIt makes installs faster by caching tarballs in the repo
    • bIt documents which packages are devDependencies
    • cIt guarantees every install resolves to the exact same dependency tree, including transitive packages
    • dIt prevents anyone from adding new dependencies
    Show the answer

    Answer: c · It guarantees every install resolves to the exact same dependency tree, including transitive packages

    package.json uses version ranges, so installs can drift; the lockfile pins exact versions and tree shape for all transitive deps, making installs deterministic. It does not store tarballs or block additions.

    Read the full bite: Why package-lock.json must be committed

12. Question 12 of 30

    Which accurately describes a key difference between Go's switch and Rust's match?

    • aGo switch can return a value directly to initialize a variable, while Rust match arms must end with an explicit break to prevent fallthrough.
    • bGo switch implicitly falls through and requires explicit break, while Rust match requires exhaustive patterns but allows fallthrough between arms.
    • cBoth Go switch and Rust match enforce exhaustiveness at compile time, but only Go allows implicit fallthrough for multiple case values.
    • dRust match is an expression that yields a value and requires exhaustive patterns, while Go switch is a statement with implicit breaks and no exhaustiveness check.
    Show the answer

    Answer: d · Rust match is an expression that yields a value and requires exhaustive patterns, while Go switch is a statement with implicit breaks and no exhaustiveness check.

    Rust match evaluates to a uniform value and the compiler rejects non-exhaustive patterns, whereas Go switch is statement-oriented, auto-breaks, and never checks exhaustiveness. Option B is tempting but wrong because Go implicitly breaks unless fallthrough is explicit, and Rust match arms never fall through.

    Read the full bite: Compare Go's switch with Rust's match on exhaustiveness, fallthrough, and expressions.

13. Question 13 of 30

    When writing a query that groups by department and filters on COUNT(*) > 10, why must the predicate be in HAVING rather than WHERE?

    • aHAVING and WHERE are logically identical, but HAVING is the conventional clause for grouped results
    • bWHERE is evaluated before GROUP BY, so the aggregate count does not yet exist
    • cHAVING is more efficient than WHERE for aggregate filters because it processes fewer rows
    • dWHERE can accept aggregate functions only if the identical expression also appears in the SELECT list
    Show the answer

    Answer: b · WHERE is evaluated before GROUP BY, so the aggregate count does not yet exist

    WHERE filters individual rows before grouping and aggregation occur, so aggregate values like COUNT(*) have not been computed yet and do not exist at that stage. Option D is wrong because repeating the aggregate expression in WHERE does not help; the aggregate still does not exist when WHERE is evaluated.

    Read the full bite: What is the difference between WHERE and HAVING in SQL?

14. Question 14 of 30

    Which statement about using ES Modules instead of CommonJS in Node is accurate?

    • aCommonJS supports top-level await but ESM does not
    • bYou can require an ESM-only file directly from a CommonJS module
    • cimport is just an alias for require with identical semantics
    • dESM lacks __dirname by default and is enabled via type module or .mjs
    Show the answer

    Answer: d · ESM lacks __dirname by default and is enabled via type module or .mjs

    ESM omits __dirname and require, and is enabled by type module or the .mjs extension. import is not an alias for require, and only ESM supports top-level await.

    Read the full bite: Choosing between CommonJS and ES Modules

15. Question 15 of 30

    When passing a string to a function by value, why is Go's operation cheap while Rust's String may require explicit cloning?

    • aRust &str is an owned growable buffer that allocates on every function call, while Go strings are fat pointers that share mutable heap data.
    • bBoth languages copy the entire heap buffer on pass-by-value, but Go's garbage collector makes the operation appear cheaper.
    • cGo strings are small two-word headers copied by value with immutable backing data, whereas Rust String moves ownership and must be cloned to duplicate its heap buffer.
    • dGo strings use copy-on-write reference counting, while Rust String always performs a deep copy when passed by value.
    Show the answer

    Answer: c · Go strings are small two-word headers copied by value with immutable backing data, whereas Rust String moves ownership and must be cloned to duplicate its heap buffer.

    Go strings are small two-word headers (pointer and length) that are cheaply copied by value while remaining immutable, whereas a Rust String owns its heap buffer and moves ownership by default, so duplicating it requires an explicit clone. Option D is tempting because copy-on-write is common in other languages, but Rust String is uniquely owned and Go strings do not use reference counting.

    Read the full bite: Compare Go string and Rust &str/String types, mutability, UTF-8, ownership

16. Question 16 of 30

    What happens if a caller ignores the error when parsing a string to an integer in Go versus Rust?

    • aGo issues a compiler warning because the error return is must-use, while Rust allows silent ignoring since Result is only idiomatic
    • bBoth panic at runtime if parsing fails because unhandled explicit errors escalate to panics in both languages
    • cBoth compile without issue because neither language requires the caller to handle an explicit error value
    • dGo compiles silently because error checking is purely conventional, while Rust emits a must-use warning since Result is enforced by the type system
    Show the answer

    Answer: d · Go compiles silently because error checking is purely conventional, while Rust emits a must-use warning since Result is enforced by the type system

    Go relies on programmer discipline to check the second error return value, so ignored errors compile silently. Rust's Result is must-use, so the compiler warns if it is not handled via match or ?; distractor A reverses these roles.

    Read the full bite: Parse a string to integer in Go and Rust with errors

17. Question 17 of 30

    Why should the service layer in a layered Express API avoid referencing the request and response objects?

    • aServices run in a different thread from controllers
    • bExpress forbids accessing them outside route handlers
    • cPassing them is slower than passing plain values
    • dIt keeps business logic framework-agnostic and unit-testable without HTTP
    Show the answer

    Answer: d · It keeps business logic framework-agnostic and unit-testable without HTTP

    Keeping req and res out of services makes the business logic reusable and testable without spinning up HTTP. Express does not forbid it and services are not on a separate thread.

    Read the full bite: Layered structure for a scalable Express API

18. Question 18 of 30

    Given a dependency written as ^1.4.2, which upgrade would npm refuse to install on its own?

    • a1.5.3, a later minor and patch
    • b2.0.0, a major release
    • c1.4.9, a patch release
    • d1.7.0, a minor release
    Show the answer

    Answer: b · 2.0.0, a major release

    The caret allows updates below the next major, so anything under 2.0.0 is permitted, but 2.0.0 itself is excluded. The tilde would be the operator that also blocks 1.7.0.

    Read the full bite: SemVer and the caret vs tilde range operators

19. Question 19 of 30

    When you create b[1:4] from a Go slice b, how does the resulting value compare to borrowing &v[1..4] from a Rust Vec?

    • aBoth operations produce a three-word header containing pointer, length, and capacity, but Rust's borrow checker prevents mutation.
    • bThe Rust borrow stores capacity to prevent use-after-free when the Vec reallocates, while the Go slice omits capacity.
    • cThe Go operation allocates a new backing array for the sub-range, while the Rust borrow creates a two-word pointer into the existing buffer.
    • dThe Go result is a new three-word header sharing the original array, while the Rust result is a two-word borrowed slice with no capacity field.
    Show the answer

    Answer: d · The Go result is a new three-word header sharing the original array, while the Rust result is a two-word borrowed slice with no capacity field.

    Go slicing creates a new header (pointer, length, capacity) that points into the same underlying array, whereas Rust's &[T] is a two-word fat pointer without capacity because it is only a borrowed view. Distractor B is tempting because one might assume slicing copies data, but Go only copies the descriptor and shares the backing array.

    Read the full bite: Describe Go slice internals and compare to Rust slice and Vec

20. Question 20 of 30

    A FastAPI endpoint declares a path parameter as item_id: int. A request arrives for /items/abc, which cannot be coerced to an integer. What happens?

    • aFastAPI returns an automatic 422 error describing the invalid value, and the endpoint function body never executes
    • bPython raises a TypeError at the point where item_id is used inside the function body
    • cFastAPI passes the string abc through unchanged, and the function must convert it manually
    • dThe server returns a 500 Internal Server Error because the type coercion crashes the process
    Show the answer

    Answer: a · FastAPI returns an automatic 422 error describing the invalid value, and the endpoint function body never executes

    FastAPI validates the coerced type before your function runs, so an uncoercible value short circuits into an automatic 422 with no handler code executing. Python itself does nothing with the int annotation at runtime, which is why expecting a TypeError or manual parsing misses the point of the hint.

    Read the full bite: How FastAPI uses type hints for validation

21. Question 21 of 30

    Which FastAPI endpoint declaration identifies a user in the URL path and accepts an optional search term after the question mark?

    • aRoute /users/{user_id}/items with user_id in path and q optional
    • bRoute /users/items with user_id and q as query arguments, q optional
    • cRoute /users/{user_id}/items/{q} with user_id and q in path, q optional
    • dRoute /users/{user_id}/items with user_id in path and q required
    Show the answer

    Answer: a · Route /users/{user_id}/items with user_id in path and q optional

    Option A correctly places the user identifier in the path template and gives q a default of None so it becomes an optional query parameter. Option B is tempting because it also makes q optional, but it omits user_id from the path so FastAPI treats it as a query parameter, violating RESTful hierarchy.

    Read the full bite: What is the difference between a path parameter and a query parameter?

22. Question 22 of 30

    An endpoint declares a query parameter as q: Optional[str] with no default value. What happens when a client omits it?

    • aFastAPI automatically assigns None as the default based solely on the Optional type hint
    • bFastAPI follows Pydantic model conventions and defaults the parameter to None
    • cFastAPI returns a 422 Unprocessable Entity error
    • dFastAPI allows the request and sets q to None because the type hint permits None
    Show the answer

    Answer: c · FastAPI returns a 422 Unprocessable Entity error

    FastAPI derives requirement from the presence or absence of a Python signature default, not from type hints, so Optional[str] without = None is still required and omitting it triggers a 422 error. Option D is a common misconception because Optional alone does not make a parameter optional in FastAPI.

    Read the full bite: How does FastAPI distinguish required optional and default query parameters

23. Question 23 of 30

    A category tree is read constantly to render menus but almost never restructured. Which model best fits, and why?

    • aNested set, because subtree reads are a single range query
    • bAdjacency list, because moving nodes touches many rows
    • cAdjacency list, because subtree reads need no recursion
    • dNested set, because inserts only change one row
    Show the answer

    Answer: a · Nested set, because subtree reads are a single range query

    Nested set encodes descendants as a left/right range, so a whole subtree is one indexed query, ideal for read-heavy trees. Its weakness is expensive writes, which barely matters here since the tree is almost never restructured.

    Read the full bite: Adjacency List versus Nested Set for hierarchies

24. Question 24 of 30

    A table is in 3NF but not BCNF because of a dependency Teacher to Subject where Teacher is not a superkey. What makes this still acceptable for 3NF?

    • aThe table has no candidate keys at all
    • bTeacher is a foreign key to another table
    • cTeacher to Subject is a trivial dependency
    • dSubject is a prime attribute, part of a candidate key
    Show the answer

    Answer: d · Subject is a prime attribute, part of a candidate key

    3NF permits a non-superkey determinant when the dependent attribute is prime, so Subject being part of a candidate key keeps it in 3NF. BCNF has no such exception, which is exactly why the table violates BCNF.

    Read the full bite: 3NF versus BCNF and the overlapping-key gap

25. Question 25 of 30

    What combination of standard and code sources enables FastAPI's automatic interactive documentation?

    • aIt generates a static JSON schema at build time from explicit annotations only
    • bIt requires manually maintaining an openapi.yaml file alongside your code changes
    • cIt uses the Swagger UI standard to parse docstrings without needing type hints
    • dIt dynamically builds an OpenAPI schema from type hints, Pydantic models, decorators, and docstrings
    Show the answer

    Answer: d · It dynamically builds an OpenAPI schema from type hints, Pydantic models, decorators, and docstrings

    FastAPI dynamically generates an OpenAPI schema by extracting metadata from type hints, Pydantic models, decorators, and docstrings, so no manual schema file is required. Option B is wrong because maintaining a separate openapi.yaml by hand is unnecessary and contradicts FastAPI's design.

    Read the full bite: What standard and code elements power FastAPI's auto-generated API docs?

26. Question 26 of 30

    Why does the Promise callback print before the setTimeout(0) callback despite both being scheduled in the same tick?

    • aThe order is implementation-defined and can vary
    • bPromises run on a higher-priority OS thread
    • csetTimeout has an enforced minimum delay larger than the Promise
    • dThe microtask queue is fully drained before the next macrotask runs
    Show the answer

    Answer: d · The microtask queue is fully drained before the next macrotask runs

    After the synchronous stack clears, all microtasks (Promise reactions) drain before any macrotask (setTimeout) runs. The delay value is not the deciding factor here; queue priority is.

    Read the full bite: Output order of sync, microtask, and macrotask

27. Question 27 of 30

    What happens to the remaining requests when one input to Promise.all rejects?

    • aPromise.all waits for all of them before reporting the rejection
    • bThe combined Promise rejects immediately, but the other requests still run to completion
    • cTheir results replace the rejected one
    • dThey are automatically cancelled by the runtime
    Show the answer

    Answer: b · The combined Promise rejects immediately, but the other requests still run to completion

    Promise.all rejects as soon as the first input rejects, but JavaScript Promises are not cancellable, so the other in-flight requests continue running. They simply have no remaining handler.

    Read the full bite: Running independent requests with Promise.all and race

28. Question 28 of 30

    Which solution best supports many concurrent readers on a typed Go map while keeping compile-time type safety?

    • aStore the map in a struct guarded by sync.Mutex with Lock for both reads and writes
    • bUse sync.Map directly with typed keys and values
    • cAccess a plain map concurrently after setting runtime.GOMAXPROCS to 1
    • dWrap the map in a struct with sync.RWMutex, using RLock for reads and Lock for writes
    Show the answer

    Answer: d · Wrap the map in a struct with sync.RWMutex, using RLock for reads and Lock for writes

    An RWMutex-wrapped map allows multiple simultaneous readers and retains compile-time type safety. sync.Map is tempting because it handles concurrency internally, but it stores interface{} values and therefore sacrifices compile-time type checking.

    Read the full bite: How do you safely share a Go map across goroutines?

29. Question 29 of 30

    In classic Express 4, how should an error from an awaited database call inside async middleware reach the error handler?

    • aThrow it and let Express catch it automatically
    • bIgnore it, since unhandled rejections are routed by default
    • cCatch it and pass it to next(err) so the error-handling middleware runs
    • dCall res.send with the error directly from the middleware
    Show the answer

    Answer: c · Catch it and pass it to next(err) so the error-handling middleware runs

    Express 4 does not auto-catch async throws, so you must catch and forward with next(err) to trigger the four-argument error handler. Throwing alone leaves the request hanging.

    Read the full bite: Handling async errors in Express middleware

30. Question 30 of 30

    Why might a try/catch fail to catch an error from an async call inside it?

    • atry/catch never works with Promises under any circumstance
    • bIf the returned Promise is not awaited, control leaves the block before it rejects
    • ccatch only catches synchronous TypeErrors
    • dasync functions disable the surrounding try/catch
    Show the answer

    Answer: b · If the returned Promise is not awaited, control leaves the block before it rejects

    Without await, the async call returns a pending Promise and execution exits the try block immediately, so a later rejection is not caught there. Awaiting the call keeps it within the try/catch scope.

    Read the full bite: Comparing the three async error-handling styles