Doing Prep for One Company

August 17, 2026

There is a company coming to my college for campus placements. I really want to get placed there.

I spent some time reading about them. They work in the space of secondary data, backups, snapshots, file services, analytics, data that most companies treat as a necessary annoyance but rarely manage well. The idea is to consolidate all of that into one platform. Simple in pitch, hard in execution.

The founder is Mohit Aron. He co-founded Nutanix before this. Before that, he was one of the lead engineers on the Google File System (GFS) the distributed storage system that Google built in the early 2000s to handle petabytes of data across thousands of commodity machines. The GFS paper was published at SOSP 2003, and it changed how people thought about building large-scale storage systems. The ideas in that paper chunk servers, a single master, relaxed consistency, fault tolerance through replication these are not just clever engineering. They are a way of thinking about the problem differently. Instead of trying to make hardware reliable, you accept that hardware will fail, and you design the system to survive that.

I did not know much about distributed systems before I read about Mohit Aron. I knew the words "distributed", "fault tolerant", "consensus" but they felt abstract. Reading about GFS made them concrete. It is one thing to say "store data redundantly". It is another thing entirely to actually build the machinery that does it transparently, at scale, while clients are reading and writing simultaneously.

So I started studying distributed systems properly. Not just reading blog posts, but going through the material seriously. I am doing MIT 6.824 (Distributed Systems). The course uses the GFS paper as one of its first readings. You also read the Raft paper (for consensus), the Spanner paper (for globally distributed databases), and others. The labs are in Go you build a MapReduce framework, a key-value store with Raft replication, a sharded key-value service. It is genuinely difficult. The concurrency bugs alone have kept me up more than once.

There is something different about studying for a company whose work you actually find interesting. Normally interview prep feels like a game you memorize patterns, solve problems from a list, and hope the interviewer picks something familiar. Here, I find myself reading the GFS paper not because it might come up in an interview, but because I genuinely want to understand how it works. That is a better place to be.

I do not know if I will get placed. I have learned not to assume. But at least I know that whatever happens, I will come out of this knowing distributed systems better than I did before. That feels like a reasonable trade.