Subash.

Rupandehi, Nepal

Subash PandeySoftware Engineer~1.5 years at Reduct Nepal · Team of 2–3 · QA → engineer

I build at Reduct Nepal on Programiz (Playground, Guided Projects) and CaseCamp—cloud IDE execution, step-by-step learning, and legal discovery workflows for real clients.

  • Programiz products
  • Cloud IDE
  • US-facing client
  • Go builds ~64% faster

Go in production, not just tutorials. Full-stack slices when the team is tiny—frontend, APIs, GCP, and the conversations around scope.

About

Who I am in four lines

If this section works, you know the employer, the arc, and the products before you scroll—proof lives in Experience.

  • Software engineer at Reduct Nepal (~1.5 years): started in QA on Programiz Playground, then shipped on execution backends, Guided Projects, and CaseCamp.
  • Team of 2–3—I've owned routes and components, APIs, GCP deploys, and calls with a US-based client and public defenders when the work required it.
  • BIM background; before this role I led the college IT club and volunteered with AWS Cloud Club Nepal—early practice explaining tech to people who were stuck.
I didn't grow through a structured ladder—I grew through partial handovers, unclear specs, and figuring things out mid-flight.
  • Before industry

    Hackathons and community events where I wasn't the most senior person in the room. Bulletin (Web3): I helped on a whitepaper with someone already in the ecosystem. It didn't ship; it taught me pressure, vague direction, and how to keep moving anyway.

  • How I work

    I write API notes and workflow diagrams so the next person isn't replaying the same Slack thread. I join client conversations when expectations need translating into something buildable. I onboard interns with seniors in the loop.

  • Where I'm headed

    More project coordination and people leadership, with engineering judgment underneath—clarity on scope and handoffs, not résumé polish.

Skills

Capabilities

Technical stack below; coordination is where I keep showing up when the team is small and the interface between people and code gets fuzzy.

Building

What shipping work has actually required

  • Node.js & Go

    Playground execution path; Node→Go migration context; compile time cut from ~6.16s to ~2.2s on our codebase

  • PHP & Java (Spring Boot)

    Jumping into existing codebases and integration-heavy changes

  • REST & services

    Endpoints, contracts, boundaries the next reader can follow

  • SQL & NoSQL

    Modeling and querying what the product actually stores

  • Cloud & deploys

    GCP in CaseCamp and related work; AWS fundamentals from coursework and community

  • Testing & QA

    Where I started—execution across languages in a cloud IDE, thinking like a user

Coordination & communication

Where I spend time beyond the PR

  • Project coordination

    Tracking parallel work across a tiny team when there's no dedicated PM

  • Documentation & workflows

    READMEs, handover notes, internal docs so knowledge isn't trapped in one thread

  • Client-facing work

    Listening, translating trade-offs, following up so scope stays honest

  • Supporting juniors

    Walking interns through workflows with seniors in the loop

  • Agile habits

    Standups and planning as alignment tools, not ceremony for its own sake

Experience

Proof: products, metrics, ownership

Intern → engineer at the same company. Same products you saw above—here's what I actually did on them.

  1. March 2025 – Present

    Software Engineer

    Reduct Nepal Pvt Ltd.

    • CaseCamp: discovery at scale, US-facing client

      Legal teams upload large discovery sets; the product builds a sourced chronology. I worked on frontend structure, backend APIs when needed, and GCP deployments—often alongside a US-based client and public defenders. Two to three people covered the stack; if something blocked release, you stepped in.

    • Go compile time: 6.16s → 2.2s (~64%)

      I reworked concurrency handling in our Go codebase and measured the win: about 6.16s down to about 2.2s compile time. Review-backed change—I'm glad to walk through what I touched and how we verified it.

    • Guided Projects: shipped a beta in ~3–4 months

      Integrated Programiz Playground into Guided Projects—execution tied to lesson steps, checks on whether users followed instructions, backend tests comparing expected vs actual code. Beta shipped in roughly three to four months while we kept Playground running with a skeleton crew.

    • Playground execution: Node.js → Go

      Backend execution for the cloud IDE moved from Node.js to Go. I read what existed, extended work others had started, and learned Go while pushing toward feature parity with the Node path.

    • Docs, handovers, and parallel tracks

      API notes and workflow diagrams for internal use and client handovers. Multiple workstreams at once. Client conversations where stakeholders don't live in the repo. Onboarding interns with context so they weren't stuck on repeat questions.

  2. Dec 2024 – March 2025

    Software Engineer Intern

    Reduct Nepal Pvt Ltd.

    • QA on Programiz Playground (cloud IDE)

      Tested execution across programming languages—user-shaped scenarios, not only happy paths. Learned how small runtime inconsistencies turn into painful incidents when usage scales.

    • READMEs and system notes

      Wrote docs so the next teammate could orient without replaying the same chat explanations.

    • Team and client discussions

      Joined meetings early, listened first, turned feedback into concrete next steps.

Projects

Things I have built or contributed to

Some are public repos, some are internal. I'm not claiming decade-long product sagas—just problems, what I did, and what I learned.

  • SastoDeal Revamp

    View on GitHub
    Problem
    E-commerce platforms pick up complexity quietly—endpoints multiply, shortcuts stack, and "later" becomes structural debt.
    Solution
    During Leapfrog Revampthon 2023 I focused on backend structure: clearer boundaries and room to grow for a major Nepali e-commerce scenario.
    Tech
    Backend focus · API thinking · Hackathon scope
    Outcome
    Hackathon scope—practice in how I'd untangle a real marketplace's growth pain, not a shipped production rewrite.
  • Miti — The Nepali Calendar

    View on GitHub
    Problem
    Living between calendars shouldn't feel like a spreadsheet chore. People wanted Nepali dates in daily life without abandoning tools they already use.
    Solution
    An open-source PWA for Nepali calendar tracking with Google Calendar sync—collaborative, incremental, and focused on usability.
    Tech
    Progressive Web App · Calendar sync · Open source
    Outcome
    A modest PWA for real schedules—Nepali dates and observances with Google Calendar sync, built in public with other contributors.
  • Bulletin (early experiment)

    Did not ship
    Problem
    A startup idea in the Web3 space needed clearer writing and structure before anyone could seriously evaluate it.
    Solution
    I contributed to a whitepaper alongside someone already in the ecosystem—support work on an idea that might or might not fly.
    Tech
    Research writing · Early-stage collaboration
    Outcome
    The product didn't launch. I still count it: pressure, unclear direction, and learning you can keep moving even when the outcome isn't guaranteed.
  • Build pipeline tightening (internal)

    Private / internal
    Problem
    Slow builds add friction. In a small team, that friction shows up as context-switching and subtle drag on morale.
    Solution
    I dug into bottlenecks with guidance from the team, adjusted concurrency, and checked the result with numbers so the improvement was obvious, not anecdotal.
    Tech
    Go · Concurrency · Profiling & measurement
    Outcome
    Faster compiles and a repeatable habit: profile, change, measure, explain.
  • API & workflow documentation

    Private / internal
    Problem
    When knowledge lives only in chats and one-off explanations, handovers get expensive—internally and with clients.
    Solution
    Structured API notes, simple workflow diagrams, and handover writeups so the next person could act without a live tour of the repo.
    Tech
    Technical writing · Diagrams · Handover support
    Outcome
    Fewer repeated questions on handovers; smoother transitions when someone new picked up the thread.

Leadership & community

Practice outside the office job

Mostly student and volunteer spaces—different from managing a payroll, but real reps for organizing, teaching patience, and helping people take a next step.

  • September 2024 – January 2025

    Lumbini Province Lead

    AWS Cloud Club Nepal

    Volunteer community work: organizing sessions and helping beginners get unstuck—patience, clarity, and logistics at province scale.

  • March 2023 – July 2024

    President

    IT Club (Oxford College)

    Running events and the boring behind-the-scenes work so a college tech club felt alive. That's some of my earliest real "people + planning" reps.

  • March 2023 – July 2023

    Deputy Community Builder

    Coding Olympics Nepal

    Supporting outreach and community programming—connecting competitive practice with people who needed a gentler entry point.

Certifications & milestones

Short list, honest weight

A few structured courses and events. They mattered to me; they don't replace shipping work or learning on the job.

  • AWS Academy Cloud Foundations
  • Java Internship Program (CodeSoft)
  • HackerRank SQL Certificate
  • HIPAA Compliance Training
  • Coding Competition — 2nd Runner-up
  • Hackathon participation (MBMC IdeaX)

How I work

Habits under load

What I reach for when trade-offs, handovers, or fuzzy debates show up—patterns, not a playbook.

  1. 01

    Habit

    Ask who needs to understand next

    Teammate next week or client who won't open the repo—I name the audience first, then shape the explanation. Early career means I'm building the reflex, not lecturing from a playbook.

  2. 02

    Habit

    Prefer changes I can explain

    Big surprises make bad Tuesdays. I like increments that can be reviewed and reasoned about, even when I'm eager to move faster.

  3. 03

    Habit

    Use numbers when the debate is fuzzy

    Not everything should be a metric. But when we're arguing about speed or reliability, I want something comparable before and after—not just confidence.

  4. 04

    Habit

    Stay in the problem long enough

    I don't need to know everything on day one—but I try not to bounce out the moment something is uncomfortable. Some of my best lessons came from partial handovers and unclear specs that needed patience, not a clever exit.

  5. 05

    Habit

    Write it where someone will find it

    If it only lives in my head or one thread, I haven't done my future self—or anyone else—any favors.

Contact

If you are hiring for engineering, coordination, or something in between

I am open to roles where I can keep growing technically while doing more of the planning and people-facing work I already gravitate toward—or to simply swapping notes with folks who care about the same problems.

No public email here—spam wins too often. If you message on LinkedIn with a line about what you are working on or hiring for, I will reply in kind. Happy to move to email once there is a real thread.