Software Engineer interview questions

Sample answer:

An array stores elements in contiguous memory with fast index-based access (O(1)), but inserting or deleting in the middle is costly (O(n)). A linked list stores nodes scattered in memory connected by pointers, so insertion or deletion is fast (O(1)) once you have the node, but access requires traversal (O(n)).

Common mistake: Describing the structures without comparing time complexity for access versus insertion.

Tip: Give a real example, like an array for a fixed lookup table versus a linked list for a queue that grows and shrinks often.

Sample answer:

REST exposes fixed endpoints that each return a predetermined shape of data, often requiring multiple calls to gather related resources. GraphQL exposes a single endpoint where the client specifies exactly which fields it needs in one query, reducing over-fetching and under-fetching.

Common mistake: Claiming one is strictly 'better' instead of discussing trade-offs like caching simplicity versus query flexibility.

Tip: Mention a concrete scenario, such as a mobile app with limited bandwidth benefiting from GraphQL's precise fetching.

Sample answer:

I'd run EXPLAIN to see the query plan, check for missing indexes on filtered or joined columns, avoid SELECT *, and consider whether the query is scanning more rows than necessary. For very large tables, I'd also look at pagination, denormalization, or caching frequent results.

Common mistake: Jumping straight to 'add an index' without explaining how you'd diagnose the actual bottleneck first.

Tip: Walk through your diagnostic process step by step - interviewers care more about method than the final fix.

Sample answer:

Time complexity describes how an algorithm's runtime grows relative to input size, usually expressed in Big-O notation. It matters because it predicts how code will perform at scale, before you'd notice a slowdown on small test data.

Common mistake: Confusing Big-O with actual runtime in seconds rather than growth rate.

Tip: Use a simple example, like comparing a linear search O(n) to a binary search O(log n) on a sorted list.

Sample answer:

Encapsulation bundles data and behavior together and hides internal details. Abstraction exposes only relevant functionality. Inheritance lets a class reuse and extend another class's behavior. Polymorphism allows objects of different types to be treated through a common interface.

Common mistake: Listing the four terms without a short example of each.

Tip: Pick one pillar and give a one-line real-world example - it shows understanding, not memorization.

Sample answer:

You'd need a way to generate a unique short code (hashing or a counter with base62 encoding), a database mapping short codes to original URLs, a redirect service, and caching for reads, since lookups vastly outnumber writes.

Common mistake: Diving straight into code instead of first clarifying scale and requirements like expected traffic or custom aliases.

Tip: Ask a clarifying question or two before designing - it signals real-world engineering habits.

Sample answer:

Synchronous code executes one operation at a time, blocking until each finishes. Asynchronous code can start a task, move on to other work, and handle the result later - useful for I/O-heavy operations like network calls or file reads.

Tip: Mention a callback, promise, or async/await example from a language you actually use.

Sample answer:

I'd use profiling tools to identify objects that aren't being released, check for lingering references such as unclosed event listeners, and verify resources like file handles or database connections are properly closed.

Common mistake: Giving a purely theoretical answer without naming a specific tool you'd actually use.

Tip: Name a profiler relevant to your stack, like Chrome DevTools' memory tab.

Sample answer:

Give a brief, relevant summary: your current role, one or two standout achievements, and why this position interests you - kept to under two minutes.

Common mistake: Reciting your entire resume chronologically instead of a focused, relevant narrative.

Tip: Structure it as present, past, future: what you do now, how you got here, what you want next.

Sample answer:

Describe the situation, the specific disagreement, how you raised it professionally with data or a prototype, and the outcome - ideally showing you focused on the best solution, not being right.

Common mistake: Making the teammate sound incompetent instead of focusing on the resolution.

Tip: End with what you learned or how it improved the way the team makes decisions.

Sample answer:

Explain the symptom, your debugging process (logs, reproducing it, isolating variables), the root cause, and the fix, plus any process change you made to catch similar bugs earlier.

Common mistake: Skipping the debugging process and jumping straight to the answer.

Tip: Emphasize your systematic approach over the specific fix - it's more transferable.

Sample answer:

Mention specific habits: following particular blogs or newsletters, building small side projects, or reading release notes for tools you use daily.

Tip: Name something specific rather than a vague 'I read blogs' - specificity is memorable.

Sample answer:

Pick a project with real impact, explain your specific contribution, the obstacles you overcame, and the measurable outcome.

Common mistake: Describing the project generically without clarifying your individual role.

Tip: Quantify the result if you can - performance improvement, users served, time saved.

Sample answer:

I prioritize the highest-impact work first, communicate early if scope needs to shrink, and can point to a real example where this worked.

Common mistake: Implying you'd just 'work harder' with no mention of prioritization or communication.

Tip: Interviewers want to see you flag risk early, not push through silently.

Sample answer:

Describe the context, how you approached learning it, and how you applied it successfully under time pressure.

Tip: Mention a resource or method you used - it shows a repeatable process, not luck.

Sample answer:

As a reviewer, I focus on correctness, readability and maintainability, and phrase feedback as questions or suggestions. As the author, I treat feedback as improving the code, not a personal critique.

Common mistake: Framing code review only from one side instead of both.

Tip: Give one specific example of feedback you gave or received that improved the outcome.

Sample answer:

I'd share my concerns privately with clear reasoning, listen to their perspective in case I'm missing context, and if they still decide to proceed, commit fully to executing it well.

Common mistake: Suggesting you would escalate or go around your manager as a first step.

Tip: 'Disagree and commit' language shows a maturity interviewers specifically look for.

Sample answer:

Stay calm, quickly assess severity and scope, communicate status early, focus on mitigation like a rollback or feature flag before root-causing, then do a blameless postmortem.

Common mistake: Jumping straight to root-cause analysis instead of stopping the bleeding first.

Tip: Mention communicating status updates - silence during an outage is a common stakeholder complaint.

Sample answer:

I'd have a direct, private conversation to understand what's blocking them before escalating, and offer to help or adjust the plan if needed.

Common mistake: Immediately reporting them to a manager without first trying to understand the cause.

Tip: Show empathy first, escalation second - that ordering matters to interviewers.

Sample answer:

Connect specific things about the company's product, engineering culture or tech stack to your own experience and goals.

Common mistake: Giving a generic answer like 'great culture' with no specifics.

Tip: Reference something concrete from their engineering blog, product, or values page.