Communications Handler
Reported by candidates from Akuna Capital's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Akuna Capital reported this one in July 2026, and it looks scarier than it is. Strip the story and it's a single-slot state machine: one active pair, three commands, a list of strings out. No graph, no DP. The risk isn't the idea, it's the exact message text and the edge-case order. If you've got an OA in the next few days, read the spec like a contract. And if you blank mid-assessment, StealthCoder runs invisibly on your desktop and gives you a working solution while you keep control of the clock.
The problem
Implement a communications handler for a single shared communication channel. At most two callers can communicate at a time, and no other pair can connect until the current communication ends.
The input instructions describes method calls in chronological order:
["connect", user1, user2] calls connect for the two named callers.
["hangup", user1, user2] calls hangup for the two named callers.
["clear_all"] calls clear_all.
Caller names uniquely identify the corresponding Caller objects. Treat a connected pair as unordered, so either caller order refers to the same active communication.
Connect
If user1 and user2 are the same caller, the call raises CommunicationException with the message {user1} cannot connect with {user2}.
If the callers are different but the line is already in use, the call raises CommunicationException with the message Connection in use. Please try later.
Otherwise, store the two callers as the active pair and return Connection established between {user1} and {user2}.
Hangup
If user1 and user2 are the same caller, the call raises CommunicationException with the message {user1} cannot hangup with {user2}.
If the two callers are the active pair, disconnect them and return {user1} and {user2} are disconnected.
Otherwise, the call raises CommunicationException with the message {user1} and {user2} not found in the communication channel.
Clear All
clear_all clears the channel regardless of its current users.
Return an array containing, in order, the returned string or exception message from every connect and hangup instruction. A clear_all instruction produces no output entry.
Function
handleCommunications(instructions: String[][]) → String[]
Examples
Example 1
instructions = [["connect","Alice","Bob"],["connect","Carol","Dave"],["hangup","Bob","Alice"],["connect","Carol","Dave"]]
return = ["Connection established between Alice and Bob","Connection in use. Please try later","Bob and Alice are disconnected.","Connection established between Carol and Dave"]
Alice and Bob occupy the free channel.
Carol and Dave cannot connect while that pair remains active.
hangup accepts the active pair in reverse order and frees the channel.
Carol and Dave can then connect.
Example 2
instructions = [["connect","Mia","Mia"],["hangup","Mia","Noah"],["connect","Mia","Noah"],["hangup","Mia","Mia"],["hangup","Noah","Mia"]]
return = ["Mia cannot connect with Mia","Mia and Noah not found in the communication channel.","Connection established between Mia and Noah","Mia cannot hangup with Mia","Noah and Mia are disconnected."]
The rejected same-caller calls do not change the channel. The final reversed-order hangup matches the active pair and disconnects it.
Example 3
instructions = [["connect","Ava","Ben"],["clear_all"],["hangup","Ava","Ben"],["connect","Cara","Dan"]]
return = ["Connection established between Ava and Ben","Ava and Ben not found in the communication channel.","Connection established between Cara and Dan"]
clear_all removes Ava and Ben without adding an output entry. Their later hangup is therefore not found, and the channel remains available for Cara and Dan.
Constraints
1 <= instructions.length <= 2000.
At most 100 distinct caller names appear.
Every instruction is one of ["connect", user1, user2], ["hangup", user1, user2], or ["clear_all"].
Every caller name is a non-empty, case-sensitive string that uniquely identifies one caller.Reported by candidates. Source: FastPrep
Pattern and pitfall
The whole problem reduces to one variable: the active pair, either empty or holding two names. Process instructions in order and append a string for every connect and hangup. For connect, check same-caller first, then line-in-use, then set the pair. For hangup, check same-caller first, then compare the pair as unordered, then clear it. clear_all just empties the slot and adds nothing to output. The pitfalls are all in the strings. Example 1 shows the in-use message printed without a trailing period in the sample output, while the spec text includes one, so match the examples carefully against the spec and keep the hangup message using the caller order given in the call, not the stored order. Also, rejected calls must not change state. Unordered comparison is easy: check (a==x and b==y) or (a==y and b==x). If you freeze on formatting during the live OA, StealthCoder is the hedge, since it reads the spec on screen and hands you the code.
If this hits your live OA and you blank, StealthCoder solves it in seconds, invisible to the proctor.
You can drill Communications Handler cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Akuna Capital's OA.
Akuna Capital reuses patterns across OAs. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Communications Handler FAQ
How hard is the Akuna Capital Communications Handler really?+
Easy on algorithms, medium on attention. It's a simulation with one stored pair and three instruction types. Constraints are tiny, so performance is irrelevant. Most lost points come from wrong message strings or checking conditions in the wrong order.
What's the trick to this problem?+
Keep a single nullable active pair. Check same-caller first in both connect and hangup, then the line state. Compare the pair unordered. Rejected calls leave state untouched. That's the whole solution, so spend your effort on exact output strings.
Does the hangup message use the order the caller passed in?+
Yes. Example 1 and 2 show hangup(Bob, Alice) returning 'Bob and Alice are disconnected.' using the arguments as given, not the stored order. Build the string from user1 and user2 of the current instruction, not from the saved pair.
Does clear_all add anything to the output?+
No. It empties the channel and produces no output entry. Only connect and hangup instructions append results. A later hangup for the cleared pair returns the not-found message, as shown in Example 3.
How do I prepare for this in 48 hours?+
Write it once from scratch without looking, then test it against all three examples and diff your strings character by character. Also try same-name connect during an active call, since the same-caller check must win over the in-use check.