harsh.dobariyaContact
Menu

Tempe, Arizona, USA
Open to relocate for the right opportunity

Harsh Dobariya Software Engineer

I build reliable software from interface to infrastructure.

Backend and full-stack engineering with a systems mindset. Clear APIs, durable data flows, and interfaces built for real users.

View my workGitHubResume

Tempe, Arizona·Backend + Full Stack·Open to relocate

01Selected work

Systems built end to end.

Two projects that show how I approach concurrency, real-time communication, storage, and system boundaries.

01 / 02

C++ systems project

Distributed Key-Value Store

A concurrent in-memory store that accepts commands over TCP and keeps expiration, eviction, and persistence behavior explicit.

  • C++
  • TCP/IP
  • Multithreading
  • CMake
Ready for commands
clientSET user:104 "Harsh"Choose a command to trace its path
What

GET, SET, and DEL commands move through a bounded concurrent execution path.

How

A TCP listener hands work to a worker pool before the key-value engine owns state changes.

Tradeoff

Memory-first access stays direct while TTL, LRU, and AOF make lifecycle decisions visible.

Learning

Concurrency is easier to reason about when transport, execution, and state ownership stay separate.

02 / 02

Real-time product system

Real-Time Collaborative Workspace

Changes move between connected clients over WebSockets. Redis Pub/Sub shares events across Node.js instances while PostgreSQL keeps durable state.

  • WebSockets
  • Redis Pub/Sub
  • PostgreSQL
  • Optimistic UI
Connected2 collaboratorsSynced
Interactive synchronization simulationEdit either window and watch the change sync live.
HHarshsynced
GGuestsynced
Live synchronization pathBidirectional events with separate durable persistence
What

A shared workspace keeps active collaborators in sync without page refreshes.

How

WebSocket sessions publish events through Redis so separate Node.js processes agree.

Tradeoff

Fast optimistic updates improve flow while durable writes preserve recoverable workspace state.

Learning

Realtime UX depends as much on clear event ownership as it does on transport speed.

02What I do

One engineer, across the stack.

01

Product engineering

Interfaces, APIs, and data models designed as one product instead of separate layers.

02

Systems and infrastructure

Concurrent services, real-time communication, caching, persistence, and failure paths.

03

Cloud and delivery

Docker, AWS, Kubernetes, and CI/CD workflows that make releases repeatable.

03Experience

Software that had to work outside a demo.

Product delivery, legacy modernization, internal tooling, and the engineering details that kept each system moving.

  1. Remote, USA

    Community Dreams Foundation

    Software Developer

    Building and maintaining React workflows, REST APIs, task tracking, forms, and user-facing dashboards for volunteer and project operations.

  2. Ahmedabad, India

    Ninja Technolabs

    Software Engineer, Full Stack

    Reworked a legacy billing workflow across React, Node.js, and MySQL, improving how invoices moved through a product used by approximately 3,000 people each month.

    15%fewer invoice propagation errors
    2,000+invoices processed monthly
    28%less duplicate UI code
    70%+test coverage on core flows
  3. Ahmedabad, India

    BrainyBeam Technologies

    Software Engineer Intern

    Consolidated MySQL data for internal search and visualization tools, then improved the CI/CD path from pull request to production.

    20+analysts supported
    35%faster PR-to-production workflow
  4. Ahmedabad, India

    Freelance

    Web Developer

    Built a React and Node.js application with REST APIs and authentication for a startup client.

    25%improvement in Lighthouse LCP

04About

Backend depth, full-stack perspective.

I am a software engineer based in Tempe, focused on backend and full-stack systems. I turn complex requirements into dependable products with clear APIs, maintainable code, and thoughtful data design.

I care about the details that make software easier to operate and easier to change: explicit boundaries, visible tradeoffs, and useful interfaces.

  1. 01Start with the problem.
  2. 02Make tradeoffs explicit.
  3. 03Design for failure.
  4. 04Leave the next change easy.

Education

Arizona State UniversityM.S. Information Technology

2024 - 2025
Tempe, Arizona

Gujarat Technological UniversityB.E. Information Technology

2019 - 2023
Gujarat, India

Tools I use

Languages
C++ · Java · Python · TypeScript · JavaScript · SQL
Frontend
React · Next.js · HTML · CSS
Backend
Node.js · Express · REST APIs · WebSockets
Data
PostgreSQL · MySQL · Redis · MongoDB
Cloud / DevOps
AWS · Docker · Kubernetes · GitHub Actions

05Contact

Have something worth building?

I'm currently open to software engineering opportunities.