Software Engineer Interview Questions

Use simple functions, clear names, tests, typing where useful, and small modules.

Interviewers look for readability, error handling, separation of concerns, and code that another engineer can change safely.

They produce values lazily without building a full list.

Generators are useful for streams, large files, and pipelines where memory efficiency matters.

Catch specific exceptions and keep recovery close to the failure.

Avoid broad except blocks unless re-raising or adding context. Good error handling makes failure modes explicit.

Normalization organizes tables to reduce redundancy and update anomalies.

Explain entities, keys, relationships, and tradeoffs. In analytics, denormalization may be acceptable for performance and usability.

A transaction is a unit of work that should satisfy ACID properties.

Good answers cover atomicity, consistency, isolation, durability, plus examples like money transfer or inventory update.

Indexes let the database find rows without scanning the whole table.

They improve lookup and join performance but add write overhead and storage cost, so they should match query patterns.

Clear contracts, validation, idempotency, timeouts, and useful errors.

A reliable API is predictable for clients and observable for maintainers. Versioning and rate limits also matter.

REST exposes resources; GraphQL lets clients request shaped data.

REST is simple and cache-friendly. GraphQL can reduce overfetching but adds schema and resolver complexity.

Use authentication, authorization, validation, rate limits, and audit logs.

Security also includes least privilege, secrets handling, safe error messages, and monitoring suspicious behavior.

Use caching, replicas, indexing, pagination, and careful invalidation.

Start with requirements, traffic, data model, hot paths, bottlenecks, and failure modes before naming tools.

Remove single points of failure and define graceful degradation.

Reliable designs use retries with backoff, circuit breakers, redundancy, backups, and observability.

Estimate users, requests, data volume, read/write ratio, and growth.

Capacity estimates guide storage, bandwidth, compute, caching, and partitioning decisions.

Clarify impact, inspect recent changes, check metrics, and form hypotheses.

Good debugging narrows scope with evidence and keeps stakeholders updated while preserving rollback options.

Metrics show trends; logs explain specific events.

Metrics are better for alerting and dashboards. Logs help inspect individual requests, errors, and context.

Write a blameless review and fix root causes, tests, alerts, and runbooks.

The goal is learning and system improvement, not blame. Track concrete follow-up work.