The 3 Types of Technical Interview Questions — and How to Answer Each

Strip away the branding and nearly every technical screen — online assessment or live interview — is assembled from three building blocks: algorithm problems, multiple-choice questions, and system design prompts. Each measures something different and rewards a different approach. Knowing which game you're playing is half the preparation.

Type 1: Algorithm questions

What they look like: "Given an array of integers, return the indices of two numbers that add up to a target." A problem statement, input constraints, and a code editor with test cases.

What they measure: Can you translate a problem into working code, and do you recognize the standard patterns — hash maps for lookups, two pointers, sliding windows, BFS/DFS on graphs, dynamic programming?

How to answer them:

  1. Read the constraints before thinking about approaches. n ≤ 10^5 rules out quadratic solutions; n ≤ 20 whispers "exponential search is fine." The constraints are the intended solution's fingerprint.
  2. State a naive solution first, even just verbally. It banks a fallback, clarifies the problem, and gives you something to optimize against.
  3. Code the version you can finish. A working suboptimal solution beats a stalled optimal one, in live interviews and in partial-credit online assessments alike.
  4. Test before declaring done: one normal case, then empty input, single element, and boundary values.

A complete answer has four parts — working code, test cases, time complexity, space complexity — and most candidates deliver only the first. That four-part shape is exactly what Marauder Bot returns for algorithm questions (see the live demo), which makes it a useful model of what "done" looks like when you review your own practice.

Type 2: Multiple-choice questions

What they look like: "What is the output of this code?" / "Which SQL query returns…?" / "What is the time complexity of…?" — usually many questions on a tight clock.

What they measure: Breadth. Language semantics, SQL, complexity analysis, OS and networking basics — the accumulated floor of knowledge a degree or a few years of work builds.

How to answer them: Fast recognition where you know it cold, disciplined elimination where you don't, and strict time-boxing throughout — every question is typically worth the same, so the puzzle that eats four minutes costs you three other questions. We wrote a full strategy guide for technical MCQs; the one-line summary is hunt for wrong answers, not right ones, and never leave a blank.

These sections are the most format-sensitive of the three: practicing full timed sections matters as much as knowing the content. You can watch structured answers-with-explanations get generated for a sample section on the multiple-choice demo.

Type 3: System design questions

What they look like: "Design a URL shortener." "Design a chat system for 10 million users." An open-ended prompt, a whiteboard (physical or virtual), and 30–45 minutes of conversation.

What they measure: Whether you can structure ambiguity. There is no correct answer; there are well-organized and poorly-organized ones. Interviewers watch for requirements-gathering, sensible decomposition, and honest tradeoff reasoning.

How to answer them: Follow a fixed skeleton so the ambiguity has walls:

  1. Requirements — functional ("shorten URLs, redirect fast") and scale ("how many reads per write?"). Two to five minutes; skipping this is the classic failure.
  2. High-level architecture — the boxes and arrows: clients, load balancer, services, database, cache.
  3. Key components in depth — pick the two or three that matter for this problem (the ID-generation scheme for a URL shortener; the fan-out strategy for a feed) and go deep there.
  4. Data flow — walk one request end to end. This is where hand-waving gets exposed, so do it to yourself before the interviewer does.

That requirements → architecture → components → data flow structure is the same shape Marauder Bot's system design answers (beta) use, and our system design primer for junior engineers works through it on a real example.

Preparing for all three at once

The three types compound different weaknesses: algorithm questions punish rusty coding, MCQs punish knowledge gaps, design punishes disorganized thinking. Diagnose before you allocate — one timed mixed practice session will tell you which type is actually costing you points, and it's rarely the one you enjoy practicing. Then weight your remaining prep toward the weak one.

For the review side of that loop, Marauder Bot analyzes all three question types on any page — attempt first, then compare your answer against a structured one. Start with the free trial: 15 page analyses over 7 days.