Software Engineer Interview Questions

Direct Answer

Array-backed lists provide fast indexed access, while linked lists require traversal for indexed access. Linked lists can add or remove known nodes efficiently, but use extra memory for links.

Detailed Explanation

List<String> arrayBacked = new ArrayList<>();
arrayBacked.add("alpha");
arrayBacked.add("beta");

List<String> linked = new LinkedList<>();
linked.add("alpha");
linked.add("beta");

String value = arrayBacked.get(1);

Common Interview Pitfalls

• Assuming linked-list insertion is constant time when the insertion position must first be found.
• Assuming an array-backed list has a permanently fixed capacity.
• Ignoring the additional memory and cache costs of linked-list nodes.

Direct Answer

A collision occurs when multiple keys map to the same bucket. Capacity controls the bucket count, while the load factor determines when resizing occurs to limit collisions and preserve efficient access.

Detailed Explanation

int expectedEntries = 1_000;
float loadFactor = 0.75f;

Map<String, Integer> counts =
    new HashMap<>(expectedEntries, loadFactor);

counts.merge("java", 1, Integer::sum);

Common Interview Pitfalls

• Claiming that every hash-map lookup is guaranteed to run in constant time.
• Using mutable key fields that change equality or hash-code behavior after insertion.
• Setting a large initial capacity without considering expected entry count and memory use.

Direct Answer

A stack processes the most recently added item first, while a queue processes the earliest item first. A deque supports insertion and removal at both ends and can implement either behavior.

Detailed Explanation

Deque<String> tasks = new ArrayDeque<>();

// Queue behavior
tasks.offerLast("first");
tasks.offerLast("second");
String next = tasks.pollFirst();

// Stack behavior
tasks.push("latest");
String latest = tasks.pop();

Common Interview Pitfalls

• Removing from the wrong end of a deque and accidentally reversing the intended order.
• Using a legacy stack implementation when a deque communicates the behavior more clearly.
• Calling methods that throw on an empty structure without handling the empty case.

Direct Answer

Binary search requires data ordered by the same comparison rule used during the search. It repeatedly halves the search range, and an unsuccessful result may encode the insertion position.

Detailed Explanation

int[] values = {4, 8, 15, 16, 23, 42};

int result = Arrays.binarySearch(values, 20);

if (result >= 0) {
    System.out.println("Found at index " + result);
} else {
    int insertionPoint = -(result + 1);
    System.out.println("Insert at index " + insertionPoint);
}

Common Interview Pitfalls

• Running binary search on data that has not been sorted.
• Sorting with one comparator and searching with a different ordering rule.
• Treating every negative result as minus one instead of decoding the insertion point.
• Assuming the returned index is the first duplicate occurrence.

Direct Answer

A priority queue guarantees efficient access to its highest- or lowest-priority head, but it does not guarantee that iteration returns every element in fully sorted order.

Detailed Explanation

record Task(String name, int priority) {}

PriorityQueue<Task> tasks = new PriorityQueue<>(
    Comparator.comparingInt(Task::priority).reversed()
);

tasks.offer(new Task("normal", 1));
tasks.offer(new Task("urgent", 10));
tasks.offer(new Task("important", 5));

Task next = tasks.poll();

Common Interview Pitfalls

• Assuming iteration over a priority queue returns elements in priority order.
• Using mutable fields in the comparator and changing them after insertion.
• Removing arbitrary elements repeatedly without considering linear search cost.
• Reversing the comparator incorrectly and processing the lowest-priority item first.

Direct Answer

A stable sort preserves the original relative order of elements that compare as equal. This matters when records are sorted repeatedly by different keys or equal-key ordering carries meaning.

Detailed Explanation

record Candidate(String name, String department) {}

List<Candidate> candidates = new ArrayList<>(List.of(
    new Candidate("Asha", "Engineering"),
    new Candidate("Ben", "Design"),
    new Candidate("Carla", "Engineering")
));

candidates.sort(Comparator.comparing(Candidate::name));
candidates.sort(Comparator.comparing(Candidate::department));

Common Interview Pitfalls

• Confusing stable sorting with deterministic sorting.
• Assuming every sorting overload provides the same stability guarantee.
• Applying repeated sorts from the most significant key to the least significant key.
• Ignoring whether equal-key records have an important existing order.

Direct Answer

Vertical scaling increases the resources of one machine, while horizontal scaling adds more machines or service instances and distributes work among them.

Detailed Explanation

Common Interview Pitfalls

• Assuming horizontal scaling automatically removes every single point of failure.
• Storing important session state only in one application instance.
• Ignoring the operational complexity introduced by distributed instances.
• Assuming vertical scaling can continue without hardware or service limits.

Direct Answer

A load balancer distributes incoming traffic across healthy targets. It may also perform health checks, TLS termination, routing, connection management, and failure isolation.

Detailed Explanation

Common Interview Pitfalls

• Using health checks that verify only that a process is running.
• Assuming a load balancer can make an unhealthy dependency available.
• Keeping session state on one target without planning for request routing.
• Configuring retries without considering duplicate side effects.

Direct Answer

With cache-aside, the application reads from the cache first and loads missing data from the database. Invalidation is difficult because cached copies can become stale after updates.

Detailed Explanation

async function getProduct(productId: string): Promise<Product | null> {
  const cacheKey = `product:${productId}`;
  const cached = await cache.get(cacheKey);

  if (cached !== null) {
    return JSON.parse(cached) as Product;
  }

  const product = await productRepository.findById(productId);

  if (product !== null) {
    await cache.set(cacheKey, JSON.stringify(product), {
      ttlSeconds: 300
    });
  }

  return product;
}

Common Interview Pitfalls

• Caching data without defining an expiration or invalidation strategy.
• Caching database misses for too long and hiding newly created records.
• Deleting a cache entry before confirming that the database write succeeded.
• Allowing many concurrent misses to overload the backing database.

Direct Answer

Replication stores copies of the same data on multiple nodes, while sharding divides different portions of a dataset across nodes using a partitioning rule.

Detailed Explanation

Common Interview Pitfalls

• Treating replication and sharding as interchangeable scaling strategies.
• Assuming read replicas always contain the latest committed data.
• Selecting a shard key that sends most traffic to one shard.
• Ignoring cross-shard queries and transactions during schema design.

Direct Answer

An operation is idempotent when repeating the same request has the same intended server effect as sending it once. Create operations can use a unique idempotency key to deduplicate retries.

Detailed Explanation

POST /api/payments
Idempotency-Key: 8df142dd-879c-4cb0-9f59-c34e118a35da
Content-Type: application/json

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

Common Interview Pitfalls

• Assuming every POST request is automatically safe to retry.
• Reusing one idempotency key for different logical operations.
• Recording the key separately from the business operation without failure coordination.
• Returning a different resource when the same key is retried.

Direct Answer

During a network partition, a distributed system cannot guarantee both immediate consistency and availability for every request. It must reject or delay some operations, or accept potentially stale state.

Detailed Explanation

Common Interview Pitfalls

• Describing CAP as a choice of any two properties during normal operation.
• Assuming eventual consistency means that conflicting writes resolve automatically.
• Applying one consistency policy to every operation without business analysis.
• Ignoring how clients observe errors, stale reads, or reconciliation.

Direct Answer

A process is an independently executing program with its own resources, while threads are execution paths within a process that share its memory and resources.

Detailed Explanation

Thread worker = Thread.ofPlatform().start(() -> {
    System.out.println(
        "Running in: " + Thread.currentThread().getName()
    );
});

worker.join();

Common Interview Pitfalls

• Claiming that threads within one process have completely separate memory.
• Assuming shared memory automatically makes thread communication safe.
• Using the terms process and thread as if they mean the same thing.
• Ignoring that one process can contain many concurrent threads.

Direct Answer

A race condition occurs when a result depends on unpredictable thread interleaving. A critical section is code that accesses shared state and must be coordinated.

Detailed Explanation

final class Counter {
  private int value;

  public synchronized void increment() {
    value++;
  }

  public synchronized int get() {
    return value;
  }
}

Common Interview Pitfalls

• Assuming that a simple increment is always an atomic operation.
• Protecting writes while leaving related reads unsynchronized.
• Using different locks to protect the same shared invariant.
• Making the critical section much larger than necessary.

Direct Answer

A mutex provides exclusive ownership of a resource, a lock is a broader coordination abstraction, and a semaphore uses permits to limit concurrent access.

Detailed Explanation

Semaphore permits = new Semaphore(3);

void callExternalService() throws InterruptedException {
  permits.acquire();

  try {
    externalService.call();
  } finally {
    permits.release();
  }
}

Common Interview Pitfalls

• Failing to release a lock or permit inside a finally block.
• Releasing more semaphore permits than were acquired.
• Using a semaphore when exclusive ownership semantics are required.
• Assuming a fair lock guarantees operating-system thread scheduling fairness.

Direct Answer

Deadlock occurs when threads wait indefinitely for resources held by one another. Consistent lock ordering, timeouts, reduced lock scope, and avoiding nested locks help prevent it.

Detailed Explanation

void transfer(Account first, Account second) {
  Account lower =
      first.id() < second.id() ? first : second;
  Account higher =
      first.id() < second.id() ? second : first;

  synchronized (lower) {
    synchronized (higher) {
      performTransfer(first, second);
    }
  }
}

Common Interview Pitfalls

• Acquiring the same set of locks in different orders across code paths.
• Holding a lock while performing slow network or file operations.
• Assuming synchronized code cannot deadlock.
• Using a timeout without handling partial work or retry behavior.

Direct Answer

Executors separate task submission from execution policy. Thread pools reuse workers, limit concurrency, queue work, manage shutdown, and reduce thread-creation overhead.

Detailed Explanation

ExecutorService executor =
    Executors.newFixedThreadPool(4);

try {
  Future<Integer> result = executor.submit(() -> {
    return calculateValue();
  });

  System.out.println(result.get());
} finally {
  executor.shutdown();
}

Common Interview Pitfalls

• Creating an unbounded number of platform threads under heavy load.
• Using an unbounded task queue without considering memory growth.
• Forgetting to shut down an executor owned by the application.
• Assuming virtual threads remove database or network capacity limits.
• Blocking indefinitely on Future.get without timeout or cancellation planning.

Direct Answer

A happens-before relationship guarantees that one thread’s earlier effects are visible to another ordered action. Without it, shared reads may observe stale or reordered values.

Detailed Explanation

final class TaskState {
  private int result;
  private volatile boolean complete;

  void produce() {
    result = 42;
    complete = true;
  }

  int consume() {
    if (!complete) {
      throw new IllegalStateException("Not complete");
    }

    return result;
  }
}

Common Interview Pitfalls

• Assuming source-code order alone guarantees cross-thread visibility.
• Using volatile for a compound read-modify-write operation.
• Confusing atomicity with memory visibility.
• Publishing a mutable object without a safe publication mechanism.
• Assuming sleep creates a happens-before relationship.

Direct Answer

A unit test checks a small component in isolation, while an integration test verifies that multiple components or external systems work together correctly.

Detailed Explanation

class PriceCalculatorTest {

  @Test
  void appliesPercentageDiscount() {
    PriceCalculator calculator = new PriceCalculator();

    BigDecimal result = calculator.applyDiscount(
        new BigDecimal("100.00"),
        new BigDecimal("0.20")
    );

    assertEquals(new BigDecimal("80.0000"), result);
  }
}

Common Interview Pitfalls

• Calling every automated test a unit test regardless of its dependencies.
• Replacing all collaborators with mocks and testing implementation details.
• Using a real database in a test intended to be fast and isolated.
• Relying only on unit tests without testing important integration boundaries.

Direct Answer

A stub returns controlled responses, a mock also verifies interactions, and a fake provides a simplified working implementation such as an in-memory repository.

Detailed Explanation

PaymentGateway gateway = mock(PaymentGateway.class);
when(gateway.charge(4999)).thenReturn(
    new PaymentResult("payment-123", true)
);

CheckoutService service = new CheckoutService(gateway);

Receipt receipt = service.checkout(4999);

assertTrue(receipt.successful());
verify(gateway).charge(4999);

Common Interview Pitfalls

• Using the words mock and stub interchangeably in every context.
• Verifying every internal method call instead of observable behavior.
• Creating complicated mocks that reproduce the production implementation.
• Using a fake whose behavior differs materially from the real dependency.

Direct Answer

The test pyramid recommends many fast, focused lower-level tests, fewer integration tests, and a small number of broad end-to-end tests for critical workflows.

Detailed Explanation

Common Interview Pitfalls

• Treating the test pyramid as a mandatory percentage formula.
• Testing every possible behavior through the user interface.
• Having many unit tests but no coverage of important system boundaries.
• Duplicating the same assertions at every test level.
• Ignoring test maintenance cost when adding broad end-to-end tests.

Direct Answer

A flaky test passes and fails without a relevant code change. Common causes include timing, shared state, test ordering, unreliable dependencies, randomness, and concurrency.

Detailed Explanation

@Test
void tokenIsExpiredAfterDeadline() {
  Instant now = Instant.parse("2026-08-04T12:00:00Z");
  Clock clock = Clock.fixed(now, ZoneOffset.UTC);

  Token token = new Token(
      now.minusSeconds(120),
      Duration.ofSeconds(60)
  );

  assertTrue(token.isExpired(clock));
}

Common Interview Pitfalls

• Adding longer sleep calls instead of waiting for an observable condition.
• Automatically retrying flaky tests without investigating their cause.
• Allowing tests to depend on execution order.
• Using shared accounts or records across parallel test runs.
• Quarantining a flaky test permanently and forgetting its coverage.

Direct Answer

A pipeline commonly validates source code, builds an immutable artifact, runs automated checks, scans for risks, deploys safely, and verifies the deployed release.

Detailed Explanation

name: Verify application

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Common Interview Pitfalls

• Rebuilding a different artifact for production than the one previously tested.
• Running fast validation only near the end of a long pipeline.
• Allowing failed quality gates to be routinely ignored.
• Placing secrets directly inside pipeline configuration.
• Deploying successfully without verifying application health afterward.

Direct Answer

Progressive delivery exposes a release gradually while monitoring health. Rollback restores a known-good version when predefined signals show unacceptable impact.

Detailed Explanation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: interview-api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: interview-api
  template:
    metadata:
      labels:
        app: interview-api
    spec:
      containers:
        - name: api
          image: registry.example.com/interview-api:2.4.0
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

Common Interview Pitfalls

• Calling a deployment successful before observing application and business metrics.
• Assuming application rollback also reverses every database change.
• Deploying all instances simultaneously without preserving healthy capacity.
• Using a readiness check that does not represent the ability to serve traffic.
• Starting a canary rollout without predefined promotion or rollback criteria.

Direct Answer

Meaningful names communicate intent, while consistent conventions make code easier to read, review, search, maintain, and modify without repeatedly interpreting local styles.

Detailed Explanation

// Unclear
int d;
List<User> list = load();

// Clearer
int retryDelaySeconds;
List<User> activeUsers = loadActiveUsers();

Common Interview Pitfalls

• Using generic names such as data, value, item, or manager without context.
• Encoding implementation details into names that may soon become outdated.
• Using unexplained abbreviations that are not standard in the domain.
• Choosing a misleading name and relying on comments to correct it.
• Applying naming conventions inconsistently within the same codebase.

Direct Answer

SOLID describes five object-oriented design principles intended to improve cohesion, substitutability, extensibility, interface focus, and dependency decoupling.

Detailed Explanation

interface PaymentGateway {
  PaymentResult charge(Money amount);
}

final class CheckoutService {
  private final PaymentGateway paymentGateway;

  CheckoutService(PaymentGateway paymentGateway) {
    this.paymentGateway = paymentGateway;
  }

  PaymentResult checkout(Money total) {
    return paymentGateway.charge(total);
  }
}

Common Interview Pitfalls

• Treating SOLID as a requirement to create an interface for every class.
• Confusing single responsibility with having only one method.
• Using inheritance even when the subtype cannot preserve the parent contract.
• Splitting interfaces so aggressively that the design becomes difficult to navigate.
• Adding abstraction before a meaningful source of variation exists.

Direct Answer

A code smell is a design warning rather than a confirmed defect. Safe refactoring improves internal structure in small steps while preserving observable behavior.

Detailed Explanation

// Before
Money calculateTotal(Order order) {
  Money total = Money.zero();

  for (LineItem item : order.items()) {
    total = total.add(
        item.unitPrice().multiply(item.quantity())
    );
  }

  return total;
}

// After
Money calculateTotal(Order order) {
  return order.items()
      .stream()
      .map(LineItem::subtotal)
      .reduce(Money.zero(), Money::add);
}

Common Interview Pitfalls

• Treating every code smell as proof that the implementation is incorrect.
• Refactoring without tests or another way to verify preserved behavior.
• Combining a large refactor with unrelated feature development.
• Introducing a design pattern without a problem that requires it.
• Changing public behavior while describing the work as only refactoring.

Direct Answer

Validate untrusted data at system boundaries, enforce domain invariants internally, fail clearly on invalid states, and avoid catching errors merely to continue with corrupted assumptions.

Detailed Explanation

public record CreateAccountRequest(
    String email,
    int age
) {
  public CreateAccountRequest {
    if (email == null || email.isBlank()) {
      throw new IllegalArgumentException(
          "Email is required"
      );
    }

    if (age < 18 || age > 120) {
      throw new IllegalArgumentException(
          "Age is outside the supported range"
      );
    }
  }
}

Common Interview Pitfalls

• Trusting client-side validation as the only security control.
• Using a denylist when a narrow allowlist is practical.
• Catching all exceptions and returning a successful result.
• Logging passwords, access tokens, or other sensitive input values.
• Repeating inconsistent validation rules across several layers.
• Silently replacing invalid data with misleading default values.

Direct Answer

A code review should evaluate correctness, design, complexity, tests, security, naming, documentation, maintainability, and whether the change fits the surrounding system.

Detailed Explanation

Common Interview Pitfalls

• Reviewing only formatting while ignoring design and correctness.
• Approving a change without understanding its intended behavior.
• Requesting broad unrelated refactoring in a focused change.
• Writing vague feedback without explaining the technical concern.
• Treating personal preferences as mandatory project standards.
• Ignoring tests, migrations, observability, or deployment impact.

Direct Answer

Teams should document debt, measure its impact, prioritize it against product risk, and record architectural decisions with assumptions, alternatives, benefits, costs, and review triggers.

Detailed Explanation

Common Interview Pitfalls

• Treating all technical debt as evidence of poor engineering.
• Creating debt tickets without impact, ownership, or review criteria.
• Postponing all remediation until a large rewrite becomes necessary.
• Choosing architecture based only on technical elegance.
• Failing to revisit decisions after assumptions or usage patterns change.
• Describing a tradeoff without identifying who or what bears the cost.