Question 1

A React TypeScript frontend expects camelCase JSON keys, while Django REST Framework (DRF) serializes model fields in snake_case. Furthermore, DRF pagination envelopes (count, next, previous, results) differ from React Query expectations. How do you configure serialization middleware and TypeScript API client transformers to bridge this gap?

Accepted Answer

The cleanest fix is to keep Python and JS each in their own natural casing and translate at the boundary rather than forcing snake_case into your React code or camelCase into your Django models. On the DRF side, add `djangorestframework-camel-case`'s `CamelCaseJSONRenderer`/`CamelCaseJSONParser` (or write a thin middleware that walks the response dict) as the default renderer/parser classes — DRF then automatically converts `first_name` to `firstName` on the way out and back on the way in, so serializers and views stay untouched.

On the pagination envelope, DRF's default `PageNumberPagination` returns `{count, next, previous, results}`, while most React Query setups just want the array plus a cursor/page. Rather than reshaping this in every component, write one `select` function (or a shared Axios response interceptor) that unwraps `results` into `data` and maps `next`/`previous` into whatever your `useInfiniteQuery`'s `getNextPageParam` expects — a single adapter function, not per-endpoint code.

```ts
// api/transform.ts
export function unwrapPage<T>(res: { results: T[]; next: string | null }) {
  return { items: res.results, nextCursor: extractPage(res.next) };
}
```

That keeps DRF idiomatic on the backend and React Query idiomatic on the frontend, with exactly one seam where the two conventions meet.

Question 2

You are building a live notification system using Django Channels (ASGI + Redis channel layer) and React. How do you implement a robust React custom hook that handles WebSocket connection lifecycles, exponential backoff reconnection, heartbeat ping/pongs, and authentication ticket handshakes?

Accepted Answer

The hook needs to own three concerns: the socket lifecycle, a reconnect strategy that backs off instead of hammering the server, and re-authentication on every new connection since Channels doesn't persist HTTP session state across a fresh WebSocket handshake.

A typical implementation keeps the WebSocket instance and a retry count in refs (not state, so reconnect logic doesn't re-trigger effects), computes the next delay as `Math.min(1000 * 2 ** attempt, 30000)` with a little jitter, and on `onclose` schedules a `setTimeout` to reconnect unless the component has unmounted or the close was intentional (code 1000). Authentication is handled by fetching a short-lived ticket from a Django REST endpoint first, then opening `wss://.../ws/notifications/?ticket=<ticket>` — Channels' consumer validates the ticket in `connect()` before accepting, since cookies aren't reliably sent on cross-origin WS upgrades.

```js
function useNotificationSocket(getTicket) {
  const wsRef = useRef(null);
  const attemptRef = useRef(0);
  useEffect(() => {
    let cancelled = false;
    async function connect() {
      const ticket = await getTicket();
      if (cancelled) return;
      const ws = new WebSocket(`${WS_URL}?ticket=${ticket}`);
      wsRef.current = ws;
      ws.onopen = () => { attemptRef.current = 0; };
      ws.onclose = (e) => {
        if (cancelled || e.code === 1000) return;
        const delay = Math.min(1000 * 2 ** attemptRef.current++, 30000);
        setTimeout(connect, delay);
      };
    }
    connect();
    return () => { cancelled = true; wsRef.current?.close(1000); };
  }, [getTicket]);
}
```

A heartbeat (client sends `{type: "ping"}` every ~20s, server echoes `pong`) lets the client detect a half-open connection — some proxies/load balancers silently drop idle WebSockets without firing `onclose` — and force-reconnect if no pong arrives in time.

Question 3

A React client needs to upload 5GB video files. Instead of routing multi-gigabyte payloads through Django/Gunicorn, design an architecture where Django generates S3 presigned multipart upload URLs, React coordinates chunked uploads directly to S3 via Axios, and Django verifies completion via an S3 webhook.

Accepted Answer

The core idea is to never let the 5GB file touch the Django process at all — Gunicorn workers have request size and timeout limits that make them a bad fit for large uploads, and routing that much traffic through your app server for something S3 does natively wastes bandwidth and worker capacity.

The flow: React asks Django for an upload "intent" (file name, size, content type). Django calls `create_multipart_upload` on S3 and returns the `UploadId` plus a set of presigned URLs, one per ~50-100MB part (calculated from file size). React slices the File object with `File.prototype.slice()`, PUTs each chunk directly to its presigned URL via Axios (with progress tracking and per-part retry), collects the returned `ETag` for each part, then calls a Django endpoint to finish — which calls `complete_multipart_upload` with the part/ETag list. Finally, S3 event notifications (via SQS or a Lambda-triggered webhook) tell Django the object landed, so completion status isn't just trusted from the client — a malicious or buggy frontend claiming "done" doesn't matter if Django only marks the upload verified once S3 itself confirms it.

```python
# django view
def initiate_upload(request):
    resp = s3.create_multipart_upload(Bucket=BUCKET, Key=key, ContentType=content_type)
    upload_id = resp["UploadId"]
    urls = [
        s3.generate_presigned_url("upload_part", Params={
            "Bucket": BUCKET, "Key": key, "UploadId": upload_id, "PartNumber": i + 1
        }, ExpiresIn=3600)
        for i in range(part_count)
    ]
    return JsonResponse({"uploadId": upload_id, "urls": urls})
```

This keeps Django's job limited to issuing short-lived credentials and verifying completion — the actual bytes move client-to-S3 with no app-server hop.

Question 4

A React user triggers an expensive PDF generation task. Django initiates an asynchronous Celery task and immediately returns a task_id. How do you design a React Query polling hook that inspects task status from a Django endpoint, dynamically adjusts polling intervals, and stops polling upon task resolution or failure?

Accepted Answer

Django kicks off the Celery task and immediately returns `{task_id}` with a 202, so the request never blocks on PDF generation. React Query then polls a `GET /tasks/{task_id}/status/` endpoint that reads the task's state via Celery's result backend (Redis/DB).

The trick is making the polling stop itself and back off, rather than hammering the endpoint every second forever. `useQuery`'s `refetchInterval` can be a function of the latest data — return a number while the task is `PENDING`/`STARTED`, and `false` once it hits `SUCCESS` or `FAILURE`, which halts polling automatically.

```js
const { data } = useQuery({
  queryKey: ["task", taskId],
  queryFn: () => fetchTaskStatus(taskId),
  refetchInterval: (query) => {
    const status = query.state.data?.status;
    if (status === "SUCCESS" || status === "FAILURE") return false;
    return status === "PENDING" ? 2000 : 1000; // slower before it even starts
  },
});
```

On the Django side, the status endpoint should return a small, consistent shape (`status`, `progress`, `resultUrl`/`error`) regardless of Celery's internal state names, so the frontend doesn't need to know Celery-specific vocabulary — that mapping lives in one serializer, not scattered across components.

Question 5

To prevent API contract drift between a FastAPI backend and a React frontend, design an automated CI pipeline that extracts the OpenAPI schema from Pydantic models and generates typed TypeScript fetch clients consumed by React.

Accepted Answer

FastAPI already generates a full OpenAPI 3.x schema from your Pydantic models and route signatures for free at `/openapi.json` — the trick is making sure that schema is treated as a build artifact your CI actually diffs and regenerates from, not something the frontend hand-copies types from.

A typical pipeline: a CI step boots the FastAPI app (or imports the `app` object directly and calls `app.openapi()` without starting a server) to dump `openapi.json`, then runs a generator like `openapi-typescript` or `orval` against that file to produce typed fetch/React Query hooks into a shared package. That generated output is committed (or built as an npm package) so a backend change that renames a field or changes a type produces a visible TypeScript compile error in the frontend PR, catching contract drift before it reaches runtime.

```bash
# ci step
python -c "import json; from app.main import app; json.dump(app.openapi(), open('openapi.json','w'))"
npx openapi-typescript openapi.json -o src/api/schema.d.ts
```

The key discipline is running this generation on every backend PR (not just occasionally) and failing CI if the generated file changed but wasn't committed — that's what actually prevents drift rather than just making drift easier to fix after the fact.

Question 6

You are building a React SPA authenticated via Django's built-in session authentication framework. Walk through configuring django-cors-headers, reading the csrftoken cookie in React, and configuring Axios to send the X-CSRFToken header on state-changing requests.

Accepted Answer

Since the React SPA and Django API are on different origins (or at least different ports in dev), `django-cors-headers` needs `CORS_ALLOWED_ORIGINS` set to the frontend's origin and, critically, `CORS_ALLOW_CREDENTIALS = True` — without that, the browser won't attach the session cookie to cross-origin requests at all. Axios needs the mirror setting, `axios.defaults.withCredentials = true`, or cookies won't be sent/received either.

Django's CSRF protection works via a `csrftoken` cookie that's readable by JS (unlike the session cookie, which is httpOnly) — the frontend reads it directly from `document.cookie` and echoes it back as an `X-CSRFToken` header on every POST/PUT/PATCH/DELETE. `CSRF_TRUSTED_ORIGINS` must also list the frontend's origin in modern Django versions.

```js
axios.defaults.withCredentials = true;
axios.interceptors.request.use((config) => {
  const csrftoken = document.cookie.match(/csrftoken=([^;]+)/)?.[1];
  if (csrftoken && ["post", "put", "patch", "delete"].includes(config.method)) {
    config.headers["X-CSRFToken"] = csrftoken;
  }
  return config;
});
```

One gotcha: the CSRF cookie is only set once the browser has hit an endpoint that calls `django.middleware.csrf.get_token()` (or a view decorated with `@ensure_csrf_cookie`) — a pure SPA that never renders a Django template may need an explicit `/api/csrf/` bootstrap endpoint the frontend calls on load.

Question 7

In a React SPA using djangorestframework-simplejwt, an expired access token triggers multiple parallel API calls to fail with 401 simultaneously. How do you implement an Axios response interceptor with a subscriber queue to ensure only a single token refresh request is made to Django while other requests pause?

Accepted Answer

The failure mode is: five components each fire a request, the access token has expired, all five get 401s simultaneously, and a naive interceptor fires five separate refresh calls to Django — wasteful, and worse, `simplejwt`'s rotation settings can invalidate a refresh token after first use, so the second-through-fifth refresh calls would fail outright.

The fix is a single in-flight refresh promise that every 401 handler awaits, plus a subscriber queue for requests that arrive while a refresh is already underway.

```js
let isRefreshing = false;
let queue = [];

axios.interceptors.response.use(null, async (error) => {
  const { config, response } = error;
  if (response?.status !== 401 || config._retry) throw error;
  config._retry = true;

if (isRefreshing) {
    return new Promise((resolve) => queue.push(() => resolve(axios(config))));
  }
  isRefreshing = true;
  try {
    const { data } = await axios.post("/auth/refresh/", { refresh: getRefreshToken() });
    setAccessToken(data.access);
    queue.forEach((cb) => cb());
    queue = [];
    return axios(config);
  } catch (e) {
    logout();
    throw e;
  } finally {
    isRefreshing = false;
  }
});
```

Every queued request just resolves once the single refresh completes, using the new token — no duplicate refresh calls, and no dropped requests.

Question 8

How do you architect a social authentication flow (e.g., Sign in with Google) between a decoupled React frontend and a Django backend using django-allauth headless/REST endpoints, ensuring authorization codes are securely exchanged without exposing client secrets?

Accepted Answer

The security requirement driving the whole design is that the OAuth client secret must never reach the browser — a React SPA is a "public client" in OAuth terms, so it can't hold secrets safely. The architecture splits the flow between the two apps: React initiates the redirect to Google (or renders Google's own button), Google redirects back to a Django callback URL (not a React route) with an authorization code, and Django — which does hold the client secret — exchanges that code server-side via `django-allauth`'s headless REST endpoints.

PKCE (Proof Key for Code Exchange) adds a second layer even without a client secret involved on the frontend side: before redirecting, React (or Django, depending on where the flow starts) generates a random `code_verifier`, hashes it into a `code_challenge`, and sends the challenge with the initial auth request; the final code exchange must present the original verifier, so even if the authorization code were intercepted in transit, it's useless without the verifier that only the initiating client has.

Once Django completes the exchange, it either sets its own first-party session cookie (if using cookie-based auth in the SPA) or returns simplejwt tokens to React — either way, the SPA never sees Google's client secret or handles the token exchange directly, it only ever talks to Django's own `/accounts/...` endpoints for the parts allauth headless exposes.

Question 9

A Django backend enforces custom object-level permissions using DRF's has_object_permission mechanism. How do you expose permission metadata in serializer responses so the React frontend can conditionally disable action buttons while maintaining strict backend enforcement?

Accepted Answer

The pattern is to compute the same permission checks the backend would enforce and expose the boolean result as read-only serializer fields, so the UI can disable a button without duplicating (and inevitably drifting from) the actual authorization logic in `has_object_permission`.

```python
class TaskSerializer(serializers.ModelSerializer):
    can_edit = serializers.SerializerMethodField()
    can_delete = serializers.SerializerMethodField()

class Meta:
        model = Task
        fields = [..., "can_edit", "can_delete"]

def get_can_edit(self, obj):
        request = self.context["request"]
        return TaskEditPermission().has_object_permission(request, None, obj)

def get_can_delete(self, obj):
        request = self.context["request"]
        return request.user == obj.owner
```

React then reads `task.canEdit`/`task.canDelete` to grey out or hide actions — pure UX, not security. The critical discipline is that both the serializer method and the actual permission class call into the *same* underlying function (or the serializer literally instantiates the permission class, as above) rather than reimplementing the rule twice; otherwise the two checks silently diverge over time and you get a button that's enabled but 403s on click, or worse, a hidden button masking the fact that the backend check is wrong. The view's `has_object_permission` remains the only thing that actually blocks the request — the serializer field is purely advisory.

Question 10

Compare deploying a Python/React app by serving React static builds directly via Nginx while proxying /api to Gunicorn versus serving compiled React assets directly through Django using WhiteNoise, detailing caching, CDN integration, and operational trade-offs.

Accepted Answer

Serving React's built assets via Nginx with `/api` proxied to Gunicorn is the more scalable, more standard setup: Nginx is purpose-built for static file serving (sendfile, gzip/brotli, efficient caching headers, gzip_static for pre-compressed files) and can front a CDN trivially by just pointing the CDN at the same asset paths. It also decouples deploys — you can push a new frontend build without touching the Django/Gunicorn process at all, and Nginx handles connection-level concerns (buffering slow clients, TLS termination) that would otherwise tie up Gunicorn worker processes.

WhiteNoise serving through Django is simpler operationally — one process to deploy, no separate web server to configure — which is genuinely a good trade for a small app or early-stage project where ops complexity costs more than it saves. It compresses and fingerprints assets at collectstatic time and sets long-lived cache headers via `CompressedManifestStaticFilesStorage`, so it's not "wrong," just a worse fit once traffic or team size grows: every static asset request still goes through a Python WSGI worker, competing for the same limited worker pool that's also serving API requests.

The practical dividing line: Nginx+Gunicorn for anything expecting real traffic or wanting CDN offload; Django+WhiteNoise for internal tools, MVPs, or anywhere a single deployable unit matters more than serving efficiency.

Question 11

Construct a docker-compose.yml local development environment that runs a Django API with PostgreSQL, Redis, a Celery worker with hot-reloading, and a React frontend with Vite HMR, managing container networking and volume mounts cleanly.

Accepted Answer

The main things to get right are volume mounts for hot reload (so code changes on the host reflect inside containers without a rebuild) and making sure dependent services are actually ready, not just started, before the app tries to use them.

```yaml
services:
  db:
    image: postgres:16
    environment: { POSTGRES_DB: app, POSTGRES_PASSWORD: dev }
    volumes: [pgdata:/var/lib/postgresql/data]

redis:
    image: redis:7

backend:
    build: ./backend
    command: python manage.py runserver 0.0.0.0:8000
    volumes: [./backend:/app]
    ports: ["8000:8000"]
    depends_on: [db, redis]
    environment: { DATABASE_URL: postgres://postgres:dev@db:5432/app }

worker:
    build: ./backend
    command: celery -A myproject worker -l info --autoreload
    volumes: [./backend:/app]
    depends_on: [db, redis]

frontend:
    build: ./frontend
    command: pnpm dev --host
    volumes: [./frontend:/app, /app/node_modules]
    ports: ["5173:5173"]

volumes: { pgdata: }
```

Two details matter: mounting `./backend:/app` gives live code reload, but `/app/node_modules` as its own anonymous volume on the frontend prevents the host's (possibly OS-mismatched or absent) `node_modules` from overwriting the one installed inside the container image. And `depends_on` only waits for the container to *start*, not for Postgres to actually accept connections — for anything beyond local dev convenience, a wait-for script or Postgres's own healthcheck plus `condition: service_healthy` avoids race conditions on cold start.

Question 12

Configure end-to-end distributed tracing using Sentry across a React frontend and a Django backend so that client-side user interactions, HTTP fetch spans, and backend Django database queries are linked under a single unified trace ID.

Accepted Answer

Sentry links frontend and backend spans into one trace by having the browser SDK inject two headers — `sentry-trace` and `baggage` — onto outgoing fetch/XHR calls, which the backend SDK reads and continues instead of starting a fresh trace.

On React, `@sentry/react`'s `browserTracingIntegration` automatically instruments `fetch`/`XHR` and propagates those headers, but only to origins listed in `tracePropagationTargets` — by default Sentry won't attach tracing headers to arbitrary third-party domains (a CORS/security consideration), so your API's origin needs to be explicitly whitelisted there or the trace breaks at the network boundary.

```js
Sentry.init({
  dsn: FRONTEND_DSN,
  integrations: [Sentry.browserTracingIntegration()],
  tracePropagationTargets: ["https://api.myapp.com", /^\/api/],
  tracesSampleRate: 0.2,
});
```

On the Django side, `sentry-sdk`'s Django integration (with `DjangoIntegration()` and DB query spans enabled) picks up the incoming `sentry-trace` header automatically via middleware and attaches its DB/cache spans as children of that same trace — so a slow page load in Sentry's UI can be expanded from the initial click, through the fetch, into the exact Django ORM query that took the time, all under one trace ID. Sampling rates should generally match (or the backend's should be driven by the incoming trace's sampling decision) so you don't end up with orphaned backend spans for traces the frontend decided not to sample.

Question 13

You are deploying a database migration that splits a Django database column into two new fields while the React production frontend is actively sending requests. How do you design a multi-stage expand-and-contract deployment to guarantee zero downtime across backend and frontend versions?

Accepted Answer

The core problem is that a naive migration (rename column, or split it and drop the old one in the same deploy) creates a window where old backend code and old cached frontend bundles are still running against a schema they no longer understand, causing 500s until every server and every client tab has picked up the new version.

Expand-and-contract breaks this into stages that are each independently safe to run while the *previous* version of the app is still live:

1. **Expand**: add the two new nullable columns via a migration; deploy backend code that writes to both old and new columns on every write, but still reads from the old one. Nothing about the API response shape changes yet.
2. **Backfill**: run a data migration (chunked, not a single UPDATE on a huge table) to populate the new columns from existing rows.
3. **Cutover**: deploy backend code that reads from the new columns and stops writing to the old one. The API response shape can now change to expose the new fields — but only once you're confident every client (including any stale cached frontend bundle still running for users who haven't refreshed) can handle it, which usually means versioning the API response additively (add fields, don't remove the old ones yet) for one more release.
4. **Contract**: once you're confident no old backend version and no stale frontend build depends on the old column, drop it in a final migration.

Each stage is a separate deploy, and at every point in between, both "old" and "new" code paths would work against the current schema — that's what makes it safe to deploy backend and roll out the frontend independently, rather than needing them to land in the same atomic release.

Question 14

How do you configure Playwright E2E tests to run against Django's StaticLiveServerTestCase, ensuring the test database is reset cleanly between test runs without leaving orphaned database rows or locking the test database?

Accepted Answer

`StaticLiveServerTestCase` spins up a real Django dev server (serving static files too) on a random port for the duration of the test class, which Playwright then points a real browser at — this is what lets you test actual rendered pages and network requests rather than mocking the backend entirely.

The database reset problem comes from `LiveServerTestCase` running the live server in a separate thread that shares the same test database connection as the test itself — this requires `TransactionTestCase`-style behavior (which truncates tables between tests, rather than the faster rollback-a-transaction approach plain `TestCase` uses) because the live server thread needs to see committed data, and a rolled-back transaction wouldn't be visible to it.

```python
from django.contrib.staticfiles.testing import StaticLiveServerTestCase
from playwright.sync_api import sync_playwright

class LoginFlowTest(StaticLiveServerTestCase):
    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        cls.playwright = sync_playwright().start()
        cls.browser = cls.playwright.chromium.launch()

def setUp(self):
        self.page = self.browser.new_page()
        UserFactory(email="test@example.com", password="pass1234")

def test_login(self):
        self.page.goto(f"{self.live_server_url}/login")
        ...

def tearDown(self):
        self.page.close()  # table truncation between tests is handled automatically
```

To avoid orphaned rows or lock contention, keep each test's fixtures self-contained (factory_boy per test, not shared module-level fixtures) and rely on Django's built-in truncation between tests rather than manually cleaning up — hand-rolled cleanup in `tearDown` is exactly what tends to leave orphaned rows when a test fails partway through.

Question 15

Your React frontend uses Mock Service Worker (MSW) for component testing. How do you generate mock response fixtures directly from Django model factories (e.g., factory_boy) or DRF serializer test dumps to ensure frontend mocks stay synchronized with backend models?

Accepted Answer

The risk with hand-written MSW mocks is that they silently drift from what the real DRF serializer actually returns — a backend field rename doesn't break the mocked tests at all, only real usage, which defeats a big part of the value of contract testing.

The fix is to generate the MSW fixture JSON from the same objects Django would actually serialize, rather than typing out JSON by hand. A management command (or a pytest fixture that also writes to disk) instantiates a `factory_boy` factory, runs it through the real DRF serializer, and dumps the `.data` to a fixtures directory the frontend test suite reads from.

```python
# management/commands/export_msw_fixtures.py
def handle(self, *args, **kwargs):
    task = TaskFactory()
    data = TaskSerializer(task).data
    Path("frontend/src/mocks/fixtures/task.json").write_text(json.dumps(data, indent=2))
```

```js
// mocks/handlers.js
import taskFixture from "./fixtures/task.json";
export const handlers = [
  http.get("/api/tasks/:id", () => HttpResponse.json(taskFixture)),
];
```

Running this export as a CI step (or a pre-commit hook) whenever backend serializers change means a renamed or removed field shows up as a `git diff` on the fixture file in the same PR that made the backend change — a reviewer sees the frontend mock changing right alongside the model, instead of finding out from a support ticket weeks later.

Question 16

In an E2E test where React initiates a long-running background task, how do you configure Celery in your test environment (e.g., eager mode vs dedicated test worker) to verify progress bars and success notifications in the React UI without creating non-deterministic timing flakiness?

Accepted Answer

`CELERY_TASK_ALWAYS_EAGER = True` runs tasks synchronously in the same process that calls `.delay()`, which is great for unit tests of task logic but wrong for E2E tests that are specifically trying to verify the *asynchronous* behavior — a progress bar animating, a "processing..." state actually appearing before "done" — because eager mode collapses the "pending → running → done" window to zero, so the UI never has time to render the intermediate state and the test passes for the wrong reason (or is flaky depending on React's render timing).

For a true E2E test of that behavior, you want a real Celery worker running against a real (or fake, e.g. `fakeredis`) broker, with the test deliberately slowing the task down or controlling its timing rather than trusting real-world task duration:

```python
@shared_task(bind=True)
def generate_pdf(self, doc_id):
    self.update_state(state="PROGRESS", meta={"percent": 50})
    if settings.TESTING:
        time.sleep(0.5)  # deterministic pause so the UI has time to render progress
    ...
```

Playwright then polls the DOM for the progress indicator (`page.wait_for_selector`) rather than asserting on wall-clock timing, and the test worker runs with `-l info --concurrency=1` so task execution order is deterministic across a test run. The general rule: eager mode for testing that task *logic* works, a real worker (even a slowed-down fake one) for testing that the *async UX* — the polling, the progress bar, the terminal states — actually behaves correctly, because those are exactly the things eager mode erases.

Question 17

Write a Cypress custom command that programmatically authenticates against a Django backend by issuing a POST to a login endpoint, capturing session and CSRF cookies, and seeding browser storage to bypass manual UI login across hundreds of test specs.

Accepted Answer

Logging in through the real UI on every spec is slow and multiplies test flakiness across hundreds of specs — a `cy.login()` custom command that hits the API directly and seeds cookies once per test is the standard fix.

```js
// cypress/support/commands.js
Cypress.Commands.add("login", (email, password) => {
  cy.request("GET", "/api/csrf/").then(() => {
    cy.getCookie("csrftoken").then((csrfCookie) => {
      cy.request({
        method: "POST",
        url: "/api/login/",
        body: { email, password },
        headers: { "X-CSRFToken": csrfCookie.value },
      });
    });
  });
});
```

`cy.request()` runs outside the browser sandbox but still shares the same browser cookie jar as the test, so Django's `Set-Cookie` response (session id) is automatically stored and sent on subsequent visits — no manual `cy.setCookie()` needed for the session itself, only for reading the CSRF token that has to be echoed back on the login POST itself.

Calling `cy.login(...)` in a `beforeEach` (or once via `cy.session()` to cache and restore the authenticated state across specs) means every spec starts already authenticated, cutting hundreds of redundant UI login flows down to a handful of API calls — and because it goes through the real login endpoint rather than faking a session token, it stays honest about testing real auth rather than just bypassing it.

Question 18

What is the GIL and how does it affect multi-threaded Python programs?

Accepted Answer

The Global Interpreter Lock is a mutex in CPython that only allows one thread to execute Python bytecode at a time, even on a multi-core machine. It exists because CPython's memory management (reference counting for garbage collection) isn't thread-safe by default, so the GIL is the simplest way to prevent two threads from corrupting an object's refcount simultaneously.

The practical effect: `threading` in Python doesn't give you real parallelism for CPU-bound work — four threads doing pure computation on a 4-core machine run barely faster than one thread, because they're all fighting for the same lock and only one runs bytecode at a time. It does still help for I/O-bound work, though, because the GIL is released during blocking I/O calls (file reads, network requests, `time.sleep`), so a thread waiting on a socket lets another thread run.

```python
# CPU-bound: threading barely helps (GIL-bound)
import threading
def burn():
    x = 0
    for _ in range(50_000_000): x += 1
threads = [threading.Thread(target=burn) for _ in range(4)]
# runs about as slow as 4 sequential calls

# I/O-bound: threading helps a lot (GIL released during I/O)
import requests
def fetch(url): requests.get(url)  # GIL released while waiting on the network
```

For real CPU parallelism you reach for `multiprocessing` (separate processes, separate GILs) or offload to a C extension/numpy that releases the GIL internally. Worth noting: PEP 703 is actively working to make the GIL optional in CPython 3.13+, the first serious attempt to remove this limitation.

Question 19

Explain the difference between a list and a tuple in Python.

Accepted Answer

Lists are mutable and tuples are immutable — that's the headline difference, but it has real consequences beyond just "can I append to it." Because tuples can't change after creation, Python can make some assumptions that let it use them safely as dictionary keys or set elements (anything hashable), while a list can never be a dict key because its hash would need to change if its contents did.

```python
coords = {}
coords[(1, 2)] = "origin-ish"     # works — tuple is hashable
# coords[[1, 2]] = "nope"          # TypeError: unhashable type: 'list'
```

Tuples are also typically used to signal "this is a fixed-shape record" (like a database row or a function returning multiple values) whereas lists signal "this is a collection that can grow or shrink." Performance-wise tuples are slightly lighter-weight (less memory overhead, marginally faster to create) since Python doesn't need to allocate for future growth, though in practice this rarely matters unless you're creating millions of them.

Question 20

What are Python decorators and how would you write one?

Accepted Answer

A decorator is a function that takes another function, wraps it with extra behavior, and returns the wrapped version — the `@decorator` syntax above a function definition is just sugar for `func = decorator(func)`.

```python
import functools
import time

def timed(func):
    @functools.wraps(func)  # preserves func.__name__, __doc__, etc.
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = func(*args, **kwargs)
        print(f"{func.__name__} took {time.perf_counter() - start:.3f}s")
        return result
    return wrapper

@timed
def slow_query():
    time.sleep(1)

slow_query()  # prints "slow_query took 1.001s"
```

`functools.wraps` is easy to forget but matters in real code — without it, `slow_query.__name__` would be `"wrapper"`, which breaks introspection, debuggers, and anything relying on function metadata (like some testing frameworks or API routers). Common real-world decorators include Django's `@login_required`, Flask/FastAPI's route decorators, and `@property`/`@staticmethod`/`@lru_cache` from the standard library — all following this same wrap-and-return pattern.

Question 21

Explain generators and the yield keyword with an example.

Accepted Answer

A generator function looks like a normal function but uses `yield` instead of `return`, which turns it into a factory for an iterator that produces values lazily, one at a time, instead of computing and holding an entire sequence in memory up front.

```python
def read_large_file(path):
    with open(path) as f:
        for line in f:
            yield line.strip()

for line in read_large_file("huge_log.txt"):  # never loads the whole file into memory
    if "ERROR" in line:
        print(line)
```

Each call to `next()` on the generator resumes execution right after the last `yield`, keeping local variables alive between calls — that's the key mechanic that makes it different from a regular function, which forgets everything once it returns. This matters for anything processing large or infinite sequences: reading a multi-gigabyte file line by line, streaming API pagination, or an infinite counter — a generator handles all of these with constant memory, where building a full list up front would either be wasteful or literally impossible.

Question 22

What's the difference between deep copy and shallow copy in Python?

Accepted Answer

`copy.copy()` (shallow) creates a new outer object but reuses references to the same nested objects inside it; `copy.deepcopy()` recursively copies everything, so nested mutable objects are independent too.

```python
import copy
original = {"tags": ["python", "react"]}
shallow = copy.copy(original)
deep = copy.deepcopy(original)

shallow["tags"].append("django")
print(original["tags"])  # ['python', 'react', 'django'] — shared list, mutation leaks through
print(deep["tags"])      # ['python', 'react'] — fully independent
```

The bug this causes in practice: someone shallow-copies a config dict or a list of lists thinking they now have an independent copy, mutates a nested list, and is baffled when the "original" also changed — because the shallow copy only duplicated the top-level container, not what it points to. For flat structures (a dict of strings/numbers) shallow and deep copy behave identically since there's nothing nested to share; the distinction only bites once there's mutable state nested inside the thing you're copying.

Question 23

Why is using a mutable default argument (like a list) in a Python function dangerous?

Accepted Answer

Python evaluates default argument values exactly once, when the function is *defined*, not each time it's called — so a mutable default like `[]` or `{}` is actually the same object shared across every call that doesn't explicitly pass its own value.

```python
def add_item(item, bucket=[]):   # BUG: bucket is created once, at def time
    bucket.append(item)
    return bucket

add_item("a")   # ['a']
add_item("b")   # ['a', 'b']  <- surprise: previous call's data is still there
```

The fix is the standard idiom: default to `None` and create the mutable object fresh inside the function body.

```python
def add_item(item, bucket=None):
    if bucket is None:
        bucket = []
    bucket.append(item)
    return bucket
```

This is one of Python's most common beginner traps precisely because it doesn't fail loudly — the function works correctly the first time it's called, and only misbehaves once it's called again without an explicit argument, which is exactly the kind of bug that slips through code review and shows up as a weird production issue (e.g. a "shared" cache that grows unexpectedly across unrelated requests).

Question 24

Explain *args and **kwargs in Python function signatures.

Accepted Answer

`*args` collects any extra positional arguments into a tuple, and `**kwargs` collects extra keyword arguments into a dict — both let a function accept a variable, unknown-in-advance number of arguments.

```python
def log_call(func_name, *args, **kwargs):
    print(f"{func_name} called with args={args}, kwargs={kwargs}")

log_call("create_user", "alice", role="admin", active=True)
# create_user called with args=('alice',), kwargs={'role': 'admin', 'active': True}
```

The reverse usage — unpacking — is just as common: `func(*my_list, **my_dict)` spreads a list into positional args and a dict into keyword args at the call site. This pattern shows up constantly in wrapper/decorator code (forwarding whatever arguments the caller passed through to the wrapped function without needing to know its exact signature) and in Django/DRF, where things like `**kwargs` in URL routing pass captured path parameters straight into view methods.

Question 25

What is the difference between `is` and `==` in Python?

Accepted Answer

`==` checks value equality (do these objects represent the same value?), while `is` checks identity (are these literally the same object in memory, i.e. do they have the same `id()`?).

```python
a = [1, 2, 3]
b = [1, 2, 3]
print(a == b)   # True — same contents
print(a is b)   # False — two distinct list objects

c = a
print(a is c)   # True — c is literally the same object as a
```

The classic gotcha is small integers and short strings: CPython caches small ints (-5 to 256) and interns some string literals, so `1 is 1` or `"abc" is "abc"` often (but not reliably, and not guaranteed by the language spec) returns `True` — relying on that is a bug waiting to happen. The one place `is` is actually the *correct* tool, not just a coincidence, is comparing against singletons: always use `x is None` rather than `x == None`, since `None` is a true singleton and some custom classes override `__eq__` in ways that could return unexpected results when compared against `None`.

Question 26

What are Python context managers and the `with` statement used for?

Accepted Answer

A context manager guarantees that setup and cleanup code run in pairs, even if an exception happens in between — that's the whole point of `with`. The classic example is file handling: `with open(...) as f:` guarantees `f.close()` runs whether the block finishes normally or raises.

```python
class DatabaseTransaction:
    def __enter__(self):
        self.conn = get_connection()
        self.conn.begin()
        return self.conn
    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type:
            self.conn.rollback()
        else:
            self.conn.commit()
        self.conn.close()
        return False  # don't suppress the exception

with DatabaseTransaction() as conn:
    conn.execute("UPDATE ...")
    # commits automatically if no exception; rolls back and re-raises if one happens
```

`__enter__` runs at the start of the block and its return value is bound to the `as` variable; `__exit__` always runs at the end, receiving exception info if one occurred, which is what lets it decide whether to commit or roll back. The `contextlib.contextmanager` decorator lets you write the same thing as a generator function with a single `yield` splitting setup from teardown, which is usually less boilerplate than a full class for simple cases.

Question 27

Explain list comprehensions vs generator expressions — when would you use each?

Accepted Answer

Both express "build a sequence by transforming/filtering another sequence," but a list comprehension `[x for x in ...]` builds the entire list in memory immediately, while a generator expression `(x for x in ...)` produces values lazily, one at a time, only as they're consumed.

```python
# list comprehension — all 10 million squares exist in memory at once
squares = [x**2 for x in range(10_000_000)]

# generator expression — values computed on demand, ~constant memory
squares_gen = (x**2 for x in range(10_000_000))
total = sum(squares_gen)  # sums lazily, never holds the full list
```

Use a list comprehension when you need to index into the result, iterate over it multiple times, or need its length — a generator can only be consumed once and doesn't support `len()` or indexing. Use a generator expression when you're just going to feed the values into another function once (`sum()`, `any()`, a `for` loop) and the full materialized list would be wasteful or, for very large/infinite sequences, impossible to hold in memory at all.

Question 28

What are Python descriptors and how does the `property` built-in use them under the hood?

Accepted Answer

A descriptor is any object whose class defines `__get__`, `__set__`, or `__delete__`, and which is used as a *class attribute* — Python's attribute lookup machinery (`__getattribute__`) special-cases these, routing `instance.attr` through the descriptor's methods instead of just returning whatever's in `instance.__dict__`.

`property` is the descriptor almost everyone uses without realizing it's one: `@property` is implemented entirely as a descriptor class with `__get__`/`__set__` that call the getter/setter functions you defined.

```python
class Celsius:
    def __set_name__(self, owner, name):
        self.name = "_" + name
    def __get__(self, instance, owner):
        return getattr(instance, self.name, 0)
    def __set__(self, instance, value):
        if value < -273.15:
            raise ValueError("below absolute zero")
        setattr(instance, self.name, value)

class Weather:
    temp = Celsius()  # reusable across as many attributes/classes as needed

w = Weather()
w.temp = 25       # calls Celsius.__set__
print(w.temp)     # calls Celsius.__get__
```

The reason you'd hand-write a descriptor instead of just using `@property` is reuse: a property is defined once per attribute per class, but a descriptor class like the one above can be instantiated as many times as you want across many attributes and classes with the validation logic written exactly once — Django's ORM fields, SQLAlchemy's column attributes, and `functools.cached_property` are all real descriptors doing exactly this under the hood.

Question 29

What are Python metaclasses, and when would you actually need one instead of a simpler alternative?

Accepted Answer

A metaclass is "the class of a class" — just as a regular class controls how its instances are created and behave, a metaclass controls how *classes themselves* are created. By default every class's metaclass is `type`; writing `class Meta(type): ...` and using `class Foo(metaclass=Meta):` lets you hook into class creation itself, before any instance ever exists.

```python
class EnforceInterface(type):
    def __new__(mcs, name, bases, namespace):
        if bases and "process" not in namespace:
            raise TypeError(f"{name} must implement process()")
        return super().__new__(mcs, name, bases, namespace)

class Plugin(metaclass=EnforceInterface):
    def process(self): ...

class BrokenPlugin(metaclass=EnforceInterface):  # raises TypeError immediately at import time
    pass
```

Honestly, most of the time you think you need a metaclass, a class decorator or `__init_subclass__` (a simpler hook added in Python 3.6 specifically to cover the common cases metaclasses were being overused for) does the job with far less complexity — `__init_subclass__` runs whenever a subclass is defined, without needing a separate metaclass hierarchy at all. Real, justified metaclass usage is rare: Django's ORM uses one to collect `Field` declarations into `Model._meta` at class-definition time, and ABCs (`abc.ABCMeta`) use one to enforce abstract methods — both cases where you genuinely need to intercept and transform the class-creation process itself, not just add behavior to instances.

Question 30

What is monkey patching in Python, and what's a legitimate use case versus a risky one?

Accepted Answer

Monkey patching means modifying a class or module's behavior at runtime, from outside its own definition — reassigning an attribute or method on an already-imported object rather than editing its source.

```python
# legitimate: patching a third-party library in tests
import requests
def fake_get(url, **kwargs):
    class FakeResponse:
        status_code = 200
        def json(self): return {"mocked": True}
    return FakeResponse()

requests.get = fake_get  # swapped for the duration of the test
```

That's the textbook legitimate use — `unittest.mock.patch` is essentially a scoped, auto-reverting version of exactly this, used constantly to isolate a test from real network calls, without needing to change the library's own code or add a dependency-injection layer just for testing.

The risky version is patching behavior in *production* code to work around a bug or missing feature in a library, or to add an "invisible" side effect (like instrumenting every method call for logging) across a class you don't own.

```python
# risky: silently changes third-party behavior everywhere it's imported
SomeLibraryClass.save = lambda self, *a, **kw: (log_it(self), original_save(self, *a, **kw))
```

The danger is that it's invisible to anyone reading the library's own code or docs — a future library upgrade can silently break the patch (if the patched method's internals changed), and any other code in the same process that imports the same class inherits the patched behavior whether it wants to or not, which is exactly the kind of action-at-a-distance bug that's brutal to debug.

Question 31

What does `__slots__` do in a Python class, and when is it worth using?

Accepted Answer

By default every Python instance carries a `__dict__` to hold its attributes, which is flexible (you can add any attribute at any time) but costs real memory — a `__dict__` per instance has meaningful overhead when you're creating millions of small objects.

```python
class PointDict:
    def __init__(self, x, y):
        self.x = x
        self.y = y

class PointSlots:
    __slots__ = ("x", "y")
    def __init__(self, x, y):
        self.x = x
        self.y = y
```

`__slots__` tells Python "this class only ever has these fixed attributes," so instances get fixed-size storage instead of a `__dict__` — typically 40-50% less memory per instance, and slightly faster attribute access since there's no dict hashing involved. The trade-off: you lose the ability to dynamically add new attributes at runtime (`point.z = 3` raises `AttributeError` if `z` isn't in `__slots__`), and multiple inheritance with slots gets fiddly (each parent's slots must not overlap). It's worth reaching for specifically when you're instantiating a class at scale — a data class representing rows from a large dataset, nodes in a big tree/graph structure — where the per-instance memory savings actually add up; for a handful of instances it's not worth the reduced flexibility.

Question 32

How does asyncio's cooperative concurrency model differ from using OS threads for I/O-bound work, and what's the biggest footgun when mixing them?

Accepted Answer

Both solve the same underlying problem — don't block the whole program while waiting on slow I/O — but with fundamentally different mechanics. OS threads are pre-emptively scheduled by the operating system; the OS can pause any thread at essentially any bytecode boundary and switch to another, which is why Python needs the GIL to keep memory operations safe. `asyncio` is cooperative: a single thread runs an event loop, and a coroutine only yields control at explicit `await` points — nothing preempts it mid-execution.

```python
# threads: OS-scheduled, each blocking call ties up a thread
import threading, requests
def fetch(url): print(requests.get(url).status_code)
threads = [threading.Thread(target=fetch, args=(u,)) for u in urls]

# asyncio: single thread, cooperative yielding at each await
import asyncio, aiohttp
async def fetch(session, url):
    async with session.get(url) as resp:
        print(resp.status)
async def main():
    async with aiohttp.ClientSession() as session:
        await asyncio.gather(*(fetch(session, u) for u in urls))
```

For I/O-bound work, asyncio typically scales to far more concurrent operations than threads — thousands of concurrent asyncio tasks cost only a bit of memory each, while thousands of OS threads each carry real stack-memory overhead and OS scheduling cost. The catch is that asyncio requires the entire call chain to be async-aware — a single blocking call (say, an unpatched synchronous DB driver) inside an `async def` blocks the *entire* event loop, stalling every other concurrent task, not just the one that made the call — whereas a blocking call inside one thread only blocks that thread. That's why mixing sync-only libraries into an asyncio codebase is the most common asyncio footgun; it needs `run_in_executor` (which runs the blocking call in a thread pool) to avoid stalling everything else.

Question 33

What is PEP 703 (the free-threaded CPython build) and why does removing the GIL matter?

Accepted Answer

PEP 703, first shipped as an opt-in build in CPython 3.13 and maturing through later releases, is the first serious, officially-adopted effort to make the GIL optional — a "free-threaded" build of CPython (`python3.13t`) can run multiple threads executing Python bytecode truly in parallel on multiple cores, something the standard build has never allowed.

The reason this is hard, and why it took this long, is that CPython's memory model relies on the GIL for more than just avoiding data races on reference counts — removing it required a redesign of reference counting itself (biased reference counting, so most refcount updates don't need atomic operations) and changes to how the object allocator and garbage collector work, since those previously assumed only one thread could be touching Python objects at a time.

The practical impact for most projects today is limited: it's an opt-in separate build, not the default interpreter, and C extensions need explicit updates (a new ABI flag) to declare themselves thread-safe under free-threading — a huge fraction of the ecosystem's native extensions needed real work to support it safely, so broad ecosystem support is a multi-year rollout, not a switch that flips overnight. What it does mean long-term is that Python's story for CPU-bound multithreading — historically "just use multiprocessing, threading won't help" — is genuinely changing, which is a bigger deal than most single-feature Python releases.

Question 34

What is Python's Method Resolution Order (MRO), and how does C3 linearization resolve diamond inheritance?

Accepted Answer

When a class inherits from multiple parents that each define the same method, Python needs a deterministic rule for which one wins — that rule is the Method Resolution Order, computed via the C3 linearization algorithm, and it's what `ClassName.__mro__` shows you.

```python
class A:
    def greet(self): return "A"
class B(A):
    def greet(self): return "B"
class C(A):
    def greet(self): return "C"
class D(B, C):
    pass

print(D.__mro__)     # (D, B, C, A, object)
print(D().greet())   # "B" — first class in MRO that defines greet()
```

The key property C3 guarantees, that naive depth-first search (which older languages/Python 2's classic classes used) doesn't, is "local precedence order" and "monotonicity" — a subclass always appears before its parents, and the order you listed the base classes in (`B, C`) is preserved and respected consistently across the whole hierarchy, even in deep diamond-inheritance graphs. If C3 can't find a consistent linearization (a genuinely contradictory inheritance order), Python raises `TypeError: Cannot create a consistent method resolution order` at class-definition time rather than silently picking an arbitrary answer.

This mostly matters in practice via `super()` — in a diamond hierarchy, `super().__init__()` calls the *next class in the MRO*, not literally "the parent class," which is exactly why cooperative multiple inheritance (each class calling `super().__init__(**kwargs)` and passing along whatever it doesn't consume) works correctly instead of skipping or double-calling a shared grandparent's `__init__`.

Question 35

What is the virtual DOM and how does React use it to update the UI efficiently?

Accepted Answer

The virtual DOM is a lightweight JavaScript object representation of what the UI should look like — a tree of plain objects describing elements, props, and children, not actual browser DOM nodes. Real DOM mutations (especially layout-triggering ones) are comparatively expensive, so React avoids touching the real DOM more than necessary by first figuring out, in memory, exactly what changed. ```jsx // before

Apple
Banana

// after state update

Apple
Banana
Cherry

``` When state changes, React builds a new virtual DOM tree, diffs it against the previous one (this diffing process is what people mean by "reconciliation"), and computes the minimal set of real DOM operations needed — in the example above, that's just "append one `

`," not "tear down and rebuild the whole list." Those minimal patches are then applied to the real DOM in one batch. The performance win isn't that virtual DOM operations are inherently faster than real DOM operations in isolation — it's that computing a diff in plain JS objects is cheap, and it lets React apply the fewest possible real DOM mutations instead of a naive implementation that might re-render everything on every state change.

Question 36

What's the difference between useState and useRef in React, and when should you use each?

Accepted Answer

Both hooks persist a value across re-renders, but they differ in the one thing that actually matters day to day: updating a `useState` value triggers a re-render, updating a `useRef` value does not. ```jsx function Timer() { const [count, setCount] = useState(0); // changing this re-renders the component const intervalRef = useRef(null); // changing this does NOT re-render useEffect(() => { intervalRef.current = setInterval(() => setCount(c => c + 1), 1000); return () => clearInterval(intervalRef.current); }, []); return

{count}

; } ``` `useState` is for anything that should show up on screen — if the UI needs to reflect a value, it belongs in state. `useRef` is for values you need to persist between renders but that shouldn't cause a re-render on their own: a timer/interval ID, a DOM node reference (`

`), a "previous value" you want to compare against, or a mutable flag like "has this effect already run." A common beginner mistake is reaching for a ref to try to read the "latest" value inside a stale closure instead of fixing the closure/dependency array — that usually just papers over a bug rather than fixing it.

Question 37

What is the purpose of the dependency array in useEffect, and what happens if you omit it?

Accepted Answer

The dependency array tells React when to re-run an effect: React re-runs the effect only when at least one value in the array has changed (by `Object.is` comparison) since the last render.

```jsx
useEffect(() => {
  fetchUser(userId).then(setUser);
}, [userId]); // re-fetches only when userId actually changes
```

Omitting the array entirely means the effect runs after *every* render, no matter what changed — usually not what you want, and a common cause of runaway re-render loops if the effect itself sets state. Passing an empty array `[]` means "run once, after the first render, and never again," which is right for one-time setup like a subscription, but wrong if the effect actually reads a prop or state value — ESLint's `react-hooks/exhaustive-deps` rule exists specifically to catch this, because an effect that reads `userId` but has `[]` as its dependency array will keep using the *first* render's `userId` forever, a subtle bug called a "stale closure." The fix is almost never to suppress the lint rule — it's to either include the missing dependency or restructure the effect (e.g. moving a stable function reference outside the component, or wrapping it in `useCallback`) so the dependency array can be honest about what the effect actually uses.

Question 38

Why does React want a stable `key` prop when rendering lists, and what goes wrong if you use the array index?

Accepted Answer

React uses the `key` prop to match elements in a list between renders — it's how React knows "this specific `

` in the new render is the same conceptual item as that specific `

` in the old render," rather than assuming position alone tells you that. ```jsx // bad: index as key {todos.map((todo, i) => )} // good: stable identity as key {todos.map((todo) => )} ``` Using the array index as the key breaks down the moment the list is reordered, filtered, or has items inserted/removed from the middle — because the index of every item after the change shifts, React thinks the item *at that index* is the same one as before, even though it now represents different data. If `TodoItem` holds any of its own internal state (an "editing" toggle, an uncontrolled input's value), that state gets attached to the wrong item after a reorder — a checkbox that appears to "jump" to the wrong row, or a text input that shows stale content, is the classic symptom of an index-as-key bug. Using a stable, unique identifier (a database ID, not the array position) means React can correctly track each item's identity across renders regardless of reordering, and can also correctly unmount/remount the item that's genuinely new or removed rather than mutating the wrong DOM node in place.

Question 39

What's the difference between controlled and uncontrolled components in React forms?

Accepted Answer

A controlled component has its value driven entirely by React state — the input's `value` comes from a state variable, and every keystroke goes through an `onChange` handler that updates that state, making React the single source of truth. An uncontrolled component lets the DOM itself hold the current value, and you read it out on demand (usually via a `ref`) rather than keeping it in sync with state on every keystroke. ```jsx // controlled function ControlledInput() { const [value, setValue] = useState(""); return setValue(e.target.value)} />; } // uncontrolled function UncontrolledInput() { const inputRef = useRef(null); const handleSubmit = () => console.log(inputRef.current.value); return ; } ``` Controlled is the default recommendation for most forms because it makes validation, conditional disabling, and formatting-as-you-type trivial — the state is always right there. Uncontrolled is a reasonable choice for very simple forms, integrating with non-React DOM code, or file inputs (`` is inherently uncontrolled since the browser owns the file value for security reasons) — and it avoids a re-render on every single keystroke, which occasionally matters for very large forms with many fields re-rendering together.

Question 40

Explain useMemo vs useCallback in React and when each is actually needed.

Accepted Answer

Both exist purely for performance — to skip expensive recomputation across re-renders — and both take a dependency array with the same re-run semantics as `useEffect`. The only real difference is what they memoize: `useMemo` caches a computed *value*, `useCallback` caches a *function reference*.

```jsx
const sortedItems = useMemo(
  () => items.slice().sort((a, b) => a.price - b.price),
  [items]
);

const handleClick = useCallback(
  () => onSelect(item.id),
  [item.id, onSelect]
);
```

`useCallback(fn, deps)` is actually just `useMemo(() => fn, deps)` under the hood — it's a convenience wrapper for the extremely common case of memoizing a callback. Both are frequently reached for prematurely: if the computation is cheap (sorting 10 items) or the function isn't passed to a memoized child (`React.memo`) or used as another hook's dependency, wrapping it in `useMemo`/`useCallback` adds complexity and a small overhead of its own without meaningfully helping — they earn their keep specifically when the computation is genuinely expensive, or when an unstable function/object reference would otherwise defeat a child's `React.memo` or retrigger another effect on every render.

Question 41

What is prop drilling and how does the Context API help solve it?

Accepted Answer

Prop drilling is passing a value down through several layers of components that don't themselves use it, purely so a component several levels deep can access it — `` passes `user` to ``, which passes it to ``, which passes it to ``, even though `Layout` and `Sidebar` have nothing to do with `user` themselves. ```jsx // prop drilling // Context API const UserContext = createContext(null); function App() { return ; } function UserBadge() { const user = useContext(UserContext); // reads directly, no drilling through Layout/Sidebar return {user.name}; } ``` Context lets any descendant subscribe directly to a value provided higher up the tree, skipping the intermediate components entirely. The trade-off worth knowing: every component that calls `useContext` on a given context re-renders whenever that context's value changes, even if the component only cares about part of it — for frequently-changing, broadly-consumed state, that can cause more re-rendering than well-targeted prop passing would, which is why Context is best for genuinely global, infrequently-changing values (theme, authenticated user, locale) rather than as a blanket replacement for all state management.

Question 42

What are React error boundaries and why can't they be implemented with hooks alone?

Accepted Answer

An error boundary is a component that catches JavaScript errors thrown during rendering anywhere in its child tree, logs them, and displays a fallback UI instead of letting the error crash the whole app to a blank white screen. ```jsx class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { logErrorToService(error, info); } render() { if (this.state.hasError) return this.props.fallback; return this.props.children; } } Something went wrong.

}> ``` Error boundaries can only be implemented as class components because they rely on two lifecycle methods — `getDerivedStateFromError` (to render a fallback UI) and `componentDidCatch` (to log the error as a side effect) — and React has never shipped hook equivalents for these; there's no `useErrorBoundary` hook, in part because the semantics of "catch an error during render and re-render something else instead" don't map cleanly onto function components' render-and-return model the way lifecycle methods on a class do. Worth knowing the limits too: error boundaries only catch errors during rendering, in lifecycle methods, and in constructors of the tree below them — they do *not* catch errors in event handlers, async code, or server-side rendering, all of which need their own `try/catch` handling.

Question 43

How does React's reconciliation algorithm decide whether to update a DOM node in place versus replace it entirely?

Accepted Answer

React's reconciliation compares the new element tree against the previous one and decides, per node, whether to update the existing DOM node in place or tear it down and create a new one — and it uses two simplifying heuristics rather than a fully general (and much slower) tree-diff algorithm, because a fully general diff of large trees is far too slow to run on every render. First, elements of different types are assumed to produce entirely different trees — if a `

` becomes a `` (or a custom component changes to a different component), React doesn't try to figure out what's reusable, it just unmounts the old subtree and mounts a fresh one, along with all local state in it. ```jsx // re-render with isEditing flipped {isEditing ? : {text}} ``` Toggling `isEditing` here unmounts one and mounts the other every time — any local state or DOM focus in the removed one is lost, which is why the same-position-but-different-type pattern above is worth avoiding for something like an editable field, where you'd want to keep the same element type and just toggle a prop instead. Second, for same-type elements, React reuses the existing DOM node and only updates the changed attributes — and for lists specifically, this is where `key` comes in: keys let React match children between renders by identity rather than assuming position tells you which old child corresponds to which new one, letting it correctly reorder/insert/remove individual list items instead of re-rendering the entire list from scratch.

Question 44

What is the difference between React.memo and useMemo?

Accepted Answer

`React.memo` wraps a whole *component* and skips re-rendering it if its props haven't changed (shallow comparison by default); `useMemo` is a hook used *inside* a component to skip recomputing a specific value. ```jsx const ExpensiveRow = React.memo(function ExpensiveRow({ item }) { return

{item.name}

; // skips re-render if `item` prop is reference-equal to last render }); function List({ items }) { const total = useMemo(() => items.reduce((s, i) => s + i.price, 0), [items]); // skips recompute return <>{items.map((item) => )}

{total}

; } ``` They're complementary, and often used together: `React.memo` on `ExpensiveRow` prevents it from re-rendering when `List` re-renders for an unrelated reason, but that only works if the `item` prop is actually the same reference each time — if `List` were creating a new object literal for `item` on every render instead of reading it from an array that only changes when its own contents change, `React.memo`'s shallow prop comparison would see a "new" object every time and re-render anyway, which is the most common reason people find `React.memo` "not working" as expected.

Question 45

What is React Fiber and why did React rewrite its reconciler around it?

Accepted Answer

Fiber is React's reconciler architecture (shipped in React 16, replacing the older "stack reconciler"), and its defining feature is that rendering work is broken into small, interruptible units instead of one big synchronous recursive tree walk that can't be paused once started.

The old stack reconciler processed the entire component tree in one uninterrupted JS call stack — for a large tree, that could block the main thread long enough to cause visibly dropped frames or unresponsive input, because JS is single-threaded and nothing else (a keystroke, an animation frame) can run until that whole recursive walk finishes. Each "fiber" is a JS object representing one unit of work for one component, structured as a linked list (child/sibling/return pointers) rather than relying on the native call stack — which means React can pause after processing a fiber, hand control back to the browser to handle something more urgent (like user input), and resume later exactly where it left off.

```
FiberNode: { type, key, child, sibling, return, pendingProps, memoizedState, ... }
```

This is the architectural foundation that everything under the "concurrent rendering" umbrella depends on — `useTransition`, `useDeferredValue`, Suspense, and time-slicing all exist because Fiber made rendering interruptible and prioritizable in the first place; without Fiber's unit-of-work model, there'd be no way to mark some updates as lower priority and let React work on them incrementally between higher-priority updates like a keystroke or a click.

Question 46

What problem does useSyncExternalStore solve that a manual useState + useEffect subscription can't?

Accepted Answer

`useSyncExternalStore` exists to correctly subscribe a React component to a data source that lives *outside* React's own state — a browser API, a global store like Redux, or a third-party pub/sub system — in a way that stays consistent under React's concurrent rendering features, which a naive `useState` + `useEffect` subscription pattern can silently get wrong.

The problem it solves is "tearing": under concurrent rendering, React can pause a render partway through, let something else run (including the external store changing), and then resume — with a manual `useEffect` subscription, different components reading the same external store could end up rendering with *different* snapshots of that store's data in the same commit, producing a UI that's internally inconsistent (e.g. a cart total in one component that doesn't match the item list in another, because they read the store at different points in time relative to an update).

```jsx
function useWindowWidth() {
  return useSyncExternalStore(
    (callback) => {
      window.addEventListener("resize", callback);
      return () => window.removeEventListener("resize", callback);
    },
    () => window.innerWidth,          // client snapshot
    () => 0                            // server snapshot (SSR), avoids hydration mismatch
  );
}
```

It takes a `subscribe` function (register a callback for store changes, return an unsubscribe function), a `getSnapshot` function (read the current value), and optionally a `getServerSnapshot` for SSR — React uses these to guarantee every component reading the same store during the same render sees the same, correctly-synchronized value, even under interruptions. Most application code never calls this directly — it's primarily a low-level primitive that state-management library authors (Redux's `react-redux`, Zustand, Jotai) use internally to make their hooks concurrent-safe; you'd reach for it yourself mainly when integrating a genuinely external, mutable data source (like a browser API) directly into React state.

Question 47

What is automatic batching in React 18 and how did it change setState behavior outside event handlers?

Accepted Answer

Batching means React groups multiple `setState` calls that happen in the same tick into a single re-render, instead of re-rendering once per call — before React 18, this only happened automatically inside React event handlers; state updates inside promises, `setTimeout`, or native event handlers each triggered their own separate synchronous re-render.

```jsx
// React 17: two re-renders (promise callback isn't batched)
// React 18: one re-render (automatic batching everywhere)
fetch("/api/user").then(() => {
  setLoading(false);
  setUser(data);
});
```

React 18's automatic batching extends this same grouping to *everywhere* — promises, `setTimeout`/`setInterval`, native DOM event listeners — so the two `setState` calls above now produce one re-render instead of two, regardless of where they're called from. This is a meaningful, if usually invisible, performance win, but it occasionally surprises code that assumed synchronous-update semantics — reading a state variable immediately after calling its setter (outside of the batched update) still won't reflect the new value until the next render, same as it always has been; if you genuinely need to opt *out* of batching for a specific update, `flushSync` from `react-dom` forces a synchronous, unbatched re-render for that one call.

Question 48

Explain useTransition and useDeferredValue and how they enable concurrent rendering without blocking urgent updates.

Accepted Answer

Both let you tell React "this update is lower priority than other things happening right now" — the difference is what you're marking as low priority: `useTransition` wraps the *state update itself*, `useDeferredValue` wraps an *existing value* you don't control the setter for. ```jsx function SearchResults({ query }) { const [isPending, startTransition] = useTransition(); const [results, setResults] = useState([]); function handleChange(e) { setInputValue(e.target.value); // urgent: keep the input responsive startTransition(() => { setResults(computeExpensiveResults(e.target.value)); // low priority: can be interrupted }); } return <>{isPending && }; } // useDeferredValue: same idea, but for a value you receive as a prop rather than a setState you own function SearchResults({ query }) { const deferredQuery = useDeferredValue(query); // "stale" value shown while a newer render is prepared const results = useMemo(() => computeExpensiveResults(deferredQuery), [deferredQuery]); return ; } ``` The point of both is keeping the UI responsive during expensive renders: without them, typing into a search box that triggers an expensive filter/render on every keystroke feels laggy, because React (in legacy synchronous mode) has to finish rendering the expensive results before it can process the next keystroke. With `startTransition`, React renders the input update immediately at high priority, and works on the expensive results update in the background, interrupting it if a newer, higher-priority update (another keystroke) comes in — the input stays snappy even while the results are still computing, with `isPending` available to show a subtle loading indicator during the gap.

Question 49

Why does React invoke component functions and effects twice in development under StrictMode, and should you worry about it in production?

Accepted Answer

In development, React 18's `StrictMode` intentionally mounts every component twice — calling render functions, and specifically effect setup/cleanup functions, twice in a row — purely to surface bugs that would otherwise only show up under React's concurrent features (or with Fast Refresh), where components genuinely can be mounted, unmounted, and remounted while preserving state.

```jsx
useEffect(() => {
  const subscription = subscribeToChat(roomId);
  return () => subscription.unsubscribe();
}, [roomId]);
// StrictMode dev: mount -> effect runs -> cleanup runs -> effect runs again
// if cleanup doesn't properly unsubscribe, you now have two live subscriptions
```

If an effect doesn't clean up properly — leaves an event listener attached, a subscription open, an interval running — this double-invoke behavior makes that bug visible immediately in development (duplicate console logs, doubled API calls, a subscription firing twice) instead of it lurking silently until it causes a real issue in production under a scenario like fast navigation or React's offscreen/prerendering features. It's purely a development-mode diagnostic: this double-invocation never happens in a production build, so seeing it shouldn't itself be treated as the bug — the bug (if there is one) is that the effect's cleanup function isn't correctly undoing everything its setup did, and the fix is to make the effect properly idempotent/cleanup-safe, not to remove StrictMode to make the symptom disappear.

Question 50

What is a hydration mismatch in server-rendered React, and what commonly causes it?

Accepted Answer

Hydration is the process where React, given HTML already rendered on the server, attaches its event handlers and internal state to that existing markup rather than re-rendering everything from scratch in the browser. A hydration mismatch happens when the HTML React expects to generate on the client doesn't match what the server actually sent — React detects the discrepancy and has to discard the mismatched DOM and re-render it client-side, which is both a wasted render and, more subtly, produces a "flash" where content briefly shows the server's version before snapping to the client's. Common causes: using `Date.now()`, `Math.random()`, or `typeof window` checks directly in render output (the server renders one value, the client computing something different a moment later), timezone-dependent date formatting differing between the server's locale and the browser's, or browser extensions injecting attributes into the DOM before React hydrates. ```jsx // causes a mismatch: server renders one timestamp, client renders a different one moments later function Timestamp() { return {new Date().toLocaleTimeString()}; } // fix: render a stable placeholder on first client render, then update after mount function Timestamp() { const [time, setTime] = useState(null); useEffect(() => setTime(new Date().toLocaleTimeString()), []); return {time ?? "--:--:--"}; // matches server output (null) on first client render } ``` The general fix pattern is the same across causes: make sure whatever renders differently between environments doesn't render at all during the initial (server-matching) pass — defer it to a `useEffect` that runs only after hydration completes on the client — rather than trying to somehow compute the "right" value during SSR, which for genuinely client-only values (window size, geolocation, `localStorage`) isn't possible at all.

Python + React Interview Questions & Answers

Ready to practice these live?