Backend Developer Interview Questions

Direct Answer

The server accepts and parses the request, routes it to application logic, authenticates and validates it, performs required work, and serializes an HTTP response.

Detailed Explanation

@RestController
@RequestMapping("/applications")
final class ApplicationController {
  private final CreateApplicationUseCase createApplication;

  ApplicationController(
      CreateApplicationUseCase createApplication
  ) {
    this.createApplication = createApplication;
  }

  @PostMapping
  ResponseEntity<ApplicationResponse> create(
      @Valid @RequestBody CreateApplicationRequest request
  ) {
    Application result =
        createApplication.execute(request.toCommand());

    return ResponseEntity
        .status(HttpStatus.CREATED)
        .body(ApplicationResponse.from(result));
  }
}

Common Interview Pitfalls

• Putting routing, validation, business logic, and database access into one controller method.
• Returning internal exception details directly to the client.
• Assuming every request reaches the controller before it can fail.
• Ignoring correlation IDs and timing information during request processing.
• Performing expensive work before authentication and basic validation.

Direct Answer

A stateless service does not depend on instance-local data from earlier requests, while a stateful service retains session or workflow state that affects later interactions.

Detailed Explanation

// Application instances remain stateless.
// Session data is stored in a shared repository.

final class SessionService {
  private final SessionRepository sessions;

  SessionService(SessionRepository sessions) {
    this.sessions = sessions;
  }

  Optional<UserSession> find(String sessionId) {
    return sessions.findById(sessionId);
  }
}

Common Interview Pitfalls

• Assuming stateless means that the application does not store any data.
• Keeping user sessions only in one application instance without accounting for failover.
• Using sticky sessions as the only protection against instance failure.
• Storing mutable shared state in singleton objects without concurrency protection.
• Moving state externally without considering consistency and availability requirements.

Direct Answer

Use synchronous processing when the client needs an immediate result and work is bounded. Use asynchronous processing for long-running, bursty, or independently retryable work.

Detailed Explanation

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

{
  "type": "application-history",
  "dateRange": "last-12-months"
}

HTTP/1.1 202 Accepted
Location: /api/report-jobs/job-42

{
  "jobId": "job-42",
  "status": "queued"
}

Common Interview Pitfalls

• Holding an HTTP request open for unbounded background work.
• Returning success before ensuring asynchronous work was stored durably.
• Retrying asynchronous work without making the operation idempotent.
• Creating background jobs without status tracking or failure visibility.
• Confusing nonblocking I/O with asynchronous business completion.

Direct Answer

Thread pools reuse a bounded set of workers and control concurrency. Poor sizing or unbounded queues can cause latency, memory growth, starvation, or overload propagation.

Detailed Explanation

ThreadPoolExecutor executor =
    new ThreadPoolExecutor(
        8,
        16,
        30,
        TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(200),
        new ThreadPoolExecutor.AbortPolicy()
    );

try {
  executor.execute(task);
} catch (RejectedExecutionException rejected) {
  metrics.increment("tasks.rejected");
  throw new ServiceOverloadedException();
}

Common Interview Pitfalls

• Using an unbounded queue and assuming queued work has no cost.
• Increasing thread count without measuring downstream capacity.
• Running blocking tasks in a pool intended for CPU-intensive work.
• Ignoring rejected tasks instead of defining overload behavior.
• Allowing one slow workload to consume every shared worker.
• Sizing a pool using a fixed rule without measuring the actual workload.

Direct Answer

Controllers handle transport concerns, application services coordinate use cases, domain code enforces business rules, and repositories abstract persistence operations.

Detailed Explanation

interface JobApplicationRepository {
  Optional<JobApplication> findById(
      JobApplicationId id
  );

  void save(JobApplication application);
}

final class RejectApplicationUseCase {
  private final JobApplicationRepository repository;

  RejectApplicationUseCase(
      JobApplicationRepository repository
  ) {
    this.repository = repository;
  }

  void execute(JobApplicationId id) {
    JobApplication application = repository
        .findById(id)
        .orElseThrow(ApplicationNotFound::new);

    application.reject();
    repository.save(application);
  }
}

Common Interview Pitfalls

• Placing business rules directly in controllers or database callbacks.
• Creating pass-through layers that add names but no meaningful responsibility.
• Allowing domain logic to depend directly on a web framework.
• Exposing ORM entities as the permanent public API contract.
• Creating one generic repository interface that cannot express domain-specific queries.
• Adding complex architecture to a simple service without clear benefit.

Direct Answer

Choose boundaries from domain ownership, scaling, reliability, deployment, and team needs. Independent services add operational complexity and should solve a demonstrated problem.

Detailed Explanation

Common Interview Pitfalls

• Creating one service for every database table or entity.
• Choosing microservices before establishing deployment and observability capabilities.
• Sharing one mutable database schema across supposedly independent services.
• Assuming network calls behave like reliable in-process method calls.
• Splitting services before domain ownership and boundaries are understood.
• Treating a monolith as inherently unscalable or poorly designed.

Direct Answer

Model client-facing domain resources with stable URLs, use HTTP methods according to their semantics, and avoid exposing internal service methods or database structures directly.

Detailed Explanation

GET    /api/projects
POST   /api/projects
GET    /api/projects/42
PATCH  /api/projects/42
DELETE /api/projects/42

GET    /api/projects/42/tasks
POST   /api/projects/42/tasks
GET    /api/tasks/91

Common Interview Pitfalls

• Using action-based endpoint names for ordinary resource operations.
• Performing state-changing operations through GET requests.
• Exposing database tables directly as the public resource model.
• Creating deeply nested paths that clients cannot use independently.
• Using inconsistent naming and pluralization across related endpoints.

Direct Answer

Use HTTP status codes to describe the request outcome and return a stable machine-readable error body containing safe details, identifiers, and actionable validation information.

Detailed Explanation

HTTP/1.1 409 Conflict
Content-Type: application/problem+json

{
  "type": "https://api.example.com/problems/email-conflict",
  "title": "Email already registered",
  "status": 409,
  "detail": "An account already uses this email address.",
  "instance": "/api/users/request-91",
  "errorCode": "EMAIL_ALREADY_REGISTERED",
  "requestId": "request-91"
}

Common Interview Pitfalls

• Returning HTTP 200 for failures and storing the real status only in JSON.
• Using 401 and 403 interchangeably.
• Returning a different error-body format from each endpoint.
• Exposing stack traces or internal exception messages to clients.
• Using 500 for expected validation or business-rule failures.
• Returning detailed resource information before authorization succeeds.

Direct Answer

Use a caller-scoped idempotency key, persist the operation result atomically, reject mismatched payload reuse, and return the recorded result for equivalent retries.

Detailed Explanation

POST /api/payments
Idempotency-Key: 041f76df-d703-4389-b630-51e43f551cb9
Content-Type: application/json

{
  "orderId": "order-42",
  "amount": 4999,
  "currency": "USD"
}

Common Interview Pitfalls

• Assuming a POST request is automatically safe to retry.
• Scoping idempotency keys globally instead of by caller and operation.
• Accepting the same key with a different request payload.
• Persisting the idempotency record separately from the business result without coordination.
• Ignoring concurrent requests that submit the same key simultaneously.
• Deleting idempotency records before legitimate client retries have ended.

Direct Answer

Set bounded timeouts, retry only transient and safe failures with backoff and jitter, limit attempts, and use a circuit breaker to fail fast during persistent dependency failures.

Detailed Explanation

RetryPolicy retryPolicy = RetryPolicy.builder()
    .maxAttempts(3)
    .initialBackoff(Duration.ofMillis(200))
    .maxBackoff(Duration.ofSeconds(2))
    .jitter(true)
    .retryOn(TimeoutException.class)
    .retryOn(ServiceUnavailableException.class)
    .build();

PaymentResponse response = circuitBreaker.execute(
    () -> retryPolicy.execute(
        () -> paymentClient.authorize(request)
    )
);

Common Interview Pitfalls

• Calling remote services without explicit connection and request timeouts.
• Retrying validation, authentication, or other permanent failures.
• Applying retries at several layers and multiplying downstream traffic.
• Retrying non-idempotent operations without duplicate protection.
• Using fixed retry delays across every client without jitter.
• Keeping a circuit permanently open without controlled recovery probes.

Direct Answer

Verify the signature over the raw request body, reject invalid deliveries, deduplicate event IDs, persist work durably, acknowledge quickly, and process heavy work asynchronously.

Detailed Explanation

public ResponseEntity<Void> receiveWebhook(
    byte[] rawBody,
    String signature,
    String deliveryId
) {
  if (!signatureVerifier.isValid(rawBody, signature)) {
    return ResponseEntity.status(401).build();
  }

  boolean accepted = webhookInbox.acceptIfNew(
      deliveryId,
      rawBody
  );

  if (accepted) {
    webhookQueue.publish(deliveryId);
  }

  return ResponseEntity.noContent().build();
}

Common Interview Pitfalls

• Verifying the signature against parsed or modified JSON instead of the raw body.
• Using ordinary string comparison for security-sensitive signatures.
• Processing duplicate deliveries more than once.
• Performing slow business work before acknowledging the webhook.
• Trusting source IP addresses as the only authentication mechanism.
• Logging webhook secrets or complete sensitive payloads.
• Assuming webhook events always arrive once and in order.

Direct Answer

Place the provider behind an internal adapter, enforce deadlines and idempotency, normalize contracts and errors, persist reconciliation state, monitor behavior, and design degraded operation.

Detailed Explanation

interface PaymentProvider {
  AuthorizationResult authorize(
      PaymentCommand command
  );

  ProviderPayment findByOperationId(
      OperationId operationId
  );
}

final class AuthorizePaymentUseCase {
  private final PaymentRepository payments;
  private final PaymentProvider provider;

  Payment authorize(PaymentCommand command) {
    Payment payment =
        payments.createPendingIfAbsent(command);

    try {
      AuthorizationResult result =
          provider.authorize(command);

      payment.record(result);
    } catch (UnknownProviderOutcome error) {
      payment.markReconciliationRequired();
    }

    payments.save(payment);
    return payment;
  }
}

Common Interview Pitfalls

• Allowing provider-specific response objects to spread throughout the application.
• Treating a network timeout as proof that the external operation failed.
• Using retries without idempotency or reconciliation support.
• Depending only on synchronous provider responses for final state.
• Ignoring provider rate limits and account-level quotas.
• Failing to store provider request and operation identifiers.
• Designing no degraded behavior for dependency outages.
• Rotating credentials without testing both activation and rollback procedures.

Direct Answer

Choose from relationships, transaction needs, query patterns, consistency requirements, schema evolution, and operational experience rather than assuming one database model is universally better.

Detailed Explanation

Common Interview Pitfalls

• Choosing a document database only because the schema may change.
• Assuming relational databases cannot scale horizontally.
• Embedding unbounded collections inside one document.
• Selecting a database before identifying important query and transaction patterns.
• Using several database technologies without a clear workload-specific benefit.

Direct Answer

Primary keys identify rows, foreign keys protect relationships, unique constraints prevent duplicate values, and check constraints reject row states that violate defined rules.

Detailed Explanation

CREATE TABLE organizations (
  id bigint GENERATED ALWAYS AS IDENTITY,
  name text NOT NULL,
  PRIMARY KEY (id),
  CONSTRAINT organizations_name_unique
    UNIQUE (name)
);

CREATE TABLE users (
  id bigint GENERATED ALWAYS AS IDENTITY,
  organization_id bigint NOT NULL,
  email text NOT NULL,
  account_status text NOT NULL,
  PRIMARY KEY (id),
  CONSTRAINT users_organization_fk
    FOREIGN KEY (organization_id)
    REFERENCES organizations(id)
    ON DELETE RESTRICT,
  CONSTRAINT users_org_email_unique
    UNIQUE (organization_id, email),
  CONSTRAINT users_status_check
    CHECK (
      account_status IN (
        'invited',
        'active',
        'disabled'
      )
    )
);

Common Interview Pitfalls

• Relying only on application validation for critical database invariants.
• Using cascading deletion without understanding record ownership.
• Adding a foreign key without considering lookup and deletion performance.
• Using nullable columns for values required by the domain.
• Creating generic constraint names that are difficult to diagnose.
• Assuming a check constraint can safely query arbitrary rows in other tables.

Direct Answer

Place one local business invariant inside one short transaction, select isolation from the anomalies that must be prevented, and retry complete transactions when serialization conflicts occur.

Detailed Explanation

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SELECT available_quantity
FROM inventory
WHERE product_id = 42;

UPDATE inventory
SET available_quantity = available_quantity - 1
WHERE product_id = 42
  AND available_quantity > 0;

INSERT INTO reservations (
  reservation_id,
  product_id,
  quantity
)
VALUES (
  'reservation-91',
  42,
  1
);

COMMIT;

Common Interview Pitfalls

• Keeping transactions open during remote API calls.
• Choosing serializable isolation without implementing transaction retries.
• Using several independent transactions for one local invariant.
• Retrying only the failed statement after a serialization conflict.
• Selecting an isolation level without identifying the anomaly being prevented.
• Holding locks while waiting for user input or background processing.

Direct Answer

Design indexes from real filters, joins, ordering, and selectivity, then compare estimated and actual query-plan behavior under representative data before and after each change.

Detailed Explanation

CREATE INDEX applications_user_status_created_idx
ON job_applications (
  user_id,
  status,
  created_at DESC
);

EXPLAIN (
  ANALYZE,
  BUFFERS
)
SELECT
  id,
  company,
  created_at
FROM job_applications
WHERE user_id = 42
  AND status = 'applied'
ORDER BY created_at DESC
LIMIT 25;

Common Interview Pitfalls

• Adding an index to every column without considering write cost.
• Ignoring column order in a composite B-tree index.
• Looking only for whether an index appears in the execution plan.
• Testing query plans with unrealistic data volume or parameters.
• Keeping redundant and unused indexes indefinitely.
• Assuming a sequential scan always indicates poor performance.

Direct Answer

Use expand-and-contract migrations: add compatible structures first, deploy code that supports both forms, backfill safely, switch reads and writes, then remove obsolete structures later.

Detailed Explanation

-- Deployment 1: expand
ALTER TABLE users
ADD COLUMN display_name text;

-- Application supports both old and new representations.

-- Backfill in bounded batches.
UPDATE users
SET display_name = full_name
WHERE display_name IS NULL
  AND id >= 1
  AND id < 10001;

-- Later deployment, after verification:
ALTER TABLE users
ALTER COLUMN display_name SET NOT NULL;

-- A future deployment may remove full_name
-- after no running code depends on it.

Common Interview Pitfalls

• Dropping or renaming a column while older application instances still use it.
• Backfilling an entire large table in one unbounded transaction.
• Adding a required field without handling existing rows.
• Deploying schema and application changes with no compatibility overlap.
• Using dual writes without monitoring divergence between representations.
• Assuming every data migration can be reversed safely.

Direct Answer

Give each service authoritative ownership of its data, coordinate cross-service work through durable messages or sagas, and design explicitly for partial failure, retries, and temporary inconsistency.

Detailed Explanation

BEGIN;

UPDATE orders
SET status = 'inventory_reserved'
WHERE id = 'order-42'
  AND status = 'pending';

INSERT INTO outbox_events (
  event_id,
  aggregate_id,
  event_type,
  payload
)
VALUES (
  'event-91',
  'order-42',
  'InventoryReserved',
  '{"orderId":"order-42"}'
);

COMMIT;

Common Interview Pitfalls

• Allowing several services to write directly to one another’s tables.
• Assuming distributed calls will either all succeed or all fail together.
• Publishing an event separately from the database transaction that produced it.
• Designing compensating actions as if they perfectly erase history.
• Ignoring duplicate, delayed, or out-of-order message delivery.
• Exposing temporary inconsistent states without defining client behavior.
• Choosing a shard or service boundary that requires frequent distributed transactions.

Direct Answer

Vertical scaling increases the capacity of one machine, while horizontal scaling adds more instances and distributes work across them.

Detailed Explanation

Common Interview Pitfalls

• Assuming horizontal scaling requires no application or data-design changes.
• Treating vertical scaling as inherently wrong for every workload.
• Adding application instances while leaving one unscaled downstream dependency.
• Keeping request-specific state only in local memory across several instances.
• Scaling from CPU utilization alone without examining latency, queues, or dependency saturation.

Direct Answer

With cache-aside, the application reads from the cache first, loads missing data from the source, and updates or invalidates cached entries when authoritative data changes.

Detailed Explanation

final class UserProfileService {
  private final Cache cache;
  private final UserRepository users;

  UserProfile find(UserId userId) {
    String key = "user-profile:" + userId.value();

    return cache.get(key, UserProfile.class)
        .orElseGet(() -> {
          UserProfile profile = users
              .findProfile(userId)
              .orElseThrow(UserNotFound::new);

          cache.put(
              key,
              profile,
              Duration.ofMinutes(10)
          );

          return profile;
        });
  }

  void update(UserProfile profile) {
    users.save(profile);
    cache.delete(
        "user-profile:" + profile.userId().value()
    );
  }
}

Common Interview Pitfalls

• Treating the cache as the authoritative source of business data.
• Caching values without an expiration or invalidation strategy.
• Using inconsistent cache-key construction across readers and writers.
• Caching every query without considering reuse, size, or change frequency.
• Allowing simultaneous cache misses to overwhelm the underlying database.
• Assuming database updates and cache invalidation occur atomically.

Direct Answer

A load balancer distributes requests across eligible instances, while health checks remove instances that cannot safely serve traffic and restore them after recovery.

Detailed Explanation

@RestController
final class HealthController {
  private final StartupState startupState;

  @GetMapping("/health/live")
  ResponseEntity<Void> live() {
    return ResponseEntity.noContent().build();
  }

  @GetMapping("/health/ready")
  ResponseEntity<Void> ready() {
    if (!startupState.isReady()) {
      return ResponseEntity
          .status(HttpStatus.SERVICE_UNAVAILABLE)
          .build();
    }

    return ResponseEntity.noContent().build();
  }
}

Common Interview Pitfalls

• Using one identical endpoint for liveness, readiness, and startup checks.
• Restarting healthy processes because a shared dependency is temporarily unavailable.
• Running expensive database queries during every health check.
• Returning secrets or sensitive infrastructure details from health endpoints.
• Sending traffic to an instance before initialization has completed.
• Assuming a load balancer removes the need for application-level overload protection.

Direct Answer

Acknowledgements transfer processing responsibility, but failures can cause redelivery. Consumers must therefore handle duplicate messages without repeating the business effect.

Detailed Explanation

BEGIN;

INSERT INTO processed_messages (
  consumer_name,
  message_id
)
VALUES (
  'invoice-created-consumer',
  'event-91'
)
ON CONFLICT DO NOTHING;

-- Continue only when the insert affected one row.

UPDATE customer_balances
SET invoiced_total = invoiced_total + 4999
WHERE customer_id = 'customer-42';

COMMIT;

-- Acknowledge the broker message only after commit.

Common Interview Pitfalls

• Acknowledging a message before its business effect is committed durably.
• Assuming a broker guarantees exactly-once effects in an external database.
• Using a non-unique processed-message lookup that permits races.
• Retrying permanently invalid messages forever.
• Ignoring duplicate delivery after consumer crashes or network failures.
• Confusing publisher confirms with consumer acknowledgements.

Direct Answer

Bound concurrency and queues, reject or defer excess work, expose overload signals, and scale consumers using queue depth, latency, and downstream capacity.

Detailed Explanation

ThreadPoolExecutor executor =
    new ThreadPoolExecutor(
        12,
        12,
        0,
        TimeUnit.SECONDS,
        new ArrayBlockingQueue<>(500),
        new ThreadPoolExecutor.AbortPolicy()
    );

try {
  executor.execute(task);
} catch (RejectedExecutionException overloaded) {
  throw new ServiceUnavailableException(
      "Processing capacity is temporarily exhausted"
  );
}

Common Interview Pitfalls

• Using an unbounded in-memory queue to hide overload.
• Scaling workers without checking database or dependency capacity.
• Monitoring only queue depth and ignoring message age.
• Retrying rejected work immediately without backoff or jitter.
• Accepting unlimited work because it has been moved to a durable queue.
• Applying one global limit without protecting high-priority or tenant-specific capacity.

Direct Answer

Use durable publication, explicit event contracts, partitioned ordering, idempotent consumers, bounded retries, dead-letter handling, observability, and reconciliation for partial failures.

Detailed Explanation

BEGIN;
 
 UPDATE orders
 SET
   status = 'confirmed',
   version = version + 1
 WHERE id = 'order-42'
   AND status = 'payment_authorized';
 
 INSERT INTO outbox_events (
   event_id,
   aggregate_id,
   aggregate_version,
   event_type,
   occurred_at,
   payload
 )
 VALUES (
   'event-91',
   'order-42',
   7,
   'OrderConfirmed',
   now(),
   '{
     "orderId": "order-42",
     "version": 7
   }'
 );
 
 COMMIT;

Common Interview Pitfalls

• Publishing an event separately from the transaction that changes authoritative state.
• Requiring global event ordering when only per-entity ordering is needed.
• Treating events as internal method calls rather than durable contracts.
• Retrying poison messages forever without a quarantine strategy.
• Changing existing event-field meaning without contract migration.
• Assuming every consumer processes an event exactly once.
• Creating events that expose the producer’s entire internal database model.
• Operating an event system without consumer-lag and dead-letter monitoring.

Direct Answer

Authentication establishes identity, authorization checks whether that identity may perform a specific action, and least privilege limits every identity to only the access it needs.

Detailed Explanation

final class ApplicationAuthorization {
  void requireReadAccess(
      AuthenticatedUser actor,
      JobApplication application
  ) {
    boolean ownsApplication =
        application.userId().equals(actor.userId());

    boolean sameTenant =
        application.tenantId().equals(actor.tenantId());

    if (!ownsApplication || !sameTenant) {
      throw new AccessDeniedException();
    }
  }
}

Common Interview Pitfalls

• Treating authentication as permission to access every resource.
• Checking a broad role without verifying object ownership or tenant scope.
• Trusting a user or tenant identifier supplied by the client.
• Enforcing authorization only through hidden frontend controls.
• Giving service accounts broad administrator permissions for convenience.
• Failing to review permissions after responsibilities change.

Direct Answer

Validate untrusted data against explicit rules, keep secrets outside source code with controlled rotation, and return safe error contracts without exposing sensitive implementation details.

Detailed Explanation

public CreateUserCommand validate(
    CreateUserRequest request
) {
  String email = request.email().trim();

  if (
      email.length() > 254 ||
      !EMAIL_PATTERN.matcher(email).matches()
  ) {
    throw new RequestValidationException(
        "A valid email address is required"
    );
  }

  if (request.displayName().length() > 100) {
    throw new RequestValidationException(
        "Display name is too long"
    );
  }

  return new CreateUserCommand(
      email,
      request.displayName()
  );
}

Common Interview Pitfalls

• Using denylist validation as the primary defense against malformed input.
• Building SQL, shell commands, or queries through string concatenation.
• Committing credentials or signing keys to source control.
• Logging access tokens, passwords, or complete sensitive payloads.
• Returning stack traces or database errors to public clients.
• Rotating a secret without supporting controlled activation and rollback.

Direct Answer

Logs describe discrete events, metrics summarize measurable behavior over time, and traces follow requests across components. Shared context allows engineers to correlate all three.

Detailed Explanation

Span span = tracer.spanBuilder(
    "CreateJobApplication"
).startSpan();

try (Scope ignored = span.makeCurrent()) {
  metrics.counter("applications.created")
      .add(1);

  logger.info(
      "Job application created applicationId={} traceId={}",
      application.id(),
      span.getSpanContext().getTraceId()
  );
} catch (RuntimeException error) {
  span.recordException(error);
  span.setStatus(StatusCode.ERROR);
  throw error;
} finally {
  span.end();
}

Common Interview Pitfalls

• Using free-form logs without stable fields or correlation identifiers.
• Adding high-cardinality values such as unrestricted user IDs to metric labels.
• Logging sensitive tokens or complete personal records.
• Collecting telemetry without defining how responders will use it.
• Assuming traces replace metrics or that metrics replace diagnostic logs.
• Failing to propagate trace context across asynchronous and remote boundaries.

Direct Answer

Health checks control instance traffic, SLIs measure user-visible reliability, SLOs define acceptable targets, and alerts should fire when meaningful action is required.

Detailed Explanation

# Example availability SLI:
successful_requests / eligible_requests

# Example SLO:
99.9% successful requests over 28 days

# Error budget:
100% - 99.9% = 0.1%

# Exclude intentionally rejected invalid requests
# only when the SLI definition documents that policy.

Common Interview Pitfalls

• Using infrastructure utilization as the only measure of user-visible reliability.
• Defining an SLO without specifying its measurement window and eligible events.
• Paging on conditions that require no immediate action.
• Making liveness depend on every temporary downstream failure.
• Setting every SLO to one hundred percent without evaluating cost and feasibility.
• Creating alerts without clear ownership, context, or a response procedure.

Direct Answer

Protect critical paths with timeouts and isolation, disable or defer noncritical work, preserve durable state, communicate degraded behavior, and reconcile incomplete operations after recovery.

Detailed Explanation

RecommendationResult recommendations(
    UserId userId
) {
  try {
    return recommendationClient.fetch(
        userId,
        Duration.ofMillis(300)
    );
  } catch (
      TimeoutException |
      CircuitOpenException unavailable
  ) {
    metrics.increment(
        "recommendations.degraded"
    );

    return RecommendationResult.unavailable();
  }
}

Common Interview Pitfalls

• Using a fallback that returns incorrect or unsafe business results.
• Retrying a recovering dependency with uncontrolled concurrency.
• Treating an uncertain external result as a confirmed failure.
• Failing the entire product because one optional feature is unavailable.
• Queueing deferred work without capacity limits or expiration policies.
• Restoring full traffic before verifying that the dependency has recovered.

Direct Answer

Use explicit trust boundaries, least privilege, layered validation, resilient dependencies, durable workflows, correlated telemetry, measurable SLOs, controlled deployment, and tested recovery procedures.

Detailed Explanation

Common Interview Pitfalls

• Treating security and observability as features to add after implementation.
• Collecting large volumes of telemetry without actionable service objectives.
• Using retries without deadlines, idempotency, or downstream protection.
• Giving services shared administrator credentials across environments.
• Deploying breaking database changes in the same step as application code.
• Creating dashboards without defining incident ownership or response actions.
• Testing backups without verifying that restoration actually works.
• Designing fallbacks that violate correctness or security requirements.