Software Engineer interview questions and answers

Two strings are anagrams if they contain the same characters the same number of times. If their lengths differ, they can't be. Otherwise count each character of the first string in a hash map (or an array of 26 counts for lowercase English letters), then decrease the count for each character of the second. If every count ends at zero, they're anagrams. That's O(n) time and O(1) extra space for a fixed alphabet. Sorting both strings and comparing also works, but it's O(n log n).

Mention the edge cases: upper and lower case, spaces, and Unicode if the input isn't plain English.

Checking every pair is O(n²). Better: walk through the array once with a hash map from value to index. For each number, check whether target minus that number is already in the map; if it is, you've found the pair, otherwise store the number. That's O(n) time and O(n) space.

If the array is sorted, use two pointers, one at each end: if the sum is too small, move the left pointer right; if too large, move the right pointer left. That's O(n) time and O(1) space. Ask whether duplicates or negative numbers are possible, and what to return if there's no pair.

Use a sliding window. Keep two pointers for the window's start and end, and a map from each character to the last index where you saw it. Move the end forward one character at a time. If the character was already seen inside the current window, move the start just past that earlier position. Update the character's last index, and record the window's length if it's the longest so far.

Each character is handled a constant number of times, so it's O(n) time, with space bounded by the alphabet size. For "abcabcbb" the answer is 3 ("abc"). Explaining why the start never moves backwards shows you understand the window.

First reduce k to k mod n, since rotating by n gives the same array. The neat in-place method uses three reversals: reverse the whole array, then reverse the first k elements, then reverse the rest. For [1, 2, 3, 4, 5, 6, 7] and k = 3: reversing all gives [7, 6, 5, 4, 3, 2, 1], then [5, 6, 7, 4, 3, 2, 1], then [5, 6, 7, 1, 2, 3, 4].

That's O(n) time and O(1) extra space. Copying each element to index (i + k) mod n of a new array is simpler but uses O(n) space; say which you'd choose when memory matters.

Big O describes how running time grows as the input grows, ignoring constants. O(n log n) grows a little faster than linear: doubling the input slightly more than doubles the work. It usually comes from splitting a problem in half repeatedly (log n levels) and doing linear work at each level.

Merge sort, heap sort and the average case of quick sort are O(n log n), and that's the best possible for sorting by comparing elements. In practice, if you sort first and then solve a problem in one pass, the whole solution is O(n log n).

Time complexity is how the number of steps grows with the input size; space complexity is how much extra memory the algorithm needs beyond the input. A common trade is spending memory to save time. To find duplicates in an array, comparing every pair takes O(n²) time and O(1) space, while storing seen values in a hash set takes O(n) time and O(n) space.

Caching in dynamic programming is the same idea: you store answers to subproblems so you never compute them twice. The right choice depends on the input size and the memory you have, so say which you'd pick and why.

On average, insert, lookup and delete are O(1): the key's hash points straight to a bucket. In the worst case they degrade to O(n) when many keys land in the same bucket, because of a poor hash function or deliberately chosen keys. Java's HashMap limits this by turning a long bucket into a balanced tree, so its worst case is O(log n).

Resizing matters too: when the map gets too full it rehashes everything, which is O(n) for that one insert, but the cost averages out to O(1) per insert over time (amortised). Mentioning collisions and amortised cost shows depth.

Measure rather than guess: use the logs and a profiler or APM tool to see which call is slow and how its time changes with input size. If the time grows much faster than the data (four times slower when the data doubles), that points to an O(n²) pattern, often a loop inside a loop or a list lookup inside a loop.

Common fixes are replacing a list search with a hash set, sorting once instead of searching repeatedly, or adding an index for a slow database query. Then test again with production-sized data, and add that case to the tests so it doesn't come back.

Encapsulation keeps data and the methods that change it together and hides the details: a BankAccount exposes deposit and withdraw, not its balance field, so the balance can't be set to anything invalid. Abstraction shows only what matters: a Payment interface with a pay method, without the caller knowing how each payment works. Inheritance lets a class reuse another: SavingsAccount extends BankAccount and adds interest. Polymorphism lets the same call behave differently: calling pay on a UpiPayment or a CardPayment runs each one's own logic.

Using one example for all four is clearer than four separate textbook definitions.

An abstract class is a partly built class: it can have fields, constructors and implemented methods, and a class can extend only one. An interface is a contract for what a class can do, and a class can implement many. (In Java, interfaces can also have default methods, so the line has blurred.)

Use an abstract class when related classes share state and code, like a base Vehicle with common fields. Use an interface for a capability unrelated classes share, like Comparable. A good rule: prefer interfaces for flexibility, and abstract classes when there's real shared implementation.

Inheritance is an is-a relationship: a Car is a Vehicle and gets its behaviour. Composition is has-a: a Car has an Engine and delegates to it. Inheritance ties a child tightly to its parent, so a change in the parent can break every subclass, and deep hierarchies become hard to follow. Composition lets you swap parts, such as a different engine or a mock in tests, and keeps classes small.

So use inheritance only for a true is-a relationship that won't change, and composition to reuse behaviour. The Strategy pattern is composition in practice.

Read the stack trace first: it names the exact file and line, and the chain of calls that led there. Find which value on that line is null, then work backwards to where it should have been set: a method that returned null, a missing database row, or an object that was never created.

Reproduce the problem with the same input and confirm the value with a debugger breakpoint or a log line. Then fix the cause rather than adding null checks everywhere, and add a test for that case so it can't come back.

Collect evidence before changing anything: the error logs and stack trace, when it happened, the user's input and the release version. Then look at what differs between production and your machine: data, configuration, environment variables, dependency versions, traffic and concurrency. Bugs that appear only under load are often race conditions or timeouts.

If the logs aren't enough, add targeted logging or metrics around the suspect code and deploy that. Try to reproduce it in staging with a masked copy of the relevant data. Once it's fixed, add a test and, if needed, an alert, and write a short note on the cause.

Start by finding where the time goes instead of guessing. Check whether it's slow for everyone or only for some requests, and whether it started with a release. Use an APM tool or a profiler to split a slow request into its parts: database queries, external API calls and your own code.

The usual causes are a missing database index, the N+1 query problem (one query per row in a loop), a slow external service with no timeout, or an inefficient algorithm. Fix the biggest cost first, measure again to confirm, and add monitoring so you see it if it returns.

An INNER JOIN returns only the rows that match in both tables. A LEFT JOIN returns every row of the left table, with the matching rows of the right table, and NULLs where there's no match.

Joining customers to orders, for example: an inner join lists only customers who have ordered, while a left join lists all customers, with empty order columns for those who haven't. So a LEFT JOIN with WHERE orders.id IS NULL is a common way to find customers with no orders.

One way: SELECT MAX(salary) FROM employee WHERE salary < (SELECT MAX(salary) FROM employee). It finds the highest salary below the top one, and returns NULL if there's only one distinct salary.

A more general way uses a window function: rank the salaries with DENSE_RANK() OVER (ORDER BY salary DESC) and pick rank 2; change the number for the Nth highest. DENSE_RANK handles ties properly: if two people share the top salary, the next one is still second. Say how your query behaves with ties and with too few rows.

An index is a separate structure, usually a B-tree, that keeps a column's values sorted with pointers to the rows, so the database can find matches without scanning the whole table: roughly O(log n) instead of O(n). But every index takes storage and has to be updated on each insert, update and delete, which slows writes, and an index on a column with few distinct values, like a yes/no flag, rarely helps.

So index the columns you often filter, join and sort on, use a composite index for queries that filter on several columns (the column order matters), and check with EXPLAIN that your queries actually use them.

ACID describes how a database keeps transactions reliable. Atomicity: all of a transaction's steps happen, or none do. Consistency: it moves the data from one valid state to another, respecting constraints. Isolation: transactions running at the same time don't see each other's half-done work. Durability: once committed, it survives a crash.

A bank transfer is the classic example: debiting one account and crediting the other must both happen (atomicity), and two transfers from the same account at once mustn't overdraw it (isolation). Isolation levels such as Read Committed and Serializable trade safety against speed.

A process is a running program with its own memory space. Processes are isolated, so one crashing doesn't usually affect another. A thread is a unit of execution inside a process: threads of the same process share its memory, which makes them cheaper to create and faster to communicate, but shared memory needs synchronisation or threads can corrupt each other's data.

A browser is a good example: modern browsers run tabs as separate processes for isolation, and each tab uses several threads for rendering, scripts and network.

A deadlock is when two or more threads each wait for a resource another one holds, so none of them can continue. For example, thread A holds lock 1 and waits for lock 2, while thread B holds lock 2 and waits for lock 1. It needs four conditions at once: mutual exclusion, hold and wait, no pre-emption and circular wait. Break any one and it can't happen.

The most practical fix is to always take locks in the same order. Others are a timeout when acquiring a lock (tryLock), holding locks as briefly as possible, or avoiding shared locks altogether.

Virtual memory gives each process its own large address space, which the operating system maps onto physical RAM in fixed-size pages; pages not needed right now can live on disk. When a program touches a page that isn't in RAM, the CPU raises a page fault. The OS finds the page on disk, loads it into a free frame (evicting another page if memory is full, with a policy like LRU), updates the page table and resumes the program.

Page faults are normal. But if RAM is too small for what the programs are using, the system keeps swapping pages in and out, "thrashes" and slows down badly.

The browser finds the server's IP address through DNS, checking its own cache, the operating system and then DNS servers. It opens a TCP connection to that address (port 443 for HTTPS), and a TLS handshake sets up encryption and checks the site's certificate. The browser sends an HTTP GET request; the server, often behind a load balancer, handles it and returns a response with a status code and the HTML.

The browser parses the HTML, requests the CSS, JavaScript and images it refers to, and renders the page. Mentioning caching and CDNs along the way shows extra depth.

TCP is connection-oriented and reliable: it sets up a connection with a handshake, delivers data in order, resends lost packets and controls how fast it sends. UDP sends packets with no connection and no delivery guarantee, so it has less overhead and lower delay.

Use TCP when every byte must arrive correctly: web pages, APIs, email, file transfers. Use UDP when speed matters more than the odd lost packet: video calls, online games, live streaming and DNS lookups. HTTP/3 runs over QUIC, which is built on UDP and adds its own reliability.

401 Unauthorized means the request isn't authenticated (no valid login or token), so the client should sign in. 403 Forbidden means the server knows who you are, but you aren't allowed to do this. 404 Not Found means the resource doesn't exist; some APIs return 404 instead of 403 so as not to reveal that a resource exists.

PUT replaces the whole resource with what you send and is idempotent: sending it twice has the same effect as once. PATCH changes only the fields you send. Using the right codes and methods makes an API predictable for the people who use it.

A large language model is a neural network trained on huge amounts of text to predict the next word (token), which lets it answer questions, summarise, write and generate code. Its main limits: it can "hallucinate", stating wrong facts confidently; its knowledge stops at its training date; it can only consider a limited amount of text at once (its context window); and its output can vary between runs.

In a product, that means checking important outputs, giving the model the right information in the prompt, and never trusting it blindly for facts.

RAG means fetching relevant information first and giving it to the model in the prompt, so its answer is based on your data. Typically you split documents into chunks, store their embeddings in a vector database, find the chunks closest to the user's question, and include them in the prompt with an instruction to answer from them.

Use RAG when the knowledge changes often or must be cited, like company documents or product help: you just update the documents. Fine-tuning changes the model's behaviour or style and needs retraining to add new facts, so it suits teaching a format or tone, not keeping knowledge current.

Wrong answers: ground the model in your own data with RAG, and show sources or a note for important answers. Prompt injection: users or documents may contain text that tries to override your instructions, so treat it as data, limit what the model can do, and never let it act without checks. Privacy: don't send personal data you don't need, and check the provider's data terms. Cost and speed: set token limits and timeouts, and cache common answers.

Test it on a set of real questions before launch, and keep checking quality afterwards, since model updates can change its behaviour.

Keep it to about a minute and make it about the job, not your life story. A simple structure is present, past, future: "I'm a final-year Computer Science student at [college], and I enjoy building web applications. In my final-year project I built [project], where I [what you did, with a result]. I also interned at [company], working on [task]. Now I'm looking to start as a software engineer where I can [what you want to do], which is why this role interests me."

Don't repeat your resume line by line, and don't start with your family or hometown unless you're asked.

Connect what the job needs with what you've shown, with evidence. Pick two or three strengths from the job description and back each with a short example: "You need someone who picks up new tools quickly. In my internship I learned Spring Boot in two weeks and delivered the login module." End with what you'll bring to the team.

Don't compare yourself with other candidates, and don't list adjectives like "hard-working" without proof.

For a strength, pick one that matters for this job and prove it with an example. For a weakness, choose a real one that won't stop you doing the job, and show what you're doing about it: "I used to find it hard to speak up in meetings, so now I prepare two points beforehand and share them early. I contributed much more in my last project's reviews."

Avoid disguised strengths like "I'm a perfectionist" or "I work too hard": interviewers have heard them many times.

Use the STAR method: Situation, Task, Action, Result. Set the scene briefly, spend most of the answer on what you personally did, and end with a measurable result and what you learned. For example: "Two days before a demo, our app crashed under load (situation). I owned the backend (task). I profiled it, found a query running once per row, and replaced it with one join plus an index (action). Response time fell from 8 seconds to under 1 and the demo went well; I now check query counts in every code review (result)."

Say "I", not "we", for the part you did.

Show ambition that fits the company, and that you plan to grow there: "I'd like to become a strong engineer in this area, someone the team relies on for [for example, backend systems], and to take on more responsibility, like owning features end to end and helping new joiners."

Avoid naming another company or a different career, and don't make this job sound like a stepping stone.