Farhad
A working record Edition 2026 · Dhaka, Bangladesh

Md Farhad Hossain

Frontend Engineer / Design Systems

I build production frontends — complex product UIs, and the design systems that hold them together.

5+ years building data-dense dashboards, web platforms, and design systems — currently core engineer on Wick UI, QuestionPro's published design system.

Read the record Résumé Get in touch
5+
Years in production frontend
47+
Components shipped
3
Companies · remote & in-office
Open to senior roles
Availability

Selected Impact

What I shipped, and why it mattered.

  1. QuestionPro 2024 — present

    Wick UI — a design system as a product

    Turned duplicated, drifting UI across several products into one published, tested, accessible source of truth.

    • 47+ Components in production
    • 500+ Commits
    • 56 / 51 Test suites / Storybook stories

    React · TypeScript · Radix UI · Tailwind CSS · CSS Modules · CVA · Storybook · Vitest · Playwright

    Read the case study
  2. QuestionPro · Wick UI 2024 — present

    The Data Grid — performance under real interaction

    Built the system's most complex component so it stays smooth on large datasets while supporting every interaction product teams asked for.

    • 1 Generalised API, many products
    • Large Datasets, kept smooth

    React · TypeScript · TanStack Table · react-virtuoso · CSS Modules

    Read the case study
  3. Versai · Palo Alto, CA 2021 — 2024

    Versai — faster, more consistent delivery

    Replaced per-feature UI rebuilds with one shared component library and pre-commit quality gates — so a small remote team shipped faster, with fewer regressions and a consistent UX across the product.

    • 4 Core surfaces shipped
    • 3 yrs On the core product
    • Fewer Regressions, via lint + gates

    React · Next.js · TypeScript · React Query · Redux · Tailwind CSS · Storybook

    Read the case study

How I Think

The calls I make under pressure.

  1. Think in systems, not features.

    I weigh how a solution fits the bigger picture and scales over time — platforms and shared patterns over one-offs.

  2. Understand the problem before the solution.

    I work from first principles — why it works, not just how — and question assumptions before I build.

  3. Build for the person using it.

    I start from the user's path — the fewest steps, clear affordances, access without friction or confusion.

  4. APIs that can't be misused.

    Predictable, well-typed props that behave the same across the system — easy to adopt, hard to hold wrong.

  5. Optimise for the next engineer.

    Readable structure over clever tricks; shared components and gates whose developer experience compounds on every later change.

  6. Performance is a feature — and it's measured.

    Speed is part of the product. I profile before I optimise, so I fix the cost that's actually there.

  7. Quality is built in, not bolted on.

    Tests aimed at what breaks a release, and accessibility by default — keyboard, focus, semantics, RTL.

  8. Learn from what works, choose what fits.

    I study how mature products solved it and stay close to modern tooling — proven patterns and the right tool, not hype.

Building Systems

Built to outlast the feature.

Architecture

Headless primitives for behaviour, owned tokens and markup for the rest. Explicit state so features compose.

Component libraries

Built as products — typed APIs, tree-shakeable packaging, releases that don't break consumers.

Documentation

Storybook as living docs. If it isn't documented, it isn't shippable.

Testing

Vitest + Testing Library for logic, Playwright for interaction — aimed at what breaks releases.

Maintainability

Conventions and gates that make the consistent thing the default path.

Collaboration

Built with UX, backend, and product — a system has to reflect how teams actually ship.

Experience

Five years, three teams.

  1. QuestionPro

    2024 — present

    Software Engineer · Dhaka, BD

    Core engineer on Wick UI, the published design system — Data Grid, 47+ components, tests and tooling. Earlier: survey-analytics dashboards.

  2. Versai

    2021 — 2024

    Software Development Engineer · Palo Alto, CA · Remote

    Built platform surfaces — admin dashboard, website builder, templates, video conferencing — plus a reusable component library and the tooling around it.

  3. Crosscope

    2020 — 2021

    Frontend Developer · Mountain View, CA · Remote

    Scalable, reusable frontend modules with structured state management; refactored core UI and raised test coverage on key components.

Runner-up Wick Office Hackathon #1, 2026 Solo build — a Dockerized office-request portal (web + PWA) with instant push notifications to staff phones.

The Stack

Tools I trust in production.

Languages
TypeScriptJavaScriptHTMLCSS / Sass
Frameworks & libraries
React 18Radix UIBase UIFloating UIreact-virtuosocmdkMotion / Framerdate-fns
State & data
ReduxZustandReact QueryTanStack Table
Styling
Tailwind CSSCSS ModulesCVAtailwind-mergeDesign tokens
Testing
VitestTesting LibraryPlaywrightjsdomV8 coverage
Build & tooling
Vitevite-plugin-dtsStorybookPrettierpnpm workspaceslint-stagedcommitlint
Practices
Design systemsnpm publishingWCAG a11yRTLi18nAI-assisted dev

Writing

Lessons, written down.

Themes Performance & InternalsFrontend Architecture

  1. Article dev.to Performance & Internals

    How JavaScript engines optimize objects, arrays, and maps

    Predictable, intentional data shapes beat micro-optimizations — because hidden classes and inline caching reward consistency, not cleverness.

    Written from performance work where the fix was structural, not a trick.

    Read
  2. Article dev.to Frontend Architecture

    Mouse events: why your UI flickers

    Hover flicker isn't a CSS bug — it's mouseover/mouseout bubbling. mouseenter/mouseleave model interaction state the way you actually meant it.

    A production hover bug that turned into a clear rule for interaction state.

    Read
  3. Deck slides Performance & Internals

    Scope, execution context & closures

    Closures stop being magic once you see variable resolution as something the engine decides at parse time, not run time.

    An engineering deck used to teach the model behind the behaviour.

    Read

Working Together

How I show up on a team.

What you can expect

  • What I hand off is typed, tested, documented, and hard to misuse.
  • I take ownership of outcomes, not just tasks — the product and the engineering process.
  • I build foundations and standards that make the whole team faster, not just ship my own features.
  • Decisions in the open — the trade-off and the reason, written down.

How I collaborate

  • Close, daily work with UX, backend, and product.
  • Align on the API and trade-offs early, not in review.

Where I do my best work

Teams that treat the frontend as a system worth investing in — where quality and DX are shared values, with real surface area to own.

What I'm looking for

Senior / lead-track frontend roles in design systems, component libraries, and complex UI.

Get in touch