Software Engineer interview questions for experienced

The Global Interpreter Lock is a lock in CPython. It lets only one thread run Python bytecode at a time. It protects CPython's internal state, such as reference counts, from race conditions.

Effects:

• CPU-bound Python code gains no speed from threads, since they take turns on one core.
• I/O-bound code still benefits, because a thread releases the GIL while waiting on sockets, files or time.sleep.
• Many C extensions (NumPy, hashing, compression) release the GIL during heavy work.
• Race conditions on your own data are still possible. You still need locks for steps like counter += 1.

Ways around it: multiprocessing or concurrent.futures.ProcessPoolExecutor for CPU-bound work, asyncio or threads for I/O, native extensions. Python 3.13 added an experimental free-threaded build (PEP 703) where the GIL can be turned off. The default build still has it.

What they are checking: Accurate detail: I/O threads work, CPU threads do not, and the GIL is not a substitute for locks

All three give concurrency but with different models.

• Threading: preemptive switching, so races are possible and locks are needed.
• Multiprocessing: real parallelism across cores, but data moves through IPC and startup costs more.
• Asyncio: cooperative; tasks switch only at await, so a blocking call (like requests.get) freezes everything. Use async libraries or asyncio.to_thread.

Rule of thumb: For CPU-bound work use processes. For many network calls use asyncio. For a few blocking calls in old code use a thread pool.

What they are checking: Ability to map a workload to the right concurrency model and know the failure modes

async def defines a coroutine. await pauses it until another awaitable finishes. Meanwhile the event loop runs other tasks. The event loop is the scheduler: it runs on a single thread and switches between coroutines at await points.

Measure first, then optimise the part that matters.

This is I/O-bound. Run the calls at the same time with asyncio (or a thread pool if the client library is blocking). Also limit how many run at once.

A dict is a hash table. For each key, Python computes hash(key) and uses it to pick a slot in an index array. It handles collisions by probing for another free slot. Then it stores the key and value.

CPython manages memory automatically with reference counting plus a cyclic garbage collector.

A context manager defines setup and cleanup around a block. with calls __enter__ on entry and always calls __exit__ on exit, even after an exception. So resources are released reliably.

Type hints are annotations that declare the expected types of variables, parameters and return values. They are not enforced by the interpreter at runtime. They exist for static checkers (mypy, pyright), IDEs and documentation.

@dataclass (module dataclasses, since 3.7) writes repeated methods for you in classes that mainly hold data: __init__, __repr__, __eq__, and optionally ordering and hashing.

It prints [2, 2, 2], not [0, 1, 2]. Closures capture the variable i, not its value at creation time (late binding). By the time the lambdas are called, the loop has finished and i is 2.

MRO is the order in which Python searches base classes for an attribute or method. It uses the C3 algorithm. Each class comes before its parents, and the order of the bases you list is kept.

You need three nested layers: an outer function that takes the decorator's arguments, and a decorator that takes the function. The third layer is a wrapper that runs on each call.

Stream it instead of loading it. File objects are lazy iterators over lines, so memory stays flat.

Confirm it is a leak (memory rising steadily and never plateauing), then find what holds references.

• Take snapshots with tracemalloc and compare them to see which lines allocate the growing objects:

CPU-bound work is limited by the GIL, so use processes or vectorisation, not threads.

• First check if the work can be vectorised with NumPy or pandas. This moves loops into C and is often 10 to 100 times faster.
• Otherwise split the data into chunks and use ProcessPoolExecutor:

Give each project its own virtual environment and pin its dependencies.

Memoization saves the result of a function for given arguments. Repeated calls return the saved value instead of recomputing. functools.lru_cache does this with a bounded Least Recently Used cache.

Wrap the call in a loop. Catch only errors worth retrying, wait longer each time, add jitter (a small random delay), and give up after a limit.

Both run automated tests. unittest ships in the standard library with class-based TestCase and self.assertEqual style. pytest is the de facto standard: plain functions, plain assert statements with rich failure output, fixtures, parametrisation and a large plugin ecosystem.

A process has its own memory space, a thread shares memory with others in the same process. Threads are lighter, but shared data needs synchronisation.

Safe ways to share:

• queue.Queue: thread-safe producer-consumer channel, the preferred approach.
• threading.Lock around read-modify-write sequences.

__new__ creates the instance (it is a static method that receives the class and returns a new object). __init__ then sets up that new instance. Python calls __new__ first. It calls __init__ only if __new__ returns an instance of the class.

In a normal CPython session, typed separately, the first line prints True and the second usually prints False. CPython creates and caches the integers from -5 to 256, so both names point to the same object. Larger integers are created as new objects.

The walrus operator := (3.8) assigns a value inside an expression. match/case (3.10) does structural pattern matching.

Duck typing means the methods an object has decide if it fits, not its declared class. The idea: "if it walks like a duck and quacks like a duck". Abstract base classes (ABCs) set a clear contract. They force subclasses to implement certain methods.

Subclass Exception (not BaseException) and give it a meaningful name, optionally with extra data. Chaining keeps the original cause visible.

It returns 2. The finally block always runs, even when the try block has already hit a return. A return inside finally replaces the earlier return value.

__slots__ declares a fixed set of attributes for a class. Instances then store them in a compact array instead of a per-instance __dict__. This saves memory and makes attribute access a little faster.

JavaScript runs your code on one thread. The event loop is what lets it handle async work without blocking.

1. Synchronous code runs on the call stack until it is empty.
2. The host (browser or Node) handles async APIs (timers, network, DOM events). Later it queues a callback.
3. Promise reactions and queueMicrotask callbacks go to the microtask queue. Timers and I/O callbacks go to the macrotask (task) queue.
4. When the stack is empty, the loop runs all microtasks. Then it takes one macrotask and runs it. Then it runs microtasks again, and repeats. In browsers rendering happens between tasks.

What this means: a long synchronous loop freezes the page and delays timers. setTimeout(fn, 0) means "after the current code and microtasks". A microtask that keeps adding microtasks can block rendering.

What they are checking: Whether you can describe stack, queues and ordering, not only say single threaded

Output: 1 4 3 2.

• 1 and 4 are synchronous, so they run first in order.
• The promise callback is a microtask, so it runs as soon as the stack is empty: 3.
• setTimeout is a macrotask, so it runs after the microtasks: 2, even with a delay of 0.

A harder variant adds async function f() { console.log('a'); await null; console.log('b'); }. Code before the first await runs synchronously; the code after it is a microtask. Explain by naming the stack, microtask queue and task queue.

What they are checking: Whether you can trace event loop ordering

async/await is syntax built on top of promises. An async function always returns a promise. await pauses that function until a promise settles, without blocking the thread.

Both are queues the event loop uses, but microtasks have higher priority.

• Microtasks: promise .then/.catch/.finally callbacks, await continuations, queueMicrotask, MutationObserver.
• Macrotasks: setTimeout, setInterval, DOM events, network and I/O callbacks, MessageChannel.

Both limit how often a function runs during rapid events.

• Debounce waits until events stop for N ms, then runs once. Good for search-as-you-type and window resize end.
• Throttle runs at most once per N ms while events keep coming. Good for scroll, mousemove and drag.

A shallow copy duplicates only the top level; nested objects are still shared references. A deep copy duplicates everything.

Arrow functions are shorter, but the real differences are behavioural:

Event delegation puts one listener on a parent element. It uses event bubbling to handle events from the children, and finds the source with event.target.

All take an iterable of promises and return one promise.

The problem: requests can return out of order. A slow response for an old query arrives last and wins.

Use try/catch around await, or .catch() on promise chains. A thrown error in an async function becomes a rejected promise.

Both split code into files, but they differ in syntax and loading.

An event travels in three phases: capturing (window down to the target), target, then bubbling (target back up to window).

• obj.regular() gives "A": called as a method, so this is obj.
• obj.arrow() gives undefined: an arrow function takes this from the place where the object literal sits (module or global scope), not from obj.
• fn() loses the receiver. In strict mode or ES modules this is undefined, so reading .name throws a TypeError. In sloppy mode this is the global object. So it returns undefined (or "" in a browser, where window.name exists).

Currying turns a function of several arguments into a chain of functions. Each one takes one (or some) arguments. It enables reuse through partial application.

Memoization caches results of a pure function keyed by its arguments, so repeated calls are instant.

Return a new promise. Track results by index so the order is kept. Resolve when the count reaches the length. Reject on the first failure.

A callback is a function passed to another function to be called later, often after async work. Callback hell is deeply nested callbacks that are hard to read, handle errors in and refactor.

• const prevents reassigning the variable. The object it points to can still change.
• Object.freeze(obj) makes the object immutable at the top level: no add, delete or change of properties.
• Object.seal(obj) blocks adding and deleting properties, but existing ones can still be changed.
• Object.preventExtensions(obj) blocks only adding.

Engines use mark-and-sweep: starting from roots (global object, stack), they mark everything reachable and free the rest. Reference counting alone fails on cycles, so it is not used.

Approach: reproduce, measure, compare, fix.

The work runs on the main thread, so it blocks rendering and input. Confirm with the DevTools Performance tab (a long task).

Fire all 1,000 at once and you will hit rate limits or exhaust the browser. Use a pool: start up to 5 workers that each pull the next id until none are left.

Retry only temporary failures (network errors, 5xx, 429). Wait longer each time. Add jitter (a small random delay) so many clients do not retry together. Limit the number of attempts. Do not retry 4xx client errors. Retry non-idempotent requests (like POST) only if the server supports idempotency keys.

Use a Map or object for O(n) work instead of nested loops.

new Fn(...) does four things: creates an empty object and links its prototype to Fn.prototype. It calls Fn with this set to that object. It returns the object (unless the function returns another object).

Fix it on both sides, because client checks alone can be bypassed.

Client:

• Disable the button and show a spinner as soon as the submit starts. Enable it again in finally.
• Guard with a flag so a second handler call returns early.

A window function computes a value across a set of rows related to the current row. Unlike GROUP BY, it does not collapse them. You define the set with OVER (PARTITION BY ... ORDER BY ...).

For salaries 90, 80, 80, 70 ordered descending:

• ROW_NUMBER: unique sequence, ties broken arbitrarily.
• RANK: ties share a rank, then a gap.
• DENSE_RANK: ties share a rank, no gap.

SELECT name, dept_id, salary,
       RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS dept_rank
FROM employees;

Other common ones: LAG, LEAD, SUM() OVER, NTILE, FIRST_VALUE.

What they are checking: Whether you know analytics SQL beyond GROUP BY

Isolation levels trade consistency for concurrency. The problems they prevent:

• Dirty read: reading uncommitted data of another transaction.
• Non-repeatable read: the same row read twice returns different values.
• Phantom read: the same query returns new rows the second time.

Rank within each department using a window function, then filter.

Measure before changing anything.

Make the check and the update atomic using row locking or a constrained update.

Option 1, pessimistic lock:

Start from the execution plan, then work through the options in order of effort.

A clustered index sets the physical order of the table rows, so the table data is the index. A non-clustered index is a separate structure with pointers back to the rows.

A Common Table Expression (WITH) is a named temporary result you can reference in the following query. It improves readability and supports recursion.

Truncate the date to the month, filter the range, group and sort.

A deadlock happens when two transactions each hold a lock the other needs, so neither can proceed. The database detects it and aborts one transaction as the victim.

Example: T1 updates row A then wants row B, while T2 updated row B and wants row A.

Simple pagination uses LIMIT and OFFSET. But the database must read and throw away all skipped rows, so page 10,000 is slow.

Common reasons the planner ignores an index:

Avoid anything that locks or rewrites the whole table during peak traffic.

One giant DELETE holds locks for a long time, bloats the transaction log and can stall replication. Delete in small batches instead.

Compare each salary to a per-department average, using a join or a window function.

Denormalize when read performance matters more than write simplicity and joins have become the bottleneck, after measuring.

Both test membership in a subquery result. IN compares a value against a list. EXISTS checks whether the correlated subquery returns at least one row.

A non-correlated subquery runs once and does not reference the outer query. A correlated subquery references outer columns, so conceptually it runs once per outer row.

Use SUM() OVER with an ordered window.

For simple conditional logic, CASE inside a query is enough and keeps everything portable. To pivot rows into columns, combine CASE with an aggregate.

A lost update happens when two transactions read the same value, both change it, and the second write overwrites the first.

Example: both read stock = 10, one sets 9 and the other sets 8, so one sale vanishes.

OLTP handles many small, concurrent transactions for running the business. OLAP handles few, heavy analytical queries over large history.

Use a subquery that takes the maximum of everything below the overall maximum.

Relational databases use a fixed schema, SQL, joins and ACID transactions. NoSQL stores (document, key-value, wide-column, graph) trade some of that for flexible schemas and horizontal scale.

A foreign key constraint does not create an index on the child column in PostgreSQL. (MySQL InnoDB does create one.) Without it:

• Joins from parent to child scan the whole child table.
• Deleting or updating a parent row forces a scan of the child table to check references. This can be slow and cause lock contention.

Annotate a class with @Entity, extend JpaRepository, and Spring generates the implementation.

Spring wraps the bean in a proxy. The proxy opens a transaction before the method. It commits on normal return. It rolls back on a RuntimeException or Error (not on checked exceptions by default).

ConcurrentHashMap is a thread-safe hash map. It allows concurrent reads and fine-grained writes without locking the whole map.

The Executor framework separates task submission from execution. You submit tasks, and a pool of reusable threads runs them.

A deadlock is when two or more threads each hold a lock the other needs, so none can move on.

Capture evidence, find what is retaining memory, fix it, and add a guard.

Measure before changing anything, and narrow down from the outside in.

count++ is not atomic (read, add, write), so threads overwrite each other's updates. This is a race condition.

@SpringBootApplication combines @Configuration, @ComponentScan and @EnableAutoConfiguration.

The default scope is singleton: one instance per container. Others are prototype (new instance per injection or lookup), and for web apps request, session and application.

All four are stereotype annotations that register a class as a bean through component scanning. The last three are specialisations of @Component that add meaning.

Try-with-resources closes any resource that implements AutoCloseable for you. It closes in reverse order of declaration, even if an exception occurs.

CompletableFuture is a Future you can compose without blocking: chain steps, combine results and handle errors.

Virtual threads are lightweight threads scheduled by the JVM, not the OS (Project Loom, final in Java 21). Millions can exist. A blocking call such as I/O parks the virtual thread and frees its carrier platform thread.

Both are reentrant mutual-exclusion locks. ReentrantLock adds control that synchronized lacks.

Use @RestControllerAdvice with @ExceptionHandler methods to turn exceptions into consistent error responses, ideally RFC 7807 ProblemDetail (Spring 6).

Lazy loading fetches an association only when it is first accessed. Eager loading fetches it immediately with the parent.

The simplest safe options are an enum singleton or the initialization-on-demand holder idiom.

The most likely cause is a key whose hashCode or equals changed after it was added, or a broken hashCode/equals pair.

map transforms each element into one element. flatMap transforms each element into a stream and flattens them into one stream.

Boot loads application.properties or application.yml, then profile files such as application-prod.yml, environment variables and command-line arguments. Later sources override earlier ones, so env vars win over files.

Test the smallest slice that proves the behaviour.

Parallel gives the most throughput but has stop-the-world pauses. G1 balances pause times and throughput. ZGC aims for very short pauses whatever the heap size.

Enable caching with @EnableCaching and annotate methods. Back it with Caffeine for in-process or Redis for shared caches.

Never return unbounded lists. Accept page, size and sort parameters, validate them, and return a page with metadata.

Read the failure analysis: it names the missing bean and the injection point.

Both memoise a value between renders and only recompute when dependencies change.

• useMemo(() => compute(a, b), [a, b]) caches a computed value.
• useCallback(fn, [deps]) caches a function; it equals useMemo(() => fn, [deps]).

const sorted = useMemo(() => items.slice().sort(cmp), [items]);
const onSelect = useCallback((id) => setSelected(id), []);

Use them when:

• A calculation is genuinely expensive.
• You pass a function or object to a React.memo child, or use it as a hook dependency, and need a stable reference.

Do not wrap everything: memoisation costs memory and comparison time. Measure with the Profiler first. The React Compiler can add much of this automatically.

What they are checking: Whether you know they are for referential stability and cost, not default habits

A component re-renders when its state changes. It also re-renders when its parent re-renders (even with the same props), or when a context it uses changes.

Ways to reduce it, roughly in order of preference:

1. Move state down, closer to where it is used, so fewer components sit under the changing state.
2. Pass expensive parts as children or props (composition), so they keep the same element identity.
3. Split contexts, or use a store with selectors.
4. Use React.memo on heavy children, with stable props through useMemo and useCallback.
5. Virtualise long lists, and use useDeferredValue or transitions for expensive updates.

Measure first with React DevTools Profiler ("why did this render") rather than guessing. A re-render alone is cheap; the problem is slow work during it.

What they are checking: Whether you diagnose before optimising

Find the problem first with the React Profiler and the browser Performance tab. Then reduce what is rendered and re-rendered.

1. Virtualise (windowing): render only visible rows using react-window, @tanstack/react-virtual or similar. This is usually the biggest win.
2. Paginate or filter on the server if users never need all rows at once.
3. Stop needless re-renders: stable keys, React.memo on the row, useCallback for handlers, and keep per-row state inside the row.
4. Move fast-changing state (like a search input) so it does not re-render the list; use useDeferredValue for filtering.
5. Avoid expensive work in render: precompute or memoise sorting and formatting.
6. Keep row DOM small and avoid layout thrash.

Confirm with before-and-after measurements.

What they are checking: Whether you measure and reach for virtualisation

Causes are usually one of these:

• Calling a setter during render: <button onClick={setOpen(true)}> runs immediately; it must be onClick={() => setOpen(true)}.
• An effect that sets state it also depends on, with no guard:

useEffect(() => { setItems([...items, 1]); }, [items]); // loops forever

• A dependency that is a new object, array or function on every render (useEffect(fn, [{ a: 1 }])). The effect then re-runs each time and sets state.

Fix:

• Move calculations into render (derived state) instead of effect plus setState.
• Use functional updates (setItems(prev => ...)) so you do not need the value as a dependency.
• Memoise object dependencies with useMemo or depend on primitives.
• Check the call stack and use the lint rule react-hooks/exhaustive-deps. Add a console log to see which dependency changes.

What they are checking: Whether you can find the loop cause quickly

Context is a delivery mechanism for a value, not a state manager. Redux (and Zustand, Jotai) provide a store, update patterns and selective subscriptions.

Use Context for low-frequency, app-wide values: theme, locale, auth user, feature flags.

Server Components render only on the server (at build time or per request). They send serialised output to the browser, with no component JavaScript shipped for them.

• CSR (client-side rendering): the browser downloads JavaScript and builds the page. Slow first paint, weak for SEO without extras.
• SSR (server-side rendering): HTML is generated on each request. Fresh data, good SEO, but needs a server and costs time per request.
• SSG (static site generation): HTML is built once...

Main additions:

• Actions: functions (often async) passed to <form action={fn}> or transitions, with built-in pending, error and optimistic handling.
• useActionState for form state from an action, useFormStatus for pending state inside a form, and useOptimistic for instant optimistic UI.
• use() to read a...

This is a stale closure (the callback holds an old value). The effect ran once with []. So the callback captured count from the first render and keeps using it.

Responses can arrive out of order, so an older request overwrites the newer one. Cancel or ignore old requests in the effect cleanup.

Split state by type and use the simplest tool for each.

Use a framework with server rendering, most pages as static or incrementally regenerated: Next.js (App Router) or similar.

Move the data logic into a custom hook that returns { data, error, loading }. Use an AbortController so a slow earlier request cannot overwrite a newer one.

An error boundary is a component that catches errors thrown while rendering its children, in lifecycle methods and in constructors. It shows a fallback UI instead of crashing the whole app.

Use useReducer when state has several related fields, when the next state depends on complex rules, or when many different actions update it. It centralises updates in a pure reducer, which is easy to test.

Both run after React updates the DOM, but at different times.

React.lazy loads a component's code only when it is first rendered. Suspense shows a fallback while the component (or data) is not ready.

Both mark updates as non-urgent so React keeps the UI responsive.

• useTransition returns [isPending, startTransition]. Wrap a state update in startTransition so React can interrupt it for urgent input.
• useDeferredValue(value) returns a lagging copy of a value that updates after urgent work finishes.

Hydration is when React attaches event handlers and state to HTML that the server already rendered. It reuses the existing DOM instead of rebuilding it.

Each keystroke updates state at the top, which re-renders everything beneath.

React preserves state only while the component keeps the same type at the same position (and key). Resets usually come from:

Treat every request as having four states: loading, error, empty and success, and design each one.

React groups multiple state updates that happen in the same event or tick into a single re-render. Since React 18 this automatic batching also works inside promises, timeouts and native event handlers, not only React events.

Server Actions are async functions marked with "use server". They run on the server but can be called from client code, usually as a form action or from an event handler. The framework creates the network endpoint for you.

Treat it as a product: a versioned package with a clear API, documentation and tests, built on shared design tokens.

Test how a user sees the behaviour, not implementation details.

The React Compiler is a build-time tool (Babel/SWC plugin). It analyses components and memoises values and functions for you, so you rarely write useMemo, useCallback or React.memo by hand.

Micro frontends split a large web application into smaller frontends. Separate teams build, test and deploy them independently. They are then combined into one page for the user. It is the frontend version of the microservices idea.

Types do not exist at runtime, so a fetch().json() result typed as User is just a guess. Check the data where it enters your app, using a runtime schema library (Zod, Valibot, ArkType). Get the static type from the schema, so the two never get out of sync.

import { z } from "zod";

const UserSchema = z.object({
  id: z.number(),
  name: z.string().min(1),
  email: z.string().email().optional(),
});
type User = z.infer<typeof UserSchema>;

async function getUser(id: number): Promise<User> {
  const res = await fetch(`/api/users/${id}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const json: unknown = await res.json();
  return UserSchema.parse(json);       // throws a clear error if the shape is wrong
}

Practical points:

• Treat all external input (network, localStorage, query string, env vars) as unknown until parsed.
• Use safeParse where you want to handle errors without exceptions.
• Share the schema between client and server so both validate the same contract.
• Hand-written type guards work for tiny shapes but get long fast.

What they are checking: Whether you understand the limit of static types and validate untrusted data at the edge

I would never trust the type for data from outside the program. The flow:

1. Define the expected shape once as a runtime schema (Zod or similar) and infer the TypeScript type from it.
2. Keep the raw result as unknown and parse it in one wrapper function so nobody reads unvalidated data.
3. Handle failure on purpose (bad status, bad shape). Return a result type or throw a typed error.

import { z } from "zod";

const Todo = z.object({ id: z.number(), title: z.string(), done: z.boolean() });
type Todo = z.infer<typeof Todo>;

async function fetchJson<T>(url: string, schema: z.ZodType<T>): Promise<T> {
  const res = await fetch(url);
  if (!res.ok) throw new Error(`Request failed: ${res.status}`);
  const body: unknown = await res.json();
  return schema.parse(body);
}

const todos = await fetchJson("/api/todos", z.array(Todo));

If the backend is also TypeScript, share the schema package or generate types from an OpenAPI/GraphQL spec. Then a contract change breaks the build instead of production. A bare as Todo[] cast is acceptable only for trusted internal data and should be a conscious exception.

What they are checking: Whether you validate at the boundary and keep a single source of truth for the contract

A constraint with extends limits what a type parameter may be, so you can safely use its members. A default gives the parameter a fallback when it cannot be inferred or is not supplied.

They extract types from existing functions or promises, so you do not repeat or drift from the source.

A discriminated union is a union of object types that share a literal-typed property (the discriminant). Checking that property lets TypeScript narrow to exactly one member.

A mapped type builds a new type by looping over the keys of another type with [K in keyof T]. It can also change modifiers or value types. Most utility types are mapped types.

Let inference work where it can, and add a generic where the initial value does not tell the full type.

Assign the leftover value to never in the default branch. If every union member is handled, the leftover type is never and it compiles. If someone adds a new member later, the assignment fails and the compiler points to the switch that needs updating.

Migrate gradually so the app keeps shipping.

Describe all endpoints in one map type, then make a generic function that looks up the types by path. The compiler then knows the body and the result for each call.

Use a discriminated union instead of separate boolean flags, so impossible combinations (loading and error at once) cannot exist.

A conditional type picks one of two types based on a check: T extends U ? X : Y. With infer you can capture a part of the matched type into a new type variable.

as const makes a value deeply readonly and keeps literal types instead of widening them. satisfies checks that a value matches a type without changing the inferred type of the value.

Overloads declare several call signatures for one function, followed by a single implementation that handles all of them. Callers see only the overload signatures.

TypeScript is structurally typed: two types are compatible if their shapes match, regardless of names. That means a UserId and an OrderId that are both number are interchangeable, which can hide bugs.

An index signature says an object can have any number of keys of a given type: { [key: string]: number }. Record<K, V> is a mapped type that expresses the same idea and also works with a union of known keys.

Use a generic with a conditional return type, or overloads, so the output depends on the input.

First measure, then reduce the work.

Contain the unsafety at the boundary so any never leaks into the rest of the code.

Both combine shapes, but they report conflicts differently.

Make the function component generic. The props use the type parameter, and TypeScript infers it from what the caller passes.

Declaration merging means TypeScript joins several declarations with the same name into one. Interfaces merge, and namespaces merge with classes and functions. Module augmentation applies that to a third-party module: you reopen its declarations and add to them.

The bundler does the emitting, so TypeScript is used only for checking.

Enable it gradually and stop the debt from growing.

Template literal types build string literal types using the same backtick syntax as JavaScript templates, and they distribute over unions.

Covariance means a more specific type can be used where a general one is expected (return types). Contravariance is the reverse: a function that accepts a general type can stand in for one that accepts a specific type (parameters).

Next 14 cached fetch results and GET route handlers by default, which surprised many teams. Since Next 15, fetch requests and GET route handlers are not cached by default, and you opt in.

The caching layers worth knowing:

• Request memoization: identical fetch calls during one render are de-duplicated.
• Data cache: persisted fetch results (opt in with next: { revalidate: n }, cache: "force-cache" or tags).
• Full route cache: the rendered HTML and RSC payload of static routes.
• Router cache (client): visited segments kept in the browser. In Next 15, page segments are no longer reused by default, so navigations are fresher.

Next 16 adds an opt-in model called Cache Components. You mark code with the "use cache" directive and control how long it lives with cache life profiles, instead of route-level flags. Dynamic data inside static shells is streamed with Suspense.

export default async function Page() {
  const res = await fetch("https://example.com/api/rates", {
    next: { revalidate: 3600, tags: ["rates"] },
  });
  const rates: Record<string, number> = await res.json();
  return <pre>{JSON.stringify(rates)}</pre>;
}

Tags let you clear the cache later with revalidateTag (in Next 16 it also takes a cache life profile as a second argument). Always check the docs for your exact version, since this area changes quickly.

What they are checking: Whether you know caching is opt-in now and understand the layers

Prefer an HttpOnly, Secure, SameSite cookie. Any JavaScript on the page can read localStorage. So one XSS bug (or a bad npm package) lets an attacker steal the token.

// app/api/login/route.ts
import { NextResponse } from "next/server";

export async function POST() {
  const token = "signed.jwt.value"; // issued after verifying credentials
  const res = NextResponse.json({ ok: true });
  res.cookies.set("session", token, {
    httpOnly: true,
    secure: true,
    sameSite: "lax",
    path: "/",
    maxAge: 60 * 60 * 24 * 7,
  });
  return res;
}

Also keep access tokens short-lived and use a refresh token. Check the signature on the server for every request. Set a strict Content Security Policy. For SSR apps, cookies are the natural choice since the server can read them during rendering.

What they are checking: Whether you understand the XSS versus CSRF choice, and pick cookies for SSR

Find where the time goes before changing anything.

1. Check whether the route is rendered dynamically on every request when it could be static or cached. Look for cookies(), headers(), searchParams or cache: "no-store" forcing dynamic rendering.
2. Measure the server: log timing around each fetch and database call, or use OpenTelemetry. Look for slow queries, missing indexes and N+1 patterns.
3. Remove request waterfalls: start independent fetches together with Promise.all.
4. Cache what can be cached: revalidate, tags, or "use cache" in Next 16; a CDN in front for public pages.
5. Stream: wrap slow, non-critical sections in Suspense so the shell is sent immediately.
6. Reduce work in middleware and avoid heavy computation on the request path.
7. Check geography: server and database should be in the same region, and users far away should hit a CDN.
8. Check cold starts and memory limits on serverless platforms.

const [user, posts] = await Promise.all([getUser(), getPosts()]); // parallel, not sequential

Verify with real field data (Core Web Vitals, server timing headers), not only local runs.

What they are checking: Whether you follow a measurement-driven approach and know Next-specific causes

This is a caching question. Walk the layers from server to browser.

1. Static or ISR page: the page was generated earlier and revalidate has not passed. Fix with on-demand revalidation (revalidatePath or revalidateTag) after writes, or lower the interval.
2. Data cache: a fetch with force-cache or a long revalidate. Use tags and invalidate them, or cache: "no-store" for truly live data.
3. Full route cache and generateStaticParams: new slugs need dynamicParams true or a rebuild.
4. Router cache in the browser: soft navigation may show a previous payload. Call router.refresh() after a mutation, or use Server Actions which refresh automatically.
5. CDN or reverse proxy cache (Cloudflare, nginx): check Cache-Control and purge. Verify with curl -I and the x-nextjs-cache header (HIT, MISS, STALE).
6. Multiple instances with separate in-memory caches: a revalidation reached only one server. Use a shared cache handler.
7. Read-replica lag or a wrong environment variable pointing at old data.

curl -sI https://example.com/blog/post | grep -i -E "cache|age|x-nextjs"

Fix by deciding the freshness requirement per page, then invalidating explicitly on write.

What they are checking: Whether you can systematically debug stale data across caches

Hydration attaches React to server HTML. If the first client render produces different markup than the server did, React reports a mismatch.

Common causes:

• Values that differ between server and client: Date.now(), Math.random(), new Date().toLocaleString() (time zone and locale differ).
• Reading window, localStorage or navigator during render.
• Invalid HTML nesting, such as a <div> inside a <p>, which the browser repairs.
• Browser extensions injecting attributes, or inconsistent conditional rendering based on the user agent.

Fixes:

"use client";
import { useEffect, useState } from "react";

export function Clock() {
  const [now, setNow] = useState<string | null>(null);   // same on server and first client render
  useEffect(() => setNow(new Date().toLocaleTimeString()), []);
  return <span>{now ?? ""}</span>;
}

• Compute browser-only values in useEffect, so the first render matches.
• Use useId for ids, and pass stable data (like a server-generated timestamp) as props.
• Fix invalid nesting.
• Use suppressHydrationWarning only for unavoidable one-off text such as a timestamp.
• next/dynamic with ssr: false for components that cannot render on the server.

What they are checking: Whether you can reason about server versus client render output

Time-based: the data is considered fresh for N seconds, then refreshed on a later request (stale-while-revalidate).

// route-level
export const revalidate = 60;
// or per fetch
// fetch(url, { next: { revalidate: 60 } })

On-demand: you invalidate immediately when something changes, for example from a Server Action or a webhook route.

// app/actions.ts
"use server";
import { revalidatePath, revalidateTag } from "next/cache";

export async function publishPost() {
  // ... write to the database
  revalidateTag("posts", "max");  // tag-based; Next 16 takes a cache life profile as 2nd argument
  revalidatePath("/blog");       // or a specific route
}

Choose time-based when a delay is fine (price lists, blogs). Choose on-demand when users expect to see their own change at once (admin edits, CMS publish webhooks). Combine both: a long revalidate as a safety net plus on-demand invalidation for freshness. Tags are better than paths when many pages depend on the same data.

What they are checking: Whether you can keep data fresh without turning off caching

Server Actions are async functions that run on the server and can be called from forms or client code. They are marked with "use server". Next creates a POST endpoint for each one automatically.

Middleware runs before a request reaches a route. It can redirect, rewrite, set headers and cookies, or short-circuit with a response. It runs for the paths you match.

generateStaticParams tells Next which dynamic route values to pre-render at build time. It replaces getStaticPaths from the Pages Router.

Streaming sends the page's HTML in chunks as each part becomes ready, instead of waiting for the slowest query. The user sees the shell immediately and slow sections fill in later.

Use layers, and put the real check next to the data.

Work from what Google sees to how the page is built.

First find the LCP element in Lighthouse or Chrome DevTools (usually a hero image or a big heading). Then remove what delays it.

Use the server by default. Fetch on the client when the data depends on the browser or changes while the user is on the page.

Migrate incrementally, because both routers work in the same project. If a path exists in both, app/ wins, so move one route at a time.

Build in CI, not on the small server, and ship only the output.

They are folder conventions that shape routing without changing URLs in unusual ways.

Create a small Client Component that wraps the provider and shows children. Then use it in the (server) root layout. Server components passed as children stay server components.

You can choose the runtime per route or middleware.

• XSS: React escapes values by default. The risks are dangerouslySetInnerHTML, unsanitised markdown or HTML from users, and unsafe URLs (javascript:). Sanitise with a library such as DOMPurify and set a Content Security Policy.
• CSRF: cookie-based auth is exposed to cross-site requests. Use SameSite=Lax or...

Never render them all. Paginate or stream, and let the database do the work.

Put the variable part in a dynamic top-level segment and resolve it early.

Reduce the cost per request first, then restrict abusers, without blocking real users or search engines.

The App Router uses React 19, so these are available:

Stop building on the production machine, and shrink the build.

Prefetch the query in a Server Component, dehydrate the cache, and pass it to a client-side provider with HydrationBoundary. The client component then reads the same query key and gets the data instantly, without a second request.

Default change detection checks every component in the tree after any event, timer or HTTP response that Zone.js sees. OnPush checks a component only when something specific changes, which cuts work a lot in large trees.

An OnPush component is re-checked when:

• an @Input reference changes (not a mutation of the same object),
• an event handler in its own template fires,
• an async pipe emits or a signal read in the template changes,
• you call markForCheck() explicitly.

@Component({
  selector: 'app-row',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `{{ user().name }}`,
})
export class RowComponent { user = input.required<User>(); }

Use OnPush by default for presentational components, combined with immutable updates and signals or observables.

What they are checking: Whether you understand what triggers checks and how to keep data flow predictable

A signal is a value that tells its users when it changes. So Angular knows exactly which views depend on which data. They were introduced to enable precise updates, simpler state code, and a path away from Zone.js.

const count = signal(0);
const double = computed(() => count() * 2);
count.set(2);          // double() is 4
count.update(n => n + 1);

Key points:

• Read by calling the function: count().
• computed is lazy, memoised and read-only.
• effect runs side effects when dependencies change.
• Signal inputs (input()), model(), and signal queries (viewChild()) are available in Angular 17.1 to 18+.
• Signals work well with OnPush because the template registers the dependency.

What they are checking: Whether you grasp the reactivity model, not only the syntax

All four map each source value to an inner observable and flatten the results; they differ in how they handle overlapping inner observables.

An interceptor sits between the app and the network. It can read or change every HTTP request and response. Typical uses are attaching auth tokens, global error handling, logging, loading indicators and retry.

Make sure every long-lived subscription ends when the component is destroyed. The cleanest options are the async pipe, takeUntilDestroyed, or toSignal.

First measure with the Angular DevTools profiler and the Chrome Performance tab. Then reduce what is drawn and what is checked.

This pattern usually means leaked subscriptions, listeners or detached DOM. Confirm it with a heap comparison, then fix the code that owns them.

Use a form control stream with debounce, removal of repeated values and switchMap. Handle loading and errors without breaking the stream.

Measure first (Lighthouse, ng build --stats-json with a bundle analyser), then cut what ships and defer the rest.

computed makes a new value from other signals and has no side effects. But effect runs code with side effects whenever the signals it reads change.

Guards decide whether navigation is allowed, and resolvers fetch data before the route activates. Since Angular 15 guards are plain functions that use inject().

A sync validator is a function that takes an AbstractControl and returns null when valid, or an error object when invalid. An async validator returns an observable or promise of the same.

inject() gets a dependency from the current injection context, such as a constructor, a field start value, a factory or a functional guard. You do not need constructor parameters. Angular resolves it by walking up a hierarchy of injectors.

Zone.js patches async APIs (timers, events, promises, XHR) so Angular knows when to run change detection. Zoneless means Angular learns about changes from signals, markForCheck, events and the async pipe instead. So Zone.js can be removed.

Start with signal-based services for local and feature state. Add NgRx (or NgRx SignalStore) when many features share complex state and you need a strict flow, devtools and managed side effects.

Catch 401 responses and refresh the token once. Hold the other failed requests until the refresh finishes. Then retry them with the new token.

It happens in development mode. A binding's value changes after Angular has already checked it in the same cycle. Usually a child or a lifecycle hook changes parent state during the check.

Use a reactive form and drive the dependent controls from the parent control's valueChanges. Reset the children when the parent changes.

Check that the template is told something changed. OnPush only refreshes when an input reference changes, on template events, on async pipe or signal updates, or on markForCheck.

Set up TestBed with the standalone component and a fake provider for the service. Then check the drawn output and the calls.

Migrate step by step, because NgModules and standalone components work together. Use the schematic to do most of the routine work.

ng-content projects markup from a parent into a component's template. ViewChild queries elements in the component's own template. ContentChild queries elements that were projected into it.

@defer loads part of a template and its dependencies later, when a trigger fires. Angular puts that code into a separate chunk automatically.

Server-side rendering (SSR) renders the page HTML on the server, so users and search crawlers get content immediately. Hydration then reuses that server DOM in the browser instead of rebuilding it.

markForCheck() marks a component and its parents to be checked in the next change detection cycle. You need this with OnPush. detectChanges() runs change detection on that component's view right now, synchronously.

Put the shared state in a service that both components inject. Expose it as a read-only signal or observable. Neither component should know about the other.

Implement ControlValueAccessor and register it with the NG_VALUE_ACCESSOR token. Then the forms API can read and write the component's value.

The event loop is run by libuv and cycles through phases, each with a queue of callbacks:

1. timers: setTimeout and setInterval callbacks that are due.
2. pending callbacks: some deferred system I/O callbacks.
3. idle, prepare: internal.
4. poll: retrieves new I/O events and runs their callbacks; it may wait here if nothing else is scheduled.
5. check: setImmediate callbacks.
6. close callbacks: for example socket.on('close').

Between each callback (and after each phase transition) Node drains process.nextTick first, then promise microtasks.

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
process.nextTick(() => console.log("tick"));
Promise.resolve().then(() => console.log("promise"));
// tick, promise, then timeout/immediate (order of the last two varies in the main module)

Inside an I/O callback, setImmediate always fires before setTimeout.

What they are checking: Whether you can name the phases and ordering

• process.nextTick(fn) runs right after the current operation, before the event loop continues and before promise microtasks. Overusing it can starve I/O.
• setImmediate(fn) runs in the check phase, after the poll phase.
• setTimeout(fn, 0) runs in the timers phase after at least 1 ms.

Order of priority: nextTick, then promise microtasks, then timers/immediates.

• Use nextTick to run something after the current function but before any I/O. One example is emitting an event after you return the emitter.
• Use setImmediate to yield to the event loop between chunks of work.
• From the main module the order of setTimeout 0 and setImmediate is not guaranteed; inside an I/O callback setImmediate is always first.

What they are checking: Whether you know the queue order

Confirm it is a leak: memory climbs and does not drop after garbage collection. Then check process.memoryUsage() or metrics for heapUsed and RSS over time.

Find it:

1. Run with node --inspect, connect Chrome DevTools, and take heap snapshots under load a few minutes apart. Use the Comparison view to see which object types grow. Then read what keeps them alive (their retainers).
2. Or use --heapsnapshot-signal=SIGUSR2 in production-like environments, or tools such as clinic.js.

Typical causes:

• Unbounded in-memory caches or maps keyed by user id.
• Event listeners added per request and never removed (the "MaxListeners" warning is a hint).
• Closures holding large request objects, global arrays that accumulate, timers never cleared.
• Un-ended streams or unclosed connections.

Fix: bound caches (LRU with a max size and TTL) or move them to Redis, remove listeners, clear timers, close resources. Verify memory plateaus under load. Setting --max-old-space-size only delays the crash.

What they are checking: Whether you debug with heap snapshots, not guesses

Node runs your code on one thread, so a hot function blocks all requests.

Diagnose:

• Capture a CPU profile: node --prof and node --prof-process, clinic flame, or Chrome DevTools via --inspect. Read the flame graph for the widest functions.
• Check event loop lag (perf_hooks.monitorEventLoopDelay) and which endpoint correlates with the spike.

Common culprits and fixes:

• Large JSON.parse/stringify, sorting or looping over big arrays: paginate, stream, or process in chunks with setImmediate.
• Synchronous crypto or hashing: use async versions or worker threads.
• Catastrophic regex backtracking: fix the pattern or limit input size.
• Complex per-request computation: cache results, precompute, or move to a worker pool or separate service.

Then run one process per core (cluster or containers). That way one busy process does not take down all capacity. Add load tests to confirm the fix.

What they are checking: Whether you profile and know the single-thread consequence

A stream processes data in chunks instead of loading it all into memory. There are four types: Readable, Writable, Duplex (both) and Transform (modify data while passing through).

const { pipeline } = require("stream/promises");
const fs = require("fs");
const zlib = require("zlib");

await pipeline(
  fs.createReadStream("input.log"),
  zlib.createGzip(),
  fs.createWriteStream("input.log.gz")
);

Use them for large files, uploads and downloads, HTTP request/response bodies, CSV processing and compression. Benefits: constant memory use and faster time to first byte. Use pipeline (not bare .pipe) so errors propagate and resources are cleaned up. Streams support backpressure: when the consumer is slow, write() returns false and the source pauses until drain.

What they are checking: Whether you can handle big data without exhausting memory

All three use more CPU cores, but in different ways.

const { Worker, isMainThread, parentPort, workerData } = require("worker_threads");
if (isMainThread) {
  new Worker(__filename, { workerData: 40 }).on("message", console.log);
} else {
  const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));
  parentPort.postMessage(fib(workerData));
}

In production, cluster is often replaced by PM2 or containers with one process each behind a load balancer.

What they are checking: Whether you pick the right tool for I/O versus CPU work

Use a central error-handling middleware with four arguments, registered last. Synchronous throws inside route handlers reach it automatically. In Express 4, rejected promises from async handlers do not, so wrap them or call next(err). Express 5 forwards rejected promises automatically.

const wrap = (fn) => (req, res, next) => fn(req, res, next).catch(next);

app.get("/users/:id", wrap(async (req, res) => {
  const user = await db.find(req.params.id);
  if (!user) { const e = new Error("Not found"); e.status = 404; throw e; }
  res.json(user);
}));

app.use((err, req, res, next) => {
  const status = err.status || 500;
  res.status(status).json({ error: status === 500 ? "Internal error" : err.message });
});

Also: create custom error classes, log with context, and never leak stack traces to clients. Handle unhandledRejection and uncaughtException at process level, to log the error and exit cleanly.

What they are checking: Whether you handle async errors and avoid leaking details

A JSON Web Token is a signed token with a header, payload (claims such as sub, exp) and signature. The server signs it after login; the client sends it on each request; the server verifies the signature and expiry without a session lookup.

Layered measures:

Scale vertically first, then horizontally, and remove bottlenecks before adding servers.

After an uncaughtException the process state may be inconsistent, so log it and exit; let a supervisor (PM2, Docker, Kubernetes) restart it. Since Node 15, unhandled promise rejections also crash the process by default.

Work from measurement to cause.

Never buffer the whole file in memory. Stream it end to end and batch the writes.

Counters must be shared across instances, so use a central store (Redis), not in-memory counters per process.

Combine graceful shutdown with a rolling or blue-green deploy.

libuv is the C library that provides Node's event loop and asynchronous I/O across operating systems. Network I/O uses OS facilities (epoll, kqueue, IOCP) directly. Operations with no async OS API are run on libuv's thread pool, which has 4 threads by default.

Use the cache-aside pattern: check Redis, on a miss read the database and store the result with a TTL.

Opening a database connection is slow and databases limit concurrent connections. A pool keeps a set of open connections and lends them out, reusing them across requests.

Use layers of tests.

Use structured (JSON) logs and send them to a central system.

Act in layers, fastest wins first.

Likely suspects:

Stateless JWTs are valid until they expire, so revocation needs extra design.

Backpressure happens when a producer writes data faster than a consumer can handle. Without control, buffered data piles up in memory.

A writable stream signals this: write() returns false when its internal buffer passes highWaterMark. The producer should pause until the drain event, then resume.

All start another process, but with different output handling.

Recent LTS releases reduced the need for extra packages:

They block the calling thread until the task completes. In an environment with a synchronization context (classic ASP.NET, WinForms, WPF), this can deadlock.

The deadlock: the UI or request thread calls GetAsync().Result and blocks. Inside, the code after await tries to resume on that same saved context. But the thread is blocked waiting, so neither can move on.

// Risky in UI / legacy ASP.NET
var data = LoadAsync().Result;

// Fix: async all the way
var data2 = await LoadAsync();

// In library code: do not capture the context
await SomeCallAsync().ConfigureAwait(false);

ASP.NET Core has no synchronization context, so this exact deadlock does not happen there. But blocking still wastes pool threads and can leave no free threads under load. Rule: go async all the way, avoid .Result, .Wait() and GetAwaiter().GetResult(), and use ConfigureAwait(false) in general-purpose libraries.

What they are checking: A favourite senior question: whether you know the cause, not just the slogan

N+1 means one query loads N parents, then one extra query per parent loads related data, giving N+1 round trips.

A clustered index sets the physical order of the table rows. So a table has only one (the primary key by default). A non-clustered index is a separate structure. It holds the key columns plus a pointer (the clustering key) to the row. A table can have many.

Use them as a fast pair programmer, and keep ownership of design and verification.

Measure first, find the bottleneck layer, then fix and verify.

A Thread is an OS thread you manage yourself. A Task is a higher-level unit of work scheduled on the thread pool. It may not even use a thread while it waits for I/O.

async void cannot be awaited, and exceptions thrown in it cannot be caught by the caller. They are raised on the synchronization context and can crash the process. Use it only for event handlers.

This is the captive dependency problem. The singleton holds the first scoped instance forever, so a DbContext is shared across requests and threads. It is not thread safe, it caches tracked entities (stale data) and grows without bound.

Use the exception handling middleware, and in .NET 8 an IExceptionHandler that returns RFC 7807 ProblemDetails.

The client logs in, the server issues a signed JWT, and the client sends it as Authorization: Bearer <token> on later requests. The JWT bearer middleware validates the signature, issuer, audience and expiry, and builds the ClaimsPrincipal.

Creating a new HttpClient() per request can exhaust sockets (ports stay in TIME_WAIT), while a single static client never refreshes DNS. IHttpClientFactory pools and recycles the underlying handlers and gives you named or typed clients with policies.

These are patterns for letting AI tools do larger, more reliable pieces of work.

Many closures read the loop variable after the loop has advanced, so you may see repeated or unexpected values.

Find what is kept in memory, using dumps and counters. Then fix the root cause.

Treat it as an evidence hunt: narrow what the failing requests have in common.

Make the operation idempotent on the server, and do not rely only on disabling the button.

SaveChanges runs inside one transaction by default. For multi-step work, use a transaction that you start yourself. For concurrent edits use optimistic concurrency.

Use OFFSET ... FETCH with a deterministic ORDER BY. For deep pages or feeds use keyset pagination.

Modern C# adds concise ways to model data.

Use System.Threading.Channels, the modern async-friendly bounded queue, instead of manual locks.

Use a hosted service for in-process work, and a durable job system when jobs must survive restarts.

Migrate incrementally and keep the system running, rather than a risky big-bang rewrite.

Both build HTTP endpoints on the same pipeline. Minimal APIs are lightweight and function based, while controllers are class based with more built-in conventions.

Prefer composition ("has-a") over inheritance ("is-a") unless there is a genuine subtype relationship.

Observer defines a one-to-many dependency: when a subject changes state, all its registered observers are notified automatically, with no tight coupling between them.

If S is a subtype of T, you can use objects of S in place of objects of T without breaking the program. A subclass must honour the parent's contract: same preconditions or weaker, same postconditions or stronger, no new exceptions.

Dependency Inversion (the D in SOLID) is a design principle: high-level modules should depend on abstractions, not on concrete low-level classes. Dependency Injection (DI) means giving a class the objects it needs from outside (constructor, setter or framework). The class does not create them inside with new.

Immutable objects cannot change after they are built. So they are thread-safe by default, safe as map keys and easy to understand (String, Integer, LocalDate).

Move each branch's behaviour into a class that implements a shared interface, and let dynamic dispatch pick the branch.

Before:

Clarify requirements first: vehicle types, number of levels, pricing, entry and exit, payment, capacity display.

Apply Open/Closed with a Strategy interface and a registry.

Use Strategy for channels. Use a factory or registry to look them up. Use Observer if one event goes to many subscribers.

Use an interface to describe a capability that unrelated classes can offer and that callers depend on: PaymentGateway, Repository, Comparable. It keeps coupling low and makes mocks easy.

The diamond problem appears with multiple inheritance: D inherits from B and C, which both inherit from A. If B and C override a method differently, which version does D get?

Clients should not be forced to depend on methods they do not use. Prefer several small, focused interfaces over one large one.

Example of breaking it:

It uses dynamic dispatch. In Java each class has a method table (vtable). Every object carries a reference to its class. For an overridden method call, the JVM looks up the method in the real object's class at run time, not in the declared reference type.

MRO is the order Python searches classes for an attribute. It uses C3 linearisation, which keeps each class before its parents and preserves the order of bases as written. Class.__mro__ or Class.mro() shows it.

Dunder (double underscore) methods let your class plug into Python's syntax and built-ins.

A shallow copy creates a new outer object but the nested objects are shared with the original. A deep copy recursively copies everything, so the two are independent.

Strategy defines a family of interchangeable algorithms behind one interface and lets the caller pick one at run time. The context holds a reference to the interface and delegates.

The Decorator design pattern wraps an object with another that has the same interface to add behaviour dynamically, without subclassing. Example: BufferedReader(new FileReader(...)).

Builder constructs a complex object step by step and produces it at the end. It is useful when a class has many optional parameters, or construction must be validated as a whole.

Record (Java 16): a compact immutable data carrier. The compiler generates the constructor, accessors, equals, hashCode and toString.

This breaks the Liskov Substitution rule: the child cannot honestly stand in for the parent.

The problem is hidden global state plus hard-wired access.

This is the fragile base class problem. Approach:

This is the telescoping constructor smell. Options:

Plan:

1. Add tests around the public behaviour (characterisation tests), even rough ones.
2. Group methods and fields by the data they touch. Clusters that use separate fields are separate responsibilities.
3. Extract classes one at a time (Extract Class refactoring). Move a cluster and its fields to a new...

HashMap is an array of buckets. For put(key, value):

1. Compute key.hashCode() and spread its bits.
2. Find the bucket index (hash & (capacity - 1); capacity is a power of two).
3. If the bucket is empty, store a node. Otherwise compare keys with equals; replace the value if equal, else append to the chain.
4. Since Java 8, a chain longer than 8 (with table size at least 64) turns into a red-black tree. So the worst-case lookup is O(log n) instead of O(n).
5. When size exceeds capacity * 0.75, the table doubles and entries are redistributed.

Consequences: keys need matching equals/hashCode. If you change a key after inserting it, you lose it. The iteration order is not guaranteed. It is not thread-safe (use ConcurrentHashMap). A null key is allowed (bucket 0). Initial capacity matters if you know the size, to avoid rehashing.

What they are checking: Internals knowledge that interviewers love

Both are self-balancing BSTs that keep height O(log n) so every operation stays O(log n).

Dijkstra finds the shortest path from one source to all vertices in a graph with non-negative edge weights. It greedily picks the unvisited vertex with the smallest known distance (using a min-heap), then relaxes its outgoing edges.

Options:

1. Sort: O(n log n). Simple, fine for small inputs.
2. Min-heap of size k: push each element, pop when size exceeds k. Result is the heap root. O(n log k) time, O(k) space. Best for streams.
3. Quickselect: partition around a pivot like quick sort but recurse into one side only. Average O(n), worst O(n^2) (random pivot makes this unlikely). Modifies the array.

Two pointers: two indices move through a sequence (often one from each end, or a slow one and a fast one). This avoids a nested loop. Typical for sorted arrays: pair sum, removing duplicates, reversing, partitioning. Turns O(n^2) into O(n).

A trie keyed by characters supports prefix lookup in O(L). Store a small list of top suggestions at each node (worked out in advance by frequency). Then a query returns results without walking the whole subtree.

Exact counting needs memory proportional to distinct items. Options:

Model users as vertices and friendships as edges (unweighted, undirected). Use BFS from the source: the first time you reach the target is the shortest path, in O(V + E).

LRU needs O(1) lookups and O(1) "move to most recent" and "evict oldest". One structure cannot do both:

• A hash map gives O(1) lookup by key.
• A doubly linked list keeps usage order; moving or removing a known node is O(1).

A topological order of a directed acyclic graph (DAG) lists the vertices so that for every edge u -> v, u comes before v. It exists only if the graph has no cycle.

Uses: build systems, course prerequisites, task scheduling, package dependency resolution.

Undirected graph: DFS or BFS and look for a visited neighbour that is not the node's parent. Or use Union-Find: if an edge joins two vertices already in the same set, there is a cycle.

A trie (prefix tree) stores strings character by character: each node is a character and a path from the root spells a prefix. Lookup, insert and prefix search take O(L), where L is the string length, independent of how many words are stored.

Union-Find tracks a partition of elements into disjoint sets. Operations: find(x) returns the set representative, union(a, b) merges two sets. With path compression and union by rank, each operation is almost O(1) (inverse Ackermann).

Given items with weights and values and a capacity W, choose a subset with maximum total value. The total weight must not exceed W. Each item is used at most once.

State: dp[w] = best value with capacity w. Iterate items, and iterate capacity downward so each item is used once.

Heap sort: build a max-heap from the array. Then swap the root (largest) with the last unsorted element, make the heap one smaller, and sift down. Repeat. Result is ascending, in place: O(n log n) time in all cases, O(1) extra space, not stable.

Amortized analysis spreads the cost over a sequence of operations, even in the worst case. A rare expensive operation is shared by many cheap ones. It is not probabilistic.

Load factor = number of entries / number of buckets. A high load factor means more collisions: chains get longer (or probe sequences grow), pushing operations from O(1) toward O(n).

A minimum spanning tree (MST) connects all vertices of a weighted undirected graph. It has the smallest total edge weight and no cycles.

Disk and SSD reads fetch whole pages, so the cost is the number of page reads, not comparisons. A binary tree has height log2(n), which means many reads. A B-tree node holds hundreds of keys (one page), so the tree is very wide and shallow. With 500 keys per node, 100 million rows need only about 3 or 4 levels.

A sorted array gives O(log n) search but O(n) insert/delete because of shifting. A plain linked list gives O(1) insert but O(n) search.

Inserting keys in sorted order into a plain BST creates a lopsided tree. Every node has only a right child, so it behaves like a linked list. Height becomes n and operations degrade from O(log n) to O(n).

Options by constraint:

1. External sort: sort chunks that fit in memory, write them out, k-way merge, and compare neighbours. O(n log n) with sequential disk I/O, exact.
2. Hash partitioning: split IDs into buckets on disk by hash(id) % B, so duplicates fall in the same bucket. Then check each bucket in...

Use two stacks of commands (Command pattern).

A priority queue implemented with a binary heap: insert and pop-highest are both O(log n), peek is O(1). A sorted list would make inserts O(n).

Sliding window with a map of the last seen index of each character. When a repeat is inside the window, move the left edge past the previous occurrence.

At each element, either extend the current subarray or start fresh, whichever is larger. Track the best seen.

Combine a hash map (O(1) lookup) with a structure that tracks recency. In Python, OrderedDict is a hash map plus doubly linked list, with move_to_end and popitem.

Use a canonical key for each word: its sorted letters. Words with the same key are anagrams.

Sort by start. Then walk through: if the next interval starts before or at the end of the last merged one, extend the end. Otherwise, start a new interval.

The number of ways to reach step n is the sum of the ways to reach n-1 and n-2. This is the Fibonacci pattern.

Bottom-up DP: dp[a] is the minimum coins for amount a. For each amount try every coin. Greedy fails for some coin sets (for example coins 1, 3, 4 and amount 6).

For each index, the answer is the product of everything to its left times everything to its right. Compute prefix products going forward, then multiply by suffix products going back.

Sort the array. For each index i, use two pointers on the rest to find pairs that sum to -a[i]. Skip duplicates to keep results unique.

Scan once, tracking the lowest price so far and the best profit if you sold today.

Use BFS with a queue. Process one level at a time by reading the queue length before looping.

Both are short recursions: depth is 1 + max of child depths; inversion swaps children at every node.

Pass down the allowed range for each node. Checking only the immediate children is a common bug, because a deep node must obey every ancestor.

Count with a Counter. Then take the K most common using a heap (O(n log k)), or a bucket sort by frequency (O(n)).

Scan the grid. When you find an unvisited 1, count one island and flood fill it (DFS or BFS) marking all connected land.

Keep a second stack (or store pairs) that tracks the minimum at each depth. Every push records the smaller of the new value and the current minimum.

Use an input stack for pushes and an output stack for pops. When the output stack is empty, move everything over, which reverses the order to FIFO.

Use a sliding window log per user: keep the timestamps of recent requests in a deque. Drop the ones older than the window. Allow the request if fewer than N remain.

Treat AI output like code from a new teammate: useful, but unreviewed. I never merge what I cannot explain line by line.

Boyer-Moore voting: keep a candidate and a counter. Matching element increments, different one decrements; when the counter hits zero pick a new candidate. A true majority always survives.

Expand around every possible centre (n odd-length and n-1 even-length centres) and keep the longest.

Keep two heaps: a max-heap for the lower half and a min-heap for the upper half, sizes balanced within one. The median is the top of the larger heap, or the average of both tops.

Store timestamps in a deque (hits arrive in time order). On each query, drop entries older than 300 seconds and return the length. For very high traffic, count into per-second buckets in a fixed array of 300 slots.

Store (value, expires_at) in a dict. Check expiry lazily on reads. A background sweep (or heap ordered by expiry) removes dead entries so memory does not grow without bound.

Give each URL an auto-increment ID (from a database sequence or a distributed ID generator). Then encode the ID in base62 (0-9, a-z, A-Z). Decoding reverses it. This avoids collisions and gives short codes: 7 characters cover 62^7, about 3.5 trillion IDs.

Modified binary search: at each step one half is always sorted. Check whether the target lies in the sorted half. If not, throw that half away.

Patience sorting with binary search: keep tails[i], the smallest possible tail of an increasing subsequence of length i + 1. For each number, replace the first tail that is greater or equal, or append.

Work in the smallest currency unit (integer cents or paisa), so there is no floating point error. Work out each share with integer division. Then give out the leftover units one by one, so the shares add up exactly to the total. This is the largest remainder method.

OAuth 2.0 is an authorization framework. It lets an app use a user's data on another service without getting the user's password. It gives the app an access token with limited permissions (scopes).

Roles: resource owner (user), client (app), authorization server, resource server (API).

Main flows:

• Authorization Code with PKCE: for web, mobile and SPA apps. The user logs in at the provider, and the app trades a code for tokens. This is the recommended default.
• Client Credentials: service-to-service, no user involved.
• Refresh Token: gets new access tokens without a new login.
• Device Code: for TVs and CLIs without a browser.
• Implicit and Resource Owner Password flows are old and should be avoided.

OAuth 2.0 handles authorization. OpenID Connect adds an ID token on top, for login ("Sign in with Google").

What they are checking: Flow choice and the OAuth versus OIDC distinction

Versioning lets you change the API without breaking existing clients. Common strategies:

Rate limiting limits how many requests a client can make in a time window. It protects the service from abuse and overload.

Use the correct status code and a consistent body that programs can read. The standard format is Problem Details (RFC 9457, previously 7807):

Resources: posts and comments (comments belong to a post).

Use idempotency keys on the non-idempotent POST calls.

Use many layers of defence:

First find the slow part with tracing, logs and database EXPLAIN. Then use the cheapest fix that works.

Postman does not enforce CORS. The browser does. So the problem is in the server response headers.

OAuth 2.0 answers "what may this app access?" and produces an access token for APIs. OpenID Connect (OIDC) is a small identity layer on top of OAuth 2.0. It answers "who is the user?". It gives an ID token (a JWT) with details about the user.

There is no perfect place; choose by threat model.

A preflight is an automatic OPTIONS request. The browser sends it before the real request when the call is not simple. For example, when it uses PUT/DELETE, a JSON Content-Type, or an Authorization header.

Do not keep the HTTP connection open. Use the asynchronous request-reply pattern.

Caching reuses saved responses to cut delay and load. The server controls it with headers.

An API gateway is one entry point in front of the backend services. It handles shared jobs, so each service does not have to.

The N+1 problem happens when you fetch a list and then run one extra query for each item to load related data. For example, 100 orders with their customers become 101 queries.

Keep old clients working while new ones move over.

Advantages:

• Clients ask for exactly the fields they need. This removes extra data and extra round trips.
• One endpoint and a typed schema, with good tools.
• You can change it without versions by marking old fields as deprecated.

HATEOAS stands for Hypermedia As The Engine Of Application State. Responses include links that tell the client what it can do next. The client follows the links instead of fixing the URLs in its code.

An ETag is an identifier for one version of a resource (often a hash or a version number). It is returned in the ETag header.

Caching with conditional GET:

GET /products/5
-> 200, ETag: "v7"
GET /products/5
If-None-Match: "v7"
-> 304 Not Modified (no body, saves bandwidth)

Do not send 10,000 separate requests. Do not send one request that times out.

Retry only when it is safe, and spread the retries out.

Treat the API like a product.

PKCE (Proof Key for Code Exchange, said "pixie") protects the authorization code flow. It is for apps that cannot keep a secret, such as browser and mobile apps. It stops an attacker who steals the authorization code from trading it for tokens.

Caching happens at several levels:

• Client: Apollo Client keeps one cache entry per object, found by its type and id. When an object changes, every query that shows it updates. Fetch policies such as cache-first and network-only decide when it asks the server.
• Server: cache hints per field and...

N+1 happens when you run one query to get N objects. Then you run one more query for each object to get a related row. That gives N+1 queries.

# 1 query for books + 1 query per book for author
for book in Book.objects.all():
    print(book.author.name)

Fixes:

• select_related("author") for ForeignKey or OneToOne (JOIN).
• prefetch_related("tags") for many-valued relations.
• .only() / .values() to fetch only the columns you need.
• Count in SQL (annotate(n=Count("comments"))) instead of counting in a loop.

Find it with django-debug-toolbar, assertNumQueries in tests, or the django.db.backends logger. In DRF, the serializer is the usual cause: put the select_related/prefetch_related in the viewset's get_queryset.

What they are checking: Recognising the pattern and tools to detect it

Measure first. Then remove the repeated queries.

1. Count queries with django-debug-toolbar or django-silk locally, or enable the django.db.backends logger. Tests can pin the number with self.assertNumQueries(3).
2. If the query count grows with the number of rows, it is N+1. Find the field that the serializer or template reads, which causes one query per object.
3. Fix in get_queryset: select_related for FKs, prefetch_related (with Prefetch objects for filtered relations) for reverse and M2M, and annotations for counts and sums.
4. Send less data: only()/defer(), paginate (PageNumberPagination or cursor pagination), avoid big nested objects.
5. Look at slow SQL with EXPLAIN ANALYZE and add indexes (db_index=True, Meta.indexes) on filtered and ordered columns.
6. If it is still slow, cache the result in Redis and measure again.

Goal: a small, fixed number of queries, no matter how many rows. Add a test to keep it that way.

What they are checking: Methodical diagnosis with ORM-level tooling

Django's own auth uses sessions. Login stores a session id in a cookie, and the server looks up the user on each request. DRF adds authentication classes you can swap in, and they set request.user.

JWT practice: use a short-lived access token (a few minutes) and a refresh token to renew it. Sign with a strong secret or key pair. Always use HTTPS. If XSS is a worry, keep tokens out of localStorage (HttpOnly cookies are safer). Authentication says who you are. Permissions decide what you may do.

What they are checking: Pros and cons of stateful and stateless auth

FastAPI's Depends lets you write reusable pieces (database session, current user, settings, pagination) as functions. FastAPI calls them and passes the results into your endpoint.

FastAPI supports both. async def endpoints run directly on the event loop. Plain def endpoints run in a pool of worker threads, so they do not block it.

Run the app server behind a reverse proxy (Nginx or a cloud load balancer). Manage it with systemd or containers.

• Django (WSGI): gunicorn project.wsgi:application --workers 4 --bind 0.0.0.0:8000.
• Django or FastAPI (ASGI): gunicorn as process manager with uvicorn workers: