💻 IT & Software Viva

The four pillars of OOP are:

• Encapsulation: Bundling data (attributes) and methods that operate on the data within a single unit (class), restricting direct access to internal state via access modifiers
• Abstraction: Hiding complex implementation details and exposing only the necessary interface. Achieved through abstract classes and interfaces
• Inheritance: Creating new classes (child) that inherit properties and behaviors from existing classes (parent), enabling code reuse
• Polymorphism: Same interface, different implementations. Compile-time (method overloading) and runtime (method overriding) polymorphism

Array: Fixed size, contiguous memory, O(1) access by index, O(n) insertion/deletion. Stores primitives or objects.

LinkedList: Dynamic size, non-contiguous memory (nodes with pointers), O(n) access, O(1) insertion/deletion at known position. Better for frequent insertions.

ArrayList: Dynamic array (resizable), contiguous memory, O(1) amortized access, O(n) insertion in middle. Internally uses array with automatic resizing (typically 1.5x or 2x growth).

When to use: Array for fixed-size, performance-critical data. ArrayList for dynamic lists with frequent reads. LinkedList for frequent insertions/deletions at arbitrary positions.

Stack (LIFO — Last In First Out):

• Operations: push (add to top), pop (remove from top), peek (view top)
• Use cases: Undo/redo functionality, browser back button, function call stack, expression evaluation, DFS traversal

Queue (FIFO — First In First Out):

• Operations: enqueue (add to rear), dequeue (remove from front), peek
• Use cases: Task scheduling, print queue, BFS traversal, message queues (RabbitMQ, Kafka), request handling in web servers

Priority Queue: Elements dequeued by priority, not insertion order. Used in Dijkstra's algorithm, job scheduling.

• Bubble Sort: O(n²) average/worst, O(n) best (already sorted), stable, in-place
• Selection Sort: O(n²) all cases, not stable, in-place
• Insertion Sort: O(n²) average/worst, O(n) best, stable, in-place — good for nearly sorted data
• Merge Sort: O(n log n) all cases, stable, O(n) extra space — divide and conquer
• Quick Sort: O(n log n) average, O(n²) worst, not stable, in-place — fastest in practice
• Heap Sort: O(n log n) all cases, not stable, in-place

In practice: Most languages use Timsort (hybrid of Merge + Insertion Sort) — Python, Java's Arrays.sort for objects.

Normalization is the process of organizing database tables to minimize redundancy and dependency.

• 1NF (First Normal Form): Each column contains atomic (indivisible) values. No repeating groups. Each row is unique (has a primary key)
• 2NF (Second Normal Form): Must be in 1NF + no partial dependency. Every non-key column must depend on the entire primary key (relevant when using composite keys)
• 3NF (Third Normal Form): Must be in 2NF + no transitive dependency. Non-key columns must depend only on the primary key, not on other non-key columns

Example: If a table has Student_ID, Course_ID, Student_Name, Course_Name — Student_Name depends only on Student_ID (partial dependency). Split into separate tables.

SQL (Relational): Structured tables with rows/columns, fixed schema, ACID compliant, uses SQL queries. Examples: MySQL, PostgreSQL, Oracle, SQL Server.

NoSQL (Non-Relational): Flexible schema, various data models, horizontal scaling. Types:

• Document: MongoDB, CouchDB — JSON-like documents
• Key-Value: Redis, DynamoDB — simple key-value pairs
• Column-Family: Cassandra, HBase — columns grouped by family
• Graph: Neo4j — nodes and relationships

When to use SQL: Complex queries, transactions, data integrity. NoSQL: Flexible schemas, massive scale, real-time apps, unstructured data.

REST (Representational State Transfer) is an architectural style for designing networked applications. A RESTful API uses HTTP methods to perform CRUD operations on resources.

Key Principles:

• Client-Server: Separation of concerns — client handles UI, server handles data
• Stateless: Each request contains all information needed; server doesn't store session state
• Uniform Interface: Standard HTTP methods — GET (read), POST (create), PUT (update), DELETE (remove), PATCH (partial update)
• Resource-Based: Everything is a resource identified by URIs (e.g., /api/users/123)
• Cacheable: Responses can be cached to improve performance
• Layered System: Client doesn't know if it's talking to the server directly or through intermediaries

Session-Based:

• Server creates a session and stores it (in memory/database)
• Session ID sent to client via cookie
• Client sends cookie with every request
• Server looks up session to verify user
• Stateful — server must maintain session store

Token-Based (JWT):

• Server generates a signed token (JWT) after authentication
• Token contains user info (payload) + signature
• Client stores token (localStorage/cookie) and sends in Authorization header
• Server verifies token signature — no server-side storage needed
• Stateless — scales better for distributed systems

JWT is preferred for APIs, microservices, and mobile apps. Sessions are simpler for traditional web apps.

Monolithic: Single deployable unit containing all business logic. Shared database, single codebase. Simple to develop initially but becomes hard to scale and maintain as it grows.

Microservices: Application broken into small, independent services. Each service has its own database, can be deployed independently, communicates via APIs (REST/gRPC/message queue).

Comparison:

• Scaling: Monolith — scale entire app; Microservices — scale only the service that needs it
• Deployment: Monolith — deploy everything; Microservices — deploy individually
• Technology: Monolith — single stack; Microservices — each service can use different tech
• Complexity: Monolith — simpler; Microservices — requires orchestration, service discovery, distributed tracing

Requirements: Given a long URL, generate a short unique URL. Redirect short URL to original. Handle millions of requests.

Core Design:

• Encoding: Generate a unique 6-7 character code using Base62 (a-z, A-Z, 0-9). 62⁷ = ~3.5 trillion unique URLs
• ID Generation: Auto-incrementing counter (converted to Base62) or hash-based (MD5/SHA256 → take first 7 chars)
• Database: Store mapping (short_code → long_url, created_at, expiry). NoSQL (DynamoDB) or SQL with indexing
• Caching: Redis/Memcached for hot URLs — most URLs follow Pareto distribution (20% URLs get 80% traffic)
• Redirect: HTTP 301 (permanent) or 302 (temporary) redirect

Scale: Load balancer → multiple app servers → cache layer → database with read replicas.

Git is a distributed version control system that tracks changes in source code during development.

Common Branching Strategies:

• Git Flow: main, develop, feature/*, release/*, hotfix/* branches. Best for scheduled releases
• GitHub Flow: Simple — main branch + feature branches. PR-based workflow, continuous deployment
• Trunk-Based: All developers commit to main/trunk frequently. Feature flags for incomplete features. Best for CI/CD

Key Commands: git branch, git checkout -b, git merge, git rebase, git stash, git cherry-pick

CI (Continuous Integration): Developers frequently merge code changes into a shared repository. Each merge triggers automated builds and tests to detect issues early.

CD (Continuous Delivery/Deployment):

• Continuous Delivery: Code is always in a deployable state. Deployment to production requires manual approval
• Continuous Deployment: Every change that passes all tests is automatically deployed to production

Tools: Jenkins, GitHub Actions, GitLab CI, CircleCI, AWS CodePipeline

Benefits: Faster feedback loops, fewer integration bugs, reliable releases, reduced manual work, consistent environments.

Use the STAR method to structure your answer:

• Situation: Set the context — project, team, constraints
• Task: What specific problem needed solving?
• Action: What steps did you take? What technologies/approaches did you use?
• Result: What was the outcome? Quantify if possible (performance improved by X%, reduced load time from 5s to 1s)

Example structure: "In our e-commerce project, the product search was slow (3+ seconds for 100K products). I implemented Elasticsearch indexing with proper analyzers and caching. Search response dropped to under 200ms and user engagement increased 40%."