Jaipur, India — connect@himanshumali.in

●Craft

How I think, build,and lead.

Three chapters: engineering principles, problem-solving practice, and community work. The things that shape how I write code — and how I show up for other people learning to.

I

Engineering Philosophy

I write backend code meant to run for years, not days. Correctness and observability first — performance tuning second, once I know which parts matter.

The best systems I’ve shipped had boring architectures and relentless attention to the boring parts: schema design, access control, error propagation, and latency budgets.

Make the implicit explicit

Implicit assumptions cause incidents. Document constraints in code — types, guards, database constraints — not just docs that drift.

Boring is a virtue

Proven patterns over clever ones. The interesting problem is the business logic, not the framework.

Schema is design

A well-normalised schema with clear invariants forces correct application logic. A messy schema creates perpetual workarounds.

Observability is not optional

Structured logs, latency histograms, and meaningful error messages before the first production deploy.

How I approach a new system

  1. 01

    Requirements & constraints

    Throughput, latency SLOs, consistency requirements, and failure modes — before touching the data model.

  2. 02

    Domain model

    Entities, invariants, and the relationships that need to be enforced at the database layer.

  3. 03

    API surface

    Resource boundaries and contract definition — what callers need, what the system guarantees.

  4. 04

    Failure modes

    Explicit decisions for every external call: retry budget, circuit-breaker threshold, fallback behaviour.

  5. 05

    Observability plan

    Metrics, structured logs, and alert thresholds agreed before the first deploy.

Working materials

Languages
JavaScript / TypeScript, Python, C, C++
Runtimes
Node.js, FastAPI (Python)
Databases
PostgreSQL, MySQL, MongoDB, Redis
Infrastructure
Docker, Oracle Cloud, AWS, Nginx, PM2
APIs
REST, Stripe Connect, Twilio, Web3Forms

II

Problem Solving

Competitive programming is where I sharpened my ability to break problems down fast. The habit carries directly into debugging production systems and designing APIs.

  1. LeetCode

    200+ problems solved across data structures and algorithms, with a focus on arrays, trees, graphs, and dynamic programming. Contests weekly to keep the under-pressure thinking sharp.

    Arrays · Trees · Graphs · Dynamic Programming

  2. Codeforces

    Rated contests from Div.4 upward. Competitive programming is where I learned to trust my intuition on complexity bounds and to write correct code under time pressure.

    Rated Contests · Greedy · Number Theory

  3. GeeksforGeeks

    Used primarily for concept depth — operating systems, DBMS, system design fundamentals, and interview preparation. GfG’s structured track helped cement the theoretical base.

    OS · DBMS · System Design · Core CS

The method

The same pattern applies whether the input is a Codeforces problem or a bug report from a production system.

  1. Understand the contract

    Read inputs, outputs, and constraints before writing a single line. Misunderstanding the problem wastes more time than any slow solution.

  2. Find the invariant

    There is always a property that holds at every step. Name it explicitly before picking a data structure or algorithm.

  3. Brute-force first

    A slow correct solution proves the problem is understood. Optimise from there — not from an abstraction built on speculation.

  4. Complexity accounting

    Time and space complexity written out before coding. Not as ritual — as a check that the approach will actually fit.

Arrays & Strings/Recursion & Backtracking/Trees & Graphs/Dynamic Programming/Greedy/Hashing/Sorting & Searching/System Design

III

Community & Leadership

Coder’s Cafe is the technical community at my college. I joined in 2023 and have been running it since 2026. Four years, four different roles.

  1. President

    2026 — Present

    Coder’s CafeCurrent

    Running the club now. Responsible for the overall direction — events calendar, workshop quality, member development, and keeping the energy high for people who came through the same path I did.

  2. Vice President

    2025 — 2026

    Coder’s Cafe

    Supported club operations, coordinated with faculty, and took point on larger events while developing the next tier of workshop facilitators.

  3. DSA Head

    2024 — 2025

    Coder’s Cafe

    Designed and ran the club’s DSA curriculum: weekly problem sessions, breakdowns of core patterns, and contest prep. The teaching forced me to understand things at a level that private practice alone never would have.

  4. Member

    2023 — 2024

    Coder’s Cafe

    Joined in my first year, attended workshops, participated in the contest series, and started building the habits that compound: showing up consistently, asking questions out loud, helping others debug.

The people who taught me didn’t wait until they were experts. Neither do I.

Questions about how I work or what I’ve built? Send a message — or see the experience page for the professional context.