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.

Three years into my role as a software engineer, I learned that reliability is a discipline, not an afterthought. On an on-call rotation at a payments platform, a seemingly minor change triggered cascading timeouts across services. The immediate fix was simple, but the lesson stayed with me: if you cannot explain your system's behavior under stress, you do not control it. That incident pushed me toward deeper systems thinking and made me increasingly interested in the theory behind distributed systems and large-scale data infrastructure.

Professionally, I have worked on microservices, observability, and performance tuning, often in environments where the business cost of downtime is visible. I learned to treat metrics and logs as first-class artifacts: define SLOs, monitor error budgets, and run post-incident reviews that focus on process, not blame. Over time, I became the engineer teammates reached for when a problem was ambiguous and cross-cutting, because I could break it down and drive a plan to resolution.

One incident that shaped my approach was an outage caused by a downstream dependency slowing unexpectedly. I led the mitigation by adding timeouts, a circuit breaker, and an exponential backoff strategy, and then wrote a post-incident review that focused on systemic fixes: better alerts, a canary rollout, and load tests for critical endpoints. This taught me to think in prevention rather than heroics and to treat reliability work as a product with its own roadmap.

One project that shaped me was a migration of a legacy reporting pipeline that had become fragile and slow. I redesigned the data flow to separate ingestion, validation, and aggregation, introduced idempotent processing, and tightened schema checks at the boundaries. The result was a pipeline that ran in hours instead of overnight, with fewer manual fixes and clearer ownership. The technical work mattered, but the coordination mattered just as much: aligning stakeholders, sequencing rollouts, and validating outputs with domain teams.

In parallel, I worked on developer productivity improvements that reduced repeated mistakes during incidents. I standardized log fields, introduced correlation IDs across services, and added basic tracing so cross-service failures were diagnosable without guesswork. These changes reduced mean time to resolution and made it easier for new engineers to contribute safely. It reinforced a lesson I now believe strongly: observability is a design choice, not a bolt-on.

Another area I became responsible for was performance budgeting. I introduced load tests for a few critical endpoints and used profiling to find hotspots, then worked with teams to set explicit p95 targets and error budgets. We improved deployment confidence by pairing canary releases with automated rollback triggers, and we reduced cold-start spikes by addressing initialization costs that were invisible in local testing. This taught me that speed and safety can coexist when you design for them deliberately.

As my scope increased, I began mentoring new engineers and reviewing designs, and I learned how to communicate tradeoffs clearly. I also learned what I lack. While industry taught me execution and pragmatism, it also revealed gaps in my formal understanding: consistency models, distributed coordination, and the mathematical foundations behind modern learning systems. I want the ability to reason from first principles when systems become complex, not only rely on experience.

These experiences clarified what I want to study next: consistency models, distributed coordination, and the foundations behind scalable machine learning systems. I want to move from pattern recognition to principled reasoning, so when a tradeoff appears, I can justify it formally and communicate it clearly. A master's program is the right setting to do that through rigorous coursework and research-style projects.

This is why I am applying for an MS in Computer Science now. I want structured depth in distributed systems, databases, and systems for machine learning, and I want research exposure that strengthens the way I evaluate ideas. I am motivated by programs that combine theory with rigorous experimentation, and that offer a thesis or capstone environment where ideas are tested honestly rather than marketed. I want to leave with stronger methods, not just stronger opinions.

I also believe I will contribute meaningfully to a graduate cohort. I bring practical context from building systems under real constraints, and I can connect classroom concepts to production tradeoffs. I value clean writing and clear thinking, and I enjoy being challenged by peers who have depth in areas where I am still growing.

After the master's, I intend to continue building core infrastructure, but with stronger judgment and wider capability. In the short term, I want to work on reliable data platforms or distributed systems at organizations that operate at scale. In the long term, I want to help build dependable systems in India that support critical workflows, and to mentor engineers the way my mentors helped me grow. I bring ownership, measured impact, and the maturity to learn from failure without repeating it. My goal is to build systems that people can trust, because at scale, trust is engineered.

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.