In my first QA interview I was asked "what is the difference between integration and end-to-end testing?" I gave a vague answer about size. The interviewer moved on, and I did not get the job.
The words are simple once someone lays them out. Nobody had.
The categories describe how much of the system a test uses.
Unit test. Tests one function on its own, with nothing else running. If you have a function that adds tax to a price, a unit test calls it with 100 and checks it returns 120. No browser, no server, no database. Runs in milliseconds. Usually written by developers.
Integration test. Tests that two or more parts work together. Your code saves a contact, and the test checks the database really has the row. Slower than a unit test, because something real is running.
API test. Tests the server directly, without a browser. Your app's frontend normally sends a message to the server to save a contact. An API test sends that message itself and checks the answer. Fast and stable, because there is no screen to load. API means the set of addresses your server answers on.
End-to-end test, or E2E. Tests the whole system the way a user meets it. A real browser opens the real page, clicks the real button, and the test checks the screen. This is what Cypress, Playwright and Selenium do, and it is the slowest and most realistic kind.
Those four describe scope. Three more words describe purpose, and interviewers mix them in freely.
Smoke test. A small set of tests that check the app basically works. Can you load the page, log in, and see the dashboard. Run first, on every build. If smoke fails, nobody bothers running the rest.
Regression test. Checks that something which used to work still works. Most of your suite becomes this over time.
Acceptance test. Checks that the feature does what the business asked for. Often written in the language of the requirement rather than the code.
Now the practical part, which is what the interviewer is really testing.
Prefer the cheapest test that can catch the bug. If a bug can be caught by a unit test, a unit test is better: it runs in milliseconds, it never flakes, and when it fails it points at one function. Catching that same bug with a browser test means a slow test that fails with "button not found" and tells you nothing about where the bug lives.
So E2E tests are not the best kind of test. They are the most expensive kind, and you spend them on the few journeys that really matter. Login. Checkout. The thing that loses money when it breaks.
This idea is often drawn as a pyramid: many unit tests at the bottom, fewer integration tests, a small number of E2E tests at the top.
Remember this: the question is never "is this tested", it is "is this tested at the cheapest level that works".
If you want the wider picture of the job, read our QA automation roadmap.