An interviewer asks whether you have used Selenium. It is a wider question than it sounds, because the name covers several tools that do different jobs.
Selenium WebDriver is the one people almost always mean. A library your test code uses to control a real browser. This is what the rest of this track teaches.
Selenium Grid runs your tests across many machines and browsers at once. You send tests to the Grid and it distributes them. Useful when your suite is large or you need many browser and operating system combinations. There is a lecture on it in the intermediate track.
Selenium IDE is a browser extension that records your clicks and plays them back. Good for a quick demonstration or for someone with no programming experience. Recorded tests are famously fragile, because a recorder writes selectors based on what it can see rather than what is stable, so teams rarely keep them.
Selenium Manager is newer and it fixes the problem that used to make Selenium's first hour miserable. It downloads and matches browser drivers for you. If you read an older tutorial telling you to download a driver by hand and put it on your PATH, that advice is out of date.
Now the piece worth understanding properly, because it explains why Selenium behaves as it does.
WebDriver is a W3C standard, not just a library. Browser makers implement it. That is why Selenium supports so many browsers and so many languages: everyone agreed on the same protocol. Your test speaks WebDriver, a driver process translates it for the specific browser, and the browser does the work.
This is the source of both Selenium's strengths and its weaknesses.
The strength. Enormous reach. Java, Python, C#, JavaScript, Ruby. Every serious browser. Any operating system. Twenty years of accumulated tooling and answers. When a company needs to test on a browser and platform combination nothing else covers, Selenium is often the only option.
The weakness. Everything travels over that protocol, out of your process and into the browser and back. That makes it slower than Cypress or Playwright, and it means Selenium knows less about what the page is doing. No built-in waiting for an element to be ready, no automatic retrying of assertions, no network interception. Those are not oversights. They are outside what the protocol was designed to do.
That trade-off explains the rest of this track. Selenium hands you control and expects you to handle timing yourself, which is why waiting gets more attention here than in the other two tracks.
Remember this: WebDriver is a standard, Grid is for scale, IDE is a recorder, and the protocol explains both the reach and the extra work.
Reference: Selenium components.