Top 25 Placement Questions - Part 1

1. What is the difference between High-Level Design (HLD) and Low-Level Design (LLD)?

HLD and LLD are two levels of design that sit between requirements and coding. HLD describes the system from a high altitude — what the major components are and how they talk to each other. LLD zooms in and describes each component in enough detail that a developer can start writing code.

                    SOFTWARE DESIGN
                          │
              ┌───────────┴───────────┐
              │                       │
             HLD                     LLD
       High-Level Design       Low-Level Design
              │                       │
       "What exists?"           "How it works?"
              │                       │
     ┌────────┼────────┐        ┌─────┼─────┐
     │        │        │        │     │     │
   API      Database  Service  Classes Functions
     │        │        │        │     │     │
     └────────┴────────┘        Algorithms
              │                Data Structures
        System Architecture    DB Schemas

High-Level Design is about architecture. It identifies the main modules of the system, the databases, the technologies, and how data flows between them. It might decide, for example, that the system has a web front end, an API layer, a payments service, and a relational database, and that the front end calls the API over HTTP. It is usually produced by a system architect, reviewed with stakeholders, and used to make technology choices. It answers the question “what modules exist and how do they connect?”

Low-Level Design is about implementation. It takes each module identified in the HLD and details its internals — the classes, functions, algorithms, data structures, and database schemas. Where the HLD says “we have a payments module,” the LLD says exactly which functions that module exposes, what each one does, what inputs and outputs they have, and what database tables back them. It is produced by developers and is essentially the blueprint from which they write code. It answers the question “how does each module work internally?”

The classic comparison is a building. HLD is the site plan — where the building sits, how many floors, where the entrance is. LLD is the detailed floor plan showing every room, door, and electrical outlet. You cannot build from the site plan alone, and you cannot build without it.

HLD
┌─────────────────────────────────┐
│         BUILDING SITE           │
│                                 │
│   ┌────────┐    ┌────────┐      │
│   │ Floor 1│    │ Floor 2│      │
│   └────────┘    └────────┘      │
│                                 │
│      Where things are           │
└─────────────────────────────────┘
              │
              ▼
LLD
┌─────────────────────────────────┐
│          ONE FLOOR              │
│  ┌─────┐ ┌─────┐ ┌──────────┐  │
│  │Room │ │Room │ │ Kitchen  │  │
│  └─────┘ └─────┘ └──────────┘  │
│     │       │          │        │
│   Door    Door     Electrical   │
└─────────────────────────────────┘

2. What is ‘Scope Creep’ and how is it managed?

Scope creep is when a project’s features quietly grow beyond what was originally agreed, without the budget or timeline growing to match. It is one of the most common reasons projects run late and over budget.

It usually starts innocently. A stakeholder asks for “one small extra feature.” The team says yes without really thinking. Then another request comes, then another. Each one seems trivial on its own, but together they can add weeks of work. Because none of them went through a formal review, the project’s scope grows while the plan stays frozen, and eventually the team is silently doing far more than it committed to.

Original Scope
      │
      ▼
┌─────────────────┐
│ Feature A       │
│ Feature B       │
│ Feature C       │
└─────────────────┘
      │
      │ "Small extra feature"
      ▼
┌─────────────────┐
│ A + B + C       │
│ + Feature D     │
└─────────────────┘
      │
      │ Another request
      ▼
┌─────────────────┐
│ A + B + C + D   │
│ + Feature E     │
└─────────────────┘
      │
      ▼
   SCOPE CREEP
      │
      ├──► More Work
      ├──► More Cost
      └──► More Time

The root causes are usually vague initial requirements, weak approval processes, and pressure to please the customer by saying yes. The danger is not the extra work itself — some extra work is normal — but that it is invisible. Nobody signed off on it, nobody budgeted for it, and it is discovered only when deadlines slip.

Scope creep is managed with a formal change request process. Every proposed addition, however small, must be written up as a change request. The request is evaluated for its impact on cost, time, and risk. It is then approved or rejected by the relevant authority, and only approved changes are added to the plan — along with the extra budget and time they require. Rejected changes are recorded and explained, so nothing disappears quietly.

New Change Request
        │
        ▼
┌──────────────────┐
│ Impact Analysis  │
│ Cost / Time/Risk │
└────────┬─────────┘
         │
         ▼
    ┌───────────┐
    │ Approved? │
    └─────┬─────┘
       Yes│   │No
          │   │
          ▼   ▼
      Update   Record
       Plan    Request
          │
          ▼
     Implement

It also helps to lock down the scope clearly at the start, with a written scope statement that stakeholders approve. When a new request arrives, it can be compared against that baseline, and anything outside it automatically goes through the change process. That makes every addition visible, deliberate, and paid for.

3. What is a ‘Traceability Matrix’ (RTM) and why is it used?

A Requirements Traceability Matrix (RTM) is a table that links every requirement to the test cases that verify it, so that nobody can claim a requirement is done unless there is proof it was tested.

The matrix is built as a table. Each row is a requirement, and the columns track its status — which design implements it, which test cases cover it, and whether those tests passed. The core idea is a link in both directions: from each requirement to its tests, and from each test back to the requirement it proves.

┌──────────────┐
│ Requirement  │
│   REQ-001    │
└──────┬───────┘
       │
       │ implemented by
       ▼
┌──────────────┐
│    Design    │
│   Module A   │
└──────┬───────┘
       │
       │ verified by
       ▼
┌──────────────┐
│  Test Cases  │
│ TC-101       │
│ TC-102       │
└──────┬───────┘
       │
       ▼
    PASS / FAIL

A simple example:

Requirement ID	Requirement	Test Case ID	Status
REQ-001	User can log in	TC-101, TC-102	Passed
REQ-002	User can reset password	TC-103	Failed
REQ-003	Dashboard shows balance	—	Not tested

The matrix is useful for several reasons. Most obviously, it proves coverage. If a requirement has no test case, the matrix makes that gap visible immediately — REQ-003 above has no test and clearly stands out. It also supports change management: when a requirement changes, the matrix instantly shows which tests are affected and need updating. And in audits or customer acceptance, it is the documented evidence that every agreed requirement was actually verified.

Requirement ───────────────► Test Case
    ▲                            │
    │                            │
    └────── proves coverage ─────┘

In short, the RTM turns “we tested things” into “every single requirement was tested.” It closes the gap between what was promised and what was proven.

4. What is the difference between Quality Assurance (QA) and Quality Control (QC)?

QA and QC both deal with quality but attack it from opposite ends. QA is about the process — it works to prevent defects from being created. QC is about the product — it works to detect defects after they exist.

                 SOFTWARE QUALITY
                        │
            ┌───────────┴───────────┐
            │                       │
           QA                      QC
      Quality Assurance       Quality Control
            │                       │
            ▼                       ▼
       PREVENTION               DETECTION
            │                       │
            ▼                       ▼
   Improve the process       Find defects
            │                       │
            ▼                       ▼
 Coding standards             Testing
 Process audits              Inspection
 Training                    Defect reporting
            │                       │
            └───────────┬───────────┘
                        ▼
                   Better Quality

Quality Assurance is proactive. It focuses on improving how the team works so that mistakes never happen in the first place. Typical QA activities are defining coding standards, running process audits, providing training, and using review checklists before work is submitted. The mindset is “if we do the right thing at every step, defects simply don’t occur.” QA applies during development, from the very start of the project.

Quality Control is reactive. It focuses on finding defects in the finished work. Typical QC activities are testing, code inspection, and defect reporting — checking the product against the requirements and flagging anything that fails. The mindset is “the work is done; now let’s verify it.” QC applies once something has been built.

	QA	QC
Focus	Process	Product
Approach	Prevention	Detection
When	Throughout development	After the product exists
Question	Are we following the right process?	Does the product meet requirements?

The relationship between them is simple: good QA reduces the number of defects that QC has to find. A team that reviews its work carefully needs less testing to reach the same quality. The classic one-liner is that QA says “do it right the first time,” while QC says “check it after it is done.” Both are necessary — prevention is cheaper, but detection is the safety net.

5. What is the purpose of Alpha and Beta testing?

Alpha and Beta testing are the two final stages of testing before a product is released to everyone. Alpha happens inside the company; Beta happens with real users in the real world.

                SOFTWARE RELEASE JOURNEY

Development
     │
     ▼
┌───────────────┐
│ Alpha Testing │
│   INTERNAL    │
│ Controlled    │
│ Environment   │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Beta Testing  │
│ REAL USERS    │
│ Real-world    │
│ Environment   │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Public Release│
└───────────────┘

Alpha testing is performed by the internal team at the developer’s site, after development is complete but before any outsider sees the product. The environment is controlled — the team knows the data, the hardware, and the scenarios. The goal is to shake out as many bugs as possible internally, while it is still cheap and private to fix them. It usually runs in two phases: the developers test first, then a dedicated QA team does a more rigorous pass.

Beta testing is performed by real users in their own environments, after alpha testing has cleaned up the obvious problems. Because the users are real, the usage is unpredictable — different machines, different browsers, different habits, different edge cases that the internal team could never have imagined. Beta testing is also called “field testing” for this reason. Its goal is to confirm the product works in the messy real world and to gather feedback on usability and performance.

The sequence is always the same: development, then alpha testing internally, then beta testing with selected real users, then the public release.

The value of the two-stage approach is that each catches what the other cannot. Alpha catches bugs cheaply and privately. Beta catches problems that only genuine, varied, uncontrolled usage reveals — the ones that would otherwise show up as angry reviews and support tickets right after launch.

6. What is ‘Technical Debt’?

Technical debt is the future cost of choosing a quick, easy solution now instead of a better, more solid one. The term borrows from finance deliberately: the speed you gain today is a loan, and it accrues interest that has to be paid back later.

        QUICK SOLUTION
              │
              ▼
       ┌─────────────┐
       │ Ship Fast   │
       └──────┬──────┘
              │
              ▼
        TECHNICAL DEBT
              │
       ┌──────┴──────┐
       │             │
       ▼             ▼
   More effort    More risk
   later          later
       │             │
       └──────┬──────┘
              ▼
       "INTEREST"
              │
              ▼
     Slower Development
              │
              ▼
       Higher Maintenance

It usually accumulates under deadline pressure. A team needs to ship by Friday, so it hard-codes a value instead of making it configurable, or it copies a chunk of code instead of extracting a reusable function, or it skips writing tests. The shortcut works — the feature ships on time. But now every future change to that code is slower and riskier than it should be, because the code is messy, duplicated, or untested. That extra effort later is the “interest.”

Common examples of technical debt include hard-coded values that have to be changed in many places, copy-pasted code that has gradually drifted into slightly different behavior, missing automated tests that make every change a gamble, and tangled dependencies that nobody fully understands.

Technical debt is not automatically bad. Some debt is a reasonable trade when a deadline matters and the code will not live long. The problem is unmanaged debt. If the team never acknowledges it, the debt compounds — every new feature built on top of the shortcut gets harder and harder, until the codebase slows to a crawl.

The healthy way to handle it is to treat it like real debt: keep a visible list of what is owed, schedule time to pay it down in small pieces during normal work, and do so before it starts blocking new features or causing production failures. A team that tracks its debt and repays it regularly avoids the day when the entire codebase has to be rewritten.

Technical Debt
      │
      ▼
┌──────────────────┐
│ Track the debt   │
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Schedule cleanup │
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Refactor / Test  │
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Debt decreases   │
└──────────────────┘

7. What are the four types of Software Maintenance?

Software maintenance keeps a product alive after release, and it comes in four distinct flavors: corrective, adaptive, perfective, and preventive.

                 SOFTWARE MAINTENANCE
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
       ▼                 ▼                 ▼
   CORRECTIVE         ADAPTIVE         PERFECTIVE
   Fix defects       Fit changes      Improve product
       │                 │                 │
   "It's broken"     "Environment     "Make it better"
                      changed"
       │                 │                 │
       └─────────────────┼─────────────────┘
                         │
                         ▼
                    PREVENTIVE
                  Avoid future issues
                         │
                  "Prevent problems"

Corrective maintenance is about fixing things that are broken. When a user reports a bug — a crash, a wrong calculation, a feature that misbehaves — the team fixes it. This is the most visible kind of maintenance and the one people usually picture when they hear the word “maintenance.”

Adaptive maintenance is about keeping the software compatible with a changing world. Operating systems get updated, hardware changes, regulations change, and third-party services change their APIs. Adaptive maintenance makes the software work in that new environment, without adding any new features.

Perfective maintenance is about making the software better. It adds new features, improves usability, speeds up slow parts, and polishes rough edges. This is where most maintenance effort actually goes in practice, because it is driven by continuous user demand for improvement.

Preventive maintenance is about avoiding future problems. It means refactoring messy code, adding missing tests, improving documentation, and removing risky shortcuts — work that makes the software easier and safer to maintain in the future, even though it adds no user-visible value today.

Type	Purpose	Example
Corrective	Fix defects	Fix a crash on login
Adaptive	Fit a changed environment	Support a new OS version
Perfective	Add improvements	Add a dark mode
Preventive	Avoid future problems	Refactor messy code

Together, the four types explain why maintenance is the longest and costliest part of a software product’s life. Bugs always appear, environments always change, users always want more, and code always decays if left alone.

8. What is the difference between a ‘Build’ and a ‘Release’?

A build and a release are related but different things. A build is any compiled version of the code; a release is a specific build that has been approved to go to customers.

Source Code
     │
     ▼
┌──────────────┐
│    BUILD     │
│              │
│ Compile      │
│ Package      │
│ Generate     │
│ Artifact     │
└──────┬───────┘
       │
       ▼
    Testing
       │
       ▼
    Review
       │
       ▼
   Approval
       │
       ▼
┌──────────────┐
│   RELEASE    │
│              │
│ Approved     │
│ Stable       │
│ Versioned    │
│ For Users    │
└──────────────┘

A build is what you get when you compile the current source code — an executable, a package, or a deployable artifact. Teams produce builds constantly, sometimes several a day, and most of them are meant only for internal use. A build can be buggy, incomplete, or experimental; that is fine, because only developers and testers see it. Builds are usually numbered or named so the team can tell them apart.

A release is a build that has passed testing and been officially approved for distribution. It is stable, documented, and versioned — v1.0, v2.3.1, and so on — and it is what customers actually receive. Going from build to release usually involves quality gates: the build passes the test suites, gets reviewed, and is signed off before it is shipped.

The relationship is one-directional. Every release is a build, but most builds never become releases. The team might produce twenty builds in a sprint and release only one of them.

                 BUILDS
        ┌────────┬────────┬────────┐
        ▼        ▼        ▼        ▼
      Build 1  Build 2  Build 3  Build 4
                  │
                  │ passes all gates
                  ▼
               RELEASE
                 v1.0

Every Release is a Build
BUT
Not Every Build is a Release

The practical distinction matters for communication. When a developer says “I have a build,” it is not ready for users. When a product manager says “we have a release,” it is. Confusing the two causes exactly the kind of disaster where a half-tested build ends up in customers’ hands.

9. What is a ‘Burn Down Chart’ in Scrum?

A burn down chart is a simple line chart that shows how much work is left in a sprint versus how much time is left. It is the Scrum team’s quickest way to see whether they are on track to finish.

Work
Remaining
  │
100│●
   │ ╲
 80│  ╲       Ideal
   │   ╲
 60│    ╲
   │     ╲
 40│      ╲
   │       ╲
 20│        ╲
   │         ╲
  0│──────────●──────────────► Time
             Sprint End

The chart has two axes. The horizontal axis is time — the days of the sprint. The vertical axis is the amount of work remaining, usually measured in story points or hours. The chart is drawn before the sprint starts with an ideal line that runs from the total work on day one, at the top-left, down to zero on the last day, at the bottom-right. Each day during the sprint, the team plots the actual amount of work remaining and connects the points.

Reading the chart is intuitive. If the actual line sits below the ideal line, the team is ahead of schedule. If it sits above, they are behind. If it stays stubbornly high and flat, something is wrong and the team needs to adjust — either by picking up the pace, or by removing work from the sprint, or by getting a blocker resolved.

        MORE WORK
            │
            ▼
      ┌───────────┐
      │ Sprint    │
      │   Start   │
      └─────┬─────┘
            │
            ▼
       Work decreases
            │
            ▼
      ┌───────────┐
      │ Sprint    │
      │    End    │
      └─────┬─────┘
            │
            ▼
        ZERO WORK

The chart does not tell you how the work is going in terms of quality or happiness — it only tracks quantity of work remaining. But that one number is remarkably useful. It keeps everyone aligned on the sprint goal, makes delays visible within a day or two of them happening, and gives the team a constant, honest read on progress.

10. What is Software Configuration Management (SCM)?

Software Configuration Management (SCM) is the discipline of tracking and controlling every change to a project’s artifacts — code, documents, designs, builds — from start to finish. It brings order to the chaos of many people changing the same thing.

             SOFTWARE CONFIGURATION
                    MANAGEMENT
                        │
        ┌───────────────┼───────────────┐
        │               │               │
        ▼               ▼               ▼
 Version Control   Configuration    Change Control
        │           Identification       │
        │               │               │
        ▼               ▼               ▼
     Git /          What exists?      Review /
    History         Which version?    Approval
        │               │               │
        └───────────────┼───────────────┘
                        │
                        ▼
                    Baselines
                        │
                        ▼
                Release Management
                        │
                        ▼
              Known + Reproducible
                    Release

SCM covers several related activities. Version control is the most familiar: a system like Git records every change to every file, so the history is always available and anything can be rolled back. Identification means knowing exactly what the configuration items are — which documents, models, and builds belong to the project and what versions they are at. Change control means that changes are proposed, reviewed, and approved rather than made silently. Baselines are approved snapshots that later work builds on. And release management means that what ships is a known, reproducible combination of those versions.

Why does all this matter? First, collaboration. With version control, many developers can work on the same codebase without overwriting each other’s work. Second, traceability. Because every change is recorded with who made it and why, the history of any file is knowable. Third, reproducibility. Because the exact source is recorded, a release can be rebuilt exactly as it was shipped, which is essential for debugging and audits.

             MANY PEOPLE
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
      Code     Documents   Builds
        │         │         │
        └─────────┼─────────┘
                  ▼
                 SCM
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
  Collaboration Traceability Reproducibility
       │          │          │
       └──────────┼──────────┘
                  ▼
           Controlled Project

A project without SCM is a project where nobody can be sure what the “current” version of anything is, where two developers can silently destroy each other’s work, and where a production bug cannot be traced to the change that caused it. SCM is one of those unglamorous disciplines that everyone misses only when it is absent.