207 lines
3.5 KiB
Markdown
207 lines
3.5 KiB
Markdown
# Beyond Interviews
|
||
|
||
## Real Engineering Problems
|
||
|
||
---
|
||
|
||
## Why This Project Exists
|
||
|
||
Modern coding interviews often reward:
|
||
|
||
* pattern recognition
|
||
* memorized solutions
|
||
* speed under pressure
|
||
|
||
Real engineering rewards something very different:
|
||
|
||
* dealing with imperfect data
|
||
* understanding systems
|
||
* debugging unknown behavior
|
||
* making trade-offs under constraints
|
||
|
||
This project explores the gap between the two.
|
||
|
||
---
|
||
|
||
## What Is This Project About?
|
||
|
||
This project analyzes common interview-style problems (LeetCode, Codility, etc.) and asks a simple question:
|
||
|
||
> Do these problems reflect real engineering work?
|
||
|
||
Not in a negative or dismissive way — but in a practical, engineering-focused way.
|
||
|
||
---
|
||
|
||
## Core Idea
|
||
|
||
Typical hiring pipeline:
|
||
|
||
```
|
||
Resume → Algorithmic Interview → Engineering Job
|
||
```
|
||
|
||
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
|
||
|
||
---
|
||
|
||
## What This Project Does
|
||
|
||
For each problem, we:
|
||
|
||
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
|
||
|
||
---
|
||
|
||
## Project Philosophy
|
||
|
||
* No toxicity
|
||
* No complaints about interviews
|
||
* Focus on understanding, not blaming
|
||
* Respect both sides: interviews *and* engineering
|
||
* Show limitations **and** value
|
||
|
||
---
|
||
|
||
## 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-...
|
||
...
|
||
```
|
||
|
||
Each analysis contains:
|
||
|
||
* Problem description
|
||
* Typical solution
|
||
* Failure scenarios
|
||
* Real-world context
|
||
* Demo code (optional)
|
||
* Key takeaway
|
||
|
||
---
|
||
|
||
## Development Workflow
|
||
|
||
Event-driven:
|
||
|
||
```
|
||
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:
|
||
|
||
* Yes (rarely)
|
||
* Partially (in modified form)
|
||
* Almost never
|
||
|
||
---
|
||
|
||
## Long-Term Vision
|
||
|
||
This project may evolve into:
|
||
|
||
* A structured knowledge base
|
||
* A series of engineering articles
|
||
* A reference for improving interview practices
|
||
|
||
---
|
||
|
||
## Final Note
|
||
|
||
This project is both:
|
||
|
||
* A personal exploration
|
||
* A contribution to the engineering community
|
||
|
||
It turns interview preparation into something more meaningful:
|
||
|
||
**understanding how real systems actually behave.**
|