How do I practice coding and algorithm questions?

Use PracHub's coding console to write, test, and debug your solutions in Python or JavaScript. View hints, test against sample inputs, and compare with official solutions.

What difficulty level is this coding question?

This is a medium difficulty Coding & Algorithms question, commonly asked during Onsite rounds at Robinhood.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Robinhood during technical interviews.

Parse Requests and Compute Balances | Robinhood Coding Question

Parse Requests and Compute Balances

Company: Robinhood

Role: Software Engineer

Category: Coding & Algorithms

Difficulty: medium

Interview Round: Onsite

You are given an array of strings representing requests in a social payments application. Process the requests in order and return the final balance of every registered user. Assume each request is one of the following forms: - `SIGN_UP <user_id> <starting_balance>` - `REQUEST_FRIEND <from_user> <to_user>` - `ACCEPT_FRIEND <to_user> <from_user>` - `DECLINE_FRIEND <to_user> <from_user>` - `SEND_MONEY <from_user> <to_user> <amount>` Rules: 1. A user must be registered before appearing in any other request. 2. `SIGN_UP` is invalid if the user already exists or the starting balance is negative. 3. Friend requests to self are invalid. 4. `REQUEST_FRIEND` is invalid if the users are already friends, if an identical pending request already exists, or if either user does not exist. 5. `ACCEPT_FRIEND` and `DECLINE_FRIEND` are valid only if there is a matching pending request. 6. `SEND_MONEY` is valid only if both users exist, they are already friends, the amount is positive, and the sender has enough balance. 7. Invalid or malformed requests must be ignored and must not change system state. 8. Friendship is mutual after an acceptance. Return each user's final balance after all valid requests are processed. If a deterministic format is needed, return the results sorted by `user_id`.

Quick Answer: This question evaluates input parsing, state management, data validation, and use of basic data structures to track user accounts, friend relationships, and transactional balances under strict rule constraints.

You are given an array of strings representing requests in a social payments application. Process the requests in order and return the final balance of every successfully registered user. Each request is one of these forms: - SIGN_UP <user_id> <starting_balance> - REQUEST_FRIEND <from_user> <to_user> - ACCEPT_FRIEND <to_user> <from_user> - DECLINE_FRIEND <to_user> <from_user> - SEND_MONEY <from_user> <to_user> <amount> Rules: 1. A user must be registered before appearing in any request other than SIGN_UP. 2. SIGN_UP is invalid if the user already exists or the starting balance is negative. 3. Friend requests to self are invalid. 4. REQUEST_FRIEND is invalid if either user does not exist, the users are already friends, or an identical pending request already exists. 5. ACCEPT_FRIEND and DECLINE_FRIEND are valid only if there is a matching pending request. 6. SEND_MONEY is valid only if both users exist, they are already friends, the amount is positive, and the sender has enough balance. 7. Invalid or malformed requests must be ignored and must not change system state. 8. Friendship is mutual after an acceptance. A request is malformed if it has the wrong number of space-separated tokens or if a numeric field cannot be parsed as an integer. Return the final balances as a list of [user_id, balance] pairs sorted by user_id.

Constraints

0 <= len(requests) <= 100000
Each request string length is between 0 and 200 characters
User IDs contain no spaces in well-formed requests
Balances and transfer amounts fit in signed 64-bit integers

Examples

Input: ['SIGN_UP alice 100', 'SIGN_UP bob 50', 'REQUEST_FRIEND alice bob', 'ACCEPT_FRIEND bob alice', 'SEND_MONEY alice bob 30']

Expected Output: [['alice', 70], ['bob', 80]]

Explanation: Alice and Bob sign up, become friends, and Alice successfully sends 30 to Bob.

Input: ['SIGN_UP alice 10', 'SIGN_UP alice 20', 'SIGN_UP bob -5', 'REQUEST_FRIEND alice bob', 'SIGN_UP bob 15', 'REQUEST_FRIEND alice alice', 'REQUEST_FRIEND alice bob', 'REQUEST_FRIEND alice bob', 'ACCEPT_FRIEND alice bob', 'DECLINE_FRIEND bob alice', 'SEND_MONEY alice bob 5', 'SEND_MONEY alice bob x', 'SIGN_UP charlie 7 extra']

Expected Output: [['alice', 10], ['bob', 15]]

Explanation: Only the first SIGN_UP for Alice, the SIGN_UP for Bob with balance 15, and the later friend request followed by a valid decline are processed. No money transfer succeeds.

Input: ['SIGN_UP u1 20', 'SIGN_UP u2 0', 'SIGN_UP u3 50', 'REQUEST_FRIEND u1 u2', 'ACCEPT_FRIEND u2 u1', 'SEND_MONEY u1 u2 25', 'SEND_MONEY u1 u2 20', 'REQUEST_FRIEND u2 u3', 'ACCEPT_FRIEND u3 u2', 'SEND_MONEY u3 u2 10']

Expected Output: [['u1', 0], ['u2', 30], ['u3', 40]]

Explanation: The first transfer from u1 to u2 fails due to insufficient funds, but the next transfer succeeds. Then u2 and u3 become friends, and u3 sends 10 to u2.

Input: []

Expected Output: []

Explanation: No requests means no users and no balances to return.

Input: ['SIGN_UP zed 5', 'SIGN_UP amy 8', 'REQUEST_FRIEND zed amy', 'ACCEPT_FRIEND amy zed', 'SEND_MONEY amy zed 0', 'SEND_MONEY amy zed 3']

Expected Output: [['amy', 5], ['zed', 8]]

Explanation: Amy and Zed become friends. A transfer of 0 is invalid, but a transfer of 3 from Amy to Zed is valid. Output is sorted by user_id.

Hints

Use hash maps to store balances and friendship sets so each valid request can be processed in near O(1) average time.
Track pending friend requests as directed pairs like (from_user, to_user). Then ACCEPT_FRIEND and DECLINE_FRIEND become simple membership checks.

Quick Overview

This question evaluates input parsing, state management, data validation, and use of basic data structures to track user accounts, friend relationships, and transactional balances under strict rule constraints.