Systems Software Engineer
Hi, I'm Ethan. I'm a systems software engineer focused on distributed systems, databases, and infrastructure, primarily in C++ and Rust. I enjoy working close to the metal: hash table internals, storage engines, concurrency primitives, and the decisions that separate fast systems from slow ones.
I studied the C/C++ systems track in college for four years, building a foundation in low-level programming, memory management, and algorithm design before adding Python for AI/ML in my final year. Outside of engineering, I competed at the top level in World of Warcraft PvP, hitting Rank 1 for nine seasons (top 0.1% globally), which taught me a lot about performance under pressure and iterating fast on systems that need to be correct.
I currently work as a software engineer at a B2B AI-first startup. On the side I have two ongoing storage projects: ShardKV, an in-memory distributed key-value store in C++23 similar in scope to Redis, and a Rust database engine for persistent document storage similar in scope to MongoDB.
I'm looking to join a team working on systems software in C++, Rust, or Python. That could be databases, distributed infrastructure, networking, storage, or any domain where correctness and performance are first-class concerns. I want to be somewhere that takes performance regressions seriously and where the interesting problems are in the system itself, not the layer on top of it.
Projects
In-memory key-value store in C++23, similar in scope to Redis. Built a custom swiss table with linear probing as the core hash map. Client requests are handled over TCP sockets with a Rust web server acting as a reverse proxy to keep client-facing traffic separated from the internal server.
Document-oriented database engine similar in scope to MongoDB, with B-tree indexing, BSON serialization, and custom file system paging. Implemented an LRU cache for hot-path reads and wrote property tests to catch silent data corruption from type casts like f32-to-f64 widening that pass unit tests but silently corrupt stored values at the boundary.
Excel-like engine with formula parsing, a cell dependency graph, and live recalculation. The observer pattern was the natural fit for propagation: any cell update triggers exactly the dependents that need it, nothing more. Command pattern makes undo/redo a stack operation. The expression evaluator has no knowledge of the UI, which meant I could test formula logic in isolation without spinning up any UI state.
SaaS platform built with Next.js and PostgreSQL. Automated auth with Google OAuth and payments with Stripe webhooks. Grew to over 300 paying customers and $5,000 in revenue without paid ads, entirely through word of mouth.
Core tools I use on a daily basis



