Software engineer interview questions

What the job is, and what the loop is testing

It helps to start from the published description of the work. The US Bureau of Labor Statistics lists the duties of software developers as analysing users’ needs and then designing and developing software to meet those needs, designing each piece of an application or system and planning how the pieces will work together, recommending upgrades to existing programs and systems, ensuring a program keeps functioning through maintenance and testing, and documenting every aspect of an application as a reference for future maintenance. For quality assurance analysts and testers it lists creating test plans and procedures, identifying project risks, implementing manual, automated and exploratory testing, and documenting defects.

Read that list again as an interview syllabus. Needs analysis is why you get asked how you clarify ambiguous requirements. Planning how pieces fit together is the system design round. Maintenance and documentation are why interviewers ask about on-call, testing and handover rather than only about clever code.

The same source gives a bachelor’s degree as the typical entry-level education for both roles, commonly in computing or a related field such as engineering or mathematics. Many engineers arrive instead from bootcamps or self-study, and those loops lean harder on a portfolio and a take-home exercise, because the panel is replacing the signal a transcript would have provided.

Across every round, three things are being judged: whether you can solve a problem you have not seen, whether you can explain your reasoning to a colleague, and whether working with you for two years would be pleasant and predictable.

The stages of a hiring loop, and what each one scores

Timelines are inconsistent. MIT’s guide to interview timelines notes that some candidates hear back within days of applying while others wait weeks or months, so treat silence as noise rather than signal.

The recruiter screen comes first and is mostly logistics and motivation. It checks, as MIT puts it, that you have the skills and experience necessary for the role as well as the motivation and fit. Have three things ready: a 60 second summary of your work, your reason for moving, and your compensation expectations or a reason to defer that question.

The technical screen follows, typically 45 to 60 minutes with one engineer and a shared editor. The problems are deliberately mid-sized, and talking while you work is part of the score.

Then comes the loop proper, and MIT’s guide describes the pattern well: in later rounds you meet someone new each time, such as the hiring manager, an HR specialist or prospective colleagues, with a combination of behavioural, technical and case questions. For engineering that usually means one or two coding rounds, a design round, a project deep dive and a behavioural or values round. Some employers add a take-home exercise or a short pairing session on their real codebase.

The hiring manager conversation deserves separate preparation, because it is where scope and expectations get set. Ask the recruiter for the agenda too: knowing whether the coding round allows your own editor removes an hour of avoidable stress.

General IT and technical questions that come up

Outside the dedicated coding round, most loops include a stretch of general questions. They tend to cluster in five places: version control, testing, debugging, the web request path, and data storage.

Version control questions reward precision about what a command does to history. A common one is the difference between undoing a commit that has already been pushed and one that has not. The git documentation is explicit: git revert takes one or more existing commits, reverts the changes their patches introduced and records new commits recording them, and it requires a clean working tree. The same page points to git reset, particularly the hard option, for throwing away uncommitted changes, and warns that it discards work in your working directory.

# shared history: add a new commit that undoes an old one
git revert <commit>

# local only: move the branch pointer back, keep the changes staged
git reset --soft HEAD~1

That distinction is the answer interviewers want: revert moves history forward with a new commit and is therefore safe on a shared branch, while reset rewrites what the branch points at and belongs to work nobody has pulled.

Testing questions start with what you test rather than which framework you use: how you choose between a unit test and an integration test, what you do about a flaky test, how you test code that touches the network or the clock. Injecting the dependency and asserting on behaviour beats naming libraries.

Debugging questions arrive as scenarios: a service got slower last Tuesday, how do you find out why. Describe the order you would look in, the signal you would check first, and what you would do to stop the bleeding before you find the cause.

Web path and storage questions get deeper in the design round, so a short, accurate answer is enough here: what happens between a browser request and your handler, where caching sits, what an index does to a query, and when you would reach for a transaction.

The project and resume deep dive

Nearly every loop has a round where an engineer reads your resume aloud and asks you to go deep on one line of it. This is the round candidates under-prepare, and the one where senior offers are won.

Pick two projects in advance, one recent and technically substantial, one where something went wrong. For each, prepare the problem and its constraints, the design you chose, at least one alternative you rejected and why, what you personally built, and what you would change now. Depth is the point: be ready for three follow-up questions on any claim you make.

Here is the shape of an answer that survives follow-ups.

Problem: Our nightly import took six hours and had started overrunning into the working day, which blocked the reporting team.

Constraints: We could not change the upstream file format, and the database was shared with the customer-facing API, so extra load had a hard ceiling.

What I did: I profiled the job and found most of the time was in row-by-row updates. I changed it to bulk load into a staging table, then one set-based merge inside a transaction, and I made the job resumable per file so a failure did not restart everything.

Trade-off: Staging doubles the disk the job needs, and the merge holds locks for about a minute. We accepted both, and scheduled the merge inside the quiet window.

Result: The import now finishes in well under an hour and has not overrun since. If I did it again I would push the format conversion upstream instead of parsing it twice.

Notice that it names a trade-off without being asked. That single habit is the clearest seniority signal in a technical interview. If your experience is mostly coursework or personal projects, the structure is identical: the project just needs to be something you can discuss honestly at that depth.

Behavioural and culture fit questions for engineers

Engineering candidates often treat this round as a formality and lose offers in it. Harvard’s career office explains the premise: behavioural interviews rest on the idea that past behaviour predicts future behaviour, and it recommends telling those stories in a situation, action, result structure. It lists eight competencies employers assess, among them critical thinking, learning orientation, leadership, problem solving, teamwork, communication, technical skills and professionalism, which maps neatly onto the questions engineers actually get.

The recurring ones are worth writing out in advance. A time you disagreed with a teammate on a technical decision. A time you shipped a defect to production. A time you chose between a deadline and the quality of the work. A time you learned an unfamiliar technology quickly. A time you dealt with an unclear requirement.

The disagreement question is where good engineers do themselves the most damage, usually by telling a story in which they were right and everyone else was slow. A stronger version states the other position fairly, says how the decision was actually made, and reports the outcome honestly, including when the other approach turned out better.

For the production defect question, do not pick something trivial. Describe the detection, your immediate mitigation, the communication you sent, the root cause and the guard you added.

Harvard also mentions the airport test, the informal question of whether a colleague would be glad to be stuck with you for a long stretch. Culture fit rounds are largely that, so answer in your own register and ask real questions about how the team reviews code and handles disagreement.

How to prepare by stack and seniority

Allocate your preparation time according to the level you are interviewing at rather than spreading it evenly.

For a junior or first role, weight the coding round and the fundamentals: data structures, complexity, strings, dictionaries and lists, plus one language you can write fluently under observation. Add a short, well-explained project and basic version control confidence. Design rounds, where they appear at all, will be scoped to a small feature.

For a mid-level role, split your time between coding practice and design, and prepare the project deep dive in detail. Expect ownership questions: how you broke work down, how you handled the migration, what you monitored after the release.

For a senior role, the loop shifts towards design, trade-offs and influence without authority. Coding rounds still happen, but a clean, tested solution to a mid-sized problem is enough; what differentiates candidates is the quality of their questions and the clarity of their trade-off reasoning.

By stack, revise the parts of your language that interviewers reliably probe: in Python, mutability, comprehensions, generators and the standard library; in JavaScript, asynchrony, closures, equality and the event loop; in Java and C#, collections, the type system and concurrency; in SQL, joins, grouping, indexes and window functions. If the posting names a framework, explain its request lifecycle and how you would test code written in it.

One caution for every level: do not script answers word for word. Harvard’s guidance is to practise articulating answers rather than memorising them, and the difference is audible.

Your questions, and the end of the process

The questions you ask are scored, informally at least, by everyone you meet. Good ones are specific to the work: how the team decides what to build next, what the code review culture is like, how often releases happen, what on-call involves, what the last incident taught them, how much of the quarter is maintenance. Asking what would make the first six months successful gives you a target and gives the manager a chance to describe the real job.

Before you leave each round, clarify the next step and the timeline. MIT’s primer recommends asking about the hiring timeline and sending a thank-you note afterwards that expresses gratitude, revisits topics from the conversation and reaffirms your interest, and it adds a useful reminder: an interview is a step but not an offer, so keep other processes alive until something is signed.

When an offer arrives, read the whole package rather than reacting to the headline number: level, scope, equity terms if any, on-call expectations, remote policy, and what the first project is. Those details are harder to renegotiate later than salary.

If you are rejected after a loop, ask which round was weakest. Many employers will say, and the answer is often one fixable habit, such as not narrating your thinking in the coding round.