diff --git a/analysis/00-Why_LeetCode_Problems_Don't_Reflect_Real_Engineering/readme.md b/analysis/00-Why_LeetCode_Problems_Don't_Reflect_Real_Engineering/readme.md
new file mode 100644
index 0000000..951490f
--- /dev/null
+++ b/analysis/00-Why_LeetCode_Problems_Don't_Reflect_Real_Engineering/readme.md
@@ -0,0 +1,217 @@
+# Analysis #03 — Why LeetCode Problems Don't Reflect Real Engineering
+
+## Overview
+
+This analysis explores why common interview problems (LeetCode, Codility, etc.) often do not reflect real engineering work.
+
+The goal is not to criticize these platforms, but to understand what they actually measure and how that differs from real-world engineering.
+
+---
+
+## Motivation
+
+Engineers can spend months preparing for algorithmic interviews:
+
+- solving hundreds of problems  
+- memorizing patterns  
+- practicing speed  
+
+And still struggle with real-world tasks such as:
+
+- debugging complex systems  
+- working with imperfect data  
+- handling system constraints  
+
+This creates a gap:
+
+Preparation for interviews ≠ Readiness for engineering work  
+Readiness for engineering work ≠ Readiness for interviews  
+
+---
+
+## Nature of LeetCode Problems
+
+Typical characteristics:
+
+- well-defined inputs  
+- deterministic behavior  
+- no external systems  
+- no side effects  
+- one optimal solution  
+
+These are closer to:
+
+> mathematical puzzles or competitive programming
+
+---
+
+## Similarity to Academic Exams
+
+These problems resemble university exams:
+
+- limited types of problems  
+- expected “correct” solutions  
+- repetition-based preparation  
+
+Students can train for years.
+
+However:
+
+> after 5–10 years in industry, this knowledge naturally fades
+
+Why?
+
+- algorithms are already implemented  
+- they are tested and optimized  
+- they are accessed through libraries  
+
+Engineers need to know:
+
+- what to use  
+not  
+- how to reimplement everything from scratch  
+
+---
+
+## What These Problems Actually Test
+
+They effectively measure:
+
+- knowledge of algorithms and data structures  
+- pattern recognition  
+- speed under pressure  
+
+But they do not measure:
+
+- system design  
+- debugging skills  
+- working with constraints  
+- maintaining large systems  
+
+---
+
+## What Is Missing
+
+Real engineering involves:
+
+- incomplete or unclear requirements  
+- unreliable data  
+- system integration issues  
+- hardware and performance constraints  
+- long-term maintainability  
+
+These aspects are almost entirely absent in interview problems.
+
+---
+
+## Impact on Experienced Engineers
+
+A critical and often overlooked effect:
+
+Algorithmic interviews may filter out experienced engineers.
+
+### 1. Shift Toward Academic Knowledge
+
+Experienced engineers:
+
+- do not memorize dozens of algorithms  
+- do not implement them from scratch  
+- do not optimize in isolation  
+
+They:
+
+- use proven libraries  
+- select appropriate solutions  
+- think in systems  
+
+---
+
+### 2. Knowledge ≠ Usage
+
+Even if they know algorithms:
+
+- they may not have implemented them recently  
+- they are not trained for timed coding  
+- they are not optimized for pattern recall  
+
+Result:
+
+> a 10–20 year engineer may appear weaker than a trained candidate  
+
+---
+
+### 3. Abstraction in Real Work
+
+In industry:
+
+- sorting is already implemented  
+- data structures are provided  
+- algorithms are tested  
+
+Engineers focus on:
+
+- architecture  
+- data flow  
+- system reliability  
+
+Interviews shift them back to:
+
+> “implement everything manually in 30 minutes”
+
+---
+
+### 4. Selection Paradox
+
+This creates a paradox:
+
+- experienced engineers get filtered out  
+- trained candidates pass  
+
+Result:
+
+> hiring selects problem solvers, not engineers  
+
+---
+
+## Why This Is a Problem
+
+Using only such problems:
+
+- removes strong candidates  
+- biases toward trained individuals  
+- reduces hiring effectiveness  
+
+The issue is not the problems themselves, but how they are used.
+
+---
+
+## Proper Perspective
+
+LeetCode is useful as:
+
+- mental training  
+- practice  
+- competition  
+
+But not as:
+
+> a primary indicator of engineering ability  
+
+---
+
+## Key Question
+
+Would solving LeetCode problems make you a better engineer?
+
+Answer:
+
+- partially — improves thinking  
+- insufficient — for real systems  
+
+---
+
+## Key Takeaway
+
+LeetCode is not bad.
+
+Mistaking it for engineering is.