some changes
This commit is contained in:
219
readme.md
219
readme.md
@@ -1,135 +1,206 @@
|
||||
# Beyond Interviews
|
||||
|
||||
## Real Engineering Problems
|
||||
|
||||
---
|
||||
|
||||
## What is this?
|
||||
## Why This Project Exists
|
||||
|
||||
This project is about one simple question:
|
||||
Modern coding interviews often reward:
|
||||
|
||||
> Do typical coding interview problems reflect real engineering work?
|
||||
* pattern recognition
|
||||
* memorized solutions
|
||||
* speed under pressure
|
||||
|
||||
Short answer: not really.
|
||||
Real engineering rewards something very different:
|
||||
|
||||
But instead of complaining about it, this project tries to **understand why**.
|
||||
* dealing with imperfect data
|
||||
* understanding systems
|
||||
* debugging unknown behavior
|
||||
* making trade-offs under constraints
|
||||
|
||||
This project explores the gap between the two.
|
||||
|
||||
---
|
||||
|
||||
## Why this exists
|
||||
## What Is This Project About?
|
||||
|
||||
Many interview processes rely on:
|
||||
This project analyzes common interview-style problems (LeetCode, Codility, etc.) and asks a simple question:
|
||||
|
||||
- LeetCode
|
||||
- Codility
|
||||
- algorithmic puzzles
|
||||
> Do these problems reflect real engineering work?
|
||||
|
||||
These tasks are:
|
||||
|
||||
- abstract
|
||||
- isolated
|
||||
- time-pressured
|
||||
|
||||
Real engineering is not.
|
||||
Not in a negative or dismissive way — but in a practical, engineering-focused way.
|
||||
|
||||
---
|
||||
|
||||
## What this project does
|
||||
## Core Idea
|
||||
|
||||
For each interview problem, we:
|
||||
|
||||
1. Look at the original task
|
||||
2. Show the typical “interview solution”
|
||||
3. Explain what it actually tests
|
||||
4. Compare it with real-world engineering
|
||||
5. Find (if possible) a real equivalent
|
||||
|
||||
---
|
||||
|
||||
## Core idea
|
||||
|
||||
There is a gap:
|
||||
Typical hiring pipeline:
|
||||
|
||||
```
|
||||
Interview problems ≠ Real engineering work
|
||||
Resume → Algorithmic Interview → Engineering Job
|
||||
```
|
||||
|
||||
This project explores that gap.
|
||||
Each stage evaluates very different skills.
|
||||
|
||||
### Interview Tasks Evaluate:
|
||||
|
||||
* Algorithm knowledge
|
||||
* Pattern recognition
|
||||
* Speed and familiarity
|
||||
* Data structures
|
||||
|
||||
### Real Engineering Requires:
|
||||
|
||||
* System design
|
||||
* Working with imperfect inputs
|
||||
* Debugging complex behavior
|
||||
* Constraints (memory, latency, hardware)
|
||||
* Trade-offs
|
||||
* Maintainability
|
||||
|
||||
---
|
||||
|
||||
## Not a rant
|
||||
## What This Project Does
|
||||
|
||||
This is **not** about:
|
||||
For each problem, we:
|
||||
|
||||
- complaining
|
||||
- mocking interviews
|
||||
- saying "everything is useless"
|
||||
|
||||
Instead:
|
||||
|
||||
- understand what these problems measure
|
||||
- show where they help
|
||||
- show where they don’t
|
||||
1. Show the typical interview solution
|
||||
2. Analyze what it actually tests
|
||||
3. Show where it breaks
|
||||
4. Map it to real-world engineering
|
||||
5. Provide runnable examples (when relevant)
|
||||
6. Discuss better approaches
|
||||
|
||||
---
|
||||
|
||||
## Engineering focus
|
||||
## Project Philosophy
|
||||
|
||||
Special attention is given to **systems and embedded development**, where reality looks very different:
|
||||
|
||||
- imperfect data
|
||||
- hardware constraints
|
||||
- memory limits
|
||||
- timing issues
|
||||
- debugging real systems
|
||||
* No toxicity
|
||||
* No complaints about interviews
|
||||
* Focus on understanding, not blaming
|
||||
* Respect both sides: interviews *and* engineering
|
||||
* Show limitations **and** value
|
||||
|
||||
---
|
||||
|
||||
## Repository structure
|
||||
## Embedded & Systems Perspective
|
||||
|
||||
Most discussions about interview problems ignore real-world constraints.
|
||||
|
||||
This project does not.
|
||||
|
||||
We focus on:
|
||||
|
||||
* Bit-level data parsing
|
||||
* CAN / J1939-like data flows
|
||||
* Sensor noise and drift
|
||||
* Floating point precision issues
|
||||
* Memory constraints
|
||||
* Real-time behavior
|
||||
* Hardware interaction
|
||||
|
||||
These are common in real systems — and rarely represented in interviews.
|
||||
|
||||
---
|
||||
|
||||
## Example Direction
|
||||
|
||||
| Interview Problem | Real Engineering Equivalent |
|
||||
| ----------------------- | ------------------------------------- |
|
||||
| Two Sum | Event correlation in streams |
|
||||
| Floating-point equality | Sensor comparison, tolerance handling |
|
||||
| Array problems | Buffers, pipelines, streaming data |
|
||||
| Graph traversal | State machines, routing, dependencies |
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
analysis/
|
||||
01-.../
|
||||
02-.../
|
||||
01-...
|
||||
02-...
|
||||
...
|
||||
```
|
||||
|
||||
Each analysis contains:
|
||||
|
||||
- explanation
|
||||
- comparison
|
||||
- conclusions
|
||||
- sometimes code
|
||||
* Problem description
|
||||
* Typical solution
|
||||
* Failure scenarios
|
||||
* Real-world context
|
||||
* Demo code (optional)
|
||||
* Key takeaway
|
||||
|
||||
---
|
||||
|
||||
## How to read this
|
||||
## Development Workflow
|
||||
|
||||
Start with any analysis.
|
||||
Event-driven:
|
||||
|
||||
Each one answers:
|
||||
```
|
||||
Problem ready → Publish
|
||||
```
|
||||
|
||||
No artificial schedule.
|
||||
|
||||
---
|
||||
|
||||
## Publishing Strategy
|
||||
|
||||
Initial phase:
|
||||
|
||||
* Prepare 2–4 analyses
|
||||
* Establish consistency
|
||||
|
||||
Then:
|
||||
|
||||
* Publish repository
|
||||
* Share insights (e.g., LinkedIn)
|
||||
|
||||
---
|
||||
|
||||
## Tone & Style
|
||||
|
||||
* Professional
|
||||
* Clear and accessible
|
||||
* Engineering-focused
|
||||
* Minimal jargon when possible
|
||||
|
||||
---
|
||||
|
||||
## Key Question
|
||||
|
||||
Each analysis answers:
|
||||
|
||||
> Would this problem appear in real engineering?
|
||||
|
||||
---
|
||||
Possible answers:
|
||||
|
||||
## Why it matters
|
||||
|
||||
Because solving puzzles ≠ building systems.
|
||||
|
||||
And understanding the difference makes you a better engineer.
|
||||
* Yes (rarely)
|
||||
* Partially (in modified form)
|
||||
* Almost never
|
||||
|
||||
---
|
||||
|
||||
## Status
|
||||
## Long-Term Vision
|
||||
|
||||
Work in progress.
|
||||
This project may evolve into:
|
||||
|
||||
Problems are added when ready — no fixed schedule.
|
||||
* A structured knowledge base
|
||||
* A series of engineering articles
|
||||
* A reference for improving interview practices
|
||||
|
||||
---
|
||||
|
||||
## Author note
|
||||
## Final Note
|
||||
|
||||
This project started as a personal attempt to make interview preparation meaningful.
|
||||
This project is both:
|
||||
|
||||
If it helps someone else — even better.
|
||||
* A personal exploration
|
||||
* A contribution to the engineering community
|
||||
|
||||
It turns interview preparation into something more meaningful:
|
||||
|
||||
**understanding how real systems actually behave.**
|
||||
|
||||
Reference in New Issue
Block a user