Common Software Engineering Interview Questions

Software engineering interviews rarely test rote memorization; instead they probe whether you can reason clearly about trade-offs, explain concepts to a teammate, and connect theory to real engineering decisions. The questions below cover the topics that recur most often across OOP, SOLID, design patterns, testing, architecture, and process. For each question, focus less on reciting a definition and more on being able to justify it with an example from your own experience.

An abstract class can hold state (fields), constructors, and a mix of implemented and unimplemented methods, and a class can extend only one abstract class. An interface traditionally declares only method signatures (though modern languages allow default methods) and a class can implement many interfaces. Use an abstract class when subclasses share common state or behavior; use an interface when you only need to guarantee a contract across otherwise unrelated classes.

Single Responsibility: a class should have only one reason to change. Open/Closed: modules should be open for extension but closed for modification. Liskov Substitution: subtypes must be substitutable for their base types without breaking correctness. Interface Segregation: clients should not be forced to depend on methods they don't use. Dependency Inversion: high-level modules should depend on abstractions, not on concrete low-level modules.

A unit test exercises a single unit of code, typically a function or class, in isolation, with all collaborators replaced by test doubles so the test runs fast and is deterministic. An integration test exercises two or more real components together, such as a service and a database, to verify that they work correctly when wired up. Unit tests catch logic errors early and cheaply; integration tests catch problems in how components interact, such as serialization mismatches or configuration errors.

Start by clarifying requirements: expected write and read throughput, custom alias support, expiration, and analytics. Core design: generate a short, unique key (e.g., a base62-encoded counter or a hash with collision checks), store the mapping of short key to long URL in a fast key-value store, and use a read-through cache in front of the database since reads vastly outnumber writes. Discuss scaling with sharding by key, using a CDN or edge cache for redirects, and rate-limiting to prevent abuse. Interviewers are evaluating your ability to break an ambiguous problem into requirements, data model, and scaling strategy, not a single 'correct' architecture.

A process is an independent, isolated unit of execution with its own memory space; processes communicate through inter-process communication mechanisms such as pipes or sockets. A thread is a lightweight unit of execution that runs within a process and shares that process's memory space with other threads. Threads are cheaper to create and switch between than processes, but shared memory introduces risks such as race conditions that require synchronization.

The browser first checks its cache, then performs a DNS lookup to resolve the domain to an IP address. It opens a TCP connection to that IP (with a TLS handshake for HTTPS), sends an HTTP request, and the server routes the request, possibly through a load balancer, to an application server that queries a database or other services and returns a response. The browser receives the HTML, parses it, and issues further requests for CSS, JavaScript, and images, then renders the page, executing scripts as they load.

Technical debt is the implied cost of future rework caused by choosing an expedient solution now instead of a more robust one. It is managed by making it visible (tracking it alongside feature work, not hiding it), prioritizing repayment based on how much it slows current development or increases risk, and preventing runaway debt through code review, refactoring as part of normal feature work, and automated quality gates rather than dedicating rare 'big bang' cleanup sprints.

A monolith is a single deployable unit containing all of an application's functionality, sharing one codebase, one database, and one deployment pipeline. Microservices split the application into independently deployable services, each owning its own data store and communicating over the network, usually via APIs or messaging. Monoliths are simpler to develop, test, and deploy at small scale; microservices trade that simplicity for independent scalability and team autonomy at the cost of operational complexity, network latency, and distributed-system failure modes.

A race condition occurs when the correctness of a program depends on the relative timing of concurrent operations, typically when multiple threads read and write shared state without coordination. It is prevented by synchronizing access to shared state, for example with locks, atomic operations, or immutable data structures, or by avoiding shared mutable state entirely through message passing or thread-confinement.

A strong answer names a concrete model, such as Scrum within an Agile framework, and explains why it fit the project: short feedback loops for a product with evolving requirements, regular demos to stakeholders, and iterative delivery instead of a single big release. It also acknowledges trade-offs, such as when a more sequential, documentation-heavy model like Waterfall or V-Model would be preferable, for example in safety-critical or fixed-scope contract work.

Read the description and linked ticket first to understand intent, then check correctness, test coverage, and readability before style. Leave specific, actionable comments rather than vague criticism, distinguish blocking issues from optional suggestions, and ask questions instead of issuing commands when the intent is unclear. The goal is to catch defects and share knowledge while keeping the author's momentum and psychological safety intact.