Practice Interview Questions

A Platform PM serves internal teams as customers — other PMs, eng leads, compliance, ops. The deliverable is APIs, events, configuration primitives, and docs. Success is adoption and team-velocity, not end-user engagement. The discipline is backward compatibility, an explicit metric registry, and treating internal customers as a sale — they can fork you if you're slow.

Today, onboarding is a set of forked flows; every new product (Futures, Margin, Pro) and every new market is from-scratch. Consolidate to three primitives — vendor abstraction, jurisdictional rule engine, configurable flow renderer. Sequence by smallest blast radius first. Drops time-to-launch from quarters to weeks, gives vendor-renewal leverage, makes audit responses a query. Migration in 90-day waves with named consumer-team unlocks.

Two-customer rule: generalize only when at least two consumer teams want similar capability. First team builds in their own space; second team's ask triggers extraction. Cross-cutting concerns (compliance, audit, identity-resolution) default to platform regardless of demand count, because they affect regulator-readiness.

Pre-wire 1:1 with each senior reviewer before the doc-review meeting. Write non-goals before goals. Make migration as concrete as the target state. Include a "what if we do nothing" section. End with explicit asks — what headcount, what calendar time, what decisions you need from whom by when.

KYC: identity verification for an individual customer. KYB: same for a business + its beneficial owners. AML: the umbrella program that uses KYC/KYB as inputs and adds transaction monitoring, sanctions screening, and suspicious-activity reporting. KYC is identity; AML is risk.

Tiers as ordered levels — basic / verified / enhanced — each unlocking specific capabilities. Each applicant has (tier, policy_version, last_verified_at). Tier upgrade is a step-up flow, not full redo. Grandfathering is first-class — existing customers don't auto-migrate on policy change. Different segments (Consumer, KYB, Institutional) use shared primitives (screen, verify, decide) composed into segment-specific flows.

Vendor abstraction layer with a waterfall — auto-failover to a secondary vendor on threshold breach. Health monitoring drives automated routing changes; on-call gets alerted in parallel. Tail of unsupported scenarios queues for retry post-recovery, customer notified. Postmortem includes vendor SLA enforcement.

FATF Recommendation 16 — when a customer sends crypto above a threshold to another regulated VASP, the originating VASP must transmit originator and beneficiary information. Implementation requires a Travel Rule integration (TRP, OpenVASP, Notabene) at the withdrawal perimeter. For self-hosted destinations, wallet attestation and on-chain risk scoring substitute for the counterparty data exchange.

Primary: median time-to-launch a new onboarding configuration. Paired: verified-customer activation rate, cost per successful verification. Guardrails: sanctions hit rate must not decline, customer-complaint volume stable, audit-log completeness 100%.

First, confirm the drop is real not a young-cohort artifact. Decompose funnel — which stage dropped? Slice by vendor (did routing change), document type, app version, time-of-day, source. Most "activation drops" trace to one explanatory dimension. Cross-reference with the change calendar — did we ship anything? Did a vendor push a model update?

Shadow-mode comparison first (call both, compare without changing UX). Then A/B at meaningful split. Primary: approval rate. Guardrails: fraud rate 90d post (proxy for false-accept), decision latency p95, customer complaints, manual-review carry-over. Stratify by document type — vendors differ wildly. Stop on guardrail breach.

Count teams onboarded + % of net-new flows landing on-platform vs forked. Pair with platform NPS from consumer-team PMs and tech leads. Time-to-launch trend. Support-ticket volume per team. Open-migration count from legacy. Adoption is breadth × depth × goodwill, not API-call volume.

Interface with create_session, get_decision, fetch_evidence, cancel. Normalized Decision schema — outcome, calibrated confidence, decision_id, evidence URLs. Adapter per vendor. Raw signals preserved in payload for audit. Capability flags for vendor-unique features. Shadow-mode rollout, then canary, then ramp.

Define stable primitives (verify_id, screen, collect_consent, set_tier). Flows are compositions of primitives with conditional branches. Config lives in consumer-team repos; CI validates the composition is legal under jurisdictional policy. Compliance review is on the flow def, fast because surface is small. Don't ship the builder until primitives are stable.

Every state transition emits an event with stable envelope (event_id, type, schema_version, occurred_at, actor, correlation_id, causation_id) and typed payload. Append-only, encrypted, retention aligned to strictest applicable AML window. Consumers: compliance reporting, fraud, support, growth, ops. Causation chains let you replay an applicant journey.

Side-by-side applicant vs list-entry. Match-score with which fields matched. Prior dispositions for same entity. One-click outcomes with rationale capture. SLA per match-confidence band. Sample audit by second reviewer. Feedback loop into match-score calibration. Every action logged.

Treat Compliance as a customer of the platform, not a constraint. Named counterpart per initiative. Standing weekly meeting kept even when nothing's burning. Compliance gets self-serve tooling (policy editor, audit search) so they don't need to file tickets. Joint OKRs where reasonable. Result: faster sign-off because they trust the rails.

Diagnose first — is it a real new primitive (build), a configuration they could do (point them at the config), or a one-off (decline with rationale)? If decline: cite the platform principle, propose an alternative path on-platform, offer to embed an eng for the launch if the alternative is harder. Document the decision publicly so the next requester sees the criteria.

First, listen. The veto is information. Diagnose: is it scope-shift, policy-misunderstanding, or a real gap? Carve-out launch if possible — ship the safe geos, defer the problematic one behind a flag. Schedule the fix with Compliance signed off. Postmortem captures why the veto came late — earlier engagement is usually the answer.

Bring data, not vibes. Quantify the false-reject and false-accept impact of the proposed threshold change. Identify the segment / vendor / jurisdiction where the tension is sharpest — the answer is usually local, not global. Make the trade-off explicit and instrumented. Often the right answer is a more nuanced threshold per segment, not a single global value.

CTE for cohort (filter created_at < today - 7 days to exclude young), CTE for first-activation (MIN occurred_at on first_deposit), outer query LEFT JOIN, group by source, compute activated_within_7d / cohort_n. Guard with NULLIF.

Because they haven't had 7 days to convert. Including them makes recent cohorts look worse than they are — purely a measurement artifact. Always cohort by entry-week and require equal observation time across cohorts.

Decompose: by referral source (queue type), by vendor (did one start referring more?), by document type, by jurisdiction. Cross-reference with the change calendar — vendor model update? Policy change? Look at score distributions — has the threshold quietly shifted? Often a single dimension explains the spike.

Top-down: market size from public sources × realistic share for a foreign exchange entering. Bottom-up: comparable LATAM market launch curves applied. Apply our funnel rates discounted 20-30% the first quarter for new-market conversion drag. Revenue: activated × ARPU × retention. Costs: per-verification cost + local-language support + amortized compliance setup. Show ranges, not point estimates; flag regulatory timeline as the dominant risk.

Shape: edge (the unfair advantage you bring), one project (most recent, most relevant, what changed measurably), bridge (point at a specific JD line), honest gap (what you'd ramp on, with a concrete 90-day plan).

STAR. Situation: the platform, the launch. Task: drive adoption. Action: what you tried; the diagnostic that revealed adoption is a sale not a mandate. Result: the change in approach (anchor partners, migration subsidy, declining to maintain forks). Lesson named — adoption planning is part of the platform, not after.

Pick a substantive disagreement, not a personality clash. Describe the trade-off cleanly, the data that informed each side, how you escalated or didn't, what was decided, and whether it was right in retrospect. Showing you can change your mind is a stronger signal than winning.

Honest version: name something specific you find compelling (self-custody, settlement finality, the permissionless market) — not a manifesto. Name something specific about the company — the platform problem in the JD, the company's long track record, the regulatory posture. Avoid fake conviction; show curiosity and engagement with the product.

Days 1-30: Learn. 1:1s with Eng, Compliance, Ops, consumer PMs. Shadow ops reviews. Read AML risk assessment and postmortems. Map current capabilities. Output: current-state doc. Days 30-60: Diagnose. 3-5 gaps named. Strategy thesis drafted. Pre-wired with VP-Product and VP-Eng. Days 60-90: Commit. Strategy approved. First 90-day wave scoped with named partner and named unlock. Roadmap published.

Weekly: 1:1 with eng lead, rotating consumer-PM check-in, platform team review. Biweekly: Compliance partnership review, stakeholder roadmap update. Monthly: IDX scorecard walkthrough, internal-customer roadmap review. Quarterly: strategy review with VP-Product and VP-Eng, OKR setting. Embedded in: writing strategy docs and platform briefs, defining metrics, refereeing source-of-truth questions, running postmortems.