Statement of Purpose for MS in Computer Science

I started taking Computer Science seriously when a system I built failed in a way I could not explain. During a campus registration drive, we launched a simple web app for slot booking. It worked with ten testers, but the first real surge exposed race conditions, duplicate writes, and timeouts. I spent two nights tracing logs and reproducing the bug locally, and I realized that good software is not the demo that works once, it is the system that behaves predictably under pressure. That incident pulled me toward distributed systems and reliability work, where correctness is earned through careful design, measurement, and testing.

My academic foundation reflects that shift from curiosity to rigor. I focused my electives on Operating Systems, Database Systems, Computer Networks, and Algorithms, and I treated each course as a chance to build a mental model, not just clear an exam. In my final year, I started reading engineering blogs and papers alongside coursework to understand how real systems handle failure: retries, idempotency, backpressure, and observability. That self-driven reading made my classes more meaningful and helped me see how small design decisions compound when a system grows.

To sharpen my fundamentals beyond coursework, I built a small key-value store as a personal project, focusing on correctness rather than features. I implemented a write-ahead log, basic compaction, and a simple in-memory index, and I wrote tests that forced me to handle edge cases like partial writes and crashes. Even though the system was small, it made abstract ideas tangible: why durability requires careful ordering, how latency changes when you move work off the hot path, and how design choices show up as operational tradeoffs. This project also trained me to write clear documentation, because if I could not explain a component, I usually did not understand it well enough.

For my capstone, I worked with two peers on a lightweight event-driven pipeline for processing logs from multiple sources. We designed it around a queue, a worker pool, and a simple schema for consistent event formats. I implemented the ingestion service in Go and wrote property-based tests around parsing and deduplication. We measured throughput and failure modes, and our biggest improvement came from changing one assumption: designing for at-least-once delivery and making consumers idempotent. That project taught me to think in guarantees and tradeoffs, not just code paths.

Beyond the capstone, I tried to develop taste for simplicity by building smaller tools that solve real problems: a rate limiter, a retry wrapper with jitter, and a log parser that could replay requests for debugging. These were not big projects, but they trained me to think about interfaces, failure modes, and the difference between a quick fix and a maintainable solution. They also taught me that good engineering often looks like removing complexity and making behavior more predictable, especially when systems interact.

I also sought industry exposure to understand production constraints. During my internship at a fintech product team, I worked on performance and reliability for a core API. One task involved a slow query that spiked under load. After profiling, I rewrote the query, added an index, and introduced a small cache for the hottest lookups. This reduced p95 latency from roughly 900 ms to 420 ms and cut error rates during peak traffic. Just as importantly, I learned how to work in a codebase with standards: write tests, document decisions, and make changes that teammates can maintain.

Working with a team also improved how I communicate. I learned to write short design notes before changing core codepaths, to include rollback plans, and to validate improvements with metrics rather than anecdotes. When something went wrong, I practiced writing blameless summaries that captured root cause and preventative actions. Those habits are what I want to carry into graduate work, where clear communication is as important as the idea itself.

I am now applying for an MS in Computer Science because I want deeper training in the theory that underpins the systems I enjoy building. I am especially drawn to coursework and research in distributed systems, storage, and systems for machine learning. I want to learn how to model consistency, reason about failure, and evaluate designs formally, not only through intuition. The master's environment is also where I can learn to do research-grade work: asking sharper questions, designing better experiments, and writing clearly about results that others can reproduce.

In the short term, I want to join a team that builds core infrastructure: data platforms, reliability, or applied systems work where correctness and performance matter. In the long term, I want to build tools in India that make critical systems more dependable for everyday users, especially in education and healthcare where downtime is not just inconvenient, it is costly. I bring consistent effort, a bias toward measurable outcomes, and the humility to learn fast when my first solution is wrong. Most importantly, I want my work to be trustworthy, because at scale, reliability is not a feature; it is a responsibility.

My first degree was in Mechanical Engineering, and I spent my early professional years working with physical systems and strict constraints. The pivot began with a practical frustration: a repeated manual workflow for cleaning and validating CAD data was consuming days of effort. I wrote a small Python script to parse exports, flag inconsistencies, and generate a clean report. It was not elegant, but it worked, and it changed my trajectory. I realized I was more energized by building tools and systems than by drafting drawings, and I wanted to learn Computer Science properly.

Once I made that decision, I treated the transition like an engineering project: define the fundamentals, practice deliberately, and measure progress through output. I rebuilt my basics by solving data-structure problems, writing small utilities from scratch, and reviewing my mistakes until I could explain them. Instead of learning in isolation, I sought feedback through peer reviews and open-source discussions, because I wanted my work to meet real standards, not personal comfort.

I approached the transition with discipline. I rebuilt my fundamentals through structured coursework in data structures, algorithms, and databases, and I deliberately chose projects that forced me to practice design, not just coding. I wrote small programs, reviewed my own work, and learned to think about edge cases and correctness. Over time, my learning became less about syntax and more about models: how data moves, where failure occurs, and how to build systems that are understandable.

To make fundamentals tangible, I built a small backend service that implemented a queue, a worker pool, and basic persistence. I wrote tests around failure cases and learned why idempotency and careful boundaries matter when systems scale. Even though the project was modest, it taught me the same lesson repeatedly: correctness is earned through constraints, not through confidence.

To prove the pivot through output, I built a small full-stack project that helped a local volunteer group coordinate attendance and logistics. I implemented authentication, built a simple relational schema, and added basic analytics so the team could see drop-offs over time. The project taught me how to ship, iterate, and support users. I also contributed fixes to an open-source repository, which was a humbling exercise in working with review standards and code written by others.

This pivot also clarified the kind of work I am drawn to. I enjoy systems that sit at the boundary of the physical and digital world: data pipelines, reliability tooling, and the infrastructure that makes applications predictable under load. My mechanical background gives me respect for failure analysis and for designing with constraints, and it makes me patient with details that other people try to skip.

My mechanical background is not irrelevant; it is transferable. It trained me to respect constraints, analyze failures, and think in systems rather than isolated parts. In physical design, a small flaw can lead to catastrophic outcomes. That mindset carries directly into software architecture, where a small assumption can become a large incident at scale. I also bring professional maturity: communicating with stakeholders, writing documentation, and staying calm when plans change.

I am applying for an MS in Computer Science because I want formal depth and a stronger theoretical foundation than self-study can provide. I am especially interested in systems, data infrastructure, and applied machine learning, and I want exposure to rigorous evaluation and research-grade thinking. I want to learn the math and theory behind the tools I use, so my work is not a collection of tricks, but a coherent, defensible method.

During the MS, I want to go deeper in distributed systems and data infrastructure, but also explore areas that connect back to my mechanical foundation: cyber-physical systems, IoT reliability, and systems that must interact with imperfect hardware. I am interested in work that treats failure as the default and designs for recovery, because that is the mindset I learned in physical engineering. A program that supports project-based research will let me build something tangible and prove that my pivot is not only possible, but valuable.

I also believe my non-traditional path is a strength in a cohort. I bring professional maturity, respect for constraints, and the habit of documenting decisions so quality is repeatable. I am comfortable starting with fundamentals and doing the hard work quietly, because I have already had to earn progress through effort rather than pedigree.

In the short term, I want to join a team that builds software systems where correctness matters, and grow into an engineer who can own complex components end-to-end. In the long term, I want to build tools that help engineering teams in India work faster and safer, especially in sectors that blend physical and digital systems. I am ready to earn this transition through effort, and I want a program that expects exactly that: clear thinking, hard work, and accountability.

My early academic record is not a clean story, but it is an honest one. In my first year, financial pressure and poor structure led to inconsistent performance. I underestimated the time required for courses that demanded mathematical discipline, and I learned too late that effort without process does not scale. The result was a GPA that did not reflect my long-term potential, and it forced me to confront my weakness directly rather than explain it away.

Instead of treating that result as a permanent label, I treated it like a systems problem: diagnose root causes, change inputs, and measure outputs. I rebuilt my habits around weekly planning, targeted practice, and seeking feedback early. I also reduced distraction, started tracking how I spent my time, and learned to study actively by solving problems and writing explanations, not by rereading notes. The improvements were not instant, but they were durable because they were built on process.

Practically, I made three changes that shifted my trajectory: I started using office hours early, I built a small study group, and I replaced passive studying with timed problem sets and written explanations. I tracked weak topics and revisited them until I could apply concepts without hints. Over time, my grades improved because my process improved. By my final semesters, I was consistently performing strongly in core CS courses and delivering projects on time with the focus I lacked at the start.

The best evidence of recovery is trajectory. In later semesters, my grades in core subjects improved and my project output became more disciplined and complete. I became comfortable with the unglamorous part of improvement: revisiting fundamentals, practicing until concepts were intuitive, and asking for help early instead of hiding confusion. This upward trend matters because it reflects a process I can repeat in graduate school.

The strongest evidence of recovery is the work I produced after I improved my process. In a security-focused project, I implemented a simple network monitor and detection rule-set that flagged abnormal request patterns on a test environment. The project forced me to handle low-level details, validate outputs, and write a clear report on limitations. It reminded me why I enjoy Computer Science: the combination of precision, creativity, and accountability.

In addition to that project, I built smaller systems that forced me to care about correctness and edge cases: parsing logs, replaying requests, and writing simple benchmarking scripts. These were not glamorous, but they taught me to respect measurement and to avoid vague claims about performance. They also improved my confidence in a healthy way: not confidence that I am always right, but confidence that I can debug, learn, and recover when I am wrong.

I also sought internships to validate my learning under real constraints. In an internship role, I worked with a backend team, contributed features behind flags, and learned to write tests that prevent regressions. The experience made me more disciplined: if you cannot explain a change and measure its impact, you should not ship it. That standard became part of my identity as an engineer and reinforced that my upward trajectory was genuine.

This period also changed how I communicate. I learned to write clearer explanations, break work into reviewable pieces, and accept critique without ego. Those habits are as important as technical skills, because complex systems are built by teams, not by lone effort.

I am especially motivated to study distributed systems, databases, and reliability engineering more formally. I want to understand consistency, isolation, and performance at a deeper level, and to apply that learning in a capstone or research-style project. My recovery taught me to respect fundamentals, and graduate study is where I want to turn that discipline into expertise rather than just survival.

I am now applying for an MS in Computer Science from a place of maturity. I am not asking to be judged by a perfect transcript; I am asking to be judged by the growth that followed a poor start and the consistent work I have delivered since then. I want graduate rigor because I respond well to high standards, and because I want deeper training in the systems and methods that will define my career. I want to learn in an environment where correctness is expected and where I can turn resilience into long-term capability.

In the short term, I want to work in roles that build reliable systems and data platforms, and learn from strong engineers and researchers. In the long term, I want to contribute to dependable digital infrastructure in India and mentor students who have talent but need structure the way I did. I have already learned how to recover from setbacks. Now I want the challenge of an environment that expects excellence, and I am ready to meet that expectation. My goal is to build systems people can trust, and to bring the same discipline I developed through recovery into every project I own.