Question 1

What is SDLC, and how do the Waterfall, Spiral, and Agile models differ?

Accepted Answer

The Software Development Life Cycle (SDLC) is a structured process used to design, develop, test, and deploy high-quality software. Phases: Planning → Requirements → Design → Coding → Testing → Deployment → Maintenance. Waterfall: Linear and sequential; every phase must finish before the next begins. Best for small projects with fixed requirements. Spiral: Risk-driven and iterative; combines prototyping with systematic waterfall stages. Used in high-risk, large-scale mission-critical systems. Agile: Incremental and iterative; delivers working software in short cycles (Sprints) with continuous customer feedback. Standard across modern IT companies (TCS, Infosys, Accenture, Cognizant, Capgemini, and product firms).

Question 2

What is the difference between Agile and Scrum? Explain the four Scrum ceremonies.

Accepted Answer

Agile: A broad philosophy and mindset based on iterative development and customer collaboration. Scrum: A specific framework used to implement Agile. Sprint Planning: Defines what can be delivered in the upcoming Sprint (usually 2 weeks) and how the work will be achieved. Daily Stand-up (Daily Scrum): A 15-minute sync covering what was done yesterday, what is planned for today, and any blockers. Sprint Review: Held at the end of the Sprint to demo the working feature increment to stakeholders. Sprint Retrospective: Team reflection on what went well, what went wrong, and how to improve processes in the next Sprint.

Question 3

What is an SRS document, and how do Functional Requirements differ from Non-Functional Requirements (NFRs)?

Accepted Answer

Software Requirements Specification (SRS): A formal blueprint detailing how a software system is expected to perform. Functional Requirements: Specify what the system should do (e.g., "Users must be able to log in via OTP or Google OAuth"). Non-Functional Requirements (NFRs): Specify how the system performs under constraints (e.g., "API response latency must be under 200ms for 10,000 concurrent users"), covering scalability, security, availability, and maintainability.

Question 4

Differentiate between PoC (Proof of Concept), Prototype, and MVP (Minimum Viable Product).

Accepted Answer

PoC: A small internal technical experiment to verify if an idea or integration is technically feasible (not shown to end-users). Prototype: A visual or interactive mockup (e.g., Figma wireframe or clickable UI) used to validate UX flow and gather early feedback before heavy coding. MVP: The first deployable version of the product containing just enough core features to solve the primary problem for early adopters and collect real-world usage data.

Question 5

How is software effort estimated using Agile Story Points versus the traditional COCOMO model?

Accepted Answer

COCOMO (Constructive Cost Model): An algorithmic B.Tech syllabus model that estimates effort and time based on predicted KLOC (Thousands of Lines of Code) across Organic, Semi-Detached, and Embedded project types. Story Points (Modern Standard): A relative unit in Agile (often Fibonacci: 1, 2, 3, 5, 8, 13) that estimates effort based on complexity, uncertainty, and volume of work rather than raw hours.

Question 6

What are Cohesion and Coupling? Why do we aim for "High Cohesion and Low Coupling"?

Accepted Answer

Cohesion: Measures how strongly related and focused the responsibilities of a single module or class are. Coupling: Measures the degree of interdependence between different modules. Why it matters: High Cohesion ensures a module does one job well (easier to understand and test), while Low Coupling ensures changes in one module do not break other parts of the codebase.

Question 7

What are the SOLID, DRY, KISS, and YAGNI principles in software engineering?

Accepted Answer

SOLID: Five OOP design principles — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. DRY (Don't Repeat Yourself): Avoid duplicating logic; abstract shared code into reusable functions or modules. KISS (Keep It Simple, Stupid): Prefer simple, readable implementations over over-engineered code. YAGNI (You Aren't Gonna Need It): Do not build features or abstractions until they are actually required.

Question 8

Compare Monolithic and Microservices architectures. When shouldn't you use Microservices?

Accepted Answer

Monolith: The entire application (UI, business logic, data access) is built and deployed as a single unified unit. Microservices: The application is split into independent, loosely coupled services that communicate via APIs or message queues, each with its own database. When to avoid Microservices: Early-stage startups or small teams should start with a Modular Monolith because microservices introduce heavy operational overhead (distributed tracing, network latency, eventual consistency, and complex DevOps).

Question 9

What makes an API truly RESTful, and what does Idempotency mean in HTTP methods?

Accepted Answer

A RESTful API follows stateless client-server communication, standard HTTP methods, resource-based URLs, and uniform interfaces. Idempotency: Making the same API request multiple times produces the exact same server state as making it once. GET, PUT, and DELETE are idempotent (updating a user's name to "Rahul" 5 times via PUT results in the same state). POST is not idempotent (calling POST /orders 5 times creates 5 separate orders).

Question 10

What is Technical Debt, and how do engineering teams manage it through Refactoring?

Accepted Answer

Technical Debt: The implied cost of future rework caused by choosing a quick, suboptimal coding shortcut today instead of a cleaner design that takes longer. Refactoring: Restructuring internal code to improve readability, modularity, and performance without changing external behavior, safely backed by automated unit tests.

Question 11

What is the difference between Verification and Validation (V&V)?

Accepted Answer

Verification ("Are we building the product right?"): Static evaluation of documents, design, and code without executing the program (e.g., code reviews, walkthroughs, static analysis). Validation ("Are we building the right product?"): Dynamic testing where the actual software is executed to verify it meets customer expectations (e.g., unit, integration, and user acceptance testing).

Question 12

Explain the Testing Pyramid: Unit, Integration, and End-to-End (E2E) Testing.

Accepted Answer

Unit Testing (Base ~70%): Tests individual functions or methods in isolation using mocks/stubs (e.g., Jest, JUnit). Fast and cheap. Integration Testing (Middle ~20%): Tests how multiple modules, databases, and external APIs work together. E2E Testing (Top ~10%): Simulates real user scenarios across the full browser/UI and backend stack (e.g., Playwright, Cypress). Slowest and most brittle.

Question 13

Differentiate between Black-Box and White-Box Testing. What is Cyclomatic Complexity?

Accepted Answer

Black-Box Testing: Tests functionality based on inputs and expected outputs without knowing internal code structure (e.g., Boundary Value Analysis, Equivalence Partitioning). White-Box Testing: Tests internal logic, branches, and code paths with full knowledge of the source code. Cyclomatic Complexity: A white-box metric for the number of linearly independent paths through a program's control flow graph: V(G) = E − N + 2P (E = edges, N = nodes, P = connected components), or simply number of predicate/decision nodes + 1.

Question 14

What is the difference between Smoke Testing, Sanity Testing, Regression Testing, and Alpha/Beta Testing?

Accepted Answer

Smoke Testing: Quick, broad check on a new build to ensure critical functionalities work before deep testing begins (Build Verification Testing). Sanity Testing: Narrow, deep check on a specific module after a minor bug fix or code change. Regression Testing: Re-running existing test suites to ensure newly added code has not broken existing features. Alpha vs. Beta: Alpha is done internally by developers/QA in a lab environment; Beta is done by real end-users in a production-like environment before general release.

Question 15

What is Test-Driven Development (TDD) and "Shift-Left Testing"?

Accepted Answer

TDD: Development practice following Red → Green → Refactor — write a failing automated test first (Red), write the minimum code to pass (Green), then clean up the code (Refactor). Shift-Left Testing: Moving testing, security checks (DevSecOps), and linting to the earliest stages of the SDLC (IDE and PR pipeline) rather than waiting until after deployment.

Question 16

In Git, what is the difference between git merge and git rebase? How do you handle merge conflicts?

Accepted Answer

git merge: Combines branches by creating a new merge commit, preserving the exact historical timeline of both branches. git rebase: Replays your feature branch commits on top of the latest main commit, creating a clean, linear commit history. Handling Conflicts: Occurs when two branches modify the same lines. Pull the target branch, manually edit conflict markers (<<<<<<<, =======, >>>>>>>), run tests, stage the resolved file, and commit (or continue rebase).

Question 17

Explain CI/CD. How does Continuous Delivery differ from Continuous Deployment?

Accepted Answer

Continuous Integration (CI): Developers frequently merge code into a shared repository, where automated builds, linters, and unit tests run on every Pull Request (e.g., GitHub Actions). Continuous Delivery: Code that passes CI is automatically packaged and deployed to staging, requiring a manual approval to push to production. Continuous Deployment: Every change that passes all automated pipeline stages goes straight to live production without human intervention.

Question 18

What are the 4 types of Software Maintenance, and what is Software Re-engineering?

Accepted Answer

Corrective: Fixing bugs and defects discovered by users in production. Adaptive: Updating software to run in a new environment (e.g., OS upgrade, cloud migration, new payment gateway compliance). Perfective: Enhancing performance, UI, or adding minor user-requested features. Preventive: Refactoring legacy code to prevent future bugs and improve maintainability. Software Re-engineering: Rebuilding or modernizing legacy software (often via Reverse Engineering → Restructuring → Forward Engineering) without changing its core business purpose.

Question 19

What is Semantic Versioning (MAJOR.MINOR.PATCH) in software releases?

Accepted Answer

A universal versioning scheme formatted as X.Y.Z (e.g., v2.4.1): MAJOR (2): Incremented when making incompatible API changes (breaking changes). MINOR (4): Incremented when adding backward-compatible new features. PATCH (1): Incremented when making backward-compatible bug fixes or security patches.

Question 20

What do interviewers look for regarding Code Reviews and using AI Coding Assistants responsibly?

Accepted Answer

Companies expect engineers to use AI tools for velocity while maintaining strict ownership over every line committed. During code reviews, engineers check for: Edge Cases & Logic Flaws: Ensuring AI-generated code does not fail silently on null/boundary inputs or use deprecated library methods. Security Vulnerabilities: Checking for hardcoded secrets, SQL injection, improper authentication checks, or vulnerable dependencies. Maintainability & Performance: Avoiding N+1 database queries, memory leaks, and bloated code that violates the project's existing architecture.

All questions & answers

All questions & answers