How should I practice Scheduled Payments with Account Aliases?

Start by reading the full statement, solve the visible examples, then compare the pattern against related Coinbase onsite interview problems in FastPrep.

Is Scheduled Payments with Account Aliases associated with Coinbase?

FastPrep tags this as a Coinbase onsite interview coding practice problem when the problem catalog has that company and stage context.

Scheduled Payments with Account Aliases

Coinbase● HardFULLTIMEONSITE INTERVIEW

Learn

Problem statement

Process a finite sequence of scheduled-payment and account-identity operations. The supplied accounts are the unique initial active account names. Initially there are no payments and the processing clock is zero. This ledger tracks payment lifecycle and account ownership; it does not model balances or money transfers.

Operations

["SCHEDULE", paymentId, account, dueTime]: create a pending payment for a resolvable active account when the ID has never been used and dueTime is at least the processing clock. Return TRUE on success, otherwise FALSE.
["CANCEL", paymentId]: cancel a pending payment and return TRUE. Return FALSE for a missing or terminal payment.
["STATUS", paymentId]: return PENDING, PROCESSED, CANCELLED or NOT_FOUND.
["PROCESS_DUE", time]: move the processing clock to time and process every still-pending payment with due time at most that clock. Return their IDs joined by commas in due-time order, breaking ties by scheduling order; return EMPTY when none is processed.
["MERGE", source, target]: merge the active group resolved from source into the distinct active group resolved from target. Every source-group name becomes an alias of the target's canonical name, and pending payments follow that group. Return TRUE, or FALSE if either name is unresolved or both already resolve to the same group.
["RETIRE", account]: retire its resolved active group, making every name in that group unresolved and cancelling all its pending payments. Return TRUE, or FALSE when already unresolved.
["RESOLVE", account]: return its active group's canonical name, or NOT_FOUND.

Only PROCESS_DUE processes payments. Scheduling at the current clock leaves a payment pending until such a call. Processing calls have nondecreasing times. Cancelled and processed payment IDs remain reserved forever, and terminal statuses never change. Merge preserves the target group's canonical name; it does not create a new account. Retirement does not change processed payments.

Return one string per operation. For this exercise, assume the exact finite interface, duplicate-ID policy, merge direction, alias behavior, retirement cancellation, due-time boundary and result strings above. They complete the reported scheduling/cancellation/status/due-processing and account merge/retire/resolve capabilities. Later unreported interview steps are outside scope.

Function

runPaymentLedger(accounts: String[], operations: String[][]) → String[]

Examples

Example 1

accounts = ["a","b","c"]operations = [["SCHEDULE","p1","a","5"],["MERGE","a","b"],["RESOLVE","a"],["PROCESS_DUE","5"],["STATUS","p1"],["CANCEL","p1"]]return = ["TRUE","TRUE","b","p1","PROCESSED","FALSE"]

A pending payment follows the merged account group and processes at the inclusive due boundary.

Example 2

accounts = ["a","b","c"]operations = [["SCHEDULE","p1","a","2"],["SCHEDULE","p2","b","2"],["RETIRE","a"],["STATUS","p1"],["PROCESS_DUE","2"],["RESOLVE","a"]]return = ["TRUE","TRUE","TRUE","CANCELLED","p2","NOT_FOUND"]

Retiring a group cancels only its pending payments and makes its names unresolved.

Example 3

accounts = ["a","b","c"]operations = [["SCHEDULE","later","c","7"],["SCHEDULE","first","a","3"],["SCHEDULE","second","b","3"],["CANCEL","first"],["PROCESS_DUE","7"],["SCHEDULE","later","a","8"]]return = ["TRUE","TRUE","TRUE","TRUE","second,later","FALSE"]

Processing uses due time and scheduling order, skips cancelled work, and never reuses a payment ID.

Constraints

1 <= accounts.length <= 1000 and 1 <= operations.length <= 1000.
Initial account names are unique. Account names and payment IDs are nonempty lowercase-letter or digit tokens of at most 20 characters.
Every operation has a documented shape. Due times and processing times are decimal integers in [0, 1000000000].
Processing times are nondecreasing. Other operations do not advance the processing clock.
A name in an operation may be unknown; retired names never become active again.