Monzo - 1st Stage with Tunde Ganiy

Questions

• How do you make decisions about what is the most important to work on/will have the biggest impact? Do you use data, take feedback from users or is it just a gut feeling or sales driven?
• Knowing that Monzo has a mobile app that is the main thing, will this role be responsible for building the web application for Monzo Business, or there are plans to build those for business and then expand for personal accounts as well in the future
  • What are the features that are currently available and what’s not yet?
• What is the stack for the monzo webapp?
• Knowing that you have one app and different accounts, how do you handle it in your application, do you use feature flags and roles, and hide/block certain features/show different parts of the UI to the user?
• What is the most challenging thing that you are currently working on as a team?

Projects

Webapp

Q: Tell us about a major technical challenge you’ve overcome on a project. What was the issue, and how did you resolve it?
Q: Rewrite of the Webapp

Situation:
At Pfida, I was tasked with redesigning a business-critical, customer-facing application that was plagued by technical debt, poor user experience, and major security flaws. Users encountered convoluted workflows that often led to dead ends, financial data inaccuracies on dashboards, and alarming security risks, including raw passwords and sensitive financial data stored in local storage. These issues led to constant firefighting, draining time from customer service, engineering, and finance teams who were repeatedly addressing the same problems.

To make matters worse, the application was built in Vue 2 with JavaScript, lacked any form of testing, and deviated from the company’s design system and preferred frontend tech stack.

Task:
The main objective was to improve the security of the application, improve user experience and ensure that the application is maintainable. We had to achieve it while keeping the application operational and to avoid disruption to business process, and be able to add new features while we fix those critical problems. I collaborated with backend engineers, product managers, stakeholders to figure out what we can do do improve the user journeys and how they should actually be working and to figure out how we can modernise our tech stack.

Action
To proritise the most pressing issues, I:

• Created a Proof of Concept for a migration solution using microfrontends to strangle out the old Vue application while we fix the issues and improve the application.
• I worked closely with the UX designer to iterate on the UI, to make sure we built accesible and intuitive user flows that met our needs based on the feedback from stakeholders. We had several feedback session with stakeholders making sure that every tweak genuinely solved a problem rather than just adding flair
• I worked with backend engineers to re-design restful APis that supported frontend features efficiently. We wanted to ensure we don’t overfetch data and we only fetch what we need for a particular page/feature. Also to hava a balance between performance and security, we implemented sanitisation and validation of data to ensure correct data is stored in a database.
• To measure performance and gather metrics, I implemented tools for monitoring operformance and we conduted code reviews. It helped us to keep an eye on load times, errors, user engagement metrics and ensure that our refactor didn’t comporimise code quality.

Result:
Our improved boosted user engagement by [number], and dropped the customer support queries related to usability issues and incorrecty data being displayed by [nuimber]. The new design not only improved customer satisfaction, but also generated positive feedback from stakeholders who appreciated balanced approach that I decided to take. This also improved engineering efficiency as more developers were able to contribute to the application, and it expanded the hiring pool.

Reflection
This project just reinforced the belief that it is important to take customer’s feedback seriously and make sure that the product they use is helping them. I also learned the value of coordinating across teams and ensuring that security is built into the process from the start and it is important to take it seriously in environments like financial apps. Next time, I would set up frequent sync outside of the tech team to catch any issues before they become a problem.

Admin panel

Q: Describe a project where you built a customer-facing app. What key considerations (user experience, accessibility, security) did you focus on and how did you implement them?
Q:

Situation: At Pfida, the CTO was manually processing financial data by running Python scripts on CSV/Excel files. This approach was inefficient, prone to errors, and lacked data validation, creating a risk of corrupted data entering the database without a clear recovery mechanism. Additionally, the CTO’s involvement in this manual task prevented them from focusing on high-level strategic initiatives.

Task: I identified an opportunity to streamline this process by building a secure, intuitive admin platform. The goal was to:

• Develop a React-based admin panel to handle data uploads and management.
• Migrate Python scripts to TypeScript, triggering AWS Lambdas instead of using Bash scripts, aligning the tech stack with our existing infrastructure.
• Improve data security through Role-Based Access Control (RBAC) and enforce API authentication using AWS Cognito to protect sensitive financial data.

Action:
To enhance the user experience, I leveraged our design system to ensure an intuitive and consistent UI. On the backend, I rewrote the scripts in TypeScript, reducing dependency on Python and aligning with our team’s core expertise. I also implemented strict data validation and error handling to prevent invalid data from corrupting the database. Additionally:

• RBAC Implementation: I defined granular roles and permissions to limit access to critical operations, ensuring only authorised personnel could modify or view sensitive data. It was working simirarily to how AWS permissions work and by default, everyone had no access to anything.
• Security Measures: AWS Cognito was used to enforce multi-factor authentication (MFA) and token-based API access, strengthening overall platform security.

Result: Within 7 months, we successfully migrated the entire process to the new admin platform and it resulted in:

• reduced time on manual data uploads (as there were barely any)
• Improved data integrity due to strict validation, reducing errors and preventing corrupted data from entering the system
• Increased operation efficinecy, enabling internal stakeholders to see the customer journey and application porcesses, which previously was done via spreadshets and emails
• CTO was actually able to focus on strategic priorities

Reflection: A potential improvemnt could have been exploring low-code platforms like Interval or something like HubSpot, where we could integrate our backend with a CRM. These tools would have allowed us to focus on backend logic, which potentially would reduce development time and would offer greated flexibility without having to maintain our frontend.

Multitenancy app

At Pfida, we had built a specialized Islamic mortgage platform for a single financial institution. Our business team identified a significant opportunity to generate new revenue streams by offering our platform as a white-label solution to other banks. However, our system wasn’t designed with multitenancy in mind, especially on the frontend, which needed to support different branding, themes, and feature sets for each tenant.

I was tasked with designing and implementing a frontend multitenancy solution with a tight deadline of just three weeks to support an imminent business opportunity. This involved creating a system that could dynamically adapt the user interface, branding elements, and available features based on which tenant was using the platform. I needed to collaborate closely with our Head of Tech and Architect, who were primarily focused on the backend aspects of the multitenancy solution.

I approached this challenge methodically:

1. Architecture Planning: I first mapped out the requirements and designed a solution that would allow us to maintain a single codebase while supporting multiple tenants. This was achieved by using Vite to build the same app, but using tenant id to hide features, and grab assets from an S3 bucket.
2. Tenant Identification System: I implemented a tenant identification mechanism using a tenant ID that would be determined at runtime. This ID would serve as the key for all tenant-specific configurations.
3. Feature Flagging System: I created a feature-hiding mechanism based on the tenant ID, allowing us to enable or disable specific features per tenant without maintaining separate codebases.
4. Dynamic Asset Loading: I developed a system to dynamically load tenant-specific assets like themes, logos, and branding elements from remote storage during the build process based on the tenant ID.
5. Deployment Strategy: Rather than attempting to serve all tenants from a single deployment, I implemented a solution where we would use the same codebase but create separate builds and deployments for each tenant, storing them in different S3 buckets with separate CloudFront distributions.
6. Infrastructure as Code: I used Terraform to automate the creation of these tenant-specific deployment environments, ensuring consistency and reducing manual work when onboarding new tenants.
7. Testing Framework: I created a comprehensive testing approach to verify that the correct assets, features, and configurations were being used for each tenant.

We successfully delivered the MVP within the three-week deadline, enabling the business to:

1. Begin white-labeling our platform to other financial institutions
2. Onboard our first new bank customer immediately after completion
3. Generate new revenue streams that weren’t previously possible

The technical outcomes were equally impressive:

1. We maintained a single codebase, avoiding the maintenance nightmare of forking for each tenant
2. The tenant-specific builds ensured optimal performance for each customer
3. Our infrastructure automation made onboarding new tenants straightforward and repeatable
4. The solution was scalable and has continued to be used as we’ve added more tenants

This project taught me several valuable lessons about building scalable frontend architectures:

1. Business-Technical Alignment: I gained deeper appreciation for how technical architecture decisions directly impact business capabilities and revenue opportunities.
2. Trade-offs Management: The tight deadline forced us to make pragmatic trade-offs. For instance, while a true runtime configuration solution might have been more elegant, our build-time approach was faster to implement and still met the business requirements.
3. Future-Proofing: In retrospect, I would have spent more time documenting the system and creating more robust onboarding guides for future developers. As the system has grown, we’ve had to retroactively improve documentation.
4. Infrastructure Automation: The decision to use Terraform from the start was crucial. Had we manually configured the first few tenants, scaling would have become increasingly difficult.

If I were to approach a similar challenge today, I would likely explore more sophisticated configuration management systems and possibly look into micro-frontend architectures that could provide even more flexibility for tenant-specific customisations. I’d also push for more extensive load testing earlier in the process to ensure the approach would scale effectively with dozens of tenants

Talking points:

• Cross-functional collaboration: I worked closely with backend engineers, product managers, and business stakeholders to ensure the technical solution aligned with business goals and backend capabilities.
• Performance optimization: The separate deployment approach for each tenant ensured we didn’t compromise on performance while supporting multitenancy - each tenant got their own optimized build.
• Security considerations: We had to carefully design the system to ensure complete tenant isolation, preventing any possibility of data leakage between tenants.
• Accessibility maintenance: We ensured that tenant-specific theming didn’t compromise accessibility requirements, implementing automated tests to verify contrast ratios and other accessibility metrics.
• Technical debt management: We made deliberate decisions about where to incur technical debt to meet the deadline, with clear plans for paying it down in subsequent iterations.
• Frontend architecture: The project required deep understanding of React, build systems, and frontend deployment patterns to create a solution that balanced flexibility with maintainability.

Design System

At Pfida, we had several applications that were being developed independently with different component libraries and styling approaches. This was causing visual inconsistencies across our products, diluting our brand identity, and creating confusion for users. Additionally, our development teams were duplicating work, with each team creating similar components but with slight variations, leading to inefficient resource utilization.

I identified the need for a unified design system that would serve as a single source of truth for both designers and developers. My primary challenge was to implement a solution that would improve development efficiency, ensure brand consistency, create a more cohesive user experience, and reduce technical debt—all while minimizing disruption to ongoing feature development. Additionally, I needed to convince stakeholders of the value of investing time in this initiative, as it would require upfront resources but deliver long-term benefits.

I took a proactive approach to solving this problem:

1. Stakeholder Alignment: I advocated for the business value of a design system, securing buy-in from leadership by demonstrating how it would accelerate feature delivery and improve user experience.
2. Cross-functional Collaboration: I worked closely with our Senior UX/UI Designer to define design principles, component specifications, and token standards—creating a shared language between design and development.
3. Technology Selection: After careful evaluation, I chose Tailwind CSS for its token system that enabled consistent styling and theming, and Radix UI for its accessibility-focused primitives—creating a modern, maintainable foundation.
4. Token-based System Implementation: I implemented a token-based approach where the exact same design tokens were used in both Figma and our codebase, eliminating guesswork in the design-to-code translation process.
5. Future-proofing Architecture: I separated styling logic from framework implementation by creating “recipes” (styling functions), making the system less dependent on any particular frontend framework and enabling future flexibility.
6. Iterative Development: Rather than building everything at once, I prioritized core components and added new ones incrementally based on project needs, allowing teams to continue feature development while we built the foundation.
7. Quality Assurance: I implemented Storybook as our component library documentation hub and set up visual regression testing through Chromatic, catching visual issues before they reached production.

The design system implementation delivered significant measurable benefits:

1. Development Efficiency: We reduced design-to-implementation time by approximately 20%, and overall feature delivery velocity increased by 15% as measured by features released per quarter.
2. Developer Experience: It improvement developer satisfaction with frontend tooling. Even backend-focused developers were able to contribute to frontend work more effectively, which increased their contribution to the frontend codebase.
3. User Experience: We achieved visual consistency across all applications, and post-implementation user form indicated a 15% improvement in user perception of our applications’ professionalism.
4. Quality Improvement: Component regression issues decreased by 20%, and we saved quite a lot of time per sprint on manual regression testing.
5. Organizational Adoption: Within 9 months, the design system was successfully adopted across all major company applications, and building a new application would be much easier.

This project taught me several valuable lessons. First, I learned that technical initiatives need strong business justification—framing the design system in terms of efficiency gains and user experience improvements was essential for getting stakeholder buy-in.

Second, I discovered the importance of balancing immediate needs with long-term architecture. Our decision to separate styling from implementation initially took more time but proved invaluable when we needed to adapt to new requirements.

If I were to implement a design system again, I would start even smaller—focusing on just color and typography tokens before moving to components. This would allow for quicker initial wins while establishing the foundation. I’d also involve more engineers from different teams earlier in the design phase to ensure we addressed diverse use cases from the beginning.

The most significant takeaway was seeing how a well-implemented design system doesn’t just improve technical aspects but transforms how teams collaborate. By creating a shared language between design and development, we reduced friction and misunderstandings, allowing everyone to focus on creating better user experiences rather than debating implementation details.

Talking points:

• The project directly mirrors Monzo’s need for building user-friendly, consistent interfaces across different products, which is mentioned in the job description as “building accessible and intuitive interfaces.”
• This experience demonstrates my ability to work in cross-functional teams (with designers, product managers, and other engineers)—a key aspect mentioned in both the interview process and job description.
• The iterative approach I took aligns perfectly with Monzo’s stated value of “building products in cross-disciplinary teams using an iterative approach, driven by user feedback and data insight.”
• The implementation of a component library showcases my experience working with modern component-oriented JavaScript frameworks, specifically mentioned as a requirement in the job description.
• The balance I struck between development velocity and code quality directly addresses one of Monzo’s stated requirements: “You understand the importance of prioritisation in your work to ensure a good balance between development velocity and code quality.”
• I can discuss the technical tradeoffs we made (such as choosing Tailwind over other styling solutions, or Radix UI vs. building components from scratch), which addresses the interview interest in “performance/reliability trade-offs.

Interview Tips:

• Focus on technical depth: The interview specifically mentions they want to hear about “data structures, language choices, performance/reliability trade-offs and security considerations.” When discussing your design system project, be prepared to dive into the technical architecture decisions, performance optimizations, and how you ensured security and accessibility.
• Be ready to discuss tradeoffs: Monzo’s interview process explicitly mentions wanting to understand “what trade-offs were made” and “what would you do differently in hindsight.” Prepare specific examples of technical or product decisions where you had to balance competing concerns, and be honest about what you’d approach differently now.
• Frame your experience in terms of customer impact: The job description emphasizes that “This role is all about collaborating with your team to make a difference to your customers.” When discussing your design system work, connect technical decisions to user experience improvements and customer outcomes.
• Highlight cross-functional collaboration: Both the job description and interview process emphasize working with diverse disciplines. Be specific about how you collaborated with designers, product managers, and other stakeholders during your design system implementation.
• Prepare questions about Monzo’s tech stack: The interview description notes that candidates should “feel free to ask engineers on this call how we do things you discuss at Monzo.” Research Monzo’s engineering blog beforehand, and prepare thoughtful questions about how they approach similar challenges to those you’ve faced, particularly around frontend architecture, component libraries, and design systems.

Frontend Architecture

Our team was developing a complex web application that required a robust and scalable frontend architecture. We had inconsistent approaches to frontend development across teams, leading to maintenance challenges, extended onboarding times for new developers, and difficulty in enforcing best practices. There was no clear documentation on technical decisions, creating knowledge silos that impeded collaboration.

I was tasked with establishing a standardized frontend architecture, making all key technology decisions, and creating comprehensive documentation to support rapid onboarding and consistent development practices. This needed to balance performance, developer experience, and long-term maintainability while considering our team composition of both frontend specialists and backend developers who occasionally contributed to the frontend.

I took several strategic actions to address these challenges:

• Technology Selection & Justification: After evaluating multiple options, I selected Vite as our build tool for its superior development experience and fast HMR capabilities. For routing, I chose Tanstack Router for its strong TypeScript support and type safety, which would catch potential errors at compile time rather than runtime.
• Architecture Design: I created a modular architecture that separated concerns and enabled code reuse. This included establishing patterns for state management, API interactions, and component structure.
• Library Selection: I carefully selected complementary libraries that would enhance our development workflow:
  • Zod for runtime type validation and schema definitions
  • Axios with custom interceptors for API communication
  • Tanstack Query for data fetching, caching, and state management
  • MSW (Mock Service Worker) for frontend testing and development without backend dependencies
• Documentation Strategy: I documented all architectural decisions in Confluence, explaining not just what we were using but why we made each choice. This included trade-off analyses, alternatives considered, and the specific problems each technology choice solved.
• Collaboration Model: I intentionally designed the architecture to allow backend-focused developers to contribute effectively to the frontend when needed, improving our hiring flexibility and team adaptability.

Result:
The implementation of this standardized architecture and documentation yielded significant benefits:

1. Improved Developer Onboarding: New developers could get up to speed in days rather than weeks by following our comprehensive documentation, understanding not just how to work within our system but why it was designed that way.
2. Increased Development Velocity: The team experienced a 30% increase in feature delivery speed due to reduced decision fatigue, clear patterns to follow, and enhanced developer tooling.
3. Reduced Technical Debt: By establishing consistent patterns and documentation, we significantly reduced the creation of new technical debt and began addressing existing issues using our new standards.
4. Enhanced Collaboration: Backend developers were able to make meaningful contributions to the frontend when needed, breaking down silos between teams and improving overall product delivery.
5. Better Type Safety: The focus on TypeScript and tools like Zod and Tanstack Router led to a measurable reduction in runtime errors and improved the reliability of our application.

Reflection
This experience taught me several valuable lessons about technical leadership and architecture design:

First, I learned that documenting the “why” behind decisions is just as important as the “what.” When new team members understand the reasoning, they can make better decisions within the established framework.

If I were to approach a similar project again, I might introduce more gradual technology transitions. While our selections worked well, the rapid adoption created some short-term challenges that a more phased approach might have mitigated.

I also realized the importance of balancing pragmatism with innovation. By choosing tools like Vite rather than more opinionated frameworks like Next.js, we gained flexibility but took on more responsibility for architecture decisions. For future projects, I would make this trade-off analysis even more explicit, considering team size and composition.

Finally, I’ve learned to continuously reassess technology choices as projects evolve. What works well for an early-stage product might not be optimal as it scales, and architecture should evolve accordingly. I now build in regular architecture review cycles to ensure our technical foundation remains appropriate for our current needs.

Questions

Why do you want to work with us

• Values align very well. I care about the customers/users and this is what you care about too.
• I also have a feeling that I might have the same mindset as others at Monzo, which is focusing on the things that have the biggest impact for customers, team and the business overall.
• I spent some time going through your blog, and I got the feeling that there’s a great engineering culture, good processes in place, colaborative and people try to help each other

Can you share an example of when you collaborated with cross-functional teams (e.g., designers, backend engineers, product managers) to deliver a project? What challenges did you face and how did you overcome them?

Tell us about a time when you worked closely with backend engineers to design or integrate an API for a new feature. What were some of the trade-offs you had to consider?

Describe a scenario where you had to balance fast development speed with maintaining high code quality. How did you approach this trade-off?

Can you discuss your experience with modern JavaScript frameworks (like React, Vue, or Angular) and how you decide which tool is best suited for a project?

Share an example of how you ensured performance, accessibility, and security in a web application you built.

Tell us about a time when you iterated on a feature based on user feedback and data insights. How did you incorporate these insights into your development process?

How do you stay current with emerging web technologies, and can you give an example of when you integrated a new technology into a project?

What is your working style?

Projects