Founded in 1997 and rebranded in 2020 to reflect several acquisitions and phenomenal growth as a travel technology provider for companies wishing to reimagine their loyalty and rewards programs. Arrivia is now the world's largest stand-alone travel loyalty provider.
You are a newly hired Senior Program Manager at a mid-size travel technology company. The company was formed through the merger of three legacy travel brands, each with its own booking engine, partner integration layer, and data model. Leadership has approved a six-month initiative to consolidate all three platforms onto a single unified partner API. The program spans four engineering teams (Platform, Integrations, Data, QA/Release), two product teams, and three external vendor partners. There is no formal program management practice today — no cross-team dependency tracking, no stage-gate reviews, no unified reporting to leadership. Engineering teams run two-week sprints with scrum masters, but nobody owns the orchestration layer. You’re building this from scratch. The Complicating Factors Two engineering teams are in different time zones (US West Coast and South America) with only a 3-hour overlapping work window. The Data team has a hard dependency: Platform cannot build unified API endpoints until schema mapping is done. But Data is also split across a separate regulatory compliance initiative. One external vendor partner may sunset their current API in 4 months — faster than your phased rollout plan. The QA/Release team has never tested a multi-platform migration at this scale. YOUR TASK Produce a Governance One-Pager, Video Walk Through, and AI Usage Log that demonstrates how you would structure this program. This is intentionally open-ended — we want to see how you think, not how thoroughly you can fill a template. See below questions that should be answered in the one-pager, video and AI Usage Log. CONSTRAINTS No greenfield. The three legacy platforms are running live production traffic 24/7. Partner SLAs guarantee booking availability. Your approach must account for zero-downtime migration. Time zone reality. A daily standup at 9 AM Pacific does not work for a team in South America with a 3-hour overlap window. Account for asynchronous collaboration. Competing priorities are real. The Data team is split. Do not assume they’re fully dedicated to your program. Budget for your time, not a textbook. This is a 30-minute exercise. Judgment and structure over exhaustive detail. A focused one-pager with clear thinking is more valuable than a 10-page template. AI USAGE GUIDANCE We expect you to use AI tools. We evaluate how you use them — not whether you use them. Evidence of iteration, redirection, and critical evaluation scores higher than a polished output with no process documentation. The single highest-signal indicator: your video answer to the mandatory AI question. If you cannot name a specific moment where you redirected AI output, evaluators will assume you did not.
This is not a traditional design challenge. There is no client brief, no wireframe spec, no predefined product. You own every decision from the first pixel. Here's the prompt: Pick an activity you're passionate about — biking, painting, cooking, climbing, birdwatching, anything. Now design a mobile app for people who share that passion. Identify a real problem this audience faces, design a solution, and prototype it. That's it. The rest is yours. Make as many assumptions as you need. There are no wrong answers to the domain question — we care about how you think through the problem, not which hobby you pick. A cooking app and a rock climbing app are on equal footing. Constraints These keep the exercise grounded. Honor them as you work: Time-box: Spend no more than 60 minutes total (roughly 30–35 on the prototype, 10–15 on the README, 8–10 on the video). We're evaluating what you can ship under real constraints, not what you can produce with unlimited time. Mobile-first: Design for a mobile app experience. You can reference web or other surfaces, but the core solution should be mobile. MVP scope: Your prototype should show one core user journey end-to-end. We'd rather see one complete flow than five half-finished screens. Scope aggressively. Real audience: Your user should be specific. "People who cook" is too broad. "Home cooks who meal prep for the week on Sundays" gives you a real design target. The more specific your audience, the sharper your design decisions will be.
The Scenario You are a full-stack engineer at arrivia, a global travel loyalty technology company that powers white-label booking platforms for banks, financial institutions, and membership organizations worldwide. arrivia's platform handles 30,000+ itineraries across 700 airlines, 1M+ hotels, and 30,000 rental car locations. Partners integrate arrivia's booking engine, loyalty currency, and marketing tools into their own branded experiences — meaning arrivia operates a multi-tenant, white-label architecture where partner-specific configuration, branding, and pricing rules must coexist on a shared platform. Your team has been tasked with building a new internal service: an Agentic Travel Recommendations API. This service will allow AI agents (powered by tools like Claude Code and MCP integrations) to query a member's travel history, loyalty tier, and partner-specific rules to generate personalized travel recommendations. The goal is to power a new 'AI Concierge' feature that partner brands can embed in their booking portals. Here is what you know: The member data service already exists as a RESTful API (you can mock it). It returns: member ID, loyalty tier (Silver/Gold/Platinum), travel history (last 5 bookings with destination, dates, and booking type), and partner ID. Partner-specific rules vary: some partners cap recommendations at 3 per session; others allow unlimited. Some partners exclude cruise offers entirely. These rules are stored in a partner configuration service (you can mock this too). The AI agent will call your service via MCP — your API must expose endpoints that an AI agent can discover and invoke through a Model Context Protocol server. Read the provided constraints carefully — they define what you can and cannot change. Constraints Existing infrastructure only: Your service must work within arrivia's current cloud and technology stack (AWS/Azure services, containerized deployment). Do not propose a new infrastructure layer or third-party platform that arrivia does not already use. Partner configuration is read-only: You cannot modify the partner configuration service. You can only read from it. Your service must respect whatever rules the partner config returns, even if they seem suboptimal. Four-week first step: Scope your implementation to what a single engineer could realistically ship in four weeks. Your README should identify what ships first vs. what comes later. On-call ownership: You and your team will own this service in production. Whatever you build, you are on call for at 2am. Design accordingly.
