Skip to content

Software engineer interview questions with worked answers

LiveRec EditorialUpdated

Software engineer interview questions usually come in a recruiter screen, one or two coding rounds, a system design round for mid-level and senior roles, and a behavioral round. Prepare data structures, one language in depth, a few system design patterns, and five work stories, then rehearse worked answers.

At a glance

  • Typical rounds: recruiter screen, technical phone or online assessment, coding on a whiteboard or shared editor, system design (mid and senior), behavioral.
  • Think aloud. Interviewers score your reasoning, not only the final code.
  • Clarify the problem before writing any code. Ask about input size, edge cases and constraints.
  • State complexity (time and space) for every solution.
  • Prepare five real stories for behavioral questions.

What do the rounds look like?

RoundLengthWhat is assessedHow to prepare
Recruiter screen20 to 30 minFit, motivation, salary range, visa statusTell me about yourself; salary expectations
Online assessment or phone coding45 to 90 minProblem solving in one or two problemsPractise timed problems in your chosen language
Coding on-site or virtual45 to 60 min, 1 to 3 roundsAlgorithms, code quality, communicationData structures, patterns, talking through trade-offs
System design45 to 60 minArchitecture, trade-offs, scalePractise two or three designs per week
Behavioral / hiring manager30 to 60 minCollaboration, ownership, conflictSTAR stories

Formats vary by company and level. Ask the recruiter what to expect in each round; it is a normal question.

What coding questions come up most?

Common patterns, with what to practice.

PatternExample promptKey idea
Hash mapTwo Sum: find two numbers that add to a targetStore seen values for O(1) lookup
Two pointersCheck if a string is a palindromeMove pointers inward
Sliding windowLongest substring without repeating charactersExpand and shrink a window
StackValid parenthesesPush opening, pop on matching close
Binary searchFind element in a sorted arrayHalve the range each step
BFS and DFSNumber of islands in a gridTraverse connected cells
Recursion and backtrackingGenerate all subsetsChoose, explore, un-choose
Dynamic programmingClimbing stairs or coin changeDefine state; reuse subproblems
Linked listReverse a linked listTrack previous, current, next
Sorting and heapsTop K frequent elementsCount, then heap or bucket

Worked example: Two Sum

Prompt: Given an array of integers and a target, return the indices of two numbers that add up to the target.

How to talk through it:

  1. Clarify: "Can there be duplicates? Is exactly one solution guaranteed? Can I use the same element twice?"
  2. Brute force: check every pair. That is O(n squared) time and O(1) space. Mention it, then say you can do better.
  3. Better: one pass with a hash map from value to index. For each number, check whether target - number is already in the map.
  4. State: O(n) time, O(n) space.
def two_sum(nums, target):
    seen = {}
    for i, n in enumerate(nums):
        need = target - n
        if need in seen:
            return [seen[need], i]
        seen[n] = i
    return []
  1. Test: [2, 7, 11, 15], target 9 returns [0, 1]. Also try an empty array, one element and negative numbers.

What language and basics should I know?

Know one language well enough to write code without looking things up: strings, arrays or lists, dictionaries, sorting with a custom key, and basic class design. Interviewers do not expect trivia, but they do expect fluency. Questions that come up often: the difference between a process and a thread, what a hash collision is, what happens when you type a URL into a browser, REST versus GraphQL, SQL joins, what an index does, and how you would test a function.

What is a system design question like?

Prompt: Design a URL shortener.

A strong outline:

  1. Clarify requirements. How many new URLs per day? How long should links last? Do we need analytics or custom aliases? Assume 100 million new links a month for this example and a read-heavy ratio.
  2. API. POST /shorten takes a long URL and returns a short code; GET /{code} redirects.
  3. Data model. A table with code, long URL, created time, optional expiry.
  4. Generating codes. Options: hash the URL and truncate (collisions to handle), a counter encoded in base 62 (needs a distributed counter), or pre-generated ranges handed to each server. State the trade-offs.
  5. Scale. Reads dominate, so put a cache (such as an in-memory store) in front of the database; use a CDN for popular links; partition the database by code.
  6. Failure and edge cases. Duplicate URLs, malicious links, rate limiting, abuse reporting.
  7. Trade-offs. Say what you would build first and what you would defer.

The numbers in step 1 are assumptions you set with the interviewer, not facts. Interviewers want you to make and defend reasonable assumptions.

What behavioral questions do engineers get?

  • "Tell me about a bug that was hard to find." Show a method: reproduce, isolate, hypothesise, verify.
  • "Describe a time you disagreed in a code review."
  • "Tell me about a project you led or owned end to end."
  • "Tell me about a technical decision you would make differently."
  • "How do you handle unclear requirements?"

Use the STAR method and name the actual technology and your specific contribution.

What mistakes cost engineers offers?

  • Coding silently for 15 minutes.
  • Jumping to code before clarifying inputs.
  • Ignoring edge cases such as empty input, duplicates or very large input.
  • Not testing your own code. Walk through one example by hand.
  • Claiming experience you cannot discuss at depth. If you list a technology, expect questions about it.
  • Getting defensive when the interviewer hints at a bug. Treat the hint as collaboration.

What is a four-week prep plan?

WeekFocusTarget
1Arrays, strings, hash maps, two pointers10 problems, review mistakes
2Trees, graphs, recursion, binary search10 problems
3Dynamic programming basics, heaps; start system design8 problems, 2 designs
4Mock interviews, behavioral stories, weak spots3 mocks, 5 stories

Time-box each problem to 30 to 45 minutes. If stuck, read the solution, then redo it from scratch the next day. Quality of review beats volume.

How do I answer "Why do you want to leave?" or "Why us?"

Keep it positive and concrete: "I want to work on systems at a larger scale, and your engineering blog describes the migration to event-driven services, which is the area I've been learning." Do not criticise your employer.

After the offer

Offers for engineers often include base salary, bonus and equity, and details vary. Compare total compensation and negotiate politely; see how to negotiate salary. For occupation-level pay and growth data, see the Bureau of Labor Statistics (Sources).

Frequently asked questions

How many coding problems should I practice? There is no magic number. Many candidates do roughly 50 to 100 problems across the main patterns, but understanding why a solution works matters more than count. Review mistakes and redo problems you missed.

Should I memorise solutions? No. Learn patterns. If you memorise a solution and the interviewer changes a constraint, you will not know how to adapt. Practise explaining why each step is needed.

What if I get stuck? Say what you are thinking, state the brute-force approach, and ask a clarifying question. Interviewers often give hints and score how you respond to them.

Do junior roles get system design? Usually not in depth. Some companies ask a lightweight design or object-oriented design question. Mid-level and senior roles expect a full system design round.

Sources

  • U.S. Bureau of Labor Statistics, Occupational Outlook Handbook: Software Developers, Quality Assurance Analysts, and Testers, https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm (accessed 30 October 2026)

This page is general career information. Interview formats differ by company.