Software engineer interview questions that match the posting

By role - Guide

Developers interviewing for backend, platform, or generalist engineering roles at startups and enterprises - especially when you have the actual job description and need focused prep in days, not weeks. Samples below are illustrative. Your kit is traced to the posting you paste.

Overview

  1. Software engineer interview loops are not one exam.

    A fintech backend posting that names Kafka and Postgres is a different night of prep than a product-engineering role that lists React, design partners, and "ship weekly." This guide is for candidates who already have the job description and need to turn it into a revision plan - not another generic LeetCode playlist.

  2. Interviewers for this path usually listen for four things: how you decompose a messy problem, whether your code and tests would survive review, how you talk about APIs/data/reliability trade-offs, and whether you sound like someone who partners with product and owns outcomes.

    Those themes only matter insofar as the posting emphasizes them. If the JD never mentions distributed systems, do not burn your last evening on gossip protocols.

  3. Read the stack and seniority verbs literally.

    "Mentor," "design," "own the service," and "on-call" raise the altitude from "can you code" to "can you decide." Domain words (payments, healthcare, ads, infra) change which failure modes and compliance language sound native.

  4. Use the sections below to triage the posting, then generate a kit from that exact JD for twenty traced questions with follow-ups and short outlines.

    Samples here are patterns only.

Backend vs full-stack vs platform - how the JD changes prep

  1. If the posting is backend-heavy (APIs, queues, datastores, SLOs), prioritize failure modes, consistency, and operability in your outlines.

    Bring one story where you diagnosed production with imperfect logs.

  2. If it is full-stack or product-engineering, rehearse explaining a UI - API trade-off to a non-engineer and one accessibility or performance win tied to user impact.

  3. If it leans platform/infra (CI, developer experience, multi-tenant services), prepare examples of leverage: reducing toil, hardening defaults, or making other teams faster - still anchored to tools named in the JD.

90-minute triage when the loop is tomorrow

  1. Minute 0-20: Paste the JD into a blank note.

    Highlight must-have languages, cloud/DB/CI tools, and seniority verbs. Cross out topics the posting never mentions.

  2. Minute 20-50: Write five short outlines only - two coding/debugging, one design/trade-off, one collaboration/ownership, one "why this role" tied to the company's product clue in the posting.

  3. Minute 50-80: Say each outline out loud once, then answer one follow-up (why / what else / what would you change).

  4. Minute 80-90: Skim highlights only.

    Sleep or logistics - no new rabbit holes.

What interviewers usually test

  1. Problem decomposition and clean coding under time pressure

  2. How you reason about complexity, edge cases, and testing

  3. Trade-offs in APIs, data models, and reliability

  4. Collaboration with product, code review habits, and ownership

Signals to read in your job description

  1. Languages and frameworks named in the posting

  2. Cloud, databases, and CI/CD tools listed as requirements

  3. Seniority language: "mentor", "design", "lead", "ship independently"

  4. Domain hints: fintech, healthcare, consumer, infra

How rounds differ

  1. Recruiter / phone screen

    Clean narrative: why this company, why this stack, proof you match the top three must-haves. Keep coding depth light unless they start a live screen.

  2. Coding / problem-solving

    Decomposition, edge cases, tests, and communication while you work. Prefer clarity over cleverness - especially if the JD emphasizes production quality.

  3. System / API / practical design (when listed)

    Trade-offs for the domain in the posting: consistency vs latency, cache invalidation, idempotency, observability - scoped to what they actually run.

  4. Hiring manager / team fit

    Ownership, code review habits, conflict with product deadlines, and how you raise the bar without blocking shipping.

Common prep mistakes

  1. Grinding random hard problems while under-preparing the languages and datastores named in the JD

  2. Giving textbook CAP/SOLID lectures with no decision you would make on their product

  3. Ignoring on-call / SLO language when the posting clearly expects operational maturity

  4. Treating "software engineer" as identical at every company and seniority

  5. Memorizing sample questions from blogs as if they were this employer's loop

Last-hour prep playbook

  1. Extract the real exam

    From the JD, list: languages, datastores, cloud, CI, domain, and seniority verbs. That list is your syllabus.

  2. Pick five outlines, not fifty topics

    Two debug/build stories, one design trade-off, one collaboration story, one motivation story - all JD-tied.

  3. Pressure with follow-ups

    For each outline, answer why that approach, what you would monitor, and what you would change with more time.

  4. Match altitude to seniority

    If the posting says mentor/own/design, add one example of raising standards or reversing a decision with data.

  5. Last-hour pass

    Re-read JD highlights + your five outlines only. Generate or reopen your kit if you have one.

20 interview questions with answer outlines

Practice set for this path: question, round, short answer outline, and a follow-up. Your kit is generated from the posting you paste - not copied from this list.

  1. How would you design a URL shortener that can handle millions of redirects per day?

    • Round: Technical / role-core. Answer outline: Encode unique IDs with base62, persist mapping, serve redirects from a cache-first read path.
    • Generate IDs via range-allocated counters, store code-to-URL in sharded KV, cache hot redirects.
    • Hash collisions and cache stampedes break uniqueness - prove with p99 redirect latency and collision rate. Follow-up: If that approach hit a hard limit, what would you change first?

  2. Walk me through how you would debug a production issue that only appears under load.

    • Round: Technical / role-core. Answer outline: Load-only bugs are usually contention, pool exhaustion, GC pauses, or lock convoys.
    • Correlate p99 latency, thread dumps, traces, and saturation metrics while reproducing on a canary.
    • Ship a bounded mitigation first - add a load test that fails if the regression returns. Follow-up: If that approach hit a hard limit, what would you change first?

  3. Tell me about a time you disagreed with a technical decision on your team.

    • Round: Phone / early round. Answer outline: Dual-writes without fencing would corrupt inventory during a partition, so I blocked the design.
    • I compared write-loss probability, rollback cost, and a single-writer queue alternative with latency numbers.
    • We shipped the queue - incident rate dropped, and I documented the partition failure mode. Follow-up: What would you do differently if you faced the same situation again?

  4. You inherit a service with no tests and frequent regressions. What do you do in the first two weeks?

    • Round: Phone / early round. Answer outline: Rank endpoints by blast radius: auth, payments, and mutating APIs get characterization tests first.
    • Wrap those paths with contract tests, golden fixtures, and a freeze on untested refactors.
    • Gate deploys on those tests - track regression rate weekly before any large rewrite. Follow-up: What would you do differently if you faced the same situation again?

  5. Explain the difference between concurrency and parallelism, and when each matters in practice.

    • Round: Hiring manager / final. Answer outline: Concurrency interleaves tasks on one core - parallelism runs them simultaneously on multiple cores.
    • I/O-bound work needs concurrency via async or threads
    • CPU-bound work needs true parallel cores.
    • Shared mutable state under concurrency races
    • Amdahl's law and lock contention cap parallel speedup. Follow-up: How would you prove it worked in the first 30 days?

  6. How would you choose between a hash map, a heap, and a balanced tree for a production lookup path?

    • Round: Hiring manager / final. Answer outline: Hash maps win average O(1) keyed lookup - they lose ordered scans and worst-case O(n).
    • Heaps give O(log n) extract-min - balanced trees give ordered range queries in O(log n).
    • Measure p99 lookup, resize pauses, and rebalance cost under the real key distribution. Follow-up: How would you prove it worked in the first 30 days?

  7. Given a stream of integers, how would you return the k most frequent values with a tight memory budget?

    • Round: Hiring manager / final. Answer outline: I count frequencies, then keep a size-k min-heap of the strongest candidates.
    • Each update costs expected O(1) counting plus O(log k) - memory tracks unique keys.
    • For unbounded keys, Count-Min Sketch saves memory but introduces estimation error. Follow-up: How would you prove it worked in the first 30 days?

  8. Design a rate limiter for a public API that must stay fair across noisy tenants.

    • Round: Technical / role-core. Answer outline: I enforce a per-tenant token bucket so each tenant receives a defined fair share.
    • Redis Lua updates tokens atomically
    • I return 429 with remaining quota metadata.
    • Distributed clocks, bursts, and hot tenants require bounded bursts and isolation. Follow-up: If that approach hit a hard limit, what would you change first?

  9. Implement LRU cache semantics and explain when you would not use a classic LRU.

    • Round: Hiring manager / final. Answer outline: I pair a hash map with a doubly linked list for constant-time cache operations.
    • Hits move nodes to the front - capacity overflow removes the least-recent tail.
    • LFU or TTL may outperform LRU when scans evict frequently reused working data. Follow-up: How would you prove it worked in the first 30 days?

  10. How would you detect a cycle in a directed graph that represents job dependencies?

    • Round: Hiring manager / final. Answer outline: DFS marks visiting nodes - an edge to a visiting node proves a directed cycle.
    • Alternatively, Kahn's algorithm removes zero-indegree nodes and checks leftovers.
    • I return the cycle path - frequent edits may require incremental cycle detection. Follow-up: How would you prove it worked in the first 30 days?

  11. Walk through designing a news feed that stays fresh without melting the database.

    • Round: Technical / role-core. Answer outline: I use fan-out-on-write for ordinary users and fan-out-on-read for celebrity authors.
    • Redis stores ranked IDs - cursor pagination hydrates bodies from a cache or database.
    • If ranking fails, serve cached recency results and protect latency over personalization. Follow-up: If that approach hit a hard limit, what would you change first?

  12. What happens, step by step, after a user types a URL and hits enter?

    • Round: Technical / role-core. Answer outline: The browser resolves DNS, establishes TCP, negotiates TLS, then sends the HTTP request.
    • It follows redirects, parses HTML, builds the render tree, and fetches subresources.
    • DNS, CDN, and browser caches remove steps
    • HSTS and HTTP/2 alter connection behavior. Follow-up: If that approach hit a hard limit, what would you change first?

  13. When would you use a relational database instead of a document store?

    • Round: Technical / role-core. Answer outline: I choose relational storage when joins, constraints, and multi-row transactions require strong consistency.
    • I choose documents for variable records read together without cross-document joins.
    • Access patterns decide - schema flexibility does not justify duplicated data that drifts. Follow-up: If that approach hit a hard limit, what would you change first?

  14. Explain time and space complexity for lookup, insert, and delete on an array versus a hash map.

    • Round: Technical / role-core. Answer outline: Arrays provide O(1) indexed access - middle insertion or deletion costs O(n) shifts.
    • Hash maps provide expected O(1) lookup and update, degrading with collisions or bad hashing.
    • Arrays preserve order and locality - hash maps trade memory for fast membership. Follow-up: If that approach hit a hard limit, what would you change first?

  15. What is an index in a database, and what does it cost you?

    • Round: Technical / role-core. Answer outline: An index stores ordered or hashed keys that locate rows without scanning the table.
    • Writes update every relevant index, increasing storage, write latency, and maintenance work.
    • I index selective filters and joins, then confirm benefit with query plans and timings. Follow-up: If that approach hit a hard limit, what would you change first?

  16. What is the difference between a process and a thread, and when does that difference bite you?

    • Round: Technical / role-core. Answer outline: A process owns isolated memory - its threads share heap, descriptors, and process resources.
    • Threads are cheaper to switch but require synchronization around shared mutable state.
    • A process crash isolates siblings - a fatal thread error can terminate the whole process. Follow-up: If that approach hit a hard limit, what would you change first?

  17. Explain HTTP methods GET, POST, PUT, and DELETE in terms of safety and idempotency.

    • Round: Technical / role-core. Answer outline: GET is safe and idempotent
    • PUT and DELETE are idempotent but can mutate state.
    • POST commonly creates or triggers work and is neither safe nor inherently idempotent.
    • Retries need idempotency keys when repeating POST could duplicate a charge or operation. Follow-up: If that approach hit a hard limit, what would you change first?

  18. What is HTTPS giving you that HTTP is not, in one sentence each for confidentiality, integrity, and authenticity?

    • Round: Technical / role-core. Answer outline: TLS provides confidentiality by encrypting application bytes against on-path observers.
    • Authenticated certificates bind the hostname, while AEAD detects tampering in transit.
    • HTTPS does not fix authorization, endpoint bugs, or stolen cookies after decryption. Follow-up: If that approach hit a hard limit, what would you change first?

  19. Stack versus heap: what lives where, and what fails if you get it wrong?

    • Round: Technical / role-core. Answer outline: The stack holds call frames - the heap holds dynamically allocated objects and longer lifetimes.
    • Deep recursion overflows the stack - uncontrolled allocations exhaust memory or trigger GC pressure.
    • Manual memory needs safe ownership - garbage collection prevents frees, not logical retention leaks. Follow-up: If that approach hit a hard limit, what would you change first?

  20. What does it mean for a function to be pure, and why do interviewers care?

    • Round: Technical / role-core. Answer outline: A pure function is deterministic for its inputs and performs no observable side effects.
    • I isolate clocks, I/O, and mutation at boundaries to simplify tests and memoization.
    • Purity costs architectural discipline - impure adapters remain necessary at system edges. Follow-up: If that approach hit a hard limit, what would you change first?

FAQ

  1. Do I need to finish a LeetCode grind before a software engineer interview?

    Only to the depth the posting and process imply. Many loops mix practical coding with design and collaboration. Use the JD and recruiter notes to set the mix - then practice short outlines you can defend under follow-ups.

  2. How do I prep if the JD lists five languages?

    Prioritize must-haves over nice-to-haves. Prepare depth in the primary stack and honest, concise familiarity for the rest. Do not fake production expertise you do not have.

  3. What if I only have one evening?

    Run the 90-minute triage above. Narrow beats broad. Pair with a JD-traced kit so your practice set matches this posting.

  4. How is this guide different from the $2 kit?

    This page teaches how to read a software-engineer posting and allocate prep. The kit is generated from your pasted JD: foundational and role questions, follow-ups, and outlines for that text.

  5. What should I do next?

    Paste the full job description on the homepage for a free three-question preview. If it fits, unlock the kit and revise from that structure.

Related guides

  1. Backend Developer Interview Questions

  2. System Design Interview Questions

  3. Technical Interview Prep

When you have a posting

  1. Get the right interview questions for the job you applied for by pasting the complete job description from the company's careers page - free preview, $2 for the full kit. No account needed. Paste the job description.