Full-Stack Developer Interview Questions

Direct Answer

The contract includes the method, URL, headers, request body, status codes, response schema, authentication requirements, errors, and compatibility expectations.

Detailed Explanation

POST /api/applications
Content-Type: application/json
Authorization: Bearer <token>

{
  "jobId": "job-42",
  "resumeId": "resume-7"
}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/applications/application-91

{
  "id": "application-91",
  "jobId": "job-42",
  "status": "saved",
  "createdAt": "2026-08-05T18:00:00Z"
}

Common Interview Pitfalls

• Treating an undocumented response shape as a stable API contract.
• Returning database entities directly to frontend clients.
• Using HTTP 200 for every success and failure outcome.
• Changing required fields without considering older frontend versions.
• Displaying raw backend exception messages directly to users.

Direct Answer

Keep secrets, privileged data access, and server-oriented rendering on the server; use client code for browser APIs, local interaction state, and immediate user interactions.

Detailed Explanation

// Server Component
export default async function ApplicationsPage() {
  const applications =
    await applicationRepository.findForCurrentUser();

  return (
    <ApplicationList
      initialApplications={applications}
    />
  );
}

// Client Component
'use client';

export function ApplicationList({
  initialApplications
}: {
  initialApplications: ApplicationSummary[];
}) {
  const [query, setQuery] = useState('');

  const visible = initialApplications.filter(
    (application) =>
      application.company
        .toLowerCase()
        .includes(query.toLowerCase())
  );

  return (
    <>
      <input
        value={query}
        onChange={(event) =>
          setQuery(event.target.value)
        }
      />

      <ApplicationCards applications={visible} />
    </>
  );
}

Common Interview Pitfalls

• Importing secret-bearing server modules into client-side code.
• Marking an entire page hierarchy as client-side for one interactive control.
• Performing authorization only while rendering the frontend.
• Accessing browser APIs from code that executes on the server.
• Duplicating the same initial data request on both server and client.

Direct Answer

DTOs define transport-specific contracts, while runtime validation proves that untrusted request and response data actually matches those contracts before use.

Detailed Explanation

type ApplicationResponse = {
  id: string;
  status: 'saved' | 'applied' | 'interview';
  createdAt: string;
};

function parseApplicationResponse(
  value: unknown
): ApplicationResponse {
  if (
    typeof value !== 'object' ||
    value === null ||
    !('id' in value) ||
    !('status' in value) ||
    !('createdAt' in value) ||
    typeof value.id !== 'string' ||
    typeof value.createdAt !== 'string' ||
    ![
      'saved',
      'applied',
      'interview'
    ].includes(String(value.status))
  ) {
    throw new Error(
      'Invalid application response'
    );
  }

  return {
    id: value.id,
    status: value.status as
      ApplicationResponse['status'],
    createdAt: value.createdAt
  };
}

async function fetchApplication(
  id: string
): Promise<ApplicationResponse> {
  const response = await fetch(
    `/api/applications/${encodeURIComponent(id)}`
  );

  if (!response.ok) {
    throw new Error(
      `Request failed: ${response.status}`
    );
  }

  const body: unknown = await response.json();
  return parseApplicationResponse(body);
}

Common Interview Pitfalls

• Casting JSON directly to a TypeScript interface without validation.
• Using database entities as request and response DTOs.
• Trusting browser validation as the backend’s only validation layer.
• Allowing provider-specific fields to spread through domain logic.
• Returning sensitive internal fields because they exist on the source entity.

Direct Answer

Track the mutation lifecycle, prevent unintended duplicates, reconcile authoritative server results, invalidate affected data, and roll back optimistic changes when necessary.

Detailed Explanation

async function updateApplicationStatus(
  applicationId: string,
  status: ApplicationStatus
): Promise<Application> {
  const response = await fetch(
    `/api/applications/${applicationId}`,
    {
      method: 'PATCH',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({ status })
    }
  );

  if (!response.ok) {
    const problem: unknown =
      await response.json();

    throw parseApiProblem(problem);
  }

  const body: unknown = await response.json();
  return parseApplication(body);
}

// On success, replace the local cached entity
// with the canonical server response.

Common Interview Pitfalls

• Allowing repeated clicks to create unintended duplicate mutations.
• Keeping optimistic data after the backend rejects the operation.
• Ignoring normalized or calculated values returned by the server.
• Invalidating every cached request after one small mutation.
• Displaying raw backend exception text as the user-facing error.
• Assuming a network timeout proves that the mutation did not complete.

Direct Answer

Use opaque secure cookies, validate the session server-side, enforce authorization on every request, and protect state-changing operations against cross-site request forgery.

Detailed Explanation

HTTP/1.1 200 OK
Set-Cookie: session=opaque-session-id;
  Path=/;
  Secure;
  HttpOnly;
  SameSite=Lax;
  Max-Age=3600

POST /api/applications/application-91/archive
Cookie: session=opaque-session-id
X-CSRF-Token: signed-request-token
Origin: https://app.example.com

Common Interview Pitfalls

• Treating a hidden frontend button as an authorization boundary.
• Using cookie sessions without considering CSRF protection.
• Storing session identifiers in insecure non-HttpOnly cookies.
• Trusting a user or tenant identifier supplied by the browser.
• Using CORS as a replacement for server-side authorization.
• Returning protected data before completing ownership checks.

Direct Answer

A backend-for-frontend adapts downstream services to one frontend’s needs, centralizing aggregation, authentication translation, and response shaping without duplicating core business ownership.

Detailed Explanation

type DashboardResponse = {
  profile: ProfileSummary;
  applications: ApplicationSummary;
  recommendations:
    | {
        status: 'available';
        jobs: RecommendedJob[];
      }
    | {
        status: 'temporarily-unavailable';
      };
};

export async function getDashboard(
  user: AuthenticatedUser
): Promise<DashboardResponse> {
  const profilePromise =
    profileService.getSummary(user.id);

  const applicationsPromise =
    applicationService.getSummary(user.id);

  const recommendationsPromise =
    recommendationService
      .getForUser(user.id)
      .catch(() => null);

  const [
    profile,
    applications,
    recommendations
  ] = await Promise.all([
    profilePromise,
    applicationsPromise,
    recommendationsPromise
  ]);

  return {
    profile,
    applications,
    recommendations:
      recommendations === null
        ? {
            status: 'temporarily-unavailable'
          }
        : {
            status: 'available',
            jobs: recommendations
          }
  };
}

Common Interview Pitfalls

• Moving core business rules into a frontend-specific aggregation layer.
• Creating a BFF that only proxies every request without adaptation.
• Allowing the BFF to read and write service-owned databases directly.
• Running unbounded request fan-out without deadlines or concurrency controls.
• Returning partial data without making degraded fields explicit.
• Implementing authorization inconsistently from authoritative backend services.
• Creating one universal BFF with unrelated responsibilities for every client.
• Hiding critical downstream failures behind successful but incorrect responses.

Direct Answer

Model domain concepts as resources, apply HTTP methods according to their defined semantics, and return status codes that accurately describe each request outcome.

Detailed Explanation

POST /api/applications
Content-Type: application/json

{
  "jobId": "job-42",
  "resumeId": "resume-7"
}

HTTP/1.1 201 Created
Location: /api/applications/application-91
Content-Type: application/json

{
  "id": "application-91",
  "jobId": "job-42",
  "status": "saved"
}

PATCH /api/applications/application-91
Content-Type: application/json

{
  "status": "applied"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "application-91",
  "jobId": "job-42",
  "status": "applied"
}

Common Interview Pitfalls

• Using POST for every operation without considering HTTP method semantics.
• Returning a success status when the response body describes an error.
• Using 401 and 403 interchangeably without considering authentication state.
• Returning 200 for newly created resources without communicating their location.
• Designing endpoint paths around database tables or controller method names.
• Using DELETE for a reversible domain transition that is not actually deletion.

Direct Answer

Define stable query parameters, enforce bounded page sizes, use deterministic ordering, and return enough navigation metadata for clients to retrieve additional results safely.

Detailed Explanation

GET /api/applications
  ?status=applied
  &sort=-updatedAt
  &limit=20
  &cursor=eyJ1cGRhdGVkQXQiOiIyMDI2LTA4LTA1In0

HTTP/1.1 200 OK
Content-Type: application/json
Link: </api/applications?status=applied&limit=20&cursor=next-cursor>;
  rel="next"

{
  "items": [
    {
      "id": "application-91",
      "status": "applied",
      "updatedAt": "2026-08-05T18:00:00Z"
    }
  ],
  "page": {
    "nextCursor": "next-cursor",
    "hasMore": true
  }
}

Common Interview Pitfalls

• Returning an unbounded collection because the current dataset is small.
• Using unstable ordering that produces duplicate or missing records across pages.
• Allowing clients to request an unlimited page size.
• Exposing database-specific cursor details as a public client contract.
• Accepting arbitrary filter fields without validation or allowlisting.
• Using high offset values without evaluating their database performance.
• Calculating an expensive exact total count for every collection request unnecessarily.

Direct Answer

Use the appropriate HTTP status and return a stable problem object with a type, title, status, detail, instance, and documented extension fields when needed.

Detailed Explanation

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/validation",
  "title": "Request validation failed",
  "status": 422,
  "detail": "One or more fields are invalid.",
  "instance": "/api/applications/request-482",
  "code": "APPLICATION_VALIDATION_FAILED",
  "errors": [
    {
      "field": "jobId",
      "message": "A valid job identifier is required."
    }
  ],
  "traceId": "trace-8241"
}

Common Interview Pitfalls

• Returning a different JSON error shape from every endpoint.
• Using a successful HTTP status for a problem response.
• Making clients parse human-readable detail text to determine behavior.
• Returning stack traces or database error messages to the browser.
• Using a generic 500 response for expected validation or conflict failures.
• Assuming clients will recognize every future extension field.
• Including sensitive resource information in an authorization failure.

Direct Answer

Use method semantics and idempotency keys, persist the first operation result atomically, reject conflicting key reuse, and retry only appropriate transient failures.

Detailed Explanation

POST /api/applications
Idempotency-Key: 622df034-8cf4-40db-b029-cb362b77e164
Content-Type: application/json

{
  "jobId": "job-42",
  "resumeId": "resume-7"
}

// Simplified server flow:
await database.transaction(async (transaction) => {
  const existing =
    await transaction.idempotencyRecords.findForUpdate(
      idempotencyKey
    );

  if (existing) {
    assertMatchingFingerprint(
      existing.requestFingerprint,
      requestFingerprint
    );

    return existing.response;
  }

  const application =
    await transaction.applications.create(command);

  await transaction.idempotencyRecords.insert({
    key: idempotencyKey,
    requestFingerprint,
    response: application
  });

  return application;
});

Common Interview Pitfalls

• Retrying a non-idempotent mutation without an operation identifier.
• Generating a new idempotency key for each retry of the same operation.
• Allowing one key to be reused with different request content.
• Checking for an existing key outside the mutation transaction.
• Retrying validation and authorization failures without changing the request.
• Using immediate unlimited retries that amplify an outage.
• Assuming a client timeout proves that the server performed no work.

Direct Answer

Cache controls define whether and how long responses may be reused, while validators such as ETag let clients revalidate stale representations without downloading them again.

Detailed Explanation

GET /api/jobs/job-42 HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=60
ETag: "job-42-version-8"

{
  "id": "job-42",
  "title": "Full-Stack Developer"
}

GET /api/jobs/job-42 HTTP/1.1
If-None-Match: "job-42-version-8"

HTTP/1.1 304 Not Modified
Cache-Control: private, max-age=60
ETag: "job-42-version-8"

Common Interview Pitfalls

• Assuming no-cache means that a response cannot be stored.
• Caching personalized responses publicly without a safe cache key.
• Generating unstable ETags that change when the representation does not.
• Returning a full response when a conditional request can use 304.
• Omitting a required Vary header for negotiated representations.
• Caching authorization-sensitive responses without reviewing privacy implications.
• Using long freshness periods without a strategy for changed data.

Direct Answer

Define contracts and deadlines, validate every boundary, control retries and concurrency, preserve idempotency, expose safe errors, instrument the flow, and degrade deliberately.

Detailed Explanation

type JobPageResponse = {
  job: JobDetails;
  application:
    | {
        status: 'available';
        value: ApplicationSummary | null;
      }
    | {
        status: 'temporarily-unavailable';
      };
  recommendations:
    | {
        status: 'available';
        values: JobSummary[];
      }
    | {
        status: 'temporarily-unavailable';
      };
};

async function getJobPage(
  user: AuthenticatedUser,
  jobId: string,
  signal: AbortSignal
): Promise<JobPageResponse> {
  const jobPromise = jobsService.getRequired(
    jobId,
    { signal }
  );

  const applicationPromise = applicationsService
    .findForUserAndJob(user.id, jobId, { signal })
    .then((value) => ({
      status: 'available' as const,
      value
    }))
    .catch(() => ({
      status: 'temporarily-unavailable' as const
    }));

  const recommendationsPromise = recommendationsService
    .getRelated(jobId, { signal })
    .then((values) => ({
      status: 'available' as const,
      values
    }))
    .catch(() => ({
      status: 'temporarily-unavailable' as const
    }));

  const [
    job,
    application,
    recommendations
  ] = await Promise.all([
    jobPromise,
    applicationPromise,
    recommendationsPromise
  ]);

  return {
    job,
    application,
    recommendations
  };
}

Common Interview Pitfalls

• Applying the same retry policy to every operation and failure type.
• Allowing optional dependency failure to take down an entire page unnecessarily.
• Hiding critical authorization or payment failures as optional degradation.
• Performing unbounded parallel fan-out to downstream services.
• Logging credentials or sensitive payloads for debugging convenience.
• Using timeouts without cancellation or resource cleanup.
• Returning inconsistent error formats from different execution branches.
• Retrying mutations without idempotency or duplicate protection.
• Collecting latency metrics without dependency or trace context.

Direct Answer

Relational constraints enforce identity, references, uniqueness, allowed values, and required fields inside the database rather than relying only on application validation.

Detailed Explanation

CREATE TABLE users (
  id UUID PRIMARY KEY,
  normalized_email TEXT NOT NULL UNIQUE,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE job_applications (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL,
  external_job_id TEXT NOT NULL,
  status TEXT NOT NULL,
  applied_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),

  CONSTRAINT fk_application_user
    FOREIGN KEY (user_id)
    REFERENCES users (id)
    ON DELETE CASCADE,

  CONSTRAINT uq_user_external_job
    UNIQUE (user_id, external_job_id),

  CONSTRAINT chk_application_status
    CHECK (
      status IN (
        'saved',
        'applied',
        'interview',
        'offer',
        'rejected'
      )
    ),

  CONSTRAINT chk_applied_date
    CHECK (
      status = 'saved' OR applied_at IS NOT NULL
    )
);

Common Interview Pitfalls

• Relying only on frontend or application validation for critical integrity rules.
• Using a mutable business label as the primary key.
• Creating foreign-key columns without defining appropriate delete behavior.
• Allowing null values without defining what absence means.
• Checking for duplicates in application code without a database uniqueness constraint.
• Assuming a unique index and every unique business rule are automatically identical concepts.

Direct Answer

A transaction groups related database work into one unit. ACID describes atomicity, consistency, isolation, and durability guarantees around that unit.

Detailed Explanation

BEGIN;

SELECT remaining_credits
FROM ai_credit_balances
WHERE user_id = 'user-42'
FOR UPDATE;

UPDATE ai_credit_balances
SET remaining_credits = remaining_credits - 1
WHERE user_id = 'user-42'
  AND remaining_credits >= 1;

INSERT INTO ai_credit_ledger (
  id,
  user_id,
  amount,
  reason
)
VALUES (
  'ledger-91',
  'user-42',
  -1,
  'resume_analysis'
);

COMMIT;

Common Interview Pitfalls

• Performing related database writes without one transaction.
• Keeping a transaction open while calling a slow external service.
• Assuming a database transaction also rolls back an email or HTTP request.
• Catching a transaction error and committing partial work manually.
• Retrying a failed transaction when the entire operation is not safely repeatable.
• Using a transaction without checking whether the intended invariant is actually protected.

Direct Answer

Indexes provide faster paths to selected rows and ordered results, but they consume storage and add maintenance work to inserts, updates, and deletes.

Detailed Explanation

CREATE INDEX idx_applications_user_updated
ON job_applications (
  user_id,
  updated_at DESC,
  id DESC
);

CREATE INDEX idx_active_applications_user
ON job_applications (
  user_id,
  updated_at DESC
)
WHERE status IN (
  'saved',
  'applied',
  'interview',
  'offer'
);

EXPLAIN ANALYZE
SELECT
  id,
  status,
  updated_at
FROM job_applications
WHERE user_id = 'user-42'
ORDER BY
  updated_at DESC,
  id DESC
LIMIT 20;

Common Interview Pitfalls

• Adding an individual index to every column without considering write cost.
• Designing indexes without examining real query patterns.
• Ignoring column order in a composite index.
• Assuming an index is used merely because it exists.
• Testing execution plans only against an almost empty development database.
• Using functions or type conversions that prevent an intended index access path.
• Adding overlapping indexes that provide little additional value.

Direct Answer

ORMs simplify mapping and common persistence work, but developers must still inspect generated queries, control relationship loading, and deploy schema migrations deliberately.

Detailed Explanation

// Potential N+1 pattern:
const applications =
  await database.application.findMany({
    where: {
      userId
    }
  });

for (const application of applications) {
  const job = await database.job.findUnique({
    where: {
      id: application.jobId
    }
  });

  console.log(job?.title);
}

// Better: fetch the required projection together.
const applicationCards =
  await database.application.findMany({
    where: {
      userId
    },
    select: {
      id: true,
      status: true,
      job: {
        select: {
          title: true,
          companyName: true
        }
      }
    }
  });

Common Interview Pitfalls

• Assuming ORM-generated queries are automatically efficient.
• Loading a related record separately inside a loop.
• Solving every N+1 query by eagerly loading the entire object graph.
• Applying production migrations without reviewing generated operations.
• Running migrations automatically from multiple application instances.
• Changing a required column in one deployment without supporting older application versions.
• Using ORM abstractions without monitoring query counts and execution time.

Direct Answer

Optimistic concurrency includes an expected version in the update condition and rejects the write when another transaction has already changed the record.

Detailed Explanation

UPDATE job_applications
SET
  notes = $1,
  version = version + 1,
  updated_at = NOW()
WHERE id = $2
  AND user_id = $3
  AND version = $4
RETURNING
  id,
  notes,
  version,
  updated_at;

// If no row is returned, respond with a conflict
// rather than overwriting a newer version.

Common Interview Pitfalls

• Updating a record by identifier without checking the version that was read.
• Treating a zero-row update as an ordinary successful save.
• Using a low-precision timestamp that cannot reliably identify every change.
• Automatically retrying a stale write with the new version and overwriting changes anyway.
• Confusing optimistic concurrency control with optimistic frontend updates.
• Returning conflict details without verifying resource ownership first.

Direct Answer

Define domain invariants, enforce critical integrity in the database, use explicit transactions and concurrency controls, evolve schemas safely, and observe real query behavior.

Detailed Explanation

async function createApplication(
  command: CreateApplicationCommand
): Promise<Application> {
  return database.transaction(async (transaction) => {
    const job = await transaction.jobs.findById(
      command.jobId
    );

    if (!job || !job.isActive) {
      throw new DomainError(
        'JOB_NOT_AVAILABLE'
      );
    }

    try {
      return await transaction.applications.insert({
        id: createId(),
        userId: command.userId,
        jobId: command.jobId,
        status: 'saved',
        version: 1
      });
    } catch (error: unknown) {
      if (isUniqueConstraintViolation(error)) {
        throw new DomainError(
          'APPLICATION_ALREADY_EXISTS'
        );
      }

      throw error;
    }
  });
}

// Database uniqueness remains the final protection
// against concurrent duplicate submissions.

Common Interview Pitfalls

• Enforcing every critical invariant only in application code.
• Using one generic repository that prevents access to necessary database features.
• Applying destructive schema changes before all application versions support them.
• Adding indexes without monitoring write cost or actual query use.
• Testing persistence behavior only through mocked repositories.
• Using runtime credentials with broad schema modification permissions.
• Retaining sensitive data indefinitely without a documented requirement.
• Collecting slow-query data without associating it with application operations.
• Assuming backups are reliable without testing restoration.

Direct Answer

Authentication establishes who a principal is, while authorization decides whether that authenticated principal may perform a specific action on a resource.

Detailed Explanation

type AuthenticatedUser = {
  id: string;
  roles: string[];
  tenantId: string;
};

async function getApplication(
  user: AuthenticatedUser,
  applicationId: string
): Promise<Application> {
  const application =
    await applicationRepository.findById(
      applicationId
    );

  if (!application) {
    throw new NotFoundError();
  }

  const canRead =
    application.userId === user.id &&
    application.tenantId === user.tenantId;

  if (!canRead) {
    throw new ForbiddenError();
  }

  return application;
}

Common Interview Pitfalls

• Treating successful login as permission to access every application resource.
• Enforcing authorization only by hiding controls in the frontend.
• Trusting a user or tenant identifier supplied in the request body.
• Checking a broad role while ignoring resource ownership or tenant scope.
• Using authentication and authorization as interchangeable terms.
• Allowing access whenever no explicit authorization rule matches.

Direct Answer

Server sessions keep authoritative session state on the server, while JWTs carry signed claims. Browser storage must be chosen according to XSS, CSRF, expiry, and revocation risks.

Detailed Explanation

HTTP/1.1 200 OK
Set-Cookie: session=opaque-session-id;
  Path=/;
  Secure;
  HttpOnly;
  SameSite=Lax;
  Max-Age=3600

// Simplified JWT claim checks:
function validateAccessToken(
  token: VerifiedJwt
): void {
  if (token.issuer !== EXPECTED_ISSUER) {
    throw new AuthenticationError();
  }

  if (!token.audience.includes(API_AUDIENCE)) {
    throw new AuthenticationError();
  }

  if (token.expiresAt <= Date.now()) {
    throw new AuthenticationError();
  }
}

Common Interview Pitfalls

• Assuming a signed JWT is encrypted and safe for sensitive data.
• Validating only the token signature while ignoring issuer or audience.
• Issuing access tokens with unnecessarily long expiration periods.
• Storing long-lived tokens in JavaScript-accessible storage without considering XSS.
• Using cookie authentication without CSRF protections.
• Embedding rapidly changing permissions into tokens that remain valid for a long time.
• Logging complete session cookies or access tokens.

Direct Answer

OAuth delegates API access, OpenID Connect adds authentication, and the code flow uses state, nonce, redirect validation, and PKCE to protect the exchange.

Detailed Explanation

const codeVerifier =
  createCryptographicallyRandomString();

const codeChallenge =
  await createSha256Base64Url(codeVerifier);

const state =
  createCryptographicallyRandomString();

const nonce =
  createCryptographicallyRandomString();

const authorizationUrl = new URL(
  authorizationEndpoint
);

authorizationUrl.searchParams.set(
  'response_type',
  'code'
);
authorizationUrl.searchParams.set(
  'client_id',
  clientId
);
authorizationUrl.searchParams.set(
  'redirect_uri',
  registeredRedirectUri
);
authorizationUrl.searchParams.set(
  'scope',
  'openid profile email'
);
authorizationUrl.searchParams.set(
  'state',
  state
);
authorizationUrl.searchParams.set(
  'nonce',
  nonce
);
authorizationUrl.searchParams.set(
  'code_challenge',
  codeChallenge
);
authorizationUrl.searchParams.set(
  'code_challenge_method',
  'S256'
);

Common Interview Pitfalls

• Using OAuth terminology while treating the access token as proof of user authentication.
• Using an ID token as a general-purpose API access token.
• Failing to verify the state value when the browser returns.
• Using the authorization code flow without PKCE.
• Accepting loosely matched or attacker-controlled redirect URIs.
• Validating an ID token signature without checking issuer, audience, expiration, and nonce.
• Placing client secrets inside browser-delivered JavaScript.
• Requesting broader scopes than the application requires.

Direct Answer

Separate configuration from code, store secrets in managed secret systems, validate configuration at startup, restrict access, rotate credentials, and avoid exposing server values to clients.

Detailed Explanation

type ServerConfiguration = {
  databaseUrl: string;
  sessionSecret: string;
  nodeEnvironment:
    | 'development'
    | 'test'
    | 'production';
  requestTimeoutMs: number;
};

function loadConfiguration(
  environment: NodeJS.ProcessEnv
): ServerConfiguration {
  const databaseUrl = environment.DATABASE_URL;
  const sessionSecret = environment.SESSION_SECRET;
  const nodeEnvironment = environment.NODE_ENV;
  const requestTimeoutMs = Number(
    environment.REQUEST_TIMEOUT_MS
  );

  if (!databaseUrl) {
    throw new Error('DATABASE_URL is required');
  }

  if (!sessionSecret || sessionSecret.length < 32) {
    throw new Error(
      'SESSION_SECRET must contain at least 32 characters'
    );
  }

  if (
    nodeEnvironment !== 'development' &&
    nodeEnvironment !== 'test' &&
    nodeEnvironment !== 'production'
  ) {
    throw new Error('NODE_ENV is invalid');
  }

  if (
    !Number.isInteger(requestTimeoutMs) ||
    requestTimeoutMs <= 0
  ) {
    throw new Error(
      'REQUEST_TIMEOUT_MS must be positive'
    );
  }

  return {
    databaseUrl,
    sessionSecret,
    nodeEnvironment,
    requestTimeoutMs
  };
}

Common Interview Pitfalls

• Committing production credentials to a source repository.
• Assuming an environment variable included in client code remains private.
• Baking credentials into a container image or reusable build artifact.
• Starting the application without validating required configuration.
• Giving every service access to the complete organization secret set.
• Logging environment objects that contain passwords or tokens.
• Using one permanent credential without a rotation procedure.
• Treating all environment variables as correctly typed strings.

Direct Answer

Containers package reproducible runtime artifacts, CI verifies them, readiness controls traffic, liveness detects stuck processes, rolling deployment limits disruption, and rollback restores a known version.

Detailed Explanation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: resumeloop-api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/resumeloop-api:sha-82a4
          ports:
            - containerPort: 3000
          startupProbe:
            httpGet:
              path: /health/startup
              port: 3000
            failureThreshold: 30
            periodSeconds: 2
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health/live
              port: 3000
            periodSeconds: 10

Common Interview Pitfalls

• Rebuilding a different container image for each deployment environment.
• Using one identical endpoint and policy for every health probe without analysis.
• Making liveness fail whenever an optional external dependency is unavailable.
• Sending traffic to a new instance before startup and readiness checks succeed.
• Deploying a destructive schema migration that prevents application rollback.
• Using mutable image tags without recording the deployed digest or commit.
• Allowing multiple production deployments to race without concurrency controls.
• Assuming restarting an unhealthy process fixes every underlying failure.

Direct Answer

Build one traceable artifact, enforce quality and security gates, use short-lived credentials and protected environments, deploy progressively, validate health, and preserve rollback compatibility.

Detailed Explanation

name: Production deployment

on:
  workflow_dispatch:

concurrency:
  group: production
  cancel-in-progress: false

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<pinned-commit>

      - name: Install dependencies
        run: npm ci

      - name: Verify application
        run: |
          npm run lint
          npx tsc --noEmit
          npm test -- --runInBand
          npm run build

      - name: Build immutable image
        run: |
          docker build             --tag registry.example.com/app:${GITHUB_SHA}             .

  deploy:
    needs: verify
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write
    steps:
      - name: Obtain short-lived cloud credentials
        run: ./scripts/authenticate-with-oidc.sh

      - name: Deploy verified image
        run: |
          ./scripts/deploy.sh             registry.example.com/app:${GITHUB_SHA}

      - name: Run production smoke checks
        run: ./scripts/smoke-test.sh

Common Interview Pitfalls

• Using permanent production cloud credentials in CI secrets.
• Rebuilding application code after approval instead of deploying the verified artifact.
• Allowing production secrets to be read before deployment protection rules pass.
• Running destructive migrations that make rollback impossible.
• Deploying globally without readiness checks or staged exposure.
• Using unpinned third-party pipeline actions with production permissions.
• Allowing overlapping production deployments to interfere with one another.
• Collecting deployment logs without recording the artifact digest and source commit.
• Considering a deployment successful before post-release health checks complete.

Direct Answer

A monolith deploys as one application, a modular monolith preserves internal domain boundaries, and microservices split capabilities into independently deployed networked services.

Detailed Explanation

// A modular-monolith boundary.

export interface ApplicationsModule {
  createApplication(
    command: CreateApplicationCommand
  ): Promise<ApplicationSummary>;

  getApplication(
    userId: string,
    applicationId: string
  ): Promise<ApplicationSummary | null>;
}

// Other modules depend on this public contract.
// They do not import repositories or database
// entities from the applications module.

Common Interview Pitfalls

• Assuming every monolith is automatically unmaintainable.
• Calling an application modular while allowing unrestricted cross-module imports.
• Splitting services before clear domain or ownership boundaries exist.
• Allowing several microservices to modify the same database tables directly.
• Ignoring network and operational failure modes when introducing services.
• Creating microservices that require coordinated deployment for every change.

Direct Answer

Unit tests isolate logic, integration tests verify real collaborations, contract tests protect service interfaces, and end-to-end tests validate critical user journeys.

Detailed Explanation

import { test, expect } from '@playwright/test';

test('user can save a discovered job', async ({
  page
}) => {
  await page.goto('/jobs');

  await page
    .getByRole('link', {
      name: 'Frontend Developer at Example'
    })
    .click();

  await page
    .getByRole('button', {
      name: 'Save job'
    })
    .click();

  await expect(
    page.getByText('Job saved')
  ).toBeVisible();

  await page.goto('/applications');

  await expect(
    page.getByRole('heading', {
      name: 'Frontend Developer'
    })
  ).toBeVisible();
});

Common Interview Pitfalls

• Testing every behavior only through slow end-to-end tests.
• Mocking the database in tests intended to verify transactions or constraints.
• Testing implementation methods instead of externally observable behavior.
• Allowing independently deployed services to change contracts without consumer verification.
• Using code coverage as the only measure of test quality.
• Protecting critical user journeys only with isolated unit tests.
• Sharing mutable test data that makes test order affect results.

Direct Answer

Cache only where ownership and freshness are defined, choose stable keys and bounded lifetimes, invalidate on relevant writes, and protect private or user-specific responses.

Detailed Explanation

async function getJob(
  jobId: string
): Promise<Job> {
  const cacheKey = `job:v2:${jobId}`;

  const cached =
    await cache.get(cacheKey);

  if (cached) {
    return parseJob(
      JSON.parse(cached) as unknown
    );
  }

  const job =
    await jobRepository.getRequired(jobId);

  await cache.set(
    cacheKey,
    JSON.stringify(job),
    {
      expiresInSeconds: 300
    }
  );

  return job;
}

async function updateJob(
  command: UpdateJobCommand
): Promise<Job> {
  const updated =
    await jobRepository.update(command);

  await cache.delete(
    `job:v2:${command.jobId}`
  );

  return updated;
}

Common Interview Pitfalls

• Caching personalized data under a key shared by every user.
• Adding a cache without defining acceptable staleness.
• Using query parameters incompletely when building a cache key.
• Treating a time-to-live as proof that cached data is always correct.
• Allowing many simultaneous cache misses to overload the database.
• Making the application completely unavailable when an optional cache fails.
• Keeping cached entries after related mutations without invalidation.

Direct Answer

Use asynchronous processing for slow or decoupled work, acknowledge only after successful processing, make consumers idempotent, bound retries, and expose pending or failed states.

Detailed Explanation

await database.transaction(async (transaction) => {
  const analysis =
    await transaction.resumeAnalyses.insert({
      id: analysisId,
      userId,
      status: 'queued'
    });

  await transaction.outbox.insert({
    id: createId(),
    eventType: 'resume-analysis-requested',
    aggregateId: analysis.id,
    payload: {
      analysisId: analysis.id,
      userId
    }
  });
});

// A publisher later sends unsent outbox events.
// The worker uses analysisId as an idempotency key.

Common Interview Pitfalls

• Assuming a queued message will be delivered exactly once.
• Acknowledging a message before durable processing succeeds.
• Retrying permanent validation failures indefinitely.
• Performing a non-idempotent side effect on every redelivery.
• Publishing an event after a database commit without handling publication failure.
• Hiding long-running job status from users who need progress or recovery.
• Allowing poison messages to block normal processing indefinitely.

Direct Answer

Metrics reveal the scope, traces locate latency across components, logs explain individual events, and profiles identify expensive code or resource consumption.

Detailed Explanation

const span = tracer.startSpan(
  'applications.create',
  {
    attributes: {
      'app.operation': 'create_application',
      'deployment.version': releaseVersion
    }
  }
);

try {
  const startedAt = performance.now();

  const result =
    await applicationService.create(command);

  requestDuration.record(
    performance.now() - startedAt,
    {
      operation: 'create_application',
      outcome: 'success'
    }
  );

  span.setStatus({ code: SpanStatusCode.OK });

  return result;
} catch (error: unknown) {
  span.recordException(
    normalizeError(error)
  );

  span.setStatus({
    code: SpanStatusCode.ERROR
  });

  throw error;
} finally {
  span.end();
}

Common Interview Pitfalls

• Collecting logs without correlation or trace identifiers.
• Using averages that hide severe high-percentile latency.
• Adding user emails or unbounded values as metric labels.
• Alerting on infrastructure changes that have no user impact.
• Recording telemetry without the deployed release version.
• Adding traces without instrumenting important database and dependency calls.
• Attempting performance optimization before identifying the dominant bottleneck.

Direct Answer

Define domain and consistency boundaries, keep services stateless where useful, protect the database, queue slow work, cache measured hotspots, instrument journeys, and scale from observed demand.

Detailed Explanation

type AnalysisState =
  | {
      status: 'queued';
      analysisId: string;
    }
  | {
      status: 'processing';
      analysisId: string;
      startedAt: string;
    }
  | {
      status: 'completed';
      analysisId: string;
      resultId: string;
    }
  | {
      status: 'failed';
      analysisId: string;
      retryable: boolean;
    };

async function requestAnalysis(
  command: RequestAnalysisCommand
): Promise<AnalysisState> {
  return database.transaction(
    async (transaction) => {
      await transaction.creditBalances
        .consumeOneCredit({
          userId: command.userId
        });

      const analysis =
        await transaction.analyses.insert({
          id: createId(),
          userId: command.userId,
          resumeId: command.resumeId,
          status: 'queued'
        });

      await transaction.outbox.insert({
        id: createId(),
        eventType: 'analysis-requested',
        aggregateId: analysis.id,
        payload: {
          analysisId: analysis.id
        }
      });

      return {
        status: 'queued',
        analysisId: analysis.id
      };
    }
  );
}

Common Interview Pitfalls

• Starting with microservices before proving independent scaling or ownership needs.
• Allowing concurrent AI requests to bypass credit or usage limits.
• Running slow document or AI processing inside interactive request transactions.
• Scaling application replicas while ignoring the database connection limit.
• Caching private resume or application data under unsafe shared keys.
• Using CPU as the only scaling signal for queue-driven workers.
• Treating optional recommendation failure as a total product outage.
• Deploying destructive schema changes that prevent rollback.
• Collecting infrastructure metrics without measuring critical user journeys.