Test design is the whole interview
Tool questions are the warm-up. The round that decides the outcome hands you a feature and asks how you would test it. There is no correct list — the interviewer is watching how you decompose.
Here is a login form with email, password and a remember-me box. How do you test it?
Start with the boundaries, not the happy path. Empty fields, wrong password, an account that does not exist, an account that is locked, a password manager autofilling, the back button after logout. Then say which of these you would automate and which you would not.
Where you would stop automating
This is the question that separates a QA engineer from someone who writes Selenium scripts. Have a position and be able to defend it.
- Tests that are slower to maintain than to run manually
- Anything that depends on a third party you cannot control
- Visual polish, which humans still catch faster
- The long tail that fails for reasons unrelated to the feature
A flaky suite that nobody trusts is worse than no suite, because it trains the team to ignore red. Saying that out loud lands well.
Writing a bug that gets fixed
You may be asked to write or critique a bug report. It is a real skill and it is quick to demonstrate.
- Steps that a stranger can follow without asking you anything
- Expected versus actual, stated separately
- Environment, build and data — the three things always missing
- Severity argued, not asserted
Manual and automation are not rival careers here
In this market many QA roles are hybrid, and manual testing is not a lesser track. Companies hiring for their first QA engineer usually need someone who can do both and decide the ratio. Interviews reflect that — expect to be asked about both regardless of which title the posting used.
What interviewers here are really assessing
- Do you find the case nobody thought of, or only the ones in the ticket
- Can you disagree with a developer without it becoming personal
- Do you understand what the feature is for, or only what it does
- Would you block a release, and can you justify it to someone who wants it out
What to focus on at your level
Junior · 0–2 years
Clear bug reports, curiosity about edge cases, and one automated test you wrote and understand.
Mid · 2–5 years
A test strategy for a feature, a stable suite you maintained, and an opinion on what not to automate.
Senior · 5+ years
Quality as a process question rather than a testing one, influence over how the team ships, and a release you stopped.
Open QA roles right now
Read from the live roles on Nebryx when this page loaded — not a list written into the page. If it is empty, nothing matching is open today.
Frequently asked questions
Is manual QA a dead end in this region?
No. Hybrid roles are the norm here and strong manual testers are genuinely scarce. Adding automation raises your ceiling, but the market is not replacing one with the other the way job adverts sometimes imply.
Which automation tool should I learn?
Playwright for web is the safest current answer, with Selenium still widespread in existing suites. The tool matters far less than being able to explain why a test is worth its maintenance cost.
Do I need to code well?
Well enough to write readable tests and read the application's code. You are not being hired to write the product, but a QA engineer who cannot read a diff is limited.