I am a software engineer who starts from the systems side. Before I think about what renders the result, I want to know how responsibility is divided: where state lives, which component owns a decision, and what the system does when a dependency fails.

That instinct rests on fundamentals I keep sharp deliberately. I practice data structures and algorithms regularly on LeetCode and Codeforces, spending most of that time in the areas that punish loose thinking: graphs, dynamic programming, binary search on the answer, and honest complexity analysis under real constraints. Competitive practice is not a line on a resume. It is where I train the habit of finding the invariant before writing the loop.

System design is where that training earns its keep. My attention goes to the decisions that determine whether a product survives its second year: service boundaries and data ownership, API contracts and versioning, caching and consistency trade-offs, queues and idempotency, indexing and query cost, and authentication and authorization treated as architecture rather than middleware bolted on at the end. I would rather argue about a schema for an hour than debug it for a month.

In delivery work I have shipped production platforms across education, messaging and automation, service marketplaces, and finance-facing operations - backend cores with separate admin surfaces and web or mobile clients. The full record lives on the journey page. Frameworks are the part I hold most loosely: I pick them on constraints rather than preference, and the discipline carries across all of them.

I hold a BCA, a Bachelor of Computer Applications from Gujarat University, with an 8.1 CGPA. Through my bachelor's I worked as a home tutor alongside my coursework.

Teaching turned out to be the most useful engineering training I had. Explaining an idea to someone with no context forces you to find the simplest correct version of it, which is the same skill that makes a code review worth reading, a design document usable, and an API obvious to the next person who touches it.

My work reflects a systems-oriented mindset. I design software to remain understandable under change, operable in production, and resilient as requirements move. Frameworks are tools. Architecture is the priority.