second

analysis/00-Why_LeetCode_Problems_Don't_Reflect_Real_Engineering/readme.md

@@ -0,0 +1,217 @@
+# 00 — 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.

analysis/02-Floating_Point_Equality_Is_a_Lie/readme.md

@@ -161,19 +161,9 @@ It shows:
 
 ---
 
-## Example Output (fill with your own results)
+## Example Output
 
-Below you can include actual output from your system.
-
-```text
-[insert your real output here]
-```
-
-Use this section to demonstrate:
-- how behavior changes with different eps values
-- how noise affects stability
-- differences between float and double
-- how hysteresis stabilizes the system
+see example/*.txt files.
 
 ---
 

analysis/03-Two_Sum_Is_Not_About_Numbers/analysis_two_sum_not_about_numbers.md

@@ -0,0 +1,173 @@
+# Analysis #XX — Two Sum Is Not About Numbers
+
+## Problem (LeetCode-style)
+
+You are given a list of records. Each record contains:
+
+- an identifier
+- a value
+- optional metadata
+
+Your task is to find whether there exists a pair of records whose values sum to a given target.
+
+Return the identifiers of any such pair.
+
+Constraints:
+- Each record may be used at most once
+- At most one valid answer exists
+
+---
+
+## Typical Interview Thinking
+
+1. Start with brute force:
+   - Check all pairs → O(n²)
+
+2. Optimize:
+   - Use a hash map
+   - Store seen values
+   - Lookup complement (target - value)
+
+```cpp
+unordered_map<int, int> seen;
+
+for (int i = 0; i < n; ++i) {
+    int complement = target - nums[i];
+
+    if (seen.count(complement)) {
+        return {seen[complement], i};
+    }
+
+    seen[nums[i]] = i;
+}
+```
+
+Time complexity: O(n)  
+Space complexity: O(n)
+
+---
+
+## What This Actually Tests
+
+- Pattern recognition
+- Familiarity with hash maps
+- Knowledge of time complexity
+- Prior exposure to the problem
+
+---
+
+## Real-World Version (Logs & Event Correlation)
+
+### Synthetic Log Example
+
+```
+2026-04-16T10:15:01.123Z service=api    event=parse_input   latency=12ms request_id=req-1001
+2026-04-16T10:15:01.130Z service=cache  event=cache_miss    latency=48ms request_id=req-1001
+2026-04-16T10:15:01.135Z service=db     event=read_user     latency=55ms request_id=req-1001
+2026-04-16T10:15:01.144Z service=net    event=external_call latency=47ms request_id=req-1001
+2026-04-16T10:15:01.151Z service=cache  event=cache_miss    latency=60ms request_id=req-3001
+2026-04-16T10:15:01.154Z service=net    event=external_call latency=52ms request_id=req-3001
+```
+
+---
+
+## Real Problem
+
+Detect whether there exist two events:
+
+- belonging to the same request_id
+- occurring within a time window
+- whose combined latency exceeds a threshold
+
+---
+
+## Where LeetCode Logic Breaks
+
+### 1. Not Exact Match
+LeetCode:
+```
+a + b == target
+```
+
+Reality:
+```
+a + b > threshold
+```
+
+---
+
+### 2. Context Matters (request_id)
+
+You cannot mix unrelated events.
+
+---
+
+### 3. Time Window
+
+Events must be close in time.
+
+---
+
+### 4. Streaming Data
+
+- Data arrives continuously
+- May be out of order
+- Cannot store everything
+
+---
+
+## Real Engineering Approach
+
+### Core Idea
+
+Maintain sliding windows per request_id.
+
+### Pseudocode
+
+```
+for each incoming event:
+    bucket = active_events[event.request_id]
+
+    remove old events outside time window
+
+    for each old_event in bucket:
+        if event.latency + old_event.latency > threshold:
+            report anomaly
+
+    add event to bucket
+```
+
+---
+
+## Additional Real Constraints
+
+- Out-of-order events
+- Missing logs
+- Duplicate events
+- Noise filtering
+- Memory limits
+
+---
+
+## Key Takeaway
+
+Two Sum is not about numbers.
+
+It is about recognizing patterns in controlled environments.
+
+Real engineering problems are about:
+
+- defining valid data
+- handling imperfect inputs
+- managing time and memory
+- maintaining system behavior under constraints
+
+---
+
+## Project Perspective
+
+Exists in real engineering?  
+→ Yes, but heavily transformed
+
+Exists in interview form?  
+→ Yes, but oversimplified

analysis/03-Two_Sum_Is_Not_About_Numbers/readme.md

@@ -0,0 +1,251 @@
+# Analysis #XX — Two Sum Is Not About Numbers
+
+## Problem
+
+At first glance, the problem looks trivial:
+
+> Given a list of values, find two elements whose sum equals a target.
+
+This is one of the most well-known interview questions, commonly referred to as **Two Sum**.
+
+It is simple, clean, and perfectly defined:
+- a static array
+- exact arithmetic
+- a guaranteed answer
+
+And that’s exactly why it works so well in interviews.
+
+---
+
+## Typical Interview Thinking
+
+A candidate is expected to go through a familiar progression:
+
+1. Start with brute force (O(n²))
+2. Recognize inefficiency
+3. Optimize using a hash map
+4. Achieve O(n) time complexity
+
+```cpp
+unordered_map<int, int> seen;
+
+for (int i = 0; i < n; ++i) {
+    int complement = target - nums[i];
+
+    if (seen.count(complement)) {
+        return {seen[complement], i};
+    }
+
+    seen[nums[i]] = i;
+}
+```
+
+The “correct” answer is not about solving the problem.
+
+It is about recognizing the pattern.
+
+---
+
+## What This Actually Tests
+
+Despite its simplicity, this problem evaluates:
+
+- familiarity with standard patterns
+- ability to choose a data structure
+- understanding of time complexity
+
+But most importantly:
+
+> it tests whether you have seen this problem before.
+
+---
+
+## A Subtle Shift
+
+Now let’s take the same idea and move it one step closer to reality.
+
+Instead of numbers, we have **log events**.
+
+Instead of a static array, we have a **stream**.
+
+Instead of a clean equality, we have **imperfect data and thresholds**.
+
+---
+
+## Synthetic Log Example
+
+```
+2026-04-16T10:15:01.123Z service=api    event=parse_input   latency=12ms request_id=req-1001
+2026-04-16T10:15:01.130Z service=cache  event=cache_miss    latency=48ms request_id=req-1001
+2026-04-16T10:15:01.135Z service=db     event=read_user     latency=55ms request_id=req-1001
+2026-04-16T10:15:01.144Z service=net    event=external_call latency=47ms request_id=req-1001
+2026-04-16T10:15:01.151Z service=cache  event=cache_miss    latency=60ms request_id=req-3001
+2026-04-16T10:15:01.154Z service=net    event=external_call latency=52ms request_id=req-3001
+```
+
+---
+
+## Real Problem
+
+We are no longer asked to find two numbers.
+
+Instead, the problem becomes:
+
+> Detect whether there exist two events:
+> - belonging to the same request
+> - occurring close in time
+> - whose combined latency exceeds a threshold
+
+This still *looks* like Two Sum.
+
+But it is not.
+
+---
+
+## Where the Interview Model Breaks
+
+### 1. No Exact Match
+
+Interview version:
+```
+a + b == target
+```
+
+Real version:
+```
+a + b > threshold
+```
+
+We are not searching for a perfect complement.
+We are evaluating a condition.
+
+---
+
+### 2. Context Is Mandatory
+
+You cannot combine arbitrary events.
+
+A latency spike only makes sense **within the same request**.
+
+Without context, the result is meaningless.
+
+---
+
+### 3. Time Matters
+
+Events are not just values — they exist in time.
+
+Two events five seconds apart may not be related at all.
+
+This introduces:
+- time windows
+- ordering issues
+- temporal constraints
+
+---
+
+### 4. Data Is Not Static
+
+LeetCode assumes:
+- full dataset
+- already loaded
+- perfectly ordered
+
+Reality:
+- streaming input
+- delayed events
+- missing entries
+- out-of-order delivery
+
+---
+
+## What the Problem Really Becomes
+
+At this point, the challenge is no longer:
+
+> “find two numbers”
+
+It becomes:
+
+> “determine which events are comparable at all”
+
+And that is a fundamentally different problem.
+
+---
+
+## Real Engineering Approach
+
+Instead of solving a mathematical puzzle, we build a system.
+
+### Core Idea
+
+Maintain a sliding window of recent events per request.
+
+### Pseudocode
+
+```
+for each incoming event:
+    bucket = active_events[event.request_id]
+
+    remove events outside time window
+
+    for each old_event in bucket:
+        if event.latency + old_event.latency > threshold:
+            report anomaly
+
+    add event to bucket
+```
+
+---
+
+## What This Introduces
+
+Now we must deal with:
+
+- bounded memory
+- streaming constraints
+- time-based eviction
+- correlation logic
+
+And beyond that:
+
+- out-of-order events
+- duplicate logs
+- partial data
+- noise filtering
+
+---
+
+## The Real Insight
+
+The difficulty is not in computing a sum.
+
+The difficulty is in defining:
+
+- what data is valid
+- what events belong together
+- what “close enough” means
+- how the system behaves under imperfect conditions
+
+---
+
+## Key Takeaway
+
+Two Sum is often presented as a problem about numbers.
+
+In reality, it is a problem about assumptions.
+
+Remove those assumptions, and the problem changes completely.
+
+> The challenge is not finding two values.  
+> The challenge is understanding whether those values should ever be compared.
+
+---
+
+## Project Perspective
+
+Exists in real engineering?  
+→ Yes, but as event correlation under constraints
+
+Exists in interview form?  
+→ Yes, but stripped of context and complexity