Home | About | Blog | Projects | Contact

New Study Plan

This post is mostly for future me — to explain what I’m actually aiming at with all these books and why my desk looks like a small library exploded, and to keep myself accountable

I’m basically standing between two paths:

• Path A: CPU / SoC / embedded / low-level systems engineer (what I enjoy right now).
• Path B: quant / low-latency C++ / high-performance systems (what’s insanely attractive for salary).

The trick is: I don’t actually have to decide today. There’s a shared core of skills that both worlds respect — deep C++ systems knowledge, understanding how hardware actually works, and being comfortable at the OS / memory / performance layer.

So this “new-study-plan” is built around one idea: build a shared core that keeps both options open in the next 6–12 months.

The Books I’m Centering Around

Right now, my main stack is:

• C++ / Systems: C++ Primer, A Tour of C++
• OS / Concurrency: Operating Systems: Three Easy Pieces (OSTEP)
• Embedded / Firmware: Embedded Systems Fundamentals with ARM-based Microcontrollers
• Architecture / Multicore: Fundamentals of Parallel Multicore Architecture
• Digital Design / Hardware: Digital Design (Dally & Harting), Advanced Digital Design (Ciletti)
• Electronics: The Art of Electronics

I’m not trying to grind every book front to back in order. Instead, I’m treating them like layers of one stack: electrons → logic → CPU → OS → firmware → C++ code that actually runs on it.

What Actually Matters for the Next 6 Months

I’m in my last internship recruitment cycle and I need to be ready for full-time recruiting this coming summer. That means I need to be sharp on what companies actually interview for, not just what’s “cool.”

For a CPU/SoC/firmware-type role, the highest-return areas are:

• Clean, correct C/C++ (pointers, memory layout, const, RAII, STL basics).
• Embedded fundamentals (interrupts, ISRs, timers, UART/SPI, memory-mapped I/O, volatile).
• OS basics (processes, threads, scheduling, virtual memory, synchronization).
• Architecture basics (5-stage pipeline, hazards, caches, MESI-level coherence understanding).

For quant/low-latency C++ later on, those same skills still matter — I’d just add more algorithms, concurrency, and math on top. So nothing here is wasted.

The Study Order (High Level)

Roughly, this is how I’m going to run through the books:

1. C++ Primer → A Tour of C++
   Lock down my C++ fundamentals and modern idioms so I can write clean, efficient systems code and actually understand what the compiler is doing.
2. Embedded Systems Fundamentals (ARM)
   Map that C/C++ knowledge onto real hardware: interrupts, timers, UART, startup code, linker scripts, and bare-metal projects on boards.
3. OSTEP (selected chapters)
   Processes, threads, scheduling, synchronization, and virtual memory — enough OS intuition to talk about what the kernel is actually doing when my code runs.
4. Fundamentals of Parallel Multicore Architecture
   Caches, cache coherence, memory consistency, and interconnects — the stuff that explains why performance is the way it is on real CPUs.
5. Digital Design (Dally & Harting) (with Ciletti as needed)
   Build the timing and pipeline intuition so I can actually follow microarchitecture discussions and speak the same language as hardware folks.
6. The Art of Electronics (slow burn)
   Fill in the “physics layer” under everything else so that weird hardware behavior makes sense when I eventually hit it on real boards.

What This Looks Like Week to Week

I’m not going to try to be a superhero and finish all of this in a month. The perfect plan for the next ~6 months is (I know I am not going to follow this perfectly but this is absolute best case):

• Daily: 1–2 hours of focused reading/coding from C++ / Embedded / OSTEP.
• Weekly: one small project or experiment (driver, scheduler, cache simulator, etc.).
• Ongoing: document everything here on the blog so I don’t forget what I learned.

By the time full-time recruiting hits, the goal is to:

• Speak C++ fluently at a systems level.
• Show real embedded and low-level projects (not just school labs).
• Be comfortable talking about OS internals and basic architecture.
• Still be able to pivot into more quant / low-latency work if I decide to chase that comp later.

Long-term, I still love the hardware side. But this plan keeps my options open: I can become a genuinely strong CPU/SoC/firmware engineer and still have the door open to high-performance trading systems if I want to jump there later.

That’s the new study plan. Hold me to it.

— Chris / 0xChunks

← Back to blog home