Katkat

Design a customer support agent dispatcher that handles mid-request breaks

GoogleSoftware Engineer · Onsite

Last updated

Design and implement the core of a dispatcher that assigns waiting customers to available support agents, then extend it for an agent who is interrupted mid-request to take a break. Tests state modeling, queue and data structure choices, fair re-queuing, stale events and per-event complexity.

Design and implement the core of a dispatcher for a customer support team. Customers contact support and wait for help. Human support agents sign in, serve one customer request after another, and sometimes leave. The dispatcher decides which agent serves which waiting customer, and when. Model the main entities as classes, implement the operations that change state, and then handle the follow-up: an agent is interrupted in the middle of serving a customer to go on break.

Assume a single process holds all state in memory and receives events one at a time, each with a timestamp, so behavior is deterministic and testable. Where a business policy is not given below, ask about it instead of assuming it.

Clarifying Questions

  • Does an agent serve one customer at a time, or several at once up to a cap?
  • Which waiting customer is served first: strict arrival order, or do priorities or required skills change the order?
  • When several agents are free, which one receives the next customer: the agent idle the longest, the one who has handled the fewest requests, or any of them?
  • Can a waiting customer give up and leave the queue?
  • Does the dispatcher need to record wait and handling times for reporting?

Part 1 — Core dispatcher

Define the entities (for example an agent, a customer request and the dispatcher itself), their fields, and the states each can be in. Implement operations such as:

  • an agent becomes available (signs in or returns);
  • a customer request arrives;
  • an agent finishes the request they are serving;
  • an agent signs out.

Every operation should make any assignment that has just become possible. State the time complexity of each operation.

What This Part Should Cover

  • Agent and request state machines, with illegal or repeated events rejected or ignored deliberately
  • Structures for waiting customers and free agents that make each assignment decision cheap
  • Assignment triggered by every event that adds demand or frees capacity
  • Complexity of each operation in terms of agents and waiting customers

Part 2 — An agent is interrupted mid-request to take a break

While serving a customer, an agent is interrupted and goes on break. What happens to the agent, and what happens to the customer they were serving? Extend the design and the code to support going on break and returning from a break.

Clarifying Questions for this Part

  • Is the break immediate, or may the agent finish the current customer first?
  • Should the interrupted customer go to the next free agent, or wait for the same agent to return?
  • Can an agent go on break while idle, and what happens if the break event arrives twice?

What This Part Should Cover

  • A break state with transitions into and out of it, for both busy and idle agents
  • A re-queue or hand-off policy that keeps the interrupted customer's place and context
  • Late or stale events, such as a "finished" event for a customer who was already handed to someone else
  • Customers who are interrupted repeatedly

Hints

Hint 1

States before structures: List the states an agent and a request can be in, and the events that move them between states, before you pick any queue.

Hint 2

The customer left behind: Decide where the interrupted customer belongs relative to customers who arrived after them, and what must travel with them so the next agent does not start over.

Follow-up questions

  • Some requests need a skill (for example, billing) that only some agents have. How do the queues change?
  • Agents may now hold up to three conversations at once. What replaces the free-agent structure?
  • One process can no longer hold every agent and queue. How would you split the dispatcher across servers without assigning one customer twice?
  • What metrics would show a supervisor that breaks are hurting customer wait times?