Designed strategic product roadmaps by identifying key user pain points and prioritizing features. For example, I developed a roadmap for the autoswap payment feature to address transaction cancellations on the P2P trading platform, ensuring alignment with user needs and business goals.

Enhanced user flows for the P2P trading platform through biweekly competitive analyses of competitor products against Binance's features and new user interviews, recommending optimisations and areas of enhancement through user pain points identified from the studies.

Worked across growth, operations and product teams to align on objectives for the India, Pakistan and Bangladesh markets, reporting weekly on product metric updates and what adjustments the team can make to maintain or improve performance of the platform.

Familiarity with JIRA and Confluence for task tracking, documentation, and managing product development workflows, such as deriving a PRD (Product Requirements Document) for the autoswap payment method feature.

Monitored and analyzed key performance metrics such as order cancellation and order conversion rates to assess feature impact and guide data-driven decision-making with the operations team.

Utilised as the main tech stack across all the projects I worked on. On the frontend React with TanStack, Next.js and Axios was mainly used for routing, implementing tables and querying data objects defined in interfaces to fetch data from the Nest.js backend API. Nest.js was used to define API controller logic, such as validating if a user is logged into the system or not. From an HTTP request to the Nest.js backend controller through Axios, most controllers implemented would then make a call to a service class where the core business logic of the system is defined, such as processing the logic for a user that is subscribing to a new product plan after they have made payment. This would typically involve multiple data objects where TypeORM's Entity defined classes come in handy, with all data objects easily instantiated in the service classes to fetch database data without any SQL code (for CRUD cases) before returning it to the Nest.js controller and finally to the Next.js frontend server.

Practiced by developing a separate Flask server to handle asynchronous execution of a Python-based machine learning (ML) algorithm for the city district cooling system planning app. The flask server was deployed on a dedicated web server where it received requests from the Nest.js backend, triggering the ML algorithm to process input data (e.g. district energy consumption) and generate an array of outputs representing the recommended distribution of cooling appliances for a given district. These outputs were then converted to JSON format and sent back via API response to the Nest.js backend, where the JSON would be parsed, stored into the database with TypeORM and made available to the frontend for data visualisation with the Recharts library.

Familiarised with Docker and AWS EC2 to deploy an instance of a city district cooling system planning tool for a client demo. The EC2 instance was managed via SSH with a Linux terminal, where Nginx was configured as a reverse proxy to route traffic to the Next.js app and Flask server ports. PM2 was also used to keep the Next.js server continuously running without downtime. As for Docker, a simple CI/CD script was set up such that new Git pushes to production would build and push new container images to a AWS ECR registry, automatically pulling the new images and restarting the existing containers running the Next.js and Flask servers using docker-compose. This way, new code pushes to production would then automatically update on the client demo instance.

Practiced by developing RESTful APIs in Nest.js for the mailer system and city district cooling app, including defining endpoints for EDM communications, transaction notifications, and implementing Role-Based Access Control (RBAC). This involved structuring routes, handling HTTP methods (e.g. GET/POST/PUT), validating inputs, ensuring scalability with TypeORM for data persistence, and defining user roles and permissions via guards or middleware to restrict access (e.g. admin-only views for analytics), thereby securing API endpoints before processing requests or returning data.

This was actually the first thing I fully owned and worked on as an intern. I practiced this by building the in-house mailer system with Handlebars.js to generate dynamic HTML templates for marketing, subscription orders, transactional emails and more. The contents of the email would be coded in HTML using Handlebars.js used to insert information like user or order details in curly braces {{}}. I also had to take note of cross-platform compatibility, where certain CSS styles were not supported in older versions of Internet Explorer or Outlook. Campaign Monitor https://www.campaignmonitor.com/css/ was found to be a great resource for drafting these emails.

To handle notifications efficiently, the observer design pattern was implemented using the Nest.js Events module for an event-driven architecture. Services like the SubscriptionService class emitted events as publishers e.g., 'user.subscribed' or 'order.placed', while subscriber methods decorated with @OnEvent() e.g. @OnEvent('order.placed') in the mailer service listened to trigger email sending. This decoupled notification logic from other core business processes, where Handlebars.js email templates could be rendered with event payload data and compiled into HTML, with emails being dispatched via the Nodemailer library as the email provider.

Towards the end of my time at Red Airship, I was thrown into a high-pressure Drupal project where a team of about 8 devs faced a 2-month crunch to meet missed deadlines, stalled by messy Figma designs from the client’s external vendor with vaguely defined component logic.

To unblock progress, I arranged calls with the vendor and client to clarify and detail component requirements, translating them into clear user stories and reprioritizing tasks to tackle no-blocker items first for async work among devs. For stories with complex dependencies affecting other devs, the engineering manager would step in to assign these complex stories to senior devs first, with senior devs handling the code review of the stories affected and implemented by other devs.

Once features were implemented, I conducted QA by testing them against acceptance criteria for accuracy, debugging any module conflicts or rendering errors. As a team, these efforts boosted our sprint velocity from 75 to 140 points per sprint, almost double the velocity. I was proud to be a part of this moment, as it ultimately stabilised the key deliverables for the project handed over to the client.

I practiced the Agile methodology by working closely with product designers especially in the early phases of projects to translate client requirements into user stories. These user stories would then be prioritized during sprint planning meetings, where I would be assigned development tasks in each sprint.

Development in each sprint would typically involve creating a new feature branch for me to start coding, followed by submitting a merge request on Git for a senior engineer to conduct a code review. This was where most of the learning would take place, where I would correct any errors in coding logic or ensure adherence to best coding practices.

After resolution of all merge request comments, the senior engineer would then merge my feature branch into the dev branch. This always leaves me with a real sense of satisfaction everytime, knowing my implementation is production-ready. Features implemented would then typically be demoed in sprint reviews for feedback, driving continuous improvement each sprint.