Software Engineering Interview Questions

SDLC (Software Development Life Cycle) is a systematic process for planning, creating, testing, and deploying software. Main phases: Planning (scope, feasibility), Requirements Analysis (gather and document needs), Design (architecture, system design), Development (coding), Testing (verify functionality), Deployment (release to production), Maintenance (updates, bug fixes). Different methodologies (Waterfall, Agile) implement these phases differently.

Waterfall is a sequential, linear approach where each phase must complete before the next begins - good for stable requirements but inflexible to change. Agile is iterative, delivering working software in short cycles (sprints), embracing changing requirements, and emphasizing collaboration. Waterfall: extensive documentation, big upfront design. Agile: continuous delivery, adaptability, customer feedback. Most modern software development uses Agile or hybrid approaches.

Unit testing verifies individual components (functions, methods, classes) work correctly in isolation. Tests are automated, fast, and repeatable. Importance: catches bugs early (cheaper to fix), documents expected behavior, enables safe refactoring, supports continuous integration. Good unit tests are: fast, isolated, repeatable, self-validating, timely (written with code). Frameworks: JUnit (Java), pytest (Python), Jest (JavaScript). Aim for high coverage of critical code paths.

Git is a distributed version control system tracking changes in source code. Basic operations: git init (create repo), git clone (copy repo), git add (stage changes), git commit (save changes), git push (upload to remote), git pull (download changes), git branch (create branch), git merge (combine branches), git checkout/switch (change branches). Git enables: collaboration, history tracking, branching for features, reverting changes. GitHub/GitLab provide remote hosting.

Design patterns are reusable solutions to common software design problems. They provide proven templates, not code, that can be adapted to specific situations. Categories: Creational (object creation - Singleton, Factory), Structural (object composition - Adapter, Decorator), Behavioral (object interaction - Observer, Strategy). Benefits: shared vocabulary, proven solutions, code maintainability, easier communication among developers. Popularized by the Gang of Four (GoF) book.

SOLID is five principles for maintainable OOP code: Single Responsibility (class has one reason to change), Open/Closed (open for extension, closed for modification), Liskov Substitution (subtypes must be substitutable for base types), Interface Segregation (many specific interfaces over one general), Dependency Inversion (depend on abstractions, not concretions). Following SOLID leads to code that's easier to understand, test, and modify.

Code review is systematic examination of code changes by peers before merging. Benefits: catches bugs early, improves code quality, shares knowledge across team, enforces coding standards, mentors junior developers. Best practices: keep reviews small (<400 lines), review promptly, focus on code not person, use checklists, automate style checking. Tools: GitHub Pull Requests, GitLab Merge Requests, Gerrit. Reviews should be constructive and aim for continuous improvement.

Scrum is an Agile framework for managing work in fixed-length iterations (sprints, usually 2-4 weeks). Key roles: Product Owner (defines what to build), Scrum Master (facilitates process), Development Team (builds product). Key events: Sprint Planning, Daily Standup, Sprint Review, Retrospective. Artifacts: Product Backlog, Sprint Backlog, Increment. Sprint delivers potentially shippable increment. Emphasizes self-organization, transparency, and continuous improvement.

Singleton ensures a class has only one instance and provides global access to it. Implementation: private constructor, static method returning the single instance. Use cases: configuration managers, connection pools, loggers. Criticisms: global state, makes testing difficult, hides dependencies. Modern alternatives: dependency injection for managing single instances. If using Singleton, consider thread-safety (double-checked locking, static initialization). Use sparingly and prefer dependency injection.

CI (Continuous Integration) is automatically building and testing code when changes are committed, catching integration issues early. CD (Continuous Delivery/Deployment) automates releasing changes to staging/production. Delivery requires manual approval; Deployment is fully automated. Benefits: faster feedback, reduced risk, consistent releases, smaller changes are easier to debug. Tools: Jenkins, GitHub Actions, GitLab CI, CircleCI. CI/CD pipeline typically includes: build, test, security scan, deploy.

The testing pyramid suggests a distribution of test types: Unit tests (base, most numerous) - fast, isolated, test individual components. Integration tests (middle) - test component interactions, databases, APIs. E2E/UI tests (top, fewest) - test complete user flows, slowest and most brittle. More unit tests because they're fast and cheap; fewer E2E tests because they're slow and expensive. Some prefer testing trophy or honeycomb shapes for different contexts.

Git Flow: main (production), develop, feature branches, release branches, hotfix branches - structured but complex. GitHub Flow: main + feature branches, deploy from main - simpler, good for continuous deployment. Trunk-Based: everyone commits to main frequently, feature flags for incomplete work - favors CI/CD. GitLab Flow: environment branches (production, staging) - adds deployment tracking. Choose based on team size, release frequency, and deployment model.

DRY (Don't Repeat Yourself) states that every piece of knowledge should have a single, unambiguous representation in the system. Avoid duplicating code, logic, or data - extract common functionality into functions, classes, or modules. Benefits: easier maintenance (change in one place), fewer bugs (no inconsistent copies), smaller codebase. Counter: YAGNI (don't over-engineer abstractions). WET (Write Everything Twice) is anti-pattern. Balance DRY with readability and simplicity.

MVC (Model-View-Controller) separates application into three components: Model (data and business logic), View (user interface and presentation), Controller (handles input and updates model/view). Benefits: separation of concerns, parallel development, easier testing, reusability. Widely used in web frameworks: Rails, Django, Spring MVC. Variations: MVP (Presenter replaces Controller), MVVM (ViewModel for data binding). MVC helps organize code and separate UI from business logic.

Technical debt is the implied cost of additional rework caused by choosing quick solutions over better approaches. Types: deliberate (consciously taking shortcuts), accidental (unknowingly making poor choices), bit rot (outdated dependencies, practices). Management: track in backlog, allocate time each sprint (20% rule), refactor incrementally, prevent with code reviews and standards. Like financial debt, it accumulates interest - small debts become large problems. Balance speed with maintainability.

Factory patterns encapsulate object creation. Simple Factory: static method creates objects (not a GoF pattern). Factory Method: subclasses decide which class to instantiate. Abstract Factory: creates families of related objects without specifying classes. Benefits: decouples client from concrete classes, follows Open/Closed principle, supports dependency injection. Use when: object creation is complex, type determined at runtime, hiding implementation details. Common in frameworks for creating service instances.

TDD writes tests before implementation following Red-Green-Refactor cycle: Red (write failing test), Green (write minimal code to pass), Refactor (improve code while keeping tests green). Benefits: ensures testability, drives simple design, documents behavior, prevents over-engineering, catches regressions. Challenges: initial slowdown, learning curve, testing external dependencies. BDD (Behavior-Driven Development) extends TDD with business-readable specifications. TDD works best for logic-heavy code; balance with pragmatism.

Dependency Injection provides dependencies to objects rather than having objects create them. Types: Constructor injection (dependencies in constructor), Setter injection (via setter methods), Interface injection (dependency provides injector method). Benefits: loose coupling, easier testing (mock dependencies), follows Dependency Inversion Principle, supports configuration over code. Frameworks: Spring (Java), .NET Core DI, Angular, Guice. Container manages object lifecycle. DI enables modular, testable, maintainable code.

Observer pattern defines one-to-many dependency where subject notifies observers of state changes. Components: Subject (maintains observers, sends notifications), Observer (interface with update method), ConcreteObservers (implement reaction to changes). Use cases: event handling, MVC (model notifies views), pub/sub systems, reactive programming. Push vs Pull: subject sends data or observers query subject. Modern implementations: RxJS, event emitters, message queues. Avoid memory leaks by properly unsubscribing.

Merge creates a merge commit combining branches, preserving complete history - non-destructive, shows when branches merged. Rebase rewrites history by replaying commits on top of another branch - creates linear history, cleaner log. Use merge: shared branches (main), preserving history matters. Use rebase: cleaning up local commits before merge, maintaining linear history for feature branches. Golden rule: never rebase public branches. Interactive rebase allows squashing, reordering commits.

Code smells indicate potential problems: Long Method (extract methods), Large Class (split responsibilities), Duplicated Code (extract common code), Long Parameter List (introduce parameter object), Feature Envy (move method to appropriate class), Data Clumps (create class for related data), Primitive Obsession (create value objects), Divergent Change (separate concerns), Shotgun Surgery (consolidate related changes). Address through refactoring. Use static analysis tools (SonarQube, ESLint) to detect smells automatically.

Mocking creates fake objects that simulate real dependencies for isolated testing. Types: Mock (verifies interactions), Stub (returns predefined responses), Spy (wraps real object, records calls), Fake (simplified working implementation). Use mocking for: external services (APIs, databases), slow operations, non-deterministic behavior. Avoid: over-mocking leading to brittle tests, mocking what you don't own (use adapters). Frameworks: Mockito (Java), pytest-mock, Jest mocks. Balance isolation with integration testing.

Strategy pattern defines a family of algorithms, encapsulating each one and making them interchangeable. Context holds reference to strategy interface; concrete strategies implement algorithm variations. Examples: payment processing (CreditCard, PayPal, Crypto strategies), sorting algorithms, validation rules, shipping calculators. Benefits: eliminates conditional statements, follows Open/Closed principle, supports runtime algorithm switching. Often combined with Factory to create strategies. Similar to State pattern but for algorithms, not state transitions.

Monolith: single deployable unit, shared database, simpler to develop/deploy initially, tighter coupling. Microservices: independent services, own databases, deployed separately, communicate via APIs. Microservices benefits: independent scaling, technology diversity, fault isolation, team autonomy. Microservices challenges: distributed complexity, data consistency, operational overhead, network latency. Start monolith, extract services when needed. Consider: team size, domain complexity, scaling needs. Microservices require mature DevOps practices.

Retrospective reflects on sprint to improve processes. Effective elements: psychological safety (blameless), focus on actionable items (specific improvements), limit action items (2-3 per sprint), assign owners, track follow-through. Formats: Start/Stop/Continue, Mad/Sad/Glad, sailboat (wind, anchors, rocks). Anti-patterns: blame individuals, no action items, same issues recurring, senior dominance. Outcomes: identified improvements, assigned actions, team bonding. Most important Scrum event for continuous improvement.

Decorator pattern attaches additional responsibilities to objects dynamically without modifying original class. Wraps objects with decorator classes implementing same interface. Examples: Java I/O streams (BufferedReader wrapping FileReader), adding logging/caching to services, UI component borders/scrollbars. Benefits: more flexible than inheritance, follows Single Responsibility, supports Open/Closed principle. Multiple decorators can be stacked. Different from inheritance - decoration is at runtime, inheritance at compile time.

Pipeline stages: 1) Source (trigger on commit/PR), 2) Build (compile, install dependencies, build artifacts), 3) Unit Tests (fast, parallel), 4) Static Analysis (linting, security scan, code quality), 5) Integration Tests (with test databases), 6) Build Container Image, 7) Deploy to Staging (automatic), 8) E2E Tests, 9) Manual Approval (for production), 10) Deploy to Production (with health checks), 11) Smoke Tests. Include rollback mechanism. Use caching for speed. Parallelize where possible. Fail fast principle.

Versioning strategies: URL path (/api/v1/users - most common, clear), Query parameter (/api/users?version=1), Custom header (Accept-Version: 1), Content negotiation (Accept: application/vnd.api.v1+json - RESTful). Considerations: breaking vs non-breaking changes, deprecation policy, documentation, backward compatibility period. Best practices: version major changes only, support N-1 version minimum, communicate deprecation early, use semantic versioning. GraphQL often avoids versioning through additive changes.

Integration tests verify component interactions. Best practices: use test databases (Docker containers), reset state between tests (transactions or cleanup), test real dependencies when feasible, mock external services (WireMock, VCR), use meaningful test data, separate from unit tests, run in CI pipeline. Test database interactions, API contracts, message queues. Balance with unit tests - slower but catch integration issues. Consider contract testing (Pact) for microservices.

Scrum: fixed sprints, defined roles (PO, SM, Team), ceremonies (planning, standup, review, retro), commitment to sprint backlog. Kanban: continuous flow, no fixed iterations, limit work-in-progress (WIP), pull-based, focus on cycle time. Scrum suits: teams needing structure, predictable delivery cycles. Kanban suits: support/ops teams, variable workloads, continuous delivery. Many teams use Scrumban hybrid. Both emphasize: visualization, limiting WIP, continuous improvement. Choose based on work nature and team maturity.

Feature flags (toggles) control feature availability without deploying new code. Types: Release (gradual rollout), Experiment (A/B testing), Ops (circuit breakers), Permission (user-specific features). Benefits: decouple deployment from release, trunk-based development, quick rollback, progressive rollout. Management: use feature flag service (LaunchDarkly, Unleash), clean up old flags, document flags, test both states. Challenges: code complexity, testing combinations, stale flags. Essential for continuous deployment.

Repository pattern abstracts data access, providing collection-like interface for domain objects. Acts as in-memory collection while hiding database details. Methods: findById, findAll, save, delete. Benefits: decouples domain from persistence, enables testing with mock repositories, supports swapping storage implementations, centralizes query logic. Often combined with Unit of Work (transaction management). ORMs like Spring Data, Django ORM implement repository concepts. Avoid: repository returning DTOs, business logic in repositories.

Twelve-Factor App principles for SaaS: 1) Codebase (one repo per app), 2) Dependencies (explicitly declared), 3) Config (in environment), 4) Backing services (treat as attached resources), 5) Build/release/run (strict separation), 6) Processes (stateless, share-nothing), 7) Port binding (self-contained), 8) Concurrency (scale via processes), 9) Disposability (fast startup/shutdown), 10) Dev/prod parity, 11) Logs (as event streams), 12) Admin processes (one-off tasks). Foundation for cloud-native applications.

Static analysis examines code without executing it. Categories: Linters (style, syntax - ESLint, Pylint), Type checkers (TypeScript, mypy), Security scanners (Snyk, SonarQube, Semgrep), Complexity analyzers (cyclomatic complexity), Dependency checkers (npm audit, OWASP). Benefits: catch bugs early, enforce standards, security vulnerabilities, code consistency. Integration: pre-commit hooks, CI pipeline. Configure rules appropriately - too strict causes noise. SonarQube provides comprehensive dashboard. Address critical issues; track trends over time.

Adapter pattern allows incompatible interfaces to work together by wrapping one interface to match another. Like power plug adapters. Examples: wrapping legacy API to match new interface, adapting third-party libraries, database driver adapters (JDBC). Class adapter uses inheritance; object adapter uses composition (preferred). Benefits: reuse existing code, integrate incompatible systems, follows Single Responsibility. Different from Facade (simplifies) and Decorator (adds behavior). Common in integrations and migrations.

DDD focuses on complex domains, aligning code with business. Strategic patterns: Bounded Context (explicit boundaries around models), Ubiquitous Language (shared vocabulary), Context Mapping (relationships between contexts). Tactical patterns: Entities (identity), Value Objects (immutable, equality by value), Aggregates (consistency boundary), Domain Events, Repositories, Domain Services. Apply to complex domains with significant business logic. Overkill for CRUD apps. Requires domain expert collaboration. Often combined with hexagonal architecture.

Event Sourcing stores state changes as sequence of events rather than current state - events are immutable, append-only. Rebuild state by replaying events. Benefits: complete audit trail, temporal queries, debugging. CQRS (Command Query Responsibility Segregation) separates read (query) and write (command) models. Often combined: commands produce events, events update read models. Challenges: eventual consistency, event schema evolution, complexity. Use for: audit requirements, complex domains, high-scale reads. Consider Event Store, Kafka for implementation.

Chaos Engineering proactively tests system resilience by introducing controlled failures. Process: define steady state, hypothesize impact, run experiment, measure, learn. Principles: start small (staging), minimize blast radius, automate experiments, run in production (carefully). Tools: Chaos Monkey (random instance termination), Gremlin (comprehensive platform), Litmus (Kubernetes), ToxiProxy (network failures). Examples: kill instances, inject latency, simulate region failure. Requires mature observability. Document runbooks from learnings. Game days formalize chaos experiments.

Hexagonal Architecture isolates core business logic from external concerns. Core domain sits at center. Ports define interfaces (incoming: use cases; outgoing: repositories, services). Adapters implement ports for specific technologies (REST adapter, database adapter). Dependencies point inward - domain knows nothing about adapters. Benefits: technology-agnostic core, testable (mock adapters), replaceable infrastructure. Similar: Clean Architecture, Onion Architecture. Structure: application (core), domain, infrastructure (adapters). Prevents framework lock-in.

Mutation testing evaluates test quality by introducing small code changes (mutants) and checking if tests detect them. Mutations: change operators (> to >=), negate conditions, remove statements. Killed mutant: tests fail (good). Surviving mutant: tests pass despite bug (weak test). Mutation score = killed/total. Tools: PIT (Java), mutmut (Python), Stryker (JS). Higher mutation score indicates more thorough tests. Challenges: slow execution, equivalent mutants (semantically same). Use for critical code paths.

Visitor pattern separates algorithms from object structures, allowing new operations without modifying classes. Elements accept visitor; visitor implements operation for each element type. Double dispatch: element type determines method, visitor provides implementation. Use cases: compilers (AST operations), document processing, reporting across hierarchies. Benefits: add operations easily, gather related operations. Drawbacks: hard to add element types, breaks encapsulation. Consider pattern matching in modern languages as alternative. Often used with Composite pattern.

Contract testing verifies service integrations by testing against agreed contracts. Consumer-Driven Contracts (CDC): consumers define expectations, providers verify they meet them. Tools: Pact (most popular), Spring Cloud Contract. Process: consumer writes contract, generates mock for consumer tests, provider runs contract tests. Benefits: fast feedback, avoids end-to-end tests, detects breaking changes early. Challenges: contract evolution, multiple consumers. Compare to: integration tests (slower, environment-dependent), schema validation (less complete). Essential for microservices.

Saga manages distributed transactions as sequence of local transactions with compensating actions for rollback. Coordination: Choreography (events trigger next steps - simple but harder to track), Orchestration (central coordinator directs flow - explicit but single point). Design: each step has compensating action, handle idempotency, manage concurrent sagas. Challenges: compensation complexity, observability, testing. Implementations: Temporal, Camunda, custom with message queues. Example: order saga - reserve inventory, charge payment, ship; each with compensating action. Critical for microservices without distributed transactions.

GitOps uses Git as single source of truth for declarative infrastructure and applications. Principles: declarative configuration, versioned and immutable, automatically applied, continuously reconciled. Operators (ArgoCD, Flux) watch Git repos and sync cluster state. Differs from push-based CI/CD: GitOps is pull-based (operator pulls changes), cluster state always matches Git. Benefits: audit trail, easy rollback (git revert), security (no direct cluster access from CI). Challenges: secret management, multi-cluster. Ideal for Kubernetes deployments.

Specification pattern encapsulates business rules as composable, reusable objects. Each specification has isSatisfiedBy(candidate) method. Specifications can be combined: AND (both must pass), OR (either passes), NOT (negation). Use cases: validation, querying (translate to SQL/NoSQL), eligibility checks. Benefits: reusable rules, testable in isolation, combinable for complex logic. Example: EligibleForDiscount = PremiumMember AND HasPurchasedRecently. Often combined with Repository for queries. Implementation: composite pattern for combinations.

Quantification methods: effort estimation (hours to fix), cost of delay (impact if not fixed), code metrics (complexity, coverage, duplication), interest (ongoing cost of not fixing). Frameworks: Technical Debt Ratio (remediation cost / development cost), SQALE. Track: in issue tracker with labels, technical debt register. Prioritize: high interest (constant pain), blocking business features, security debt (immediate). Process: regular review meetings, allocate sprint capacity (20%), address during related feature work. Tools: SonarQube, CodeScene for visualization. Balance with feature delivery.

Modular monolith is single deployment with well-defined module boundaries - combines monolith simplicity with microservices-like modularity. Modules: own domain, internal data, explicit APIs, can be extracted to services later. Benefits: simple deployment, no distributed system complexity, easier refactoring, enforced boundaries prepare for microservices. Implementation: Maven/Gradle modules, package structure with ArchUnit enforcement, separate databases per module. Appropriate: smaller teams, unclear boundaries, starting new project. Netflix and Shopify advocate this approach before microservices.

Property-based testing generates random inputs and verifies properties hold for all inputs, rather than testing specific examples. Properties: invariants, round-trip (encode-decode), oracle (compare implementations), inductive (recursive properties). Tools: QuickCheck (Haskell), Hypothesis (Python), jqwik (Java), fast-check (JS). Benefits: finds edge cases, more thorough coverage, reveals assumptions. Challenges: defining good properties, debugging failures (shrinking helps). Use for: parsers, serialization, algorithms, mathematical properties. Complements example-based tests.

Semantic versioning (SemVer): MAJOR.MINOR.PATCH. MAJOR: breaking changes. MINOR: backward-compatible features. PATCH: backward-compatible fixes. Breaking changes: removed APIs, changed signatures, changed behavior. Process: document changes in CHANGELOG, tag releases, use pre-release versions (1.0.0-alpha), protect main branch. API evolution: deprecate before removal, version APIs, provide migration guides. Tools: semantic-release (auto-versioning from commits), conventional commits. Consider: API stability promise, dependency management implications. Clear versioning builds user trust.

ADRs document significant architectural decisions with context and consequences. Format: Title, Status, Context, Decision, Consequences. Store in repo (docs/architecture/decisions). Benefits: capture rationale, onboard new members, prevent re-debates, track evolution. When to write: technology choices, design patterns, trade-offs, team conventions. Keep: concise, linked to code/PRs, reviewed. Tools: adr-tools (templating), lightweight text files. Anti-patterns: documenting everything, not updating status. ADRs create organizational memory for why decisions were made.