Articles
Selenium Grid Interview Questions: Session Routing, Capacity, and Failed Browser Starts
Practice Selenium Grid interview questions with a session-routing trace, slot-capacity example, and failed-browser-start diagnostic tree.
A Selenium Grid interview question becomes much easier when you stop treating Grid as one remote browser. A new-session request enters the Router, waits in the New Session Queue, is matched by the Distributor to a Node slot, and only then attempts to start a browser. A later WebDriver command follows a different path: the Router uses the Session Map to find the Node that already owns the session. That distinction tells you where to investigate a slow queue, a capability mismatch, or a browser that fails during startup.
Official facts in this guide come from Selenium’s Grid documentation. The three-node capacity exercise and diagnostic choices are editorial examples, not observations from a particular deployment. No candidate report establishes that an employer asks this exact trace.
What does each Grid component own?
Selenium describes Grid 4 as several cooperating components, not a single scheduler. The architecture guide names the Router, New Session Queue, Distributor, Nodes, Session Map, and Event Bus. The Router is the client-facing entry point. It forwards new-session requests to the queue and routes commands for existing sessions toward their owning Nodes. The Session Map supplies that ownership lookup.
The New Session Queue holds requests that have not been assigned a Node. The Distributor maintains a model of available Nodes and their slots, polls the queue, and attempts to match a request to a suitable slot. A Node actually runs the WebDriver session. The Event Bus carries internal events such as Node registration. If an interviewer asks, “Which component launches Chrome?” answer Node, not Router or queue.
A slot is a place where one session may run, with a stereotype describing the minimum capabilities it offers. Selenium’s documentation distinguishes slot count from a Node’s maximum simultaneous session count. A Node can advertise several browser-specific slots while still limiting total running sessions. Therefore totalSlots in a dashboard is not a promise that all those slots can be occupied at once.
Trace a new session, then trace an existing command
Imagine a Java test constructs ChromeOptions and calls RemoteWebDriver against the Grid URL. Selenium’s Remote WebDriver guide says the client supplies the remote address and browser options. The Router receives the new-session request and sends it to the New Session Queue. The Distributor searches its model for a matching free slot, reserves an eligible Node, and asks that Node to create the session. Once creation succeeds, the session-to-Node relationship is recorded, and the response returns to the client.
Now the test asks the browser for its current URL. This is not another capacity decision. The request already contains a session ID. The Router consults the Session Map and forwards the command to the Node that owns that session. If the map points to a missing Node, the problem is different from an initial “no matching slot” case. Inspect the session ID, map entry, Node health, and command response rather than raising the new-session timeout.
This routing split is the first article-specific asset: draw two arrows, one through the queue and Distributor for creation and another through the Session Map for later commands. A candidate who collapses both arrows into “the hub sends it to a node” cannot locate the failure boundary.
A capacity fixture: why four requests behave differently
Use this hypothetical Grid, not a claim about Selenium defaults. Node A advertises two Chrome slots and allows at most two simultaneous sessions. Node B advertises one Firefox slot and permits one session. Both Nodes are healthy and registered. At time zero, all slots are free. Four requests arrive close together: Chrome C1, Chrome C2, Chrome C3, and Firefox F1. Assume equal ordinary matching requirements and that browser startup succeeds.
| Request | Matching capacity at arrival | Expected first decision | What to verify |
|---|---|---|---|
| C1 | A has a free Chrome slot | Assign to A | Session ID appears on A. |
| C2 | A has its second free Chrome slot | Assign to A | A now reaches max concurrent sessions. |
| C3 | Chrome matches A, but A is full | Keep waiting in queue | Queue time and slot release matter. |
| F1 | B has a free Firefox slot | Assign to B | Firefox can proceed independently. |
C3 is not a capability mismatch. A suitable kind of slot exists but is occupied. When C1 quits and the slot becomes available, the Distributor may assign a waiting matching request, subject to the real queue’s rules and timing. Do not promise a strict completion order between C3 and F1 from this toy arrival list. Selenium’s component guide describes queue matching and retry behavior; actual scheduling depends on the implementation and live state.
Change C3 to a Safari request while this toy Grid has no Safari slot. Waiting longer cannot manufacture a compatible Node. The queue may retain the request until its configured timeout, but the repair is to provide a matching Node or correct the request, not simply increase max-sessions on A. This changed-input comparison is the second article-specific asset: it holds queue length constant while changing the reason no browser starts.
What do capabilities and stereotypes actually decide?
Capabilities describe what the test asks the remote end to provide. A Node slot stereotype states the minimum properties it can match. Browser name is the obvious example, but platform, browser version, or a custom capability can narrow eligibility. Selenium’s Grid architecture page explicitly describes the slot stereotype and the Distributor’s model.
A useful interview answer writes the requested capabilities beside each slot stereotype and marks the first mismatch. “Chrome exists on the Grid” is insufficient if the request requires a platform or browser version not offered by the currently registered slots. Likewise, a matching stereotype says only that the Distributor can attempt a session there. It does not prove the browser binary, driver, container, filesystem, or startup environment will work.
Do not equate the number of slots with throughput. Browser startup consumes CPU and memory, and a session can hold a slot while idle. Selenium’s getting-started guide notes Node concurrency and machine-resource considerations. A team may intentionally set max-sessions lower than apparent slot inventory to avoid resource contention. The right capacity answer names a workload, a bottleneck, and a measured queue or startup distribution rather than proposing “add more nodes” without evidence.
Diagnose a session that never starts
First determine whether the client received a new-session response, waited, or got an error. Record the requested capabilities, correlation or request ID if available, submission time, queue time, Grid version, and which Nodes were UP, DRAINING, or unavailable. Then branch. If no Node offers a matching stereotype, check the requested browser/platform/version and registration. If matching slots exist but are busy, inspect session counts, maxSession, queue size, long-running sessions, and session cleanup.
If the Distributor selected a Node but startup failed, inspect that Node’s logs and health, driver/browser compatibility, resource pressure, container image, and browser-start error. A selected slot is a promise to try, not proof of a live browser. Selenium documents SessionNotCreatedException as a failure to create a browser session; the exception name alone does not identify which prerequisite failed. Preserve the original Node error rather than replacing it with a generic queue-timeout explanation.
A useful production diagnostic is a short timeline: 09:00 request accepted, 09:01 still queued, 09:02 matching slot released, 09:02 Node creation attempted, 09:02 browser process exits. Those timestamps are illustrative. The timeline rules out “no capacity” as the final cause after the assignment and focuses the investigation on browser startup. Conversely, a request that never reached a Node should not send engineers hunting for a Chrome crash log.
What can Grid observability prove?
Selenium documents GraphQL queries for Grid maxSession, sessionCount, queue size, Node status, stereotypes, slots, and sessions. Compare several signals rather than one total. A high sessionCount near maxSession plus a growing queue supports a capacity hypothesis. A small sessionCount with a growing queue suggests capability mismatch, unavailable Nodes, registration lag, or a stale model. It does not by itself prove which one.
The Node registration process uses events and a Node status check, and Selenium cautions that the Distributor’s Grid Model can temporarily differ from reality. If the dashboard says a slot exists yet session attempts fail, compare the model with Node status and logs. A session count graph without capability labels can hide that Chrome is full while Firefox is idle. Segment queue age and failures by requested stereotype.
For interviews, avoid inventing a universal service-level target. Define one for the example: perhaps the team wants the 95th percentile from request arrival to session ready below its CI budget. Measure separately queue delay, Node selection, browser startup, test duration, and teardown. That decomposition tells you whether to add matching capacity, fix startup failures, or end abandoned sessions. It also prevents optimizing a fast Router while the browser binary repeatedly crashes.
How do you size and protect a CI Grid?
Start with the tests’ arrival pattern and session duration, not a raw “number of tests.” Suppose twenty jobs each request Chrome simultaneously and the measured healthy capacity is eight Chrome sessions. At least twelve initially wait; whether the queue drains before timeout depends on how quickly the first sessions release their slots. A browser that hangs after a failed test can occupy capacity long after useful work ends. Always close the driver in teardown and retain enough logs to distinguish client abandonment from Node failure.
Selenium’s configuration documentation shows explicit max-sessions and browser-driver settings. Set those deliberately, then load test with the browsers and versions the suite actually requests. Over-advertising capacity can turn queue delay into out-of-memory startup errors; under-advertising capacity can create avoidable waiting. The objective is stable completed tests per time window with understandable failure signals, not the highest nominal slot count.
When a Node must be removed, a draining state helps stop new assignments while active sessions complete. Do not treat deleting a Node mid-run as equivalent to graceful draining. Across CI jobs, retain test identity, requested capabilities, assigned Node, and session ID in logs without recording credentials or sensitive page content. That small linkage lets an engineer trace a failure from the test runner into the relevant Grid component.
Interview follow-ups that reveal understanding
Does every command pass through the Distributor? No. The Distributor handles new-session assignment. Existing commands are routed using the Session Map to the Node that owns the session.
If totalSlots is ten and sessionCount is five, why can a request still wait? Slots may be wrong-browser stereotypes, Nodes may be draining or unavailable, or per-Node maximum concurrency may already be reached. Inspect eligible free capacity, not aggregate numbers alone.
Will increasing a queue timeout repair a browser crash? No. It may allow more waiting before failure. If assignment occurs and the browser process cannot start, investigate the Node and driver/browser environment.
Does a matching slot guarantee a successful session? No. Matching determines eligibility for an attempt; actual creation can fail. Keep a trace across queue, Distributor, Node, and client response.
How do you compare two proposed fixes? Reproduce the same requested capability and workload, measure queue delay, startup success, and session completion, and check whether the failure moved to another boundary.