Documentation Index
Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
Use this file to discover all available pages before exploring further.
Why Learn Engineering Fundamentals?
Strong engineering fundamentals separate good developers from great ones. Frameworks change every few years, but the principles behind them — how operating systems manage memory, how networks route packets, how databases maintain consistency — have remained remarkably stable for decades. An engineer who understands fundamentals can learn any new framework in weeks because they already understand the “why” behind the “what.” These topics help you:- Design scalable and maintainable systems from first principles, not by copying tutorials
- Debug complex issues efficiently by reasoning about what the system is actually doing under the hood
- Communicate technical decisions clearly using precise vocabulary that signals competence
- Excel in system design interviews where interviewers test depth of understanding, not memorized patterns
- Build production-ready applications that survive real-world traffic, failures, and changing requirements
Career Impact: Engineers with strong fundamentals are 3x more likely to be promoted to senior roles and consistently outperform in technical interviews at top companies. This is not because they memorize more — it is because they can reason from principles when they encounter problems they have never seen before, which is exactly what senior engineering roles demand.
Topic Categories
Computer Science Fundamentals
OS, Networks, Databases, Computer Architecture, and Distributed Systems basics
Software Design Principles
SOLID, DRY, KISS, Design Patterns, and Clean Code practices
Architecture Patterns
Microservices, Monolith, Event-Driven, DDD, Hexagonal, and more
DevOps & Infrastructure
CI/CD, Containers, Kubernetes, IaC, GitOps, and SRE
Security Fundamentals
Authentication, Authorization, Encryption, OWASP, and API Security
Performance & Optimization
Caching, Profiling, Load Testing, Async Processing, and Scaling
Learning Path
This is an 8-week progressive curriculum. Each step builds on the previous one — resist the temptation to skip ahead. Understanding why a circuit breaker pattern exists requires first understanding distributed system failure modes, which requires understanding networking fundamentals.Foundation (Week 1-2)
Start with CS Fundamentals — understand how computers, networks, and databases work at a fundamental level. Master processes, threads, TCP/IP, and ACID properties. This is the bedrock everything else sits on. Without it, you will memorize patterns without understanding when and why to apply them.
Design Principles (Week 3-4)
Master SOLID principles, Design Patterns, and Clean Code practices. These form the foundation of all professional software. Focus on understanding the “why” behind each principle, not just the code examples. The goal is to develop an instinct for code structure.
Architecture (Week 5-6)
Learn different architecture patterns (Monolith, Microservices, Event-Driven) and when to apply each. Understand trade-offs and DDD concepts. This is where design principles scale from individual classes to entire systems. The key skill: evaluating which pattern fits your specific constraints (team size, domain complexity, scale requirements).
Topic Difficulty Matrix
| Topic | Difficulty | Interview Frequency | Time to Learn |
|---|---|---|---|
| CS Fundamentals | 🟡 Medium | Very High | 2-3 weeks |
| SOLID Principles | 🟢 Easy | Very High | 1 week |
| Clean Code | 🟢 Easy | High | 1 week |
| Design Patterns | 🟡 Medium | Very High | 2-3 weeks |
| Microservices | 🟡 Medium | High | 2 weeks |
| DDD & Hexagonal | 🔴 Hard | Medium | 2-3 weeks |
| DevOps Basics | 🟡 Medium | Medium | 2 weeks |
| Kubernetes | 🔴 Hard | Medium | 3-4 weeks |
| Security | 🟡 Medium | Medium | 2 weeks |
| Performance | 🔴 Hard | Medium | 2-3 weeks |
What You’ll Learn
Computer Science Fundamentals
- Process vs Thread, Memory Management, Deadlocks
- TCP/IP, HTTP/1.1 vs HTTP/2 vs HTTP/3, WebSockets
- ACID, Transaction Isolation, Indexing, CAP Theorem
- CPU Cache Hierarchy, Latency Numbers
Design Principles & Patterns
- SOLID, DRY, KISS, YAGNI, Law of Demeter
- Creational: Singleton, Factory, Builder
- Structural: Adapter, Decorator, Facade
- Behavioral: Strategy, Observer, Command
Architecture Patterns
- Monolith vs Microservices vs Modular Monolith
- Event-Driven, CQRS, Event Sourcing
- Hexagonal Architecture, DDD Concepts
- Saga Pattern, Circuit Breaker, API Gateway
DevOps & SRE
- CI/CD Pipelines, GitOps
- Docker, Kubernetes, Helm
- Terraform, Infrastructure as Code
- Monitoring, Logging, Tracing (Observability)
- SLIs, SLOs, SLAs, Error Budgets
Security
- Authentication (JWT, OAuth 2.0) & Authorization (RBAC)
- OWASP Top 10 Vulnerabilities
- Encryption, HTTPS/TLS, Secrets Management
- API Security, CORS, CSP
Performance
- Caching Strategies (Cache-Aside, Write-Through)
- Database Optimization, N+1 Problem
- Load Testing, Profiling
- Horizontal vs Vertical Scaling
Interview Deep-Dive
You are joining a new team that owns a critical backend service. On your first week, you discover there are no tests, no monitoring, and deployments are done manually by SSH-ing into production servers. Where do you start?
You are joining a new team that owns a critical backend service. On your first week, you discover there are no tests, no monitoring, and deployments are done manually by SSH-ing into production servers. Where do you start?
Strong Answer:
- The instinct is to fix everything at once, but that is a trap. You have three problems (no tests, no monitoring, manual deploys), and the right order matters because each layer builds on the previous one.
- I start with monitoring, not tests. Here is why: you cannot improve what you cannot measure, and right now, you do not even know if the system is healthy. Add the Four Golden Signals (latency, traffic, errors, saturation) using Prometheus + Grafana or a managed service like Datadog. Instrument the top 5 API endpoints with request duration histograms and error rate counters. Set up a basic PagerDuty alert: “if 5xx error rate exceeds 5% for 3 minutes, page the on-call.” This takes 2-3 days and gives you a safety net immediately.
- Next, I add a CI/CD pipeline — even a basic one. A GitHub Actions workflow that builds the project and deploys to a staging environment on merge to main. This eliminates the SSH-to-production pattern, which is the highest risk item. Every deployment through the pipeline is logged, reversible, and consistent. No tests in the pipeline yet — that comes next. This takes 1-2 days.
- Then, I write integration tests for the critical path. Not aiming for 80% coverage — aiming for the top 3 user journeys that, if broken, would be an incident. Run these in the CI pipeline as a gate. Now deployments are automated AND validated. This takes 1-2 weeks of incremental work alongside feature development.
- Throughout all of this, I am documenting what I find: the architecture, the deployment process, the failure modes I discover. The new team member who joins after me should not have to rediscover everything from scratch.
- What I would NOT do: propose a 3-month “stability sprint” where the team writes no features. Leadership will not approve it, the team will resent it, and you will not have the context yet to make good decisions about what to test. Instead, bake improvements into daily work: every PR that touches a file adds a test for the code it changes.
Explain the relationship between SOLID principles and architecture patterns. How do the same ideas manifest at the class level versus the system level?
Explain the relationship between SOLID principles and architecture patterns. How do the same ideas manifest at the class level versus the system level?
Strong Answer:
- SOLID principles and architecture patterns are the same ideas operating at different scales. What SRP is to a class, a bounded context is to a system. What DIP is to a module, an API contract is to a microservice. Understanding this fractal relationship is what separates an engineer who can design a class from one who can design a system.
- Single Responsibility at the class level: one class should have one reason to change. At the system level: one microservice should own one business domain. The Order service handles orders, not orders AND inventory AND notifications. If you violate SRP at the system level, you get a distributed monolith where changing the inventory logic requires redeploying the order service.
- Open/Closed at the class level: add new behavior through extension (new classes implementing an interface), not modification. At the system level: add new capabilities by deploying new services that subscribe to existing events, not by modifying existing services. An event-driven architecture is the system-level manifestation of OCP — the Order service publishes “OrderPlaced” events and does not know or care how many downstream services consume them. Adding a Loyalty Points service requires zero changes to the Order service.
- Dependency Inversion at the class level: depend on abstractions (interfaces), not concretions. At the system level: services communicate through well-defined API contracts or event schemas, not through shared databases or internal implementation details. A service mesh enforces this at the infrastructure level.
- The key insight for interviews: when a system design question asks you to decompose a large system, you are applying SOLID at the architecture scale. The skills you learned writing clean classes directly transfer to drawing clean service boundaries.
A startup with 5 engineers asks you to advise on their technical architecture. They have 1,000 daily active users and want to scale to 100,000. What do you recommend and, critically, what do you tell them NOT to do?
A startup with 5 engineers asks you to advise on their technical architecture. They have 1,000 daily active users and want to scale to 100,000. What do you recommend and, critically, what do you tell them NOT to do?
Strong Answer:
- At 1,000 DAU with 5 engineers, the architecture should be a well-structured monolith deployed on a single server or a small managed service (Heroku, Render, Railway, or a single ECS/Cloud Run instance). A PostgreSQL database with proper indexes handles this scale trivially. Redis for session storage and basic caching. That is it.
- What I would tell them NOT to do: Do not adopt Kubernetes. Do not build microservices. Do not implement event sourcing. Do not set up a Kafka cluster. Each of these is a full-time job to operate, and with 5 engineers you cannot afford to spend 40% of your engineering capacity on infrastructure. Every hour spent configuring Helm charts is an hour not spent on product features that determine whether you have users to scale for.
- For the growth from 1,000 to 100,000 DAU (a 100x increase): a single PostgreSQL instance with read replicas handles this comfortably. Add proper indexing, connection pooling (PgBouncer), and a CDN for static assets. Move expensive background work (email, report generation, image processing) to async workers (Celery + Redis or a managed queue like SQS). Implement caching at the application layer for frequently-read, rarely-changed data.
- The architecture changes that actually matter at this stage: (1) Observability — add Prometheus/Grafana or Datadog so you know what is slow before users tell you. (2) CI/CD — every merge to main deploys automatically with rollback capability. (3) Horizontal scaling of the web tier — run 3-4 instances of the monolith behind a load balancer so you can handle traffic spikes and deploy without downtime.
- The point at which microservices become worth discussing: when the team exceeds 15-20 engineers and distinct teams own distinct domains that need to deploy independently. That is probably at 500K+ DAU with product-market fit confirmed. For now, ship features fast and stay alive.