Software Engineer Interview Questions

I reach for a hash map when I need O(1) average-time lookup by an arbitrary key, not a numeric index. Arrays are the right choice when I'm indexing by dense integers and care about cache locality, but the moment my key space is sparse or non-numeric, a hash map wins. In production I've used arrays for frequency counts over a small fixed alphabet and hash maps for everything from session stores to adjacency lists. The main cost is memory: a hash map carries load-factor overhead and loses cache-line efficiency compared to a flat array. I also keep in mind that O(1) average is not O(1) worst case when the hash function produces many collisions, so key distribution matters on high-throughput paths. If I know I'll need sorted iteration over keys, I'll consider a balanced BST map instead.

I start at DNS resolution: the browser checks its local cache, then the OS cache, then recurses through the resolver chain until it gets an IP address. Next comes a TCP handshake followed immediately by a TLS handshake if the site uses HTTPS, which most do. Once the secure channel is open, the browser sends an HTTP GET; the server responds with an HTML document. The browser begins parsing that document, discovers CSS and JS references, and fires additional requests for each. As assets load, the browser builds the DOM and CSSOM, combines them into a render tree, and paints the page. I always mention that modern browsers pipeline these steps and that HTTP/2 multiplexing reduces the per-asset round-trip cost significantly.

My first move is to treat it as a data problem, not a guessing game. I pull structured logs and correlate them with the timestamp of the incident, looking for stack traces, slow queries, or upstream error codes I wouldn't see locally. If logs are thin, I check whether the environment differs: different JVM flags, a config value missing from my dotenv, a third-party service rate-limiting only in prod. I'll add targeted instrumentation behind a feature flag so I can observe without a full deploy. When I suspect a timing issue, I reach for distributed tracing spans rather than log grep. And I always write a failing test the moment I form a hypothesis, so the fix is verifiable even if I can't reproduce the exact conditions manually.

My default is SQL whenever the domain has clear relationships, the schema is reasonably stable, and I need transactional guarantees. A relational database gives me referential integrity, a mature query optimizer, and decades of operational tooling. I switch to NoSQL when I genuinely need horizontal write scaling across commodity hardware, the data is naturally document-shaped with no joins, or I am storing time-series or graph data that relational models handle awkwardly. The mistake I see most often is reaching for NoSQL because it sounds more "scalable" without quantifying the actual write volume. Most services never outgrow a well-indexed Postgres instance. I always ask: what consistency guarantees do I actually need, and what shape is my data?

Concurrency and parallelism are often conflated, but they solve different problems. Concurrency is about structuring a program to handle multiple tasks that can overlap in time; they do not need to run simultaneously. Parallelism is when tasks literally execute at the same moment on multiple CPU cores. A single-core machine can be concurrent through context switching but not truly parallel. I think of it this way: concurrency is a design property, parallelism is a runtime property. In Go, goroutines give you concurrency; whether they run in parallel depends on GOMAXPROCS. In Python, the GIL prevents true CPU-bound parallelism even with threads, so I reach for multiprocessing there. Getting this distinction right shapes how I approach I/O-bound versus CPU-bound performance problems in completely different ways.

I was brought onto a backend team to help rescue a search service that was timing out under load. The existing code ran a full table scan for every query, and latency had climbed to over four seconds at peak. I started by profiling every hot path to find the two queries responsible for 80 percent of the load. Then I designed and shipped an inverted index backed by a Redis sorted set, which cut median latency from 4.2 seconds to 180 milliseconds. Finally, I wrote a runbook and onboarding doc so the team could own it without me. We hit our SLA within three days of launch and the fix held through a 3x traffic spike two months later.