👨‍💻 Software Engineer Viva

Monolithic: Single deployable unit containing all application logic — UI, business logic, data access in one codebase.

Microservices: Application decomposed into small, independent services, each running its own process and communicating via APIs.

Comparison:

• Deployment: Monolith = deploy everything together; Microservices = deploy independently
• Scaling: Monolith = scale entire app; Microservices = scale individual services
• Technology: Monolith = one tech stack; Microservices = polyglot (different languages/databases per service)
• Complexity: Monolith = simpler initially; Microservices = operational complexity (networking, monitoring, orchestration)
• Team Structure: Monolith = one team; Microservices = small autonomous teams per service

When to use Microservices: Large teams, complex domains, need for independent deployments, high scalability requirements. Not for small projects or small teams.

Requirements: Given a long URL, generate a short URL; when short URL is accessed, redirect to original.

Core Design:

• Short URL Generation: Base62 encoding (a-z, A-Z, 0-9) of a unique ID. 7 characters = 62^7 = 3.5 trillion unique URLs
• Database: store mapping {short_code → long_url, created_at, expiry, user_id}
• API: POST /shorten {url} → returns short URL; GET /{code} → 301 redirect

Architecture:

• Load Balancer: Distributes traffic across application servers
• Application Server: Handles URL creation and redirect logic
• Cache (Redis): Cache popular short URLs for fast lookups (~80% hit rate)
• Database (NoSQL): DynamoDB or Cassandra for high write throughput
• ID Generator: Distributed ID generation — Twitter Snowflake or pre-generated ID ranges

Scale Estimates (1B URLs/month): ~400 writes/sec, ~40K reads/sec (100:1 read-write ratio). Need horizontal scaling, database sharding, CDN for global access.

REST (Representational State Transfer) is an architectural style for designing networked applications using HTTP.

Key Principles:

• Stateless: Each request contains all information needed — server doesn't store session state
• Resource-based: Everything is a resource identified by URI (e.g., /users/123)
• HTTP Methods: GET (read), POST (create), PUT (full update), PATCH (partial update), DELETE (remove)
• Uniform Interface: Consistent URL patterns and response formats
• Representations: Resources returned as JSON/XML

Best Practices:

• Use nouns for URLs: /users not /getUsers
• Use HTTP status codes: 200 (OK), 201 (Created), 400 (Bad Request), 404 (Not Found), 500 (Server Error)
• Versioning: /api/v1/users
• Pagination: /users?page=2&limit=20
• Filtering: /users?role=admin&status=active

REST vs GraphQL: REST has multiple endpoints per resource; GraphQL has one endpoint with flexible queries.

• S — Single Responsibility: A class should have one reason to change. Don't put email sending logic in a User class — create a separate EmailService
• O — Open/Closed: Open for extension, closed for modification. Use interfaces/abstract classes so new behavior can be added without changing existing code
• L — Liskov Substitution: Subtypes must be substitutable for their base types. If Square extends Rectangle, it shouldn't break when used as a Rectangle
• I — Interface Segregation: Many specific interfaces are better than one general interface. Don't force a Bird class to implement swim() if only Duck needs it
• D — Dependency Inversion: Depend on abstractions, not concretions. A NotificationService should depend on an IMessageSender interface, not directly on SmsSender

Why SOLID matters: Produces maintainable, testable, flexible code. Reduces coupling, increases cohesion.

Design patterns are reusable solutions to common software design problems (Gang of Four — 23 patterns).

1. Singleton (Creational):

• Ensures only one instance of a class exists globally
• Use case: Database connection pool, configuration manager, logger
• Implementation: Private constructor, static instance method
• Caution: Can make testing difficult; avoid overuse

2. Observer (Behavioral):

• Defines one-to-many dependency — when subject changes, all observers are notified
• Use case: Event systems, UI frameworks, pub/sub messaging
• Real example: YouTube subscribe — when a channel uploads, all subscribers get notifications

3. Strategy (Behavioral):

• Defines a family of algorithms, encapsulates each one, makes them interchangeable
• Use case: Payment processing (CreditCard, bKash, Nagad strategies), sorting algorithms
• Eliminates complex if-else chains by polymorphism

Others to know: Factory, Builder, Adapter, Decorator, Facade, Repository.

Concurrency: Managing multiple tasks by interleaving their execution — tasks make progress within overlapping time periods. One CPU can handle concurrency by switching between tasks.

Parallelism: Executing multiple tasks simultaneously — requires multiple CPU cores. Tasks literally run at the same time.

Analogy:

• Concurrency: One chef cooking two dishes — chopping vegetables for dish A, then stirring dish B, back to A
• Parallelism: Two chefs each cooking one dish simultaneously

Implementation:

• Threads: Shared memory, lightweight, need synchronization (mutex, semaphore)
• Processes: Separate memory, heavier, communicate via IPC
• Async/Await: Non-blocking I/O — single thread handles many concurrent operations (Node.js, Python asyncio)

Common Issues: Race conditions, deadlocks, starvation, priority inversion. Solution: locks, atomic operations, message passing, immutable data.

Database Index is a data structure (usually B-tree or B+ tree) that speeds up data retrieval at the cost of additional storage and slower writes.

How it works: Without index: full table scan (O(n)). With index: B-tree lookup (O(log n)).

Types:

• Primary Index: On primary key (auto-created)
• Secondary/Non-clustered: On non-primary columns (CREATE INDEX)
• Composite: On multiple columns — column order matters!
• Unique Index: Enforces uniqueness constraint
• Full-text Index: For text search (MATCH AGAINST)

Trade-offs:

• ✅ Faster SELECT queries
• ❌ Slower INSERT/UPDATE/DELETE (index must be updated)
• ❌ Extra disk space
• ❌ Too many indexes = diminishing returns

When to index: Columns used in WHERE, JOIN, ORDER BY, GROUP BY. Don't index columns with low cardinality (e.g., boolean) or tables with heavy writes.

SQL (Relational): MySQL, PostgreSQL, Oracle

• Structured data with defined schema
• ACID transactions (Atomicity, Consistency, Isolation, Durability)
• Complex queries with JOINs
• Vertical scaling primarily
• Best for: Financial data, inventory, order management, CRM

NoSQL:

• Document (MongoDB): Flexible JSON-like documents — content management, user profiles
• Key-Value (Redis, DynamoDB): Fast lookups — caching, session storage, leaderboards
• Column-Family (Cassandra): Wide columns — time-series data, IoT, analytics
• Graph (Neo4j): Relationships — social networks, recommendation engines

Decision Factors:

• Need ACID? → SQL
• Flexible schema? → NoSQL (Document)
• Extreme scale? → NoSQL (Cassandra, DynamoDB)
• Complex relationships? → SQL or Graph NoSQL
• Caching/speed? → Redis

Normalization organizes database tables to reduce redundancy and dependency.

1NF (First Normal Form):

• Each column contains atomic (indivisible) values
• Each column has a unique name
• No repeating groups or arrays
• ❌ "Skills: Java, Python, SQL" in one column → ✅ Separate rows or junction table

2NF (Second Normal Form):

• Must be in 1NF
• All non-key columns depend on the entire primary key (no partial dependency)
• Relevant when composite primary key exists
• ❌ {StudentID, CourseID} → StudentName depends only on StudentID → Move to Student table

3NF (Third Normal Form):

• Must be in 2NF
• No transitive dependency — non-key columns don't depend on other non-key columns
• ❌ EmployeeTable: DeptID → DeptName (DeptName depends on DeptID, not EmployeeID) → Move to Department table

Denormalization: Sometimes intentionally violating normalization for read performance (e.g., caching joined data in NoSQL).

CI (Continuous Integration): Developers frequently merge code to main branch; each merge triggers automated builds and tests.

CD (Continuous Delivery/Deployment):

• Continuous Delivery: Code is always in a deployable state — deployment is manual approval
• Continuous Deployment: Every passing change is automatically deployed to production

Typical Pipeline Stages:

• 1. Source: Code push triggers pipeline (Git push, PR merge)
• 2. Build: Compile code, resolve dependencies, create artifacts
• 3. Unit Tests: Run automated unit tests (fast, isolated)
• 4. Integration Tests: Test component interactions, API contracts
• 5. Static Analysis: Code quality, security scanning (SonarQube, Snyk)
• 6. Staging Deploy: Deploy to staging environment for acceptance testing
• 7. E2E Tests: End-to-end tests simulating user behavior
• 8. Production Deploy: Blue-green, canary, or rolling deployment

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

Docker packages applications and their dependencies into lightweight, portable containers that run consistently across environments.

Container vs VM:

• Container: Shares host OS kernel, lightweight (MBs), starts in seconds, less isolation
• VM: Full guest OS, heavier (GBs), starts in minutes, stronger isolation

Key Concepts:

• Dockerfile: Instructions to build an image (FROM, COPY, RUN, EXPOSE, CMD)
• Image: Read-only template — like a class definition
• Container: Running instance of an image — like an object
• Registry: Image storage (Docker Hub, AWS ECR, GitHub Container Registry)
• Docker Compose: Define multi-container apps (web + database + cache) in one YAML file

Benefits: "Works on my machine" → works everywhere. Consistent dev/staging/production environments. Fast scaling. Microservices-friendly.

Use the STAR Framework:

• Situation: Describe the context — what system, what was happening, who was affected
• Task: What was your responsibility? What needed to be fixed?
• Action: What specific steps did YOU take? (This is the most important part)
  • How did you reproduce the bug?
  • What debugging tools/techniques did you use?
  • What was the root cause?
  • What was the fix?
• Result: What was the outcome? Quantify if possible (reduced errors by X%, saved Y hours)

Good Example Structure:
"In our e-commerce platform, users were intermittently getting wrong order totals. I added logging to the checkout service, discovered a race condition in the cart calculation when multiple browser tabs were open. Fixed by implementing optimistic locking on the cart object. Zero pricing errors since deployment."

Framework for Answering:

• 1. Listen first: "I always start by understanding the other person's perspective completely. Often, disagreements arise from different assumptions or priorities"
• 2. Data-driven discussion: "I suggest we evaluate options against objective criteria — performance benchmarks, maintenance cost, team expertise, project timeline"
• 3. Prototype/POC: "If both approaches have merit, I suggest building a small proof-of-concept for each to compare"
• 4. Escalate constructively: "If we still disagree, I involve the tech lead or architect for a tiebreaker — not because I can't decide, but because fresh eyes help"
• 5. Disagree and commit: "Once a decision is made, I fully commit to it even if it wasn't my preference. I've learned that consistent execution of a 'good enough' decision beats inconsistent execution of a 'perfect' one"

Key Phrase: "The goal isn't to be right — it's to build the best solution for our users and our team."