Example job post · Fictional company
Frontend engineer
Northwind Pay
What we read
Northwind Pay is a fictional payments company used only for interview practice. We help small online shops understand settlements, investigate failed payments and reconcile refunds without a finance department. This example vacancy is not a real opportunity. We are looking for a frontend engineer who can make complex financial workflows understandable while keeping the interface predictable when services are slow. Our merchant dashboard uses React, TypeScript and a shared component library. Backend teams expose versioned REST APIs, and Playwright covers the main checkout and refund journeys. You will work alongside a designer, a payments engineer and a support specialist. We favour small releases with feature flags, written trade-off notes and feedback from merchants before extending a workflow to everyone. Your responsibilities include building accessible payment and refund forms, modelling pending, successful and failed transaction states, and making recovery paths clear. You will prevent duplicate submissions during slow network responses, preserve useful input when validation fails, and help users distinguish an unavailable balance from a zero balance. You will also investigate dashboard performance on older laptops and measure whether changes reduce time to complete reconciliation. We require practical React and TypeScript experience, confidence with semantic HTML and keyboard navigation, and the ability to test loading, empty and error states. You should explain how you coordinate API contract changes with backend engineers and turn ambiguous support reports into reproducible cases. Familiarity with browser profiling and component tests matters more than knowledge of a particular state-management library. Nice-to-haves include experience with payment-provider integrations, international number and currency formatting, and design-system maintenance. During your first three months, you would simplify the refund review flow and agree success measures with support. We value careful handling of sensitive information: examples and logs must exclude card details and personal customer data.Example questions
Pre-written examples. No AI is called in the demo.
- How would you model pending, successful, and failed transaction states in a React and TypeScript interface?
From the post: modelling pending, successful and failed transaction states
- What techniques would you use to prevent duplicate refund submissions when the network is slow?
From the post: You will prevent duplicate submissions during slow network responses
- How would you preserve a merchant’s entered information when a form fails validation?
From the post: preserve useful input when validation fails
- How would you make a balance that is unavailable clearly distinct from a balance of zero?
From the post: help users distinguish an unavailable balance from a zero balance
- How do you approach accessibility for payment and refund forms, including keyboard navigation?
From the post: building accessible payment and refund forms
- Describe how you would coordinate an API contract change with backend engineers and verify the resulting behavior.
From the post: explain how you coordinate API contract changes with backend engineers
- How would you investigate dashboard performance problems on older laptops, and what would you measure?
From the post: investigate dashboard performance on older laptops and measure whether changes reduce time to complete reconciliation
- How would you turn a vague support report about the refund review flow into a reproducible case while protecting customer data?
From the post: turn ambiguous support reports into reproducible cases