Software Engineering Quick Reference

SOLID Principles

• Single Responsibility Principle (SRP): a class should have only one reason to change.
• Open/Closed Principle (OCP): software entities should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP): subtypes must be substitutable for their base types without breaking correctness.
• Interface Segregation Principle (ISP): clients should not be forced to depend on interfaces they don't use.
• Dependency Inversion Principle (DIP): depend on abstractions, not on concrete implementations.

GoF Pattern Categories

• Creational — concerned with object creation: Singleton, Factory Method, Abstract Factory, Builder, Prototype.
• Structural — concerned with composing classes and objects: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.
• Behavioral — concerned with communication between objects: Observer, Strategy, Command, Iterator, Template Method, State, Chain of Responsibility, Mediator, Memento, Visitor, Interpreter.

SDLC Models

• Waterfall: sequential phases (requirements, design, implementation, verification, maintenance), each completed before the next begins.
• Agile: iterative, incremental delivery in short cycles with continuous stakeholder feedback (e.g., Scrum, Kanban).
• Iterative model: builds the system through repeated cycles, refining a working version each time.
• Spiral model: combines iterative development with explicit risk analysis at each cycle.
• V-Model: a Waterfall variant that pairs each development phase with a corresponding testing phase.
• RAD (Rapid Application Development): emphasizes fast prototyping and user feedback over rigid planning.

Testing Pyramid Layers

• Unit tests (base, most numerous): test a single function or class in isolation; fast and cheap to run.
• Integration tests (middle): verify that multiple real components work correctly together, such as a service and a database.
• End-to-end / UI tests (top, fewest): exercise the whole system through its real interface; slower, more brittle, but highest fidelity to real user behavior.

Test Double Types

• Dummy: passed around to satisfy a parameter list but never actually used.
• Fake: a working but simplified implementation, such as an in-memory database standing in for a real one.
• Stub: returns predefined, canned answers to calls made during the test.
• Spy: a stub that also records information about how it was called, so the test can assert on that later.
• Mock: pre-programmed with expectations about the calls it should receive, and the test fails if those expectations aren't met.

OOP Core Concepts

• Encapsulation: bundling data and the methods that operate on it, hiding internal state behind a public interface.
• Inheritance: a class acquiring properties and behavior from a parent class, enabling reuse and hierarchy.
• Polymorphism: objects of different types responding to the same interface or method call in type-specific ways.
• Abstraction: exposing only essential behavior through an interface while hiding implementation complexity.

Git & CI/CD Essentials

• Feature branch: a short-lived branch created off main/trunk to develop a single feature or fix in isolation.
• Pull request (PR): a request to merge a branch, reviewed by teammates before it's accepted.
• Continuous Integration (CI): automatically building and testing every change as it's merged.
• Continuous Delivery/Deployment (CD): automatically preparing (delivery) or directly releasing (deployment) every change that passes CI.

• SOLID (SRP, OCP, LSP, ISP, DIP) and the three GoF pattern categories (Creational, Structural, Behavioral) are the most commonly tested vocabulary in software engineering interviews.
• The testing pyramid favors many fast unit tests, fewer integration tests, and the fewest end-to-end tests.
• Test doubles (Dummy, Fake, Stub, Spy, Mock) each serve a distinct, non-interchangeable purpose in isolating code under test.
• SDLC model choice should match project risk and requirement volatility, not personal preference alone.