# 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.