CHENGHONG MENGFull-Stack Developer, with AI applied mindset | SF Bay Area

Designed and developed internal systems for session scheduling, wellness digitalization, goal progress tracking, batch reporting,and compliance workflows across multiple roles and campuses.6200+ contributions from May 2022 on GitHub

Managed user center and developed KYC verification flow for a cryptocurrency trading platform supporting 68k+ users, ensuring secure and compliant onboarding while maintaining a seamless user experience.

I am a full-stack developer with 5+ years of experience, mainly focused on backend systems: schema design, data integrity, versioning, query optimization, caching, async tasks, load balancing, and pagination. I also care about frontend performance, especially lazy loading, virtualization, debouncing, and throttling. Before engineering, I spent 6 years in medical research, which is why I remain especially interested in life science and healthcare domains. My curiosity and ability to break down complex issues into manageable parts help me achieve tasks across various subjects and industries

In my last job, HR was managing PTO entirely in Excel. The core pain point: PTO requests and actual consumption were separated in different sheet without state linked up— when employees requested time off but didn't take it, HR had to manually refund balances by digging through logs. UTO deductions from payroll were tracked separately. Carry-over calculations were manual. Every edge case landed on HR's desk.When I got this assignment, I modeled it as a ledger system — every PTO event as an immutable transaction rather than a mutable balance field. That single design decision solved multiple problems at once: audit trail came for free, request vs. consumption became two separate transaction types, refunds and UTO deductions were just negative entries, carry-over was a scheduled reconciliation job.Then I built department admin tooling on top — allowing admins to backfill records by cross-referencing remote and attendance logs.At the end, HR stopped doing manual reconciliation. Refunds, UTO deductions, and carry-overs became automated. Audit trail meant any discrepancy could be traced to the source transaction instantly.

we were told, "we want to use AI," but there was no actual spec. I started by mapping the reporting workflow and the available data, then reframed the problem from "build a chatbot" into a structured data-to-text pipeline. I broke execution into stages: data normalization, prompt construction, model invocation, and output validation. The main tradeoff was local versus cloud model routing, so I designed a routing layer that defaulted to local models for predictable structured inputs and used cloud models for harder cases. Guardrails and human review were added before any output could affect an official report. That design projected about a 33% reduction in clinician documentation time and stayed model-agnostic for future upgrades.

I have owned a scheduling engine, a quarterly compliance reporting system, and a PTO tracking system in production. The strongest example is the scheduling engine: I gathered requirements directly from stakeholders, designed the data model from scratch, and built the system across schema, backend services, and admin-facing views. The main design challenge was separating recurring weekly sessions from daily actuals that needed to change in real time. Operationally, the system was deployed on AWS ECS through GitHub Actions with staging on merge, controlled production promotion, and CloudWatch-based monitoring and alerts.

About six months into a role, I inherited a broken quarterly reporting system after the lead developer left, with no documentation or handoff. The visible problems were data integrity issues, concurrent write conflicts, and incorrect ER mappings. I had to decide whether to patch symptoms or refactor more aggressively. I chose to rebuild the data model foundations instead of layering fixes on top, because patching would have increased complexity without removing the root cause. The refactor stabilized the system in production, eliminated recurring integrity issues, and later made it possible to build reliable AI orchestration on top of clean input data.

Our ops team ran all scheduling — student sessions, provider availability, PTO, co-treat coordination — in a shared Excel sheet. Multiple people editing, data always stale, conflicts invisible. The ask was essentially "make it better than Excel." No spec, no wireframes.I ran separate conversations with each stakeholder group first — admins, clinicians, paras — because their mental models of "the schedule" were completely different. The hardest design question was how to model recurring weekly sessions against daily actuals that needed to flex in real time based on attendance and PTO. I built a two-layer data model to separate those concerns, then brought edge cases back to stakeholders iteratively to validate business rules before locking the schema.At the end, I replaced the spreadsheet entirely. Conflicts that were previously invisible now surface automatically. Admins got a live weekly view; providers and paras saw only what was relevant to them.

One production issue I debugged was severe frontend performance degradation in a React + Laravel application used internally by clinicians.Users reported browser freezing, typing lag, and unstable autosave behavior, especially when multiple tabs were open for long periods.My role was the primary engineer investigating the issue.Initially, it looked like an autosave or API problem, but after profiling with React DevTools and Chrome Performance tools, I found the real issue was massive unnecessary re-renders caused by unstable object and array references being recreated on every render.Because users often kept many tabs open simultaneously, small render inefficiencies multiplied into major CPU spikes.I fixed it by stabilizing prop references, memoizing derived data, and reducing cascading state updates. After the fix, CPU usage and typing latency dropped significantly, and autosave became stable again.The biggest lesson was not to trust the most obvious symptom in production debugging. The visible issue is often only exposing a deeper systems problem.

I usually take the structuring role. When work is ambiguous or fragmented, I start decomposing the problem, identifying dependencies, and clarifying execution order so the team can move without getting stuck in uncertainty. I do not try to dominate discussion for its own sake, but I naturally step in when technical direction is fuzzy or momentum slows down. A lot of my value comes from connecting architecture, debugging, and implementation detail into a workable path forward.

I start from the source: find the entry points, trace the data flow, and identify the interface contracts before worrying about surface syntax. One example was a SaaS platform with thin documentation and a proprietary DSL that had already consumed significant budget before I joined. I treated it like any unfamiliar system, read the source code directly, traced where custom logic could be injected, and then implemented the required workflow with plain JavaScript at the right hook points. The project shipped in two weeks without paid support. My general view is that unfamiliar systems are usually not inherently hard; the bottleneck is disciplined reading and decomposition.

In my last role, We were rebuilding the session note system for the vision service. Neither my lead nor I had domain expertise in vision therapy, so before our first meeting I asked the stakeholder — a senior education admin — to prepare written examples and workflow outlines in advance. We also documented discussions carefully to reduce ambiguity.During early reviews, we realized a recurring issue: requirements kept shifting, terminology was interpreted differently, and both sides were spending a lot of time translating domain-specific expectations into engineering changes.That experience led me to a bigger insight: the core problem wasn't communication quality alone — it was that engineering had become a bottleneck for domain configuration.So instead of continuing to hardcode workflows, I designed a generalized self-service note template system. Education admins could directly configure, adjust, and publish note pools for their own domains without requiring engineering involvement for every change.What I learned is that when working with domain experts, my job isn't to become the domain expert myself. My responsibility is to understand the problem class well enough to build abstractions and tools that give domain experts direct control. That removes an entire category of translation and coordination problems at the system level.

In my previous role, we had a scheduled job that generated approximately 2,000 session records at a time. The job read recurring schedule data from a parent table and created corresponding records in child tables for the upcoming week.Initially, the entire process took around 12–15 seconds, which was longer than expected and created noticeable load during execution.I was responsible for identifying the bottlenecks and improving the overall performance of the job.I conducted code review and discovered a classic N+1 query issue. Laravel Eloquent was lazily loading related models inside a loop, which resulted in hundreds of unnecessary database queries.To address this, I replaced the lazy loading pattern with eager loading using with(), allowing the related data to be retrieved in a single query.After implementing that change, the execution time dropped from roughly 12–15 seconds to 7–8 seconds.I then investigated the remaining bottleneck and found that the bulk insert process was creating significant memory pressure and I/O spikes because a large number of records were being held in memory before writing to the database.To solve this, I introduced chunking and processed the data in smaller batches, which reduced memory consumption and smoothed out the database writes.After both optimizations, the job execution time was reduced from approximately 12–15 seconds to 3–5 seconds, representing more than a 60% improvement.More importantly, the job became much more stable and predictable under production load