Arrivia
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.
Open Opportunities
Available Challenges
Post-Merger Service Desk Operating Design
Description You're joining Arrivia as Director, IT Service Desk & End-User Support, reporting to the EVP of IT & Security. Arrivia is a merger of three travel-loyalty brands — ICE, SOR Technology, and WMPH Vacations — supporting roughly 2,000 employees across all three. The problem you've been handed: Each of the three brands ran its own Tier-1 support motion before the merger. First-contact resolution is currently uneven — strong on ICE's legacy queue, weak on the other two — and median time-to-resolution is well above the ≤4-business-hour target leadership wants. Ticket deflection through self-service sits under 10%, far short of the ≥30% target. Endpoint patch compliance is inconsistent across the three brands' device fleets, and nobody has a clean picture of which devices are past end-of-life. New hires from all three legacy brands report inconsistent Day-1 device readiness. The team is currently 20 people and approved to grow to 24. Leadership wants a Service Desk & End-User Support Operating Design — not a slide deck of buzzwords — that a fellow engineering leader, an HR/People-ops partner, and the CIO could each act on. Constraints to Consider You cannot request new ITSM platform spend, new endpoint-management tooling, or headcount beyond the approved 20→24 plan. Design within the team and toolset described — this is a constraint on operating-model design, not an invitation to ask for more budget. You do not own Identity's Access Control and Authentication systems. Your team executes Tier-1 password/MFA resets and enrollment; you do not redesign authentication policy or own passwordless/passkey architecture decisions. You do not own Problem Management or Change Enablement. Change & Configuration Management owns those. Your scope is feeding incident and ticket-trend data into them — not designing their process. You do not own the end-user-endpoint patching platform. Infrastructure & Cloud owns that. Your scope is end-user-endpoint patch/EOL compliance and coordination — not rebuilding their tooling. You own this in production. Whatever operating model you propose, your team lives with it — including the week a self-healing remediation misfires and reboots devices mid-workday, or a Day-1 cohort shows up to unready laptops. Design and document accordingly. 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. Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why. Speak naturally and conversationally — as if you're briefing your CIO directly. Strategic clarity and CIO-peer tone matter. We don't assess verbal polish, accent, or filler words. Submission: Upload each deliverable as a separate file directly on the Provn platform: your Operating Design document, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
Loyalty Points Redemption Service
Description You are a full-stack engineer on arrivia's loyalty platform team. arrivia powers white-label travel booking portals for banks, financial institutions, and membership organizations worldwide. Partners integrate arrivia's booking engine, loyalty currency, and marketing tools into their own branded experiences — meaning arrivia operates a multi-tenant architecture where partner-specific configuration, branding, and redemption rules coexist on a shared platform. Three days ago, your team shipped v2.3.2 of the Points Redemption Service. Since the deploy, 8% of redemption attempts are failing for one high-value bank partner (Partner BNK-0047, 2.1M active members). All other partners are unaffected. The partner's account team is escalating. Your observability stack has surfaced three data points: Data Point 1 — Error rate spike Since the v2.3.2 deploy, the Points Redemption Service is returning 'INSUFFICIENT_BALANCE' errors for \~8% of redemption attempts on BNK-0047. Other partners: normal error rates. Data Point 2 — Sample error log Data Point 3 — Deployment diff summary Read the provided data carefully — the service may have failure modes beyond the primary incident. Your task is to diagnose the root cause, build a proof-of-concept fix, and design the observability strategy that would have caught this before a member reported it. Constraints to Consider The mvmemberpoints_balance view is owned by the Data Platform team. You cannot modify its refresh schedule or definition. You decide whether and how to use it — but you cannot change it. The partner configuration service is read-only. You can read partner-specific redemption rules (minimum thresholds, blocked categories, point multipliers) but cannot modify the service or its schema. Scoped delivery: Scope your work to what stops the bleeding in 48 hours. Your README must distinguish the immediate fix from the two-week hardening work — and explain why you drew the line where you did. On-call ownership: Your team owns this service in production. Whatever you ship, you are on call for it at 2am. Design accordingly. 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. Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why. Speak naturally. Communication is assessed on clarity of technical ideas and logical structure — not verbal polish, accent, or filler words. Submission: Upload each deliverable as a separate file directly on the Provn platform: your code artifact, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
AI Governance & Agent Runtime Security Design
Description You're joining Arrivia as Manager, Application & AI Security, reporting to the EVP of IT & Security. You hold the central AI-governance mandate and own DevSecOps golden pipelines, application security testing, and MCP/AI-agent runtime security — making safe AI adoption the default rather than a review bottleneck. The problem you've been handed: Two things are happening at once, and your new team of three is behind on both. First: engineers across Arrivia's brands have been using ChatGPT, GitHub Copilot, and other AI coding tools for months with no formal governance. There's no inventory of which tools are in use, no registry of what's been approved, and no visibility into whether anyone has pasted member PII or loyalty-account data into a public LLM. Leadership wants a usage policy and a discovery mechanism — not a document nobody reads. Second: the Contact Center team has built an MCP-based AI support agent that connects to three internal tools — a loyalty-account lookup tool, a redemption-processing tool, and a refund-issuance tool — so support agents can resolve member requests faster. It's scheduled to go live with real members in three weeks. Nobody has red-teamed it, and nobody has designed authorization for what happens when the agent calls one of those tools. Your manager needs a design document — not code, not a slide deck of buzzwords — covering both problems, that an engineer, a GRC partner, and the CIO could each act on. Constraints to Consider You cannot request new raw data fields or new tooling budget. Work with the AI agent and tool set described above — this is a constraint on control design, not an invitation to redesign the agent's architecture. You do not own the AI management-system program or its compliance evidence. GRC owns the ISO/IEC 42001 and NIST AI RMF "Govern" program and evidence. Your scope is implementing the technical controls (registry, discovery, runtime guardrails, red-teaming) that GRC's program will point to — not writing GRC's audit narrative. You do not own prompt/response DLP or training-data controls. Data Security owns those. Your scope for the AI agent is runtime authorization, containment, and red-teaming of the agent itself — not what the model is allowed to say or what data it was trained on. You do not own Identity or Infrastructure's platforms. Identity owns PIM/PAM — you consume it for pipeline and application entitlements, you don't redesign it. Infrastructure owns IaaS/AI-ML hosting — you own the application/PaaS layer and pipeline guardrails on top of it. Touch all required areas — don't go deep on one at the expense of the rest. You have 45 minutes total, including video. Breadth across the required areas, calibrated to what's achievable in that time, is what's being tested — not exhaustive depth on a single area. 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. Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why. Speak naturally, as if briefing your CIO directly. Communication is assessed on how clearly you translate technical controls for a broad audience — not verbal polish, accent, or filler words. Submission: Upload each deliverable as a separate file directly on the Provn platform: your AI Governance & Agent Runtime Security Design, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
Account Takeover Risk Model
Description You're joining Arrivia's Security team, which protects the BuilderEx platform and its partner brands from fraud, abuse, and account compromise across multiple travel loyalty programs. The problem you've been handed: Over the past month, the security team has traced a new wave of successful logins to compromised loyalty accounts that current rule-based checks are missing. The pattern: credential-stuffing bots rotating through residential proxies, automation frameworks that mimic human timing closely enough to slip past simple thresholds, and rapid high-value redemption requests immediately after login. You've been asked to build and evaluate an account-takeover / bot-abuse risk model — not a set of hand-written rules — that produces a risk score usable at login time. Provided asset: account\takeover\events.csv — a synthetic, labeled dataset of \~420 login/session events. Each row represents one session with behavioral and network fields plus a label (is\account\takeover: 0 or 1). The positive class is intentionally rare (\~12%), reflecting real account-takeover base rates. Fields in the dataset: session\_id login\hour\local session\duration\sec ip\reputation\score (0–1, higher \= better reputation) geo\velocity\kmh (implied travel speed since the account's last login) device\change\since\last\login (0/1) new\device\flag (0/1) failed\attempts\last\_1h typing\cadence\variance\_ms (variance in keystroke timing; lower can indicate automation) proxy\or\vpn\_flag (0/1) account\age\days redemption\requested\within\_10min (0/1 — a high-value redemption requested within 10 minutes of login) is\account\takeover (label: 0 \= legitimate, 1 \= confirmed account takeover) Constraints to Consider Low-latency, synchronous scoring only. Your model must be callable as a function at login time — no batch-only pipeline, and no external heavy model-serving infrastructure to assume. Design as if this needs to return a decision in well under a second. You cannot request new raw data fields. The login/session event stream and feature store are owned by another team. Work with the fields provided — this is a constraint on feature engineering, not an invitation to ask for more data. Scope this to account-takeover / bot-abuse detection only. This is not a general-purpose security platform covering malware, insider risk, or data exfiltration — those are out of scope for this round. Your team owns this in production. That includes the 2am page when precision drops and legitimate platinum-tier members start getting blocked mid-booking. Design and document accordingly. 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. Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why. Speak naturally. Communication is assessed on clarity of technical ideas and logical structure — not verbal polish, accent, or filler words. Submission: Upload each deliverable as a separate file directly on the Provn platform: your model code, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
Multi-Brand Data Protection Design
Description Arrivia is the product of a merger of three brands — ICE, SOR Technology, and WMPH Vacations — each of which brought its own data systems into the combined company. You've just joined as Director, Data Security & Governance, reporting to the CIO. Your first mandate: discover, classify, and protect wherever data lives across this newly combined estate — the program the team calls "DSPM + classification + DLP modernization," with encryption/key-management standardization as the next phase. Below is the current data inventory your team has pulled together in week one. It's incomplete and messy — exactly what you'd expect right after a three-way merger. | Repository | Type / Location | What's actually in it | |---|---|---| | loyalty-member-profiles-db | Postgres on AWS RDS | Member PII (name, email, phone, address), loyalty tier, account status — shared across all three brands | | redemption-transactions-log | S3 bucket | Redemption events: timestamp, partner ID, points redeemed, member ID (no name/contact fields) | | payment-tokenization-vault | On-prem, HSM-backed (legacy WMPH system) | Tokenized card references + last-4 digits, used to settle redemption payments | | partner-fulfillment-export | Weekly SFTP export to a third-party fulfillment vendor | CSV of member name, shipping address, redemption SKU | | support-ticket-system | SaaS helpdesk (multi-brand) | Free-text customer support tickets — agents sometimes paste card numbers or account details into ticket notes | | marketing-campaign-lists | SaaS CRM | Email/segment lists, opt-in status, campaign engagement history | | hr-employee-records | On-prem HR system (legacy SOR Technology) | Employee PII, payroll data, SSNs | | ai-support-copilot-corpus | Cloud vector store (RAG index) | Built from support-ticket text and CRM notes; feeds an internal AI assistant that drafts replies for support agents | | web-session-analytics | Cloud data warehouse | Clickstream/session logs, device IDs, IP addresses, joined to member ID | | legal-hold-archive | Cold storage | Historical records under an active legal hold from a past partner dispute — cannot be deleted or altered regardless of normal retention rules | Your manager needs a Data Protection & Governance Design — not code, not a slide deck of buzzwords — that a compliance officer, an engineering colleague, and the CIO could each act on. Constraints to Consider You cannot request new raw data fields or new repositories. Work with the inventory above — this is a constraint on classification and control design, not an invitation to ask for more data. You do not own the AI model registry or runtime guardrails. That belongs to Arrivia's App & AI Security team. Your scope for the ai-support-copilot-corpus repository is training-data/RAG-source controls and prompt/response DLP only — design within that boundary. You set cryptography standards; you don't rebuild Infrastructure's systems. Infrastructure owns backups and storage — you own the encryption/key-management standards they must apply. Don't propose replacing their systems. The legal-hold archive cannot be deleted or reclassified out of its hold, regardless of your retention schedule. Design your retention policy to explicitly account for this exception, not around it. Touch all required areas — don't go deep on one at the expense of the rest. You have 45 minutes total, including video. Breadth across the required areas, calibrated to what's achievable in that time, is what's being tested — not exhaustive depth on a single area. 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. Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why. Speak naturally, as if briefing your CIO directly. Communication is assessed on how clearly you translate technical controls for a broad audience — not verbal polish, accent, or filler words. Submission: Upload each deliverable as a separate file directly on the Provn platform: your Data Protection & Governance Design, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
Full Stack AI Engineer — Identity Risk Scorer
You're joining the BuilderEx team at a travel loyalty company that operates identity and authentication for multiple partner brands. The team is mid-migration to a unified OAuth 2.0/OpenID Connect identity provider — three legacy auth systems are consolidating into one, but the migration is not complete. The problem you've been handed on your second week: The fraud team has flagged a pattern — 847 logins over the past 30 days succeeded (valid credentials, valid OIDC token issued) but showed anomalous post-auth behavior: unusual geolocation, device switches within minutes of login, then immediate redemption requests against high-value loyalty accounts. The current system trusts a valid token completely. There is no post-authentication risk assessment. Your manager asks you to build a risk-scoring middleware that sits in the post-authentication flow. After a valid OIDC token is issued, your middleware receives a login event payload and returns a structured risk_decision object that downstream systems use to determine whether to allow, step-up-authenticate, or block the session. Constraints: You cannot modify the OIDC token issuance flow — the identity provider is a managed system; your middleware hooks in after token issuance. The explanation field must be readable by a compliance officer without translation — "risk score exceeds threshold" is not acceptable. Scope your PoC to what's achievable in a two-week sprint — heuristic, rule-based, lightweight ML, or a combination is fine; it just needs to be functional, observable, and improvable. Your team will own this in production, including on-call at 2am when the scorer starts generating false positives and blocking loyal platinum-tier members. Design accordingly. AI Usage Guidance: Using AI tools is expected and encouraged — how you use AI is part of what's evaluated. Your video walkthrough must include this mandatory question: "Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why."
Product Designer — Showcase Your Portfolio
This isn't a design challenge. We're not asking you to solve a hypothetical problem or build something from scratch. We want to see how you think, how you communicate, and what your real work looks like. You'll be joining a design team that builds consumer travel experiences — search, discovery, comparison, and booking flows — across multiple branded product variants. The person in this role works closely with PMs and engineers in a product pod, contributes to a shared design system, and ships work that real travelers interact with every day. We need someone who brings genuine visual and interaction craft and wants to keep getting sharper. Record a single video, no longer than 12 minutes total. Three parts.  Part 1: Show us your work (5 minutes)  Walk us through the highlights of a recent, relevant project. We're not looking for a full case study. We want the highlight reel.  Show us: the problem (what were you solving and why did it matter?), the work (show us craft — typography, layout, color, spacing, interaction — and what shipped), and the impact (metrics, behavior changes, or what you observed).  Screen share your portfolio, Figma files, or the live product. No deck required.  Part 2: Tell us about you (5 minutes)  Answer these three questions:  1\. What are you looking for in your next role and team? 2\. Which areas of design energize you most, and are there areas that drain you? 3\. What kind of environment and team brings out your best work?   Part 3: How you work with AI (2 minutes)  Tell us which AI tools you use in your design workflow and how. Be specific — name the tools and describe what you use them for.  Then walk us through one moment where you disagreed with or redirected what the AI gave you. Name the moment, explain what it produced that didn't meet the bar, and what you did instead.   Constraints  12 minutes total. Hard ceiling, not a target. We'd rather see an authentic 11 than a polished 15. Show the work, not the process. Shipped design, Figma files, or live product — not journey maps or slide decks. Pick work you can speak to with specificity — the problem, the decisions, the outcome. If you worked within a design system, say so.  AI Usage Note  We expect you to use AI tools — it's a core requirement. We evaluate how you use them, not whether you use them. The highest-signal moment: Part 3, where you describe redirecting AI output. If you can't name a specific moment, we'll assume you haven't engaged deeply yet.  Video note: We're not evaluating production quality. Speak naturally. We're listening for how you think, not how you present on camera.  Submission: Upload your video (MP4 or MOV) directly on the Provn platform.
Saving a Multi-Team Program at Risk
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.
Snr Product Designer/ Snr Design Engineer / Product Designer Challenge
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.
Agentic Software Engineer Skills Challenge
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.