Software Developer Interview Questions

Direct Answer

Encapsulation hides internal representation and exposes controlled operations, allowing an object to validate changes and preserve its business invariants.

Detailed Explanation

public final class BankAccount {
  private BigDecimal balance;

  public BankAccount(BigDecimal openingBalance) {
    if (openingBalance.signum() < 0) {
      throw new IllegalArgumentException(
          "Opening balance cannot be negative"
      );
    }

    this.balance = openingBalance;
  }

  public void withdraw(BigDecimal amount) {
    if (amount.signum() <= 0) {
      throw new IllegalArgumentException(
          "Withdrawal must be positive"
      );
    }

    if (balance.compareTo(amount) < 0) {
      throw new IllegalStateException(
          "Insufficient funds"
      );
    }

    balance = balance.subtract(amount);
  }

  public BigDecimal balance() {
    return balance;
  }
}

Common Interview Pitfalls

• Equating encapsulation only with declaring fields private.
• Providing unrestricted setters that allow invalid object states.
• Returning mutable internal collections directly to callers.
• Placing domain validation only in controllers or user interfaces.

Direct Answer

Prefer composition when one object needs another object’s capabilities without forming a genuine substitutable subtype relationship or inheriting implementation details.

Detailed Explanation

interface DiscountPolicy {
  Money apply(Money subtotal);
}

final class CheckoutService {
  private final DiscountPolicy discountPolicy;

  CheckoutService(DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
  }

  Money calculateTotal(Money subtotal) {
    return discountPolicy.apply(subtotal);
  }
}

Common Interview Pitfalls

• Using inheritance only to reuse a small amount of implementation.
• Creating a subtype that cannot satisfy the parent type contract.
• Building deep inheritance hierarchies that are difficult to change.
• Assuming composition always requires a dependency injection framework.

Direct Answer

Interfaces define capabilities and contracts across unrelated types, while abstract classes can share state, constructors, protected behavior, and partial implementation within a hierarchy.

Detailed Explanation

interface Auditable {
  AuditEntry auditEntry();
}

abstract class Document {
  private final String id;

  protected Document(String id) {
    this.id = id;
  }

  public String id() {
    return id;
  }

  public abstract String render();
}

final class Invoice extends Document
    implements Auditable {

  Invoice(String id) {
    super(id);
  }

  @Override
  public String render() {
    return "Invoice " + id();
  }

  @Override
  public AuditEntry auditEntry() {
    return new AuditEntry(id(), "invoice");
  }
}

Common Interview Pitfalls

• Using an abstract class only because two types contain similar code.
• Adding unrelated default methods to an interface for implementation reuse.
• Exposing protected mutable state that subclasses can invalidate.
• Creating an interface with only one implementation without a variation boundary.

Direct Answer

Overriding supplies subtype behavior selected at runtime, while overloading defines methods with different parameter lists selected from compile-time argument types.

Detailed Explanation

interface NotificationSender {
  void send(String message);
}

final class EmailSender
    implements NotificationSender {

  @Override
  public void send(String message) {
    System.out.println("Email: " + message);
  }
}

final class Formatter {
  String format(int value) {
    return Integer.toString(value);
  }

  String format(String value) {
    return value.trim();
  }
}

NotificationSender sender = new EmailSender();
sender.send("Welcome");

Common Interview Pitfalls

• Describing method overloading as runtime polymorphism.
• Attempting to overload methods using only different return types.
• Accidentally changing a parameter type instead of overriding a method.
• Assuming static methods do not participate in dynamic dispatch.
• Using an unsafe narrower contract in an overriding implementation.

Direct Answer

Objects considered equal must produce the same hash code. Equality should also be reflexive, symmetric, transitive, consistent, and false for null.

Detailed Explanation

public record ProductId(String value) {
  public ProductId {
    if (value == null || value.isBlank()) {
      throw new IllegalArgumentException(
          "Product ID is required"
      );
    }
  }
}

Common Interview Pitfalls

• Overriding equals without providing a compatible hashCode implementation.
• Assuming unequal objects must always have different hash codes.
• Using mutable fields for equality while objects are stored in a HashSet.
• Implementing equality asymmetrically across a class hierarchy.
• Comparing reference identity when logical value equality is required.

Direct Answer

Dependency injection supplies collaborators externally, reducing construction coupling. Incorrect lifetimes can cause shared-state bugs, stale data, leaks, or short-lived services captured by long-lived ones.

Detailed Explanation

interface UserRepository {
  Optional<User> findById(UserId id);
}

final class UserProfileService {
  private final UserRepository repository;

  UserProfileService(UserRepository repository) {
    this.repository = repository;
  }

  UserProfile load(UserId id) {
    User user = repository.findById(id)
        .orElseThrow(UserNotFoundException::new);

    return UserProfile.from(user);
  }
}

Common Interview Pitfalls

• Using a service locator that hides an object’s real dependencies.
• Injecting a short-lived service directly into a singleton.
• Registering mutable non-thread-safe services as singletons.
• Creating interfaces for every class without a useful abstraction boundary.
• Allowing constructors to accumulate many unrelated dependencies.
• Assuming a dependency injection container fixes poor separation of concerns.

Direct Answer

Normalization separates related facts to reduce duplication and update anomalies. Denormalization intentionally duplicates or combines data to simplify or accelerate specific reads.

Detailed Explanation

CREATE TABLE customers (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name text NOT NULL,
  email text NOT NULL UNIQUE
);

CREATE TABLE orders (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id bigint NOT NULL
    REFERENCES customers(id),
  ordered_at timestamptz NOT NULL DEFAULT now()
);

Common Interview Pitfalls

• Treating normalization as a requirement to split every field into another table.
• Denormalizing before measuring an actual query-performance problem.
• Duplicating data without identifying the authoritative source.
• Ignoring the consistency work required when duplicated values change.

Direct Answer

A primary key identifies each row, a unique constraint prevents duplicate values, and a foreign key requires referenced values to exist in another compatible key.

Detailed Explanation

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

CREATE TABLE members (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  team_id bigint NOT NULL,
  email text NOT NULL UNIQUE,
  CONSTRAINT members_team_fk
    FOREIGN KEY (team_id)
    REFERENCES teams(id)
    ON DELETE RESTRICT
);

Common Interview Pitfalls

• Using a nullable column as part of required entity identity.
• Assuming a foreign key automatically creates an index on every referencing column.
• Using cascading deletion without considering the ownership relationship.
• Relying only on application code to maintain referential integrity.
• Confusing a unique business key with the table primary key.

Direct Answer

An inner join keeps matching rows, while outer joins also preserve unmatched rows from one or both sides. One-to-many matches can multiply result rows.

Detailed Explanation

SELECT
  c.id,
  c.name,
  COUNT(o.id) AS order_count
FROM customers AS c
LEFT JOIN orders AS o
  ON o.customer_id = c.id
GROUP BY c.id, c.name
ORDER BY c.id;

Common Interview Pitfalls

• Using an inner join when unmatched parent rows must remain visible.
• Forgetting a join condition and accidentally producing a cross join.
• Assuming one output row will always correspond to one left-side row.
• Counting joined rows without considering duplicated matches.
• Filtering nullable outer-joined columns in a way that removes unmatched rows.

Direct Answer

Isolation controls which concurrent changes a transaction may observe. Stronger isolation reduces anomalies but may cause blocking, serialization failures, or retries.

Detailed Explanation

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SELECT available_quantity
FROM inventory
WHERE product_id = 42
FOR UPDATE;

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

COMMIT;

Common Interview Pitfalls

• Assuming a transaction automatically prevents every concurrency anomaly.
• Performing external side effects inside a transaction that may be retried.
• Retrying only the failed statement instead of the entire transaction.
• Keeping transactions open while waiting for user input or network calls.
• Selecting an isolation level without identifying the protected invariant.

Direct Answer

Indexes provide faster paths to matching rows but add storage and write overhead. In a multicolumn B-tree index, leading-column conditions usually determine efficient scan boundaries.

Detailed Explanation

CREATE INDEX applications_user_created_idx
ON job_applications (user_id, created_at DESC);

SELECT id, company, status, created_at
FROM job_applications
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 20;

Common Interview Pitfalls

• Adding an index to every column without considering write overhead.
• Ignoring the order of columns in a composite B-tree index.
• Keeping duplicate or unused indexes indefinitely.
• Assuming the database must use an index whenever one exists.
• Indexing low-selectivity values without considering the actual query pattern.

Direct Answer

EXPLAIN shows the planner’s estimated execution plan, while EXPLAIN ANALYZE executes the query and reports actual timing and row counts for comparison.

Detailed Explanation

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

Common Interview Pitfalls

• Looking only for whether an index appears in the plan.
• Ignoring large differences between estimated and actual row counts.
• Testing with unrepresentative data or parameters.
• Running EXPLAIN ANALYZE on a modifying statement without controlling side effects.
• Optimizing one query without measuring the overall workload impact.
• Assuming the operation with the highest displayed cost is always the root cause.

Direct Answer

REST APIs model domain resources with stable URLs and use HTTP methods according to their defined semantics, such as GET for retrieval, POST for processing, PUT for replacement, and DELETE for removal.

Detailed Explanation

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

Common Interview Pitfalls

• Using action-heavy paths such as getProject or deleteProject instead of HTTP method semantics.
• Performing state-changing operations through GET requests.
• Exposing internal database structure directly as the public API contract.
• Using PUT for partial updates without defining replacement semantics.
• Creating inconsistent pluralization and path conventions across resources.

Direct Answer

An API should select the status code that describes the HTTP outcome and return a consistent machine-readable error body, such as RFC 9457 Problem Details, with safe diagnostic information.

Detailed Explanation

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

{
  "type": "https://api.example.com/problems/validation-error",
  "title": "Request validation failed",
  "status": 422,
  "detail": "One or more fields are invalid.",
  "instance": "/api/applications/request-729",
  "errors": {
    "email": ["A valid email address is required."]
  }
}

Common Interview Pitfalls

• Returning HTTP 200 for every response and placing failure status only in JSON.
• Using 401 and 403 interchangeably.
• Returning different error structures from different endpoints.
• Exposing stack traces or sensitive implementation details to clients.
• Using 500 for validation errors or expected business conflicts.

Direct Answer

An operation is idempotent when repeated identical requests have the same intended server effect as one request. Non-idempotent operations can use scoped idempotency keys to deduplicate retries.

Detailed Explanation

POST /api/orders
Idempotency-Key: 814629e3-5450-48fb-b7c3-ab81188b3c46
Content-Type: application/json

{
  "customerId": "customer-42",
  "items": [
    {
      "productId": "product-9",
      "quantity": 2
    }
  ]
}

Common Interview Pitfalls

• Assuming every POST request is automatically safe to retry.
• Reusing one idempotency key for different logical operations.
• Ignoring payload differences when the same key is submitted again.
• Recording the idempotency key separately from the business transaction without coordination.
• Keeping idempotency keys globally scoped instead of associating them with the caller.

Direct Answer

Version an API when an unavoidable breaking contract change is introduced. Preserve compatibility through additive changes, tolerant clients, deprecation periods, migration guidance, and contract testing.

Detailed Explanation

GET /api/v1/customers/42
Accept: application/json

GET /api/v2/customers/42
Accept: application/json

Common Interview Pitfalls

• Creating a new public API version for every internal code change.
• Removing fields without a deprecation and migration period.
• Assuming adding a required request field is backward-compatible.
• Changing the meaning of an existing field without changing the contract.
• Maintaining old versions indefinitely without usage monitoring or retirement criteria.

Direct Answer

Authentication establishes the caller’s identity, while authorization decides whether that identity may perform a specific action on a particular resource.

Detailed Explanation

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

  if (
    application === null ||
    application.userId !== actor.userId
  ) {
    throw new NotFoundError();
  }

  return application;
}

Common Interview Pitfalls

• Treating authentication as proof that a caller can access every resource.
• Checking roles without checking ownership of the requested object.
• Trusting client-supplied user IDs or tenant IDs without server validation.
• Enforcing authorization only by hiding user-interface controls.
• Putting access tokens, passwords, or API keys in request URLs.
• Returning excessive resource details before authorization succeeds.

Direct Answer

High-volume APIs should bound page sizes, use stable ordering and cursor pagination where appropriate, validate filters, expose continuation metadata, and communicate enforceable rate limits and retries.

Detailed Explanation

GET /api/jobs?status=applied&limit=25&cursor=eyJjcmVhdGVkQXQiOiIyMDI2LTA4LTA0VDE4OjAwOjAwWiIsImlkIjoiam9iLTQyIn0
Accept: application/json

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

{
  "items": [],
  "nextCursor": "eyJjcmVhdGVkQXQiOiIyMDI2LTA4LTA0VDE3OjMwOjAwWiIsImlkIjoiam9iLTY3In0",
  "hasMore": true
}

Common Interview Pitfalls

• Returning an unbounded collection from a public endpoint.
• Using cursor pagination without a deterministic and unique ordering.
• Accepting arbitrary filter or sort expressions from clients.
• Allowing clients to request extremely large page sizes.
• Retrying rate-limited requests immediately without backoff.
• Exposing cursor internals that clients are expected to construct or modify.

Direct Answer

Meaningful names communicate intent, while focused functions keep related behavior together and reduce the amount of context required to understand, test, and change code.

Detailed Explanation

// Too vague and overloaded
void process(Order order) {
  validate(order);
  save(order);
  emailCustomer(order);
}

// Clearer orchestration through named operations
void placeOrder(Order order) {
  validateOrder(order);
  orderRepository.save(order);
  confirmationService.sendFor(order);
}

Common Interview Pitfalls

• Using generic names such as data, value, result, helper, or manager without useful context.
• Splitting every statement into a separate function regardless of readability.
• Giving a broad function a narrow name that hides additional side effects.
• Encoding obsolete implementation details into public method names.
• Choosing short names that require readers to inspect the implementation repeatedly.

Direct Answer

Code should express what it does through structure and naming, while comments and API documentation should explain contracts, intent, constraints, tradeoffs, and non-obvious decisions.

Detailed Explanation

/**
 * Reserves inventory for one order.
 *
 * <p>The caller may safely retry with the same reservation ID.
 * A different payload using the same ID is rejected.
 *
 * @throws InsufficientInventoryException
 *     when the requested quantity is unavailable
 */
Reservation reserve(
    ReservationId reservationId,
    ProductId productId,
    int quantity
) {
  // The database constraint is the final protection
  // against concurrent over-reservation.
  return reservationRepository.reserve(
      reservationId,
      productId,
      quantity
  );
}

Common Interview Pitfalls

• Writing comments that repeat the implementation without adding intent or context.
• Using comments to compensate for misleading names or unnecessarily complex code.
• Leaving documentation unchanged after the behavior or contract changes.
• Documenting implementation details as if they were stable public guarantees.
• Adding TODO comments without ownership, context, or a trackable follow-up.

Direct Answer

A code smell is a warning that a design may be difficult to understand or change. It should be evaluated using context, change frequency, defect risk, and maintenance cost.

Detailed Explanation

Common Interview Pitfalls

• Treating every code smell as a confirmed defect.
• Applying a design pattern before understanding the actual change pressure.
• Refactoring stable code only to satisfy a personal style preference.
• Ignoring a smell that repeatedly causes defects or slows delivery.
• Evaluating maintainability without considering the surrounding system and team.

Direct Answer

Extract Method moves a coherent block into a well-named function, improving readability or reuse. It should represent a meaningful concept rather than merely reducing line count.

Detailed Explanation

Money calculateInvoiceTotal(Invoice invoice) {
  Money subtotal = calculateSubtotal(invoice.lines());
  Money tax = calculateTax(subtotal, invoice.taxRegion());
  Money discount = calculateDiscount(
      subtotal,
      invoice.customerTier()
  );

  return subtotal.add(tax).subtract(discount);
}

private Money calculateSubtotal(
    List<InvoiceLine> lines
) {
  return lines.stream()
      .map(InvoiceLine::total)
      .reduce(Money.zero(), Money::add);
}

Common Interview Pitfalls

• Extracting functions only to satisfy an arbitrary line-count limit.
• Creating vague helper methods that hide rather than clarify behavior.
• Combining coincidentally similar code that represents different domain rules.
• Passing many unrelated parameters into every extracted function.
• Moving duplication into a shared utility that becomes a dependency for unrelated modules.

Direct Answer

Establish tests for observable behavior, make small structural changes, run the relevant suite after each step, and separate behavior changes from refactoring whenever practical.

Detailed Explanation

Common Interview Pitfalls

• Beginning a large refactor while the existing test suite is already failing.
• Changing behavior and structure together without making the distinction clear.
• Writing tests that are tightly coupled to private implementation details.
• Making many structural changes before running any verification.
• Assuming passing unit tests prove that integrations and deployments remain correct.

Direct Answer

Introduce abstraction when stable common behavior and real variation are understood. Prefer the simplest design that meets current needs while preserving practical paths for future change.

Detailed Explanation

Common Interview Pitfalls

• Creating a generic framework before the first concrete use case is understood.
• Assuming every duplicated line must immediately share one abstraction.
• Using boolean parameters to combine operations with different responsibilities.
• Rejecting all upfront design even when public contracts are expensive to change.
• Preserving an abstraction after its original assumptions are no longer valid.
• Measuring simplicity only by the number of source-code lines.

Direct Answer

Reproduce the failure consistently, record the environment and inputs, reduce the scenario to its smallest failing case, and change one suspected factor at a time.

Detailed Explanation

@Test
void rejectsDuplicateRegistrationEmail() {
  UserRepository repository =
      new InMemoryUserRepository();

  repository.save(
      new User("existing@example.com")
  );

  RegistrationService service =
      new RegistrationService(repository);

  assertThrows(
      DuplicateEmailException.class,
      () -> service.register(
          "existing@example.com"
      )
  );
}

Common Interview Pitfalls

• Attempting fixes before confirming the failure can be reproduced.
• Changing several variables at once and losing causal information.
• Testing with different data or configuration than the failing environment.
• Keeping unnecessary application components in the reproduction case.
• Ignoring whether the defect began after a specific deployment or dependency update.

Direct Answer

Start with the exception type and message, inspect the first relevant application frame, follow chained causes, and correlate timestamps, request IDs, and surrounding log events.

Detailed Explanation

try {
  paymentGateway.charge(request);
} catch (GatewayTimeoutException cause) {
  logger.error(
      "Payment gateway timed out orderId={} requestId={}",
      request.orderId(),
      requestId,
      cause
  );

  throw new PaymentProcessingException(
      "Unable to complete payment",
      cause
  );
}

Common Interview Pitfalls

• Reading only the final exception message and ignoring the chained cause.
• Assuming the first framework frame identifies the application defect.
• Logging an exception without the operation or correlation context.
• Removing the original cause when wrapping an exception.
• Logging credentials, access tokens, or sensitive request contents.
• Searching logs without aligning timestamps and time zones.

Direct Answer

Use targeted breakpoints to pause near the suspected transition, inspect variables and call stacks, evaluate assumptions, and avoid changing runtime state in ways that hide the defect.

Detailed Explanation

public Money calculateTotal(Order order) {
  Money subtotal = calculateSubtotal(order);

  // Conditional breakpoint example:
  // order.id().equals("order-42")

  Money discount =
      discountPolicy.apply(order, subtotal);

  return subtotal.subtract(discount);
}

Common Interview Pitfalls

• Stepping through the entire application without first narrowing the suspected area.
• Using unconditional breakpoints inside high-frequency loops or request paths.
• Changing variable values in the debugger and then trusting the resulting behavior.
• Evaluating methods with side effects while inspecting runtime state.
• Assuming debugger-paused concurrency behaves exactly like normal execution.

Direct Answer

A symptom fix reduces the visible failure, while a root-cause correction addresses the underlying condition that created it and prevents recurrence through systemic improvements.

Detailed Explanation

Common Interview Pitfalls

• Treating a restart or retry as proof that the underlying problem is solved.
• Stopping the investigation at the first human mistake found.
• Writing a root cause that is not supported by incident evidence.
• Using the Five Whys mechanically to force one simple explanation.
• Correcting code without improving detection or preventing recurrence.
• Blaming an individual instead of examining system and process conditions.

Direct Answer

Measure the affected resource, capture evidence during the failure, identify where time or memory is consumed, form a hypothesis, and verify improvements with comparable measurements.

Detailed Explanation

# Print Java threads
jcmd <pid> Thread.print

# Create a class histogram
jcmd <pid> GC.class_histogram

# Start a two-minute Java Flight Recorder capture
jcmd <pid> JFR.start \
  name=diagnostic \
  settings=profile \
  duration=2m \
  filename=diagnostic.jfr

Common Interview Pitfalls

• Optimizing code before measuring where time or resources are consumed.
• Looking only at average latency and ignoring tail latency.
• Taking a heap dump after restarting and losing the failing state.
• Assuming high memory usage always proves a memory leak.
• Collecting one thread dump instead of comparing several samples.
• Improving one component without checking downstream or system-wide effects.

Direct Answer

Preserve evidence, correlate logs, metrics, traces, deployments, and affected requests, compare successful and failed cases, and test hypotheses without destabilizing production.

Detailed Explanation

Common Interview Pitfalls

• Restarting affected instances before preserving useful diagnostic evidence.
• Enabling unrestricted debug logging across all production traffic.
• Assuming correlation between a deployment and failure proves causation.
• Investigating only failed requests without comparing successful cases.
• Changing several production controls at once and losing causal clarity.
• Ignoring rare data shapes, retries, timeouts, and concurrency conditions.