Your suite takes ninety minutes on one machine. You need to test Safari, and your team is on Windows. Both problems have the same answer.
Grid runs your tests on other machines. Your test code stays where it is and sends its commands to a Grid, which passes them to a browser somewhere else. Because everything already travels over the WebDriver protocol, sending it to another machine changes almost nothing in your code.
Two parts:
The Hub receives requests and decides where each one goes.
Nodes are machines that actually run browsers. A Windows node with Edge, a Mac node with Safari, several Linux nodes with Chrome.
Connecting to it is one change:
const driver = await new Builder()
.forBrowser('chrome')
.usingServer('http://grid-hub.example.com:4444/wd/hub')
.build();
usingServer is the whole difference. Without it the driver runs locally; with it, the Hub finds a node with Chrome and runs it there.
You ask for what you need with capabilities:
const driver = await new Builder()
.usingServer(gridUrl)
.withCapabilities({ browserName: 'safari', platformName: 'mac' })
.build();
The Hub matches that against its nodes and queues you if none is free.
What Grid gives you.
Parallel scale. Twenty nodes means twenty tests at once. This is the usual reason teams adopt it: ninety minutes becomes under ten.
Browsers you do not have. Safari needs macOS. Edge on Windows needs Windows. A Grid with the right nodes gives your Linux build server access to both.
Consistency. Every run uses the same node images, so "works on my machine" stops being an argument.
What it costs, and be honest about this in interviews.
Machines to maintain. Nodes are real computers that need browsers, drivers and updates. Many teams start with a self-hosted Grid and move to a cloud provider (BrowserStack, Sauce Labs, LambdaTest) precisely to stop maintaining it.
Harder debugging. The failure happened on a machine you cannot see. Screenshots and logs stop being nice-to-have and become the only evidence you will get.
New failure modes. Nodes go offline. The queue backs up. Network latency between your test and the browser makes timing looser, and tests that were marginally flaky locally become reliably flaky on Grid.
Your tests must be independent. This is the requirement people discover too late. Running in parallel across machines is impossible for a suite that shares data or depends on order. Everything the earlier lectures said about unique data is what makes Grid possible at all.
Docker is the common setup now. A Hub and several nodes as containers, started together, torn down after. It removes most of the maintenance argument, and it is worth mentioning if an interviewer asks how you would set one up.
Remember this: Grid distributes the same WebDriver protocol to other machines. It buys speed and browser coverage, and it charges you in infrastructure and debugging.
Reference: Selenium Grid.