work

Arista Networks

Babe wake up, the link is down

I got to realize my coursework the most at Arista. I was responsible for the L1 (link) layer on network switches. It was nice to see applications of fourier transforms, computer architecture, and software design patterns in a real-world setting. I was really excited to work on a team close to hardware and this experience did not let down. But then again, my work dodged dealing with all the incompatibility issues that come with Broadcom chips.

A network switch can have many configurations, and as a result, that many states to juggle. My job was to ensure we have a centralized diagnostic tool to aggregate and read from this distributed state system. Don’t want to reveal too much detail here, but I want to share my learnings. I got to use the observer design pattern to trigger state aggregations on change. There is a huge emphasis on code quality as this is something Arista and its customers really value. grugbrain.dev. I now regret some of the code I wrote at Stealth where I made it “easy” to dynamically extend features. This only worked if you follow a strict pre-determined design pattern and made it really inflexible to change the underlying functionality. I avoided this at Arista by making my code more verbose, and consequently explicit. I also learned how to write tests that document the code. Overall, I learned the most about being a software engineer here.

Databento

Are the servers running slow or is it just me…

company blog feature

I took notice of Databento when I saw the CEO’s take on the FTX collapse. I was intrigued by the firm, as their mission to make a “simpler, faster way to get market data” entails many interesting infrastructure challenges. This is the most “full-time-y” internship I have had, where I got to work on tickets (mainly automation and service monitors), along with a fun project.

I was tasked with creating live histograms that measure latency between every colocation centre and the stock exchanges they reach. If I could go back, I would take some inspiration from twitter’s solution as I really like their sophistication. A reader would listen for latencies, and the writer would aggregate these latencies into a histogram and store them persistently. Aggregation intervals were configurable to minimize effect of server downtime. Redis was used as the persistent store for fast querying and writes. I liked working on this project as it was a fun and simple introduction to distributed systems. I also learned a lot from the team, who all shared a background and interest in finance.

Stealth Media

Gaming, cinematics, and everything in between

I met my to-be-manager on a plane ride back home during vacations. It took courage to start a conversation with someone a seat across, but I found his sketch intriguing and let my curiosity take over. This internship was different in all aspects. I was responsible for engineering a game show suite, encompassing the game itself, network architecture for participants, viewers, and studio equipment, as well as the hardware needed for podiums, and other elements… This was a bit of a squeeze for the 4 months, however my goal was to make everything plug-and-play so adding future functionality incurs minimal engineering cost.

Often times, I had to decide between making a feature scalable and easy to maintain, or just functional. There was a rush at the firm to create prototypes for stakeholders, which taught me how make decisions and defend them deductively. The engineering design process really helped in making sound design decisions. In hindsight, this helped me build a more decoupled infrastructure as I reasoned about each problem individually. The most relevant coursework for my work was: systems programming, embedded systems, and linear algebra. Overall, I was pleased with this internship as it was a testament to the practical use of what I have learned so far.

Citadel

Everything is a hashing problem

at the bottom of this bloomberg page

After the lenghthiest interview process I have gone through, I was a part of Citadel’s compute engineering division. My team was responsible for creating and maintaining all Linux related infrastructure, including the OS images themselves. While they were rapidly building the infra to create and deploy these images, the storage and management overhead for the images was getting out of hand. Hence, I was tasked with making these image deployments immutable, which would solve many issues, including: wasted storage, long rollback times, slow deployments, and configuration drifts.

The key to understanding the existing infrastructure in place and implementing my solution was listening to the people who created it. Over time, I learned how to solve problems functionally, where every problem is a black box, with its respective input and output. When we understand this, every image deployment can be viewed as a black box process that produces an output: OS image, which can be can cached for a set of inputs: {os-image-dependency-set: os-image}. When we detect a change in dependencies, we build a new image tracked with a different version. This opened up many oppurtunities for improvements, such as cached and concurrent builds. I am very grateful for this learning experience, as it taught me how to decompartmentalize and solve problems systematically.

Questrade

Infra is cool?

After applying for full stack roles all term, I had my first interview for an infra engineering role. Not knowing much about the field, I felt underqualified. There was significant hype around general SWE (backend / frontend / client-facing) roles at the time and not many were interested in infra. It is over the course of the degree that students realize the value of performant and scalable infrastructure (YAML engineer =/= configuration monkey). Luckily for me, my interviewer did not quiz me on arbitrary infra technologies, but he rather showed me that infrastructure problems are mostly intuitive but fruitful. I was able to derive most answers based on patterns learned in any engineering course.

I learned how to fix problems using code. Being an intern, anyone on the team was free to use me as a resource. Hence, I was able to contribute to several high impact projects, teaching me a diverse set of skills. API Facade was my favourite thing to learn; this was my introduction to system design. I was able to architect a system for servers to pull confgurations by calling an API endpoint, that fetched configs from a data store (google sheets ;-; at the time). This lowered downtime, as servers would go into “sunset” only when software required updating (e.g. antivirus updates). This internship experience proved invaluable later down the line, as it made infrastructure accessible to me.