From 4fdcf67b0aa704c61872c8d90c25db377e7946bf Mon Sep 17 00:00:00 2001 From: deeaitch Date: Sat, 28 Mar 2026 09:14:39 -0400 Subject: [PATCH] some changes --- readme.md | 219 ++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 145 insertions(+), 74 deletions(-) diff --git a/readme.md b/readme.md index 7c1e9e8..953c5be 100644 --- a/readme.md +++ b/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.**