Software Engineer Interview Questions & Answers (2026)

Explain how a hash table works and discuss its average‑case time complexity for insert, delete, and lookup.

A hash table maps keys to buckets using a hash function, then stores the key‑value pair in that bucket. In the average case, assuming a good hash function and low load factor, insert, delete, and lookup are O(1) because you compute the hash and access the bucket directly. Collisions are handled via chaining or open addressing; with chaining, each bucket holds a linked list, so worst‑case becomes O(n) if many keys collide. Interviewers look for understanding of collision resolution, load factor impact, and why constant‑time expectations rely on uniform distribution.

class HashTable:
    def __init__(self, size=1024):
        self.buckets = [[] for _ in range(size)]
    def _hash(self, key):
        return hash(key) % len(self.buckets)
    def set(self, key, value):
        idx = self._hash(key)
        for i, (k, _) in enumerate(self.buckets[idx]):
            if k == key:
                self.buckets[idx][i] = (key, value)
                return
        self.buckets[idx].append((key, value))

What is the difference between a process and a thread, and when would you use each?

A process is an independent execution unit with its own memory space, while a thread is a lightweight unit that shares the process's memory. Processes provide isolation, making them suitable for tasks that must not interfere with each other, such as running separate services. Threads enable parallelism within the same application, useful for I/O‑bound or CPU‑bound work where shared data reduces communication overhead. Interviewers expect you to discuss context switching cost, synchronization primitives, and typical use cases like web servers (threads) versus microservices (processes).

Describe the quicksort algorithm and its average‑case time complexity.

Quicksort selects a pivot, partitions the array into elements less than and greater than the pivot, then recursively sorts the partitions. The average‑case time complexity is O(n log n) because each partition roughly halves the array, leading to log n levels of recursion, each processing n elements. The worst case degrades to O(n²) when the pivot is consistently the smallest or largest element, which can be mitigated by randomizing the pivot or using median‑of‑three. Interviewers look for clear articulation of partitioning, recursion, and the importance of pivot choice.

How does garbage collection work in Java, and what are its main phases?

Java's garbage collector reclaims memory that is no longer reachable. It typically operates in three phases: marking, where reachable objects are identified; sweeping, where unmarked objects are reclaimed; and compacting, which moves surviving objects to reduce fragmentation. Modern collectors like G1 or ZGC add concurrent phases to minimize pause times. Interviewers expect you to explain generational hypotheses (young vs. old generation), why most objects die young, and how tuning parameters affect latency and throughput.

What is a RESTful API and what are its key constraints?

A RESTful API follows the architectural style of Representational State Transfer, using standard HTTP methods (GET, POST, PUT, DELETE) to operate on resources identified by URIs. Key constraints include statelessness (each request contains all needed information), cacheability (responses can be cached), uniform interface (consistent use of verbs and media types), layered system (intermediaries can be added), and optional code on demand. Interviewers want to see you understand how these constraints improve scalability and simplify client‑server interactions.

Explain the concept of Big O notation and why it matters in interviews.

Big O notation describes the upper bound of an algorithm's growth rate relative to input size, abstracting away constants and lower‑order terms. It matters because it lets interviewers compare efficiency across solutions, focusing on scalability. For example, O(n) linear time grows proportionally with input, while O(n²) quadratic time becomes impractical for large n. Candidates should discuss worst‑case, average‑case, and space complexity, and demonstrate ability to choose data structures that improve asymptotic performance.

How would you design a URL shortening service like bit.ly?

Start with a high‑level architecture: a stateless API layer, a key‑generation service, a database for mapping short keys to original URLs, and a caching layer for fast redirects. Use a base‑62 encoding of an auto‑incrementing integer or a hash with collision handling for key generation. Ensure scalability with sharding, load balancers, and CDN for redirect traffic. Discuss rate limiting, analytics, and handling abusive links. Interviewers look for trade‑offs between simplicity (sequential IDs) and security (random hashes) and how you would evolve the design.

What is a deadlock, and how can you prevent it in a multithreaded application?

A deadlock occurs when two or more threads hold locks that the others need, creating a circular wait. Prevention strategies include lock ordering (acquire locks in a consistent global order), using lock timeout, employing lock‑free data structures, or reducing lock granularity. Detecting deadlocks can involve monitoring thread states or using tools like Java's ThreadMXBean. Interviewers expect you to explain the four Coffman conditions and demonstrate practical techniques to avoid them in production code.

Explain the difference between optimistic and pessimistic concurrency control.

Optimistic concurrency assumes conflicts are rare; it reads data without locking and validates before commit, typically using version numbers or timestamps. If a conflict is detected, the transaction aborts and retries. Pessimistic concurrency acquires locks upfront, preventing other transactions from modifying the data until the lock is released. Optimistic control reduces lock contention and improves throughput for read‑heavy workloads, while pessimistic control is safer for write‑heavy scenarios where conflicts are frequent. Interviewers want you to discuss trade‑offs and appropriate use cases.

How does a binary search tree differ from a balanced tree like AVL or Red‑Black, and why does balance matter?

A plain binary search tree (BST) can become skewed, leading to O(n) operations in the worst case. Balanced trees like AVL or Red‑Black maintain height constraints (AVL: |height(left)‑height(right)| ≤1; Red‑Black: longest path ≤2× shortest path) through rotations during insert/delete. This guarantees O(log n) search, insert, and delete. Balance matters for predictable performance, especially in large datasets. Interviewers look for understanding of rotation logic, height invariants, and why self‑balancing structures are preferred in production databases.

Describe how you would implement rate limiting for an API endpoint.

Use a token bucket algorithm: each client has a bucket that refills at a fixed rate (e.g., 100 tokens per minute). On each request, consume a token; if the bucket is empty, reject the request with a 429 status. Store bucket state in a fast, distributed cache like Redis to support multiple API servers. Include burst capacity for occasional spikes. Interviewers expect you to discuss trade‑offs between token bucket and leaky bucket, handling distributed consistency, and monitoring usage.

Explain the difference between synchronous and asynchronous I/O and when each is appropriate.

Synchronous I/O blocks the calling thread until the operation completes, simplifying code flow but limiting concurrency. Asynchronous I/O returns immediately, invoking a callback or future when the operation finishes, allowing the thread to handle other work. Use synchronous I/O for simple scripts or CPU‑bound tasks where blocking is negligible. Use asynchronous I/O for high‑throughput servers, GUI applications, or when handling many concurrent network connections to avoid thread exhaustion. Interviewers look for awareness of event loops, thread pools, and resource utilization.

What is the CAP theorem, and how does it apply to modern distributed databases?

CAP states that a distributed system can only guarantee two of three properties simultaneously: Consistency (all nodes see the same data at the same time), Availability (every request receives a response), and Partition tolerance (system continues despite network partitions). Modern databases make trade‑offs: relational DBs favor consistency, NoSQL stores like Cassandra prioritize availability, and systems like Spanner aim for strong consistency with sophisticated coordination. Interviewers want you to explain real‑world implications, such as why eventual consistency is acceptable for social feeds but not for financial transactions.

Explain how garbage collection works in Go and the role of the tri‑color marking algorithm.

Go's garbage collector is a concurrent, non‑generational, tri‑color marking collector. It classifies objects as white (unreachable), gray (reachable but not scanned), or black (reachable and scanned). The mutator runs concurrently, and the collector periodically pauses to mark gray objects, turning them black, while white objects are reclaimed. This approach reduces stop‑the‑world pauses and maintains low latency. Interviewers expect you to discuss how the algorithm handles write barriers, the impact on latency, and why Go favors simplicity over generational optimizations.

Design a scalable notification system that supports email, SMS, and push notifications.

Create a decoupled architecture: an API gateway receives notification requests, writes them to a durable message queue (e.g., Kafka). Worker services consume messages, format them per channel, and invoke third‑party providers (SMTP, Twilio, Firebase). Use a fan‑out pattern for multi‑channel delivery, and store delivery status in a NoSQL store for audit. Implement back‑pressure handling, retry policies, and rate limiting per provider. Discuss eventual consistency, idempotency, and how to scale workers horizontally.

What are monads in functional programming, and how do they help manage side effects?

A monad is a design pattern that encapsulates values with a computational context, providing two operations: bind (flatMap) and unit (return). In functional languages, monads like Maybe, Either, or IO allow sequencing of computations while preserving purity. The IO monad, for example, defers side effects, enabling lazy evaluation and easier testing. Interviewers look for you to explain the three monad laws (left identity, right identity, associativity) and illustrate how monads isolate side effects, making code more predictable.

How would you approach migrating a monolithic application to microservices?

Start with domain-driven design to identify bounded contexts, then extract those as independent services with well‑defined APIs. Introduce an API gateway for routing, and use a shared database pattern only as a transitional step. Implement asynchronous communication via events to decouple services, and adopt container orchestration (Kubernetes) for deployment. Emphasize incremental migration, automated testing, and observability (tracing, logging). Interviewers expect you to discuss data consistency challenges, deployment pipelines, and rollback strategies.

What is eventual consistency and how does it differ from strong consistency?

Eventual consistency guarantees that, given no new updates, all replicas will converge to the same state over time, but reads may return stale data in the interim. Strong consistency ensures that all reads see the most recent write instantly. Eventual consistency is acceptable for use cases like social feeds where slight staleness is tolerable, offering higher availability and partition tolerance. Strong consistency is required for financial transactions where correctness is critical. Interviewers expect you to discuss replication lag, read‑repair mechanisms, and trade‑offs in CAP context.