Role: Senior Product Engineer (Frontend & Design Systems)
Location: Remote (Global)
Type: Full-time
The Mission
Aura is looking for a Product Engineer who sits at the intersection of Design and Engineering. You aren't just handing off tickets from Figma; you are a "Design Engineer" who cares deeply about interaction physics, micro-interactions, and the "feel" of the application.
You will own our core workflows—complex, multi-step interfaces like our Booking Engine and Call Analysis Dashboard. You will leverage the bleeding edge of React 19 and Next.js 16 to ensure these flows aren't just beautiful, but run at 60fps even on low-end devices.
The Stack
- Frontend Core: Next.js 16 (App Router), React 19, TypeScript (Strict).
- Styling & Motion: Tailwind CSS, shadcn/ui, Framer Motion.
- Testing: Vitest (Unit/Component), Playwright (E2E).
- Performance: React Compiler, Web Vitals (INP), Sentry Replay.
- Architecture: Repository Pattern (Server Actions), Turborepo.
What You Will Do
- Design Engineering: Bridge the gap between Figma and Code. You will architect our design system to be composable and type-safe, ensuring UI consistency across the platform.
- Testing Culture: You don't verify features by "clicking around." You write Vitest specs for complex logic and Playwright tests for critical user journeys (e.g., the booking flow).
- Architecture: You respect the boundaries. You build Server Actions that call our shared repositories (not direct DB queries), ensuring our frontend code remains decoupled and testable.
- Frontend Performance: Obsess over Core Web Vitals, specifically INP (Interaction to Next Paint). You will use the React Profiler to optimize re-renders and implement virtualization for large datasets.
- Error Resilience: Implement granular Error Boundaries and Sentry tracking so that if one component crashes, the rest of the dashboard stays alive.
Who You Are
- Pixel-Perfectionist: You notice when a border is 1px off or an animation easing feels "wrong."
- Testing Advocate: You believe that if it isn't tested, it's already broken. You are comfortable writing E2E tests for async flows.
- Performance Native: You know exactly why a component is re-rendering and how to fix it without memoizing everything blindly.
- Strict Typer: You enable strict: true and never use any. You know how to derive types from Zod schemas or Database definitions.
Internal Interview Canvas
Topic: Testing Strategy
The Question:
"You've built a complex multi-step booking wizard with form validation. How do you test it to ensure it works correctly and doesn't regress?"
- ✅ Green Flags: Mentions Component Testing (Vitest/Testing Library) for the validation logic and state transitions. Mentions E2E Testing (Playwright) for the full "happy path" user flow. Tests error states (network failure), not just success.
- 🚩 Red Flags: "I check it manually." "I rely on QA." Only tests the happy path. Doesn't mention mocking API calls in unit tests.
Topic: Server Components & Data Fetching
The Question:
"You need to display a dashboard with a list of 1,000 calls and a complex filter sidebar. How do you structure this in Next.js App Router to minimize client-side JavaScript?"
- ✅ Green Flags: Uses Server Components for the initial data fetch (keeps heavy dependencies on the server). Uses Client Components only for the interactive bits (filters, search input). pushes state to the URL (search params) so the filter works with Server Components.
- 🚩 Red Flags: Fetches all 1,000 items in a Client Component using useEffect. Puts the entire page in "use client".
Topic: Error Handling & Recovery
The Question:
"A user reports that a form submission failed, but they can't remember what they entered. How do we help them recover and fix the bug?"
- ✅ Green Flags: Mentions Error Boundaries (error.tsx) to catch the crash gracefully. Mentions Sentry Context (User ID, breadcrumbs) to debug. Suggests persisting form drafts to localStorage so the user doesn't lose data on refresh/crash.
- 🚩 Red Flags: "Tell them to refresh." No mention of automated error tracking.
Topic: Design Engineering
The Question:
"Here is a complex Figma component with multiple variants and animations. Walk me through how you design the Prop API for this to be flexible but type-safe."
- ✅ Green Flags: Focuses on Composition (Compound Components) over one giant "god component." Mentions accessibility (ARIA) and keyboard navigation. Uses TypeScript discriminated unions for the variants.
- 🚩 Red Flags: Creates a single component with 50 optional props. Ignores animation/states entirely. Uses any for props.