Full-Stack Offer Plan

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");

A, D, C, B. Synchronous code runs first (A, D). When the stack empties, all microtasks run (the promise callback C), then one macrotask (the timer B).

A function that remembers the variables of the scope where it was created, even after that scope has returned.

function debounce(fn, ms) {
  let t;                                   // lives on in the closure
  return (...args) => { clearTimeout(t); t = setTimeout(() => fn(...args), ms); };
}

var is function-scoped and hoisted with the value undefined. let and const are block-scoped and in the "temporal dead zone" until declared. const stops reassignment, not mutation: const a = []; a.push(1) is fine. The classic trap: for (var i...) setTimeout(() => console.log(i)) prints the final value every time; let gives each iteration its own i.

It's decided by how a function is called. obj.f() gives obj. A plain call gives undefined in strict mode. new F() gives the new object. call, apply and bind set it explicitly. Arrow functions have no own this; they use the surrounding one, which is why they're handy in callbacks.

=== compares without type conversion; always use it. undefined means "not assigned"; null means "deliberately empty". ?? falls back only on those two, while || also falls back on 0 and "".

all rejects on the first failure. allSettled waits for every result, success or not. race takes the first to settle. any takes the first success. Run independent awaits in parallel with await Promise.all([a(), b()]), not one after the other.

Spread ({...obj}) copies one level; nested objects are shared. structuredClone(obj) does a real deep copy, including Dates and Maps. That matters in React state updates.

type Result<T> = { ok: true; data: T } | { ok: false; error: string };   // discriminated union

function unwrap<T>(r: Result<T>): T {
  if (r.ok) return r.data;           // narrowing: TS knows r.data exists here
  throw new Error(r.error);
}

function parse(input: unknown) {      // unknown forces you to check before use; any switches TS off
  if (typeof input === "string") return input.trim();
}

Interfaces can be extended and merged; types can express unions and mapped types. Either is fine for object shapes, so pick one and stay consistent. Useful utilities: Partial, Pick, Omit, Record.

State change, parent re-render, or context change. A parent re-render re-renders its children even if their props are the same.

Keys tell React which item is which between renders. With index keys, inserting at the top shifts every key, so React reuses the wrong DOM and component state (a checkbox stays ticked on the wrong row). Use a stable id.

useEffect(() => {
  const ctrl = new AbortController();
  fetch(`/api/tasks?team=${teamId}`, { signal: ctrl.signal })
    .then(r => r.json()).then(setTasks).catch(() => {});
  return () => ctrl.abort();          // cleanup: cancel if teamId changes or we unmount


}, [teamId]);                          // re-run only when teamId changes

Missing dependencies give stale values; an object created on every render as a dependency gives an infinite loop. Many effects shouldn't exist: derive values during render instead of syncing state with an effect.

Controlled: React state owns the value (value + onChange), which is good for validation as you type. Uncontrolled: the DOM owns it, and you read it via a ref or FormData, which is simpler for big forms. Libraries like React Hook Form mix both for speed.

Local UI state: useState. Shared and rarely changing (theme, current user): Context. Complex client state: Zustand or Redux Toolkit. Server data (lists from the API): TanStack Query or SWR, which handle caching, refetching and loading states. Interviewers like this split because it shows you don't put everything in Redux.

Code-split routes with React.lazy, virtualise long lists, memoise expensive children, debounce search inputs, avoid big context values, and lazy-load images. Check bundle size. Always say what you measured before and after.

The event loop. I/O (network, disk) is handed to the OS or libuv's thread pool, and the JS thread moves on, so one process serves thousands of waiting connections. CPU-heavy work (image processing, big JSON) blocks everyone. Move it to worker threads, a queue, or another service.

const app = express();
app.use(express.json({ limit: "1mb" }));
app.use(helmet());                                   // security headers
app.use(cors({ origin: process.env.WEB_ORIGIN, credentials: true }));

app.get("/api/tasks", requireAuth, async (req, res, next) => {
  try {
    const { rows } = await db.query(
      "SELECT id, title, done FROM tasks WHERE team_id = $1 ORDER BY id LIMIT 50", [req.user.teamId]);
    res.json(rows);
  } catch (err) { next(err); }                       // hand errors to the error middleware
});

app.use((err, req, res, next) => {                   // 4 arguments = error handler, registered last
  req.log?.error(err);
  res.status(err.status ?? 500).json({ error: err.expose ? err.message : "Internal error" });
});

Middleware runs in order. Each one calls next() or ends the response.

Plural nouns (/tasks/42), verbs from HTTP methods, pagination (?limit=&cursor=), filtering in query params, versioning (/v1), and validation at the edge with zod or Joi. PUT replaces a resource and PATCH updates part of it; GET, PUT and DELETE should be idempotent.

• Validate all input; use parameterised queries.
• Hash passwords with bcrypt or argon2, never encrypt or store them plain.
• helmet, a strict CORS allowlist, rate limiting on login.
• Secrets in environment variables, never in git.
• Cookies HttpOnly, Secure, SameSite=Lax; CSRF protection if you use cookies for auth.
• Don't leak stack traces in production errors.

Run several processes (PM2 cluster or several containers) behind a load balancer. Keep servers stateless (sessions in Redis or Postgres), add caching, a connection pool for the database, and graceful shutdown on SIGTERM.

An index is a sorted lookup structure (usually a B-tree). It speeds up WHERE, JOIN and ORDER BY on its columns and slows down writes, because every insert updates it. A composite index (team_id, created_at) serves filters on team_id alone or both, but not on created_at alone (leftmost prefix).

Atomic (all or nothing), Consistent (constraints hold), Isolated (concurrent transactions don't see each other's half-done work), Durable (committed means saved). Transfer money, or "create order + reduce stock", inside BEGIN … COMMIT. Postgres's default isolation is Read Committed. Know that SELECT … FOR UPDATE locks rows to prevent a double-booking race.

Normalize to remove duplicated facts (a user's email lives in one row). Denormalize on purpose for read speed. N+1: loading 50 tasks, then querying the assignee for each one is 51 queries. Fix it with one JOIN, or a single WHERE id = ANY($1) batch.

Mongo suits flexible, document-shaped data read as a whole (a product with variable attributes, event logs). Postgres suits relational data with joins and strong constraints (users, teams, payments). One-to-many in Mongo: embed when the children are few and always read with the parent (an order's line items); reference when they are many or shared (a user's thousands of posts).

// aggregation: open tasks per assignee
db.tasks.aggregate([
  { $match: { done: false } },
  { $group: { _id: "$assigneeId", open: { $sum: 1 } } },
  { $sort: { open: -1 } }
]);

Type hints become validation, serialisation and API docs automatically. Pydantic parses input into typed models and returns a 422 with details when it's invalid.

async def runs on the event loop, so use it with async libraries (httpx, asyncpg). A blocking call inside it (requests.get, time.sleep) freezes every request. Plain def endpoints run in a thread pool, which is safer for blocking code.

• List vs tuple vs set vs dict, and their lookup costs (set and dict are O(1) on average).
• Generators and yield for streaming big data.
• Decorators: a function wrapping a function (how @app.post works).
• Virtual environments and pinning dependencies.
• The GIL: threads don't run Python bytecode in parallel; use processes for CPU work, async for I/O.

Server sessions: the cookie holds a random id, and the server looks it up. Easy to revoke, needs a store. JWT: signed claims the server verifies without a lookup. Scales simply, but you can't revoke one early, so keep access tokens short (5–15 minutes) and use a refresh token that can be revoked and is rotated on use. For a normal web app, an HttpOnly session cookie is the safest default. Never keep tokens in localStorage if you can avoid it, because any XSS can read it.

const can = { admin: ["task:delete", "task:write", "task:read"], member: ["task:write", "task:read"], viewer: ["task:read"] };
const requirePerm = (perm) => (req, res, next) =>
  can[req.user.role]?.includes(perm) ? next() : res.status(403).json({ error: "Forbidden" });

app.delete("/api/tasks/:id", requireAuth, requirePerm("task:delete"), deleteTask);
// AND check ownership in the query: WHERE id = $1 AND team_id = $2   (else: IDOR bug)

Always check on the server. Hiding a button in React is UX, not security. The classic bug is IDOR (insecure direct object reference): /tasks/43 belongs to another team and you return it anyway.

XSS: attacker script runs in your page and can read anything JS can (so tokens in localStorage are exposed). Defence: escape output (React does by default; beware dangerouslySetInnerHTML), plus a Content-Security-Policy. CSRF: another site makes the browser send a request with your cookies. Defence: SameSite cookies, CSRF tokens, checking Origin.

An image is a read-only template; a container is a running instance of it. Each instruction is a cached layer. Copy package.json and install before copying the source, so code changes don't reinstall dependencies.

function twoSum(nums, target) {
  const seen = new Map();                    // value -> index
  for (let i = 0; i < nums.length; i++) {
    const need = target - nums[i];
    if (seen.has(need)) return [seen.get(need), i];
    seen.set(nums[i], i);
  }
  return [];
}

One pass. Say the complexity out loud: O(n) time, O(n) space.

function longestUnique(s) {
  const last = new Map();                    // char -> last index seen
  let start = 0, best = 0;
  for (let i = 0; i < s.length; i++) {
    if (last.has(s[i]) && last.get(s[i]) >= start) start = last.get(s[i]) + 1;
    last.set(s[i], i);
    best = Math.max(best, i - start + 1);
  }
  return best;                               // "abcabcbb" -> 3
}

API: POST /links {url} → {code}, GET /:code → 301 redirect. Table: links(code PK, url, owner_id, created_at, clicks). Code: base62 of an auto-increment id, or 7 random characters with a uniqueness check. Reads far outnumber writes, so cache hot codes in Redis. Count clicks asynchronously (a queue or a batched increment) so redirects stay fast. Add rate limiting and a malicious-URL check.

One IdP (Keycloak or Okta) with OIDC. Each app is a client with its own redirect URI. Apps keep their own sessions; global logout uses the IdP's end-session endpoint plus short session lifetimes. Roles come from IdP groups mapped to app permissions. Talk about token verification with JWKS caching, clock skew, and what happens when the IdP is down (existing sessions keep working; new logins fail with a clear message).

Producers put events on a queue (Redis streams, RabbitMQ or SQS). Workers fan out to email, SMS and push providers, with retries and a dead-letter queue. Store user preferences. Make sending idempotent with an event id, so a retry doesn't send twice.

// npm i openid-client express-session   (API shape varies by version: check its README)
import * as client from "openid-client";

const config = await client.discovery(new URL(process.env.OIDC_ISSUER), process.env.OIDC_CLIENT_ID, process.env.OIDC_CLIENT_SECRET);

app.get("/auth/login", async (req, res) => {
  const verifier = client.randomPKCECodeVerifier();
  req.session.pkce = verifier;
  req.session.state = client.randomState();
  const url = client.buildAuthorizationUrl(config, {
    redirect_uri: process.env.OIDC_REDIRECT_URI, scope: "openid email profile",
    code_challenge: await client.calculatePKCECodeChallenge(verifier), code_challenge_method: "S256",
    state: req.session.state,
  });
  res.redirect(url.href);
});

app.get("/auth/callback", async (req, res) => {
  const tokens = await client.authorizationCodeGrant(config, new URL(req.originalUrl, process.env.APP_URL), {
    pkceCodeVerifier: req.session.pkce, expectedState: req.session.state,
  });
  const claims = tokens.claims();                    // verified id_token: sub, email, ...
  req.session.user = await upsertUser(claims.sub, claims.email);
  res.redirect("/");
});

Library APIs change between major versions, so treat this as the shape of the solution and follow the library's current README. What matters in the interview is that you can explain each line against the flow in section 8.1.

S: Our multiplayer game started refusing every player after a deploy. T: I owned the game service and had to restore it during peak hours. A: I checked logs, found the token check was calling the wrong main-API URL from a stale environment variable, fixed the config, added a startup check that fails loudly on a mismatch, and documented it. R: Restored in about 20 minutes, and that class of outage hasn't happened again.

Positive and forward-looking: "I want to work on a larger product with a team, especially on SSO and AI features like this role describes." Never criticise a current employer.

"Based on the role and my experience with React, Node, Postgres and FastAPI, I'm looking at ₹X–Y LPA. I'm flexible for the right role." Have your current CTC and its breakup ready if asked.

"Owning major features end to end, mentoring juniors, and going deeper into backend and AI systems."

Always yes: "What would success look like in my first 90 days?" "How do you do code reviews?" "Which auth provider do you use for SSO?" (That last one shows you read the JD.)