10 Technical Interview Questions Every Developer Should Know How to Answer in English

Example answer

“An index is a data structure that makes queries faster by letting the database jump directly to the relevant rows instead of scanning the whole table. The most common type is a B-tree index. The tradeoff is that indexes take up extra storage and slow down writes, because the index has to be updated every time a row changes. You want to index columns you frequently filter or join on, and avoid indexing every column. For high-cardinality columns used in WHERE clauses, a single-column index works well. When you filter on multiple columns together, a composite index can be more efficient.”

Example answer

“It depends on where you are in the product lifecycle. For a new product with a small team, I would start with a monolith. It is simpler to deploy, easier to debug, and lets you move fast before you fully understand the domain. Premature decomposition into microservices adds operational complexity before you have the scale to justify it. That said, if the team is large and different parts of the system need to scale independently, microservices make sense. The key signals I would look for are: team size, deployment independence requirements, and whether different components have very different scaling needs. I have seen teams go microservices-first and spend most of their time managing infrastructure rather than building product.”

Example answer

“A few things can go wrong. The most common is stale data: the cache holds an old value after the source has been updated, and users see incorrect information. Deciding when to invalidate the cache is notoriously hard because it depends on how frequently data changes and how much staleness you can tolerate. Another issue is a cache stampede, sometimes called a thundering herd: the cache expires and hundreds of requests hit the database simultaneously before it is repopulated. You can address this with locking or probabilistic early expiration. A third issue is cold start: when the cache is empty, for example after a restart, all requests fall through to the database until the cache warms up, which can spike your database load. Finally, there is consistency: in a distributed system with multiple cache nodes, keeping all of them in sync adds another layer of complexity.”

Example answer

“This is a classic race condition. Both users read the available quantity as 1, both decide they can proceed, and both write a purchase, leaving the quantity at -1. There are two common solutions. The first is optimistic locking: you add a version field to the inventory row. When you update, you check that the version has not changed since you read it. If it has, the transaction fails and you retry. This works well when conflicts are rare. The second is pessimistic locking: you lock the row with SELECT FOR UPDATE when you read it, so no other transaction can read or write it until you commit. This is safer but blocks concurrent users. Both approaches wrap the operation in a database transaction to make it atomic. I would lean toward optimistic locking for most e-commerce use cases because conflicts are infrequent.”

Example answer

“The first thing I would do is identify the bottleneck, because the right answer depends on where the pressure is. For the application tier, the first step is making it stateless so you can run multiple instances behind a load balancer. At 1 million requests per day, horizontal scaling with a few app servers should handle the compute. The bigger risk is usually the database. I would look at adding a caching layer in front of it to absorb read traffic, adding read replicas for read-heavy queries, and reviewing connection pooling settings. If there are long-running operations like email sending or report generation, I would move those to an async queue so they do not block the request-response cycle. At this scale you also want to review your indexes and make sure you are not doing full table scans. Vertical scaling, adding more CPU or RAM to a single server, is often a quick fix but hits a ceiling. Horizontal scaling is the more sustainable path.”

Example answer

“I think of it as a pyramid. Unit tests are at the bottom: fast, isolated, and there should be a lot of them. They test individual functions or classes with all dependencies mocked or stubbed. I use them for business logic that has clear inputs and outputs. Integration tests sit in the middle: they test how components interact, like a service hitting a real database or calling a real external API. They are slower and there are fewer of them, but they catch bugs that unit tests miss because they test real boundaries. End-to-end tests are at the top: they simulate a real user in a real browser, going through a complete flow. They are the most expensive to write and the most likely to be flaky, so I keep them for the critical paths only, like checkout or login. The key principle is to test at the lowest level that gives you confidence.”

Example answer

“Before I design anything, I would ask a few clarifying questions. Is this for public use or internal? How many URLs per day? Do we need analytics? For a public service handling millions of URLs, here is how I would approach it. The core data model is simple: a table with the original URL and a short code, with the short code as the primary key. To generate the short code, I can either use a hash of the URL or generate a random ID. For the API: POST a long URL, get back a short URL. GET the short URL, redirect to the original. For scaling: the redirect path is read-heavy, so a cache in front of the database is critical. The database write happens once, but the read can happen millions of times. I would cache the mapping in something like Redis with a long TTL since URLs rarely change. For storage, even a billion URLs would fit in a few hundred gigabytes. The main scaling challenge is handling the redirect traffic at low latency.”

Example answer

“In my previous role, we had an intermittent bug where certain users were seeing duplicate records in their transaction history. It only happened in production and we could not reproduce it in staging. I started by adding more detailed logging around the write path to capture the exact timing of operations. After a few days, I noticed the duplicates always had timestamps within a few milliseconds of each other, which pointed to a race condition. I traced it to a retry mechanism in our payment service that was re-sending a request when it did not receive a response in time, but the original request had actually succeeded. The fix was to make the endpoint idempotent by adding a unique request ID and checking for it before processing. I also added a postmortem doc so the team understood why idempotency matters for payment operations.”

Example answer

“My first step is always to add more observability: logging, metrics, or traces around the area where the bug seems to be happening. If I cannot reproduce it locally, I try to understand when it occurs. Is it time-based? Load-based? Specific to certain users or data? That pattern usually narrows down the cause. I then try to reproduce it in a staging environment with conditions that match production as closely as possible. If the bug started appearing after a recent change, I would look at the git history and narrow down which commit introduced it. For truly intermittent bugs, I look for anything that introduces non-determinism: concurrent operations, network timeouts, environment-specific configuration. The goal is to form a hypothesis and then design an experiment to confirm or rule it out.”

Example answer

“A mutable object can be changed after it is created. A list is mutable: you can append, remove, or change elements in place. An immutable object cannot be changed. A string or a tuple is immutable: any operation that looks like it modifies a string actually creates a new one. The practical implication is that when you pass a mutable object to a function, the function can change the original, which can cause side effects that are hard to track. The most common gotcha is using a mutable object as a default argument in a function definition. For example, defining a function with a default argument of an empty list: def add_item(item, lst=[]) means that lst is created once when the function is defined and reused across calls. If you call add_item twice, the second call sees the list from the first call. The fix is to use None as the default and create the list inside the function.”