Software Engineer interview questions and answers

An array stores elements in contiguous memory, so reading index i is O(1) and it is cache-friendly, which makes iteration fast in practice. Inserting or deleting in the middle is O(n) because elements shift. A linked list stores nodes with pointers, so inserting or deleting is O(1) once I have the node, but finding the node is O(n) and there is no random access. I would use an array or a resizable list for most cases, like storing scores I read often. I would use a linked list for things like an LRU cache, where a doubly linked list plus a hash map gives O(1) moves.

A hash map runs the key through a hash function to get an integer, then takes it modulo the number of buckets to pick a bucket. Lookup, insert and delete are O(1) on average. A collision is when two keys land in the same bucket. The common fix is chaining, where each bucket holds a small list of entries, or open addressing, where we probe for the next free slot. When the load factor crosses a limit, often 0.75, the table doubles and all keys are rehashed. With a bad hash function everything piles into one bucket and operations degrade to O(n).

Binary search is O(log n) time and O(1) space in the iterative version, because each step halves the search range. It needs a sorted array or, more generally, a monotonic condition, where the answer is false up to some point and true after it. That second use is powerful: I have used it to find the minimum capacity a ship needs to deliver packages within D days, by binary searching over capacity and checking feasibility. Common bugs are integer overflow in the midpoint, so I write low plus (high minus low) divided by two, and off-by-one errors in loop bounds.

I would first confirm requirements: create short links, redirect fast, optional expiry, and roughly how many new links and redirects per day. It is heavily read-dominant. For keys, I would use a counter-based unique ID from a distributed ID generator, encoded in base62, so seven characters give over three trillion combinations with no collision checks. Storage can be a key-value store mapping short code to long URL. Redirects go through a cache like Redis in front, since popular links are hit repeatedly, and return 301 or 302 depending on whether we need click analytics. Analytics events go to a queue, not the redirect path.

I would first find out why it is slow using slow-query logs and metrics. Often the fix is cheap: adding the right index, removing N+1 queries, or caching hot reads in Redis. Next I would add read replicas and route reads there, accepting slight replication lag for things like dashboards. Connection pooling helps if connections are exhausted. For heavy writes, I would move non-critical work like notifications to a queue. Only if one primary still cannot keep up would I shard, for example by customer ID, because sharding makes joins, transactions and rebalancing much harder to manage.

First I check the change does what the ticket says and handles edge cases: empty input, nulls, failures from external calls and concurrency. Then I look at readability, naming, whether the function does one thing, and whether tests cover the new behaviour. I watch for security issues like unvalidated input and secrets in code, and performance traps like queries inside loops. Formatting I leave to the linter. I phrase comments as questions or suggestions, mark small ones as optional, and approve quickly when it is good. For large pull requests, I ask the author to split them.

A process has its own memory space, so processes are isolated and communicate through pipes, sockets or files. Threads live inside one process and share its memory, which makes them lighter but lets them interfere with each other. A race condition happens when the result depends on the timing of threads accessing shared data. The classic case is two threads doing count equals count plus one: both read 10, both write 11, and one update is lost. I would fix it with a lock or mutex, an atomic increment, or by avoiding shared mutable state and passing messages through a queue.

CAP says a distributed system cannot guarantee consistency, availability and partition tolerance all at once. Since network partitions will happen, the real choice during a partition is between consistency and availability. For a wallet balance or seat booking, I choose consistency: better to reject a request than to sell the same seat twice. For a product catalogue, likes count or feed, I choose availability and accept eventual consistency, so users may briefly see stale data. In practice I also think about latency when there is no partition, since strong consistency across regions adds round trips to every write.

I cache data that is read far more often than it changes and is expensive to compute, like a product page or a user’s permissions. The usual pattern is cache-aside: read from cache, on a miss read the database and store the result with a TTL. On writes I delete the cache key rather than update it, which avoids races between two writers. The TTL is a safety net for any missed invalidation. For very hot keys, I prevent a stampede, where many requests miss at once, by using a lock so only one request rebuilds the value. I never cache anything user-specific under a shared key.

In a payments service we supported two gateways, and the checkout code had if-else checks for each gateway spread across many files. Adding a third meant touching all of them. I applied the dependency inversion principle with a strategy pattern: I defined a PaymentGateway interface with charge, refund and verifyWebhook methods, and wrote one class per gateway. Checkout depended only on the interface, and a small factory picked the implementation from config. Adding the third gateway became one new class and a config entry, and it was easy to unit test checkout with a fake gateway.

I unit test pure logic with many branches, like pricing rules, discount calculations or parsers, because those tests are fast and pinpoint failures. Integration tests cover the boundaries that break most often: database queries, API endpoints and queue consumers, run against a real test database in a container. I mock things I do not control or that are slow and costly, such as payment gateways, SMS providers and the clock. I avoid mocking my own internal classes heavily, because then tests only check the implementation. A few end-to-end tests cover the critical paths like signup and checkout.

A senior engineer asked me to replace a simple loop with a generic rules engine so future discount types could plug in. I felt it added complexity for a need we did not yet have. I replied in the review with the two known discount types, showed that the loop was 30 lines, and suggested we extract an interface only when a third type arrived. We discussed it on a short call. He agreed to keep it simple but asked me to add tests covering both types, which was fair. Four months later we did add a third type, and the refactor took an afternoon.

During a sale, our order API latency jumped and error rates rose. I was on call. I first checked dashboards and saw database connections maxed out. To stop the damage, I rolled back that morning’s release, which had added a report query on the primary database. Errors dropped within minutes. I posted updates in the incident channel every fifteen minutes so support could answer customers. In the postmortem we found the query lacked an index and ran on every order. We moved reporting to a read replica, added the index, and added a connection-pool alert.

I pushed to split our monolith into six microservices when we had a team of five engineers. It looked cleaner on paper. In practice, every feature touched three services, local setup took an hour, and debugging across network calls slowed us down. After two quarters I raised it in our retro myself and proposed merging four services back into a modular monolith with clear internal boundaries. We kept only the notification service separate because it scaled differently. Delivery speed improved noticeably. Now I tie architecture decisions to team size and real scaling needs, not to what large companies do.

In my internship I joined a team with a Java codebase of several hundred thousand lines. I started by running it locally and following one request, an order status update, from the controller through to the database with a debugger. I wrote notes and a small diagram as I went. I picked small bugs from the backlog first, since each one taught me a different module. I time-boxed being stuck to about an hour before asking my mentor, and I wrote down the answers so I never asked twice. By week four I shipped a feature to add delivery-slot filters.

A client needed bulk CSV upload of employee data within a week for their payroll cut-off. The proper design was an async job with progress tracking and row-level error reports. That would take three weeks. I proposed shipping a synchronous upload limited to five thousand rows, with clear validation errors, which covered their current file size. I wrote down the limits in the ticket and created a follow-up task for the async version, which my lead scheduled for the next sprint. The client met their cut-off, and we built the proper version before they grew past the limit.

A new graduate on my team kept getting large pull requests sent back with dozens of comments, and he was losing confidence. I set up two thirty-minute pairing sessions a week for a month. We broke his next feature into four small pull requests, and I reviewed the design with him before he wrote code rather than after. I also shared a short checklist of things our reviewers usually flag. His review rounds dropped from four or five to one or two, and by the third month he was reviewing other people’s code. I learned to review ideas early, not just code late.

My current CTC is 22 lakh, of which 19 lakh is fixed and the rest is a performance bonus. This role is at the senior engineer level with system design ownership and on-call duties, which is a step up from my current scope. Based on that and on conversations with recruiters for similar roles in Bengaluru, I am expecting around 30 lakh fixed. If there are stock options, I would like to understand the vesting schedule and the valuation basis, because I compare offers on the fixed component first and treat stock as a bonus.

Yes, I am open to relocating to Hyderabad. I am currently in Indore, and I have no family constraints that would stop me moving within a month of joining. I actually prefer hybrid over fully remote at this stage, because as a newer engineer I learn much faster sitting with the team during design discussions and debugging sessions. If there is a relocation allowance or temporary accommodation for the first few weeks, that would help, but it is not a condition for me. I would just like to know the expected office days per week.

I have spent four years at a services company, and I have learned a lot about delivery and working with clients. But most of my projects end at handover, so I rarely see how a system behaves at scale over years or get to own its architecture. I want to work on a product where I own services long term, handle real traffic growth and improve them based on metrics. Your team runs its own platform with millions of daily requests and a strong on-call culture, which is exactly the ownership I am missing now.