82 Robot Framework interview questions with answers

What they are assessing

Basic orientation.

Model answer

Robot Framework is an open source, generic automation framework built on Python, using a keyword driven approach where tests are written as sequences of readable keywords rather than code. It is not a testing library itself: the actual capability comes from libraries such as SeleniumLibrary for browsers, RequestsLibrary for HTTP or DatabaseLibrary for SQL. That separation is the defining feature, because the same syntax drives web, API, database and desktop testing.

Likely follow-up

What does generic mean in that description?

What they are assessing

The central concept.

Model answer

An approach where each action is represented by a named keyword, and a test is a sequence of those keywords with arguments. The keyword hides the implementation, so a test reads as Open Browser, Input Text, Click Button, Page Should Contain rather than as code. The benefit is that tests are readable by people who do not write code, and that changing how something is done means editing one keyword rather than every test that uses it.

What they are assessing

Whether they can state the case for the tool.

Model answer

Readable tests that non-programmers can follow and often write. A large ecosystem of libraries covering web, mobile, API, database and desktop, so one framework spans several test types. Excellent reporting out of the box, with a log that records every keyword, its arguments and its result, which is unusually good for debugging. Easy extension in Python when a keyword does not exist. And the ability to build higher-level keywords from lower-level ones, so a suite can be written at whatever level of abstraction suits the reader.

What they are assessing

Balance, which separates users from advocates.

Model answer

The syntax is unusual, with significant whitespace separating arguments, which trips up people coming from a programming background and makes editing without a proper plugin painful. Complex logic is awkward: conditionals and loops exist but are verbose, and anything genuinely algorithmic belongs in a Python library rather than in test data. The abstraction can hide too much, so a readable test gives no indication of what it actually does. And debugging a deep keyword chain means reading through several layers of the log. Teams with strong Python skills often find pytest more direct.

Trap to avoid

Claiming it has no disadvantages. Interviewers ask this specifically because the answer indicates whether you have maintained a suite or only built one.

What they are assessing

A comparison candidates frequently confuse.

Model answer

They are not alternatives. Selenium is a browser automation library. Robot Framework is a test framework that organises and runs tests, provides reporting, and calls libraries to do the work. SeleniumLibrary is the bridge that exposes Selenium functionality as Robot keywords. So you can use Robot Framework without Selenium, for API or database testing, and you can use Selenium without Robot Framework, driving it from pytest or JUnit. Asking which is better is a category error.

Likely follow-up

When would you use Robot Framework over a pytest and Selenium combination?

What they are assessing

Tool selection with reasons.

Model answer

When the suite needs to be readable or writable by people who are not programmers, which is the strongest case. When the team spans several test types and wants one framework and one report across web, API and database. When reporting quality matters to stakeholders outside engineering, since the Robot log is better than most alternatives without configuration. I would choose pytest instead when the team is entirely engineers, when the tests need real programming logic, or when the project already has a Python codebase whose fixtures and tooling the tests should reuse.

What they are assessing

Basic file structure.

Model answer

Settings, for imports, documentation, suite-level setup and teardown, and metadata. Variables, for defining variables in the file. Test Cases, or Tasks in RPA usage, for the tests themselves. And Keywords, for user-defined keywords local to that file. Comments is a fourth, rarely used. The headers are written with a leading asterisk notation, and only Settings and Test Cases appear in most simple suites.

What they are assessing

The syntax detail that causes the most beginner failures.

Model answer

By at least two spaces, or by a pipe character in the pipe-separated format, or by a tab. A single space is part of the text rather than a separator, which is the rule people forget. This is why a keyword with an argument appears to be ignored or produces a confusing error: one space was used and Robot read the whole line as a single long keyword name. It is also why editing Robot files in an editor that trims trailing whitespace or converts tabs can silently break a suite.

Trap to avoid

Saying a single space. It is the most common cause of a Robot file that will not run, and interviewers use this to check whether someone has actually written tests.

What they are assessing

Current knowledge, since this changed.

Model answer

Plain text with the .robot extension is the standard, in either space-separated or pipe-separated form. Resource files use .resource by convention. Older versions supported HTML and TSV formats, and HTML was removed in version 3.2, so a legacy suite in HTML will not run on a current installation. Robot Framework 6 and later also support JSON for programmatically generated test data, though that is uncommon in hand-written suites.

What they are assessing

Readability practice.

Model answer

A hash begins a comment on any line. Documentation is different and better: the Documentation setting in the Settings section documents the suite, the Documentation setting inside a test documents that test, and the same inside a user keyword documents the keyword. The important distinction is that documentation appears in the generated report and log and in the output of libdoc, while comments do not, so anything a reader of the report needs belongs in documentation rather than a comment.

What they are assessing

Current syntax, which changed significantly in version 5.

Model answer

Since version 5 there is native IF, ELSE IF, ELSE and END syntax, plus FOR and END, WHILE, TRY and EXCEPT, and BREAK and CONTINUE. Before that, conditionals meant the Run Keyword If keyword from BuiltIn, which is still common in older suites and is much harder to read. Knowing both matters, because any suite more than a couple of years old is full of Run Keyword If and a candidate who only knows the modern syntax will struggle to maintain it.

Likely follow-up

When should logic live in test data at all rather than in a Python keyword?

What they are assessing

Basic vocabulary.

Model answer

A library keyword is implemented in code, usually Python, and imported from a library such as SeleniumLibrary or BuiltIn. A user keyword is defined in Robot syntax in the Keywords section of a test file or a resource file, and is built by combining other keywords. Most suites are mostly user keywords calling library keywords, with the user keywords providing the domain vocabulary.

What they are assessing

Core authoring skill.

Model answer

Define the keyword in the Keywords section, declare parameters with the Arguments setting, and return a value with the RETURN statement in version 5 and later, or Return From Keyword in older versions. Arguments can have default values, and you can accept a variable number with a list argument prefixed by an asterisk or named arguments with a double asterisk, which mirrors Python. The caller assigns the returned value to a variable on the left of the keyword call.

What they are assessing

A real source of confusing failures.

Model answer

Keywords in resource files and the test file itself take priority over library keywords. Between two libraries defining the same name, the match is ambiguous and Robot raises an error rather than guessing. The fix is to prefix the keyword with its library name, as in SeleniumLibrary.Click Element. You can also set a library search order explicitly with the Set Library Search Order keyword, which is the right approach when the conflict is systematic rather than occasional.

Likely follow-up

Why is relying on search order riskier than prefixing?

What they are assessing

A distinctive Robot feature.

Model answer

A keyword name can contain variables, so a keyword defined as Login With Username and Password can be called with the values written inline in the sentence. It makes tests read like natural language, which is the main appeal and the reason behaviour-driven style works in Robot. The cost is that embedded arguments make keyword resolution more complex and can produce ambiguous matches, and refactoring them is harder because the name itself carries structure.

What they are assessing

Design judgement, which is where Robot suites succeed or fail.

Model answer

I aim for three layers. A business layer where the test reads in domain terms, such as Place An Order For A Standard Customer. A workflow layer of reusable page or feature actions, such as Add Item To Basket. And a technical layer wrapping the library calls, where the locators live. Tests only call the top layer, so a UI change touches the bottom. The failure mode in both directions is real: too flat and every test is full of Click Element with raw locators, too deep and a reader has to open five files to find out what the test actually does, which makes the suite unmaintainable in a different way.

Likely follow-up

How do you stop the abstraction layers multiplying over time?

What they are assessing

Dynamic keyword execution and its risks.

Model answer

Run Keyword from BuiltIn executes a keyword whose name is supplied as a string, which allows the keyword to be decided at run time. Related variants include Run Keyword If, Run Keyword And Ignore Error, Run Keyword And Return Status and Wait Until Keyword Succeeds. They are useful for retry logic and for tolerating an expected failure. The risk is that heavy use makes a suite hard to follow and defeats static analysis, so I prefer the native IF and TRY syntax where it covers the case, and keep Run Keyword variants for genuine retry and error-tolerance patterns.

What they are assessing

Basic syntax.

Model answer

Scalar variables with a dollar prefix, holding a single value. List variables with an at prefix, which expand into multiple arguments when used. Dictionary variables with an ampersand prefix, which expand into named arguments. And environment variables with a percent prefix. A list or dictionary can also be accessed as a scalar, which is how you pass the whole structure rather than expanding it, and that distinction is the usual source of confusion.

What they are assessing

A frequent source of bugs in shared suites.

Model answer

Local by default, meaning the current keyword or test. Test scope with Set Test Variable, visible for the rest of the current test including inside keywords it calls. Suite scope with Set Suite Variable, visible to all tests in the suite. Global scope with Set Global Variable, visible everywhere for the rest of the run. The practical caution is that suite and global variables create hidden coupling between tests, so a test can pass or fail depending on what ran before it, which is exactly the dependency that makes a suite impossible to run in parallel or in isolation.

Trap to avoid

Using Set Global Variable for convenience. It works immediately and makes the suite order-dependent in a way that is very hard to trace later.

What they are assessing

Practical execution.

Model answer

With the --variable option, giving a name and value pair, repeated for each variable. For many variables, a variable file supplied with --variablefile is cleaner, and it can be a Python file that computes values rather than a static list. Command line variables have the highest priority, overriding those defined in the Variables section, which is what makes the same suite runnable against different environments without editing the test data.

What they are assessing

Configuration design.

Model answer

A Python or YAML file supplying variables, imported in Settings or passed on the command line. It is better whenever the values need to be computed rather than literal: reading from the environment, decrypting a secret, deriving a URL from a region code, or building a dictionary from a data source. A Python variable file can also expose a get_variables function that receives arguments, so one file serves several environments. The Variables section remains the right home for genuinely static values that belong with the tests.

Likely follow-up

Where should credentials live, and why not in a variable file in the repository?

What they are assessing

Depth on a feature that explains a lot of real suite code.

Model answer

It allows attribute access and method calls inside a variable reference, so you can call a method on an object held in a variable directly in test data, or index into a list or dictionary. It is powerful and it is the main way Robot test data reaches into Python objects without a wrapper keyword. The caution is that it puts code in test data, which is precisely what the keyword layer exists to avoid, so I use it for simple access and write a keyword when the expression stops being readable.

What they are assessing

Awareness of what is available without imports.

Model answer

The standard library imported automatically, providing the general-purpose keywords: Should Be Equal and the other assertions, Log, Set Variable, Run Keyword and its variants, Sleep, Convert To Integer, Evaluate and so on. Because it is automatic, its keywords are available in every suite without a Library setting, which is why beginners often do not realise where they come from.

What they are assessing

Breadth.

Model answer

BuiltIn, Collections for lists and dictionaries, String, DateTime, OperatingSystem, Process, Screenshot, Telnet, XML, and Dialogs for manual intervention during a run. Remote is also standard and enables the remote library interface. Everything else, including SeleniumLibrary, Browser, RequestsLibrary, DatabaseLibrary and AppiumLibrary, is a separate installation from PyPI, which is a distinction worth getting right because it affects what you can assume on a new machine.

What they are assessing

Basic configuration.

Model answer

With the Library setting in the Settings section, giving the library name and any arguments after it. SeleniumLibrary, for example, accepts a default timeout and an implicit wait at import. You can also import with a WITH NAME alias, which is how you use two instances of the same library with different configuration, or shorten a long library name for prefixing. Libraries can also be imported dynamically at run time with the Import Library keyword, which is occasionally necessary but worth avoiding since it hides dependencies.

What they are assessing

A subtle topic that causes state bugs.

Model answer

A library declares a scope of GLOBAL, SUITE or TEST. GLOBAL means one instance for the whole run, so any state it holds persists across every test. SUITE means a new instance per suite. TEST means a new instance per test, so state is reset. SeleniumLibrary is GLOBAL, which is why the open browser persists between tests and why a test that leaves a browser in a bad state affects the next one. When writing a custom library that holds state, choosing the scope deliberately is the difference between a reusable library and a source of intermittent failures.

Likely follow-up

What scope would you choose for a library holding an API session token?

What they are assessing

The most basic web keyword.

Model answer

Open Browser with a URL and a browser name opens a session and navigates to the page. Go To navigates an already-open browser. Close Browser closes the current one and Close All Browsers closes every session, which is what belongs in a suite teardown. Modern versions can also take browser options and a remote URL for grid execution as arguments to Open Browser.

What they are assessing

Locator fluency.

Model answer

id, name, class, tag, xpath, css, link, partial link, and some element-specific strategies. The prefix is written before a colon, as in css:button.primary, and when no prefix is given SeleniumLibrary tries id and then name, which is a convenience that makes some locators work without anyone understanding why. Preference order in practice is id, then a stable data attribute via css, then a well-written xpath only where css cannot express the relationship.

What they are assessing

The flakiness question in Robot terms.

Model answer

With the explicit Wait Until keywords: Wait Until Element Is Visible, Wait Until Page Contains Element, Wait Until Element Is Enabled and so on, each taking a timeout. There is also an implicit wait set at import or with Set Selenium Implicit Wait, and a Selenium speed setting that delays every action. The right answer is explicit waits on the specific condition you care about. Implicit wait applies globally and interacts badly with explicit waits, and Set Selenium Speed is a demonstration feature that should never be in a real suite.

Trap to avoid

Using Sleep to fix a timing problem. It is the single most common thing in inherited Robot suites and the reason they take hours to run.

What they are assessing

Common interaction patterns.

Model answer

A standard select element is handled with Select From List By Label, By Value or By Index, and verified with List Selection Should Be. A JavaScript alert is handled with Handle Alert, which accepts an action of ACCEPT or DISMISS and can return the text. A frame requires Select Frame before interacting and Unselect Frame afterwards, since locators only search the current frame. Custom dropdowns built from divs are not select elements at all, and need ordinary click and element keywords rather than the Select keywords, which is a frequent source of confusion.

What they are assessing

Practical debugging setup.

Model answer

SeleniumLibrary takes a screenshot automatically on failure by default, embedding it in the log, which is one of its genuinely good defaults. Beyond that I add a test teardown using Run Keyword If Test Failed to capture the page source, the browser console log and any relevant application state. Capture Page Screenshot can also be called explicitly at key points. The thing worth configuring is the screenshot directory, so that in CI the images are published as artefacts rather than left in the workspace where the log cannot resolve them.

What they are assessing

Current ecosystem awareness.

Model answer

Browser library is built on Playwright rather than Selenium. The practical differences are automatic waiting built into most keywords, which removes much of the explicit wait code a SeleniumLibrary suite carries, considerably faster execution, native support for intercepting network traffic, and first-class handling of multiple browser contexts and tabs. It also uses a different locator syntax with strict mode by default, meaning a locator matching more than one element is an error rather than silently taking the first.

Likely follow-up

Why is strict mode an improvement rather than an inconvenience?

What they are assessing

Migration judgement.

Model answer

Not wholesale, and not for its own sake. The keyword names, locator syntax and waiting model all differ, so it is a rewrite of the technical keyword layer rather than a find and replace, and if the suite is layered properly that layer is where the work is concentrated, which is an argument for the layering rather than against the migration. I would consider it seriously if the suite is slow and full of explicit waits, or if it needs capabilities Selenium handles poorly such as network stubbing or multiple contexts. I would not do it if the suite is stable and the team has deep Selenium knowledge, because the gain is real but rarely worth a rewrite on its own.

What they are assessing

The main extension mechanism.

Model answer

Write a Python module or class whose public methods become keywords: the method name is converted from snake case to a space-separated keyword name, so a method named login_as_admin becomes Login As Admin. Import it with the Library setting using the module path. A class-based library can hold state and declare ROBOT_LIBRARY_SCOPE. Docstrings become keyword documentation visible in libdoc and in the log, and type hints on parameters give automatic argument conversion, so a parameter annotated as int receives an integer rather than a string.

Likely follow-up

What determines whether a method becomes a keyword?

What they are assessing

The architectural boundary that most determines suite quality.

Model answer

Anything algorithmic: parsing, calculation, data generation, retry logic with conditions, or interaction with a system that has a real API. Robot test data is good at sequencing readable steps and poor at expressing logic, so a nested conditional in a .robot file is a signal that the logic belongs in Python. The rule I apply is that test data should describe what is being tested and Python should implement how, and if someone reading a test file has to trace control flow to understand it, the boundary has been drawn in the wrong place.

What they are assessing

Depth on library implementation.

Model answer

The static API is a module or class where methods map directly to keywords, which covers most cases. The dynamic API implements get_keyword_names and run_keyword, so the keywords a library offers can be determined at run time, which is how libraries that wrap another system expose keywords generated from that system. The hybrid API sits between them with get_keyword_names but direct method resolution. Dynamic is worth knowing because it is how the remote library interface and several large libraries work, and because a keyword that does not appear in your editor but works at run time is usually a dynamic library.

What they are assessing

Basic reuse mechanism.

Model answer

A file holding user keywords, variables and imports to be shared across test suites, imported with the Resource setting. It has the same syntax as a test file but no Test Cases section. Resource files are how a Robot suite avoids duplicating keywords, and the conventional structure is one per page or feature area plus a common one for shared setup.

What they are assessing

Project organisation.

Model answer

Tests in a tests directory, organised by feature, with suite directories mirroring the application structure. Resources in a separate directory, split into page or feature resource files plus a common resource importing the libraries and shared keywords. Python libraries in a libraries directory. Test data and variable files separate from both. A single common resource that every suite imports keeps the Settings sections short, and the critical discipline is that tests never import SeleniumLibrary directly, only the resource layer does, so the underlying library can be changed in one place.

Likely follow-up

Why should tests not import SeleniumLibrary directly?

What they are assessing

Suite-level configuration, which many users never encounter.

Model answer

A file placed in a directory to configure the suite that directory represents. It can set suite documentation, metadata, and crucially Suite Setup and Suite Teardown that apply to everything in that directory and below. It cannot contain test cases. It is the right place for one-time setup shared across a group of suites, such as establishing a session or preparing an environment, and it is how you avoid repeating the same setup in every file.

What they are assessing

Basic selection mechanism.

Model answer

Free-form labels attached to tests with the Tags setting, or to every test in a file with Test Tags, previously Force Tags. They are used to select what runs, with --include and --exclude on the command line, and they appear in the report with per-tag statistics. Typical tags mark a smoke set, a feature area, a priority level, or a known-broken test.

What they are assessing

Execution control.

Model answer

By tag with --include and --exclude, which accept AND, OR and NOT combinations and simple patterns. By name with --test or --suite. By path, pointing the runner at a directory or file. And with --rerunfailed together with a previous output.xml to run only what failed last time, which is extremely useful when stabilising a suite. Tag-based selection is the one to design for, because name and path selection break as the suite is reorganised.

Likely follow-up

How would you build a smoke suite that stays useful as the project grows?

What they are assessing

Current features, since skipping was added in version 4.

Model answer

Robot Framework 4 introduced genuine skipping, with the Skip keyword, the Skip If keyword, a --skip option for tags, and the robot:skip and robot:skip-on-failure reserved tags. A skipped test is reported separately from passed and failed, which is the point: before this, teams either removed tests or let them fail, both of which distort the result. robot:skip-on-failure is particularly useful for tests covering known-broken functionality, since the test still runs and reports but does not fail the build.

What they are assessing

Knowledge of a genuine gap in the core tool.

Model answer

Not natively. Robot Framework has no built-in parallel execution, and the standard answer is Pabot, which splits tests or suites across processes and merges the output files afterwards. The real work is making the suite capable of it: no suite or global variables carrying state between tests, no shared test data that two processes can collide on, and unique browser sessions and screenshot paths per process. Pabot also supports a shared value store for cases where coordination is genuinely needed. A suite written without parallelism in mind rarely runs correctly under Pabot on the first attempt.

Trap to avoid

Saying Robot Framework supports parallel execution. It does not, Pabot does, and the distinction usually leads to the follow-up about what makes a suite parallel-safe.

What they are assessing

Lifecycle basics.

Model answer

Setup runs before and teardown after. They exist at suite level, with Suite Setup and Suite Teardown in Settings, at test level with Test Setup and Test Teardown applying to every test in the file or the Setup and Teardown settings on an individual test, and at keyword level with a Teardown setting inside a user keyword. Suite-level runs once per suite, test-level once per test.

What they are assessing

A detail that determines whether cleanup is reliable.

Model answer

Yes. Teardown runs regardless of whether the test passed or failed, which is precisely why cleanup belongs there rather than at the end of the test body. Teardown also continues through its own failures rather than stopping at the first one, so several cleanup steps all execute. If a teardown itself fails, the test is marked failed even if the body passed, which is correct behaviour but occasionally surprising when a cleanup step is flaky.

Likely follow-up

What belongs in test teardown for a browser suite?

What they are assessing

The property that determines whether a suite can scale.

Model answer

Each test establishes its own preconditions, preferably through an API or database rather than the UI, and cleans up after itself in teardown. No reliance on suite or global variables carrying state forward. No assumption about execution order. A browser session that is either created per test or reset to a known state in setup. The test for whether you have achieved it is simple: run any single test on its own, and run the suite with --randomize tests, and see whether it still passes.

What they are assessing

A core pattern.

Model answer

A test that runs the same keyword with different data sets. The native mechanism is the Test Template setting, which names a keyword, after which each row in the test body is a set of arguments and produces its own result rather than failing the whole test on the first bad row. Templates can be set per test or for the whole file. This is the right tool for input validation and boundary testing, where twenty variations of one check would otherwise be twenty near-identical tests.

Likely follow-up

What is the advantage of a template over a FOR loop here?

What they are assessing

Practical data handling.

Model answer

Through a library: DataDriver is the common choice for driving a template from a CSV, Excel or JSON file, generating one test per row at parse time, which means each row appears as a separate test in the report. Alternatively, read the file in a Python keyword and loop, though that produces a single test whose failures are harder to read. ExcelLibrary and openpyxl via a custom keyword cover reading spreadsheets directly when the data is needed mid-test rather than as the driver.

What they are assessing

Balance on a technique that is easy to over-apply.

Model answer

The data becomes the test, and nobody reviews it. A spreadsheet of four hundred rows is not reviewable in the way a test file is, so coverage decisions get made by whoever last edited a cell. Failures also become harder to diagnose, since the failing input is a row rather than a named scenario. And the approach encourages volume over thought: it is easy to add fifty more rows and feel productive without adding any new risk coverage. I use it where the variation genuinely is just data, such as validation rules, and write explicit tests where each case represents a different behaviour.

What they are assessing

Basic output knowledge.

Model answer

output.xml holding the complete machine-readable results, log.html with the detailed step-by-step execution log including every keyword and its arguments, and report.html giving the high-level summary with statistics by suite and tag. The log is for debugging a failure, the report is for telling someone the outcome, and output.xml is the source both are generated from.

What they are assessing

A tool many users do not know exists.

Model answer

Rebot is the post-processing tool that generates reports and logs from one or more output.xml files. Its most valuable uses are merging the outputs of a parallel run back into a single report, which is what Pabot relies on, combining results from several separate runs such as different browsers, and re-generating a report with different options without re-running the tests. The --merge option is also how a rerun of failed tests is folded back into the original results so the report shows the final state rather than two conflicting ones.

Likely follow-up

Why does merging matter for a rerun of failed tests?

What they are assessing

Debugging control.

Model answer

TRACE, DEBUG, INFO, WARN and ERROR, with INFO as the default threshold. The Log keyword takes a level argument. Running with --loglevel DEBUG or TRACE produces far more detail, including library internals and argument values, which is how you debug a failure you cannot reproduce interactively. TRACE in particular logs keyword arguments and return values for everything, which makes the log large but very informative. There is also a separate console log level controlled independently.

What they are assessing

A real problem, since Robot logs arguments by default.

Model answer

This matters because Robot logs keyword arguments, so a password passed to Input Text appears in the log in plain text by default. SeleniumLibrary mitigates this for some keywords, and the general solutions are to use Input Password rather than Input Text, which masks the value, to set the log level so argument logging is reduced, and in custom libraries to use the robot.api.logger with care and avoid returning secrets. For values that must be handled, I keep them out of test data entirely and fetch them inside a Python keyword from the environment or a secret store, so they never become a keyword argument.

Trap to avoid

Not realising the log contains credentials at all. Robot logs are routinely published as CI artefacts, which makes this a genuine disclosure risk rather than a theoretical one.

What they are assessing

Pipeline basics.

Model answer

By invoking the robot command, usually through a Python virtual environment with dependencies pinned in a requirements file, pointing at the test directory with the appropriate tag selection and an --outputdir under the workspace so artefacts can be published. The exit code is the number of failed tests, capped at 250, with 0 for success, so the pipeline fails naturally. The log and report HTML files should be published as artefacts, and most CI systems can also consume a JUnit XML conversion for native test reporting.

Likely follow-up

How do you get Robot results into a CI system that expects JUnit XML?

What they are assessing

The practical setup problem that breaks most pipelines.

Model answer

Containers are the reliable answer: an image with the browser and matching driver installed, so the version pairing is fixed and reproducible rather than depending on whatever is on the agent. Where a container is not possible, webdriver-manager or Selenium Manager handles driver resolution automatically, which removes the classic failure where Chrome auto-updates overnight and every test fails the next morning with a driver mismatch. For the Browser library, the Playwright browsers are installed as part of its initialisation, which is more self-contained but adds setup time.

What they are assessing

Configuration design at scale.

Model answer

All environment-specific values come from variable files or command line variables, never from edited test data, so the suite is identical everywhere and the environment is a parameter. A variable file per environment, selected with --variablefile, is the cleanest form, with secrets injected from the CI secret store as environment variables and read with the percent syntax or inside a Python keyword. The rule I hold to is that the git working tree should be identical whichever environment you are running against, because any suite where you edit a file to change environment eventually gets committed pointing at the wrong one.

What they are assessing

The most common Robot error.

Model answer

The library or resource is not imported in that file. The library is not installed in the active Python environment, which is common when a virtual environment is not activated. The name is misspelt or spaced wrong, since keyword matching ignores case, spaces and underscores but not actual spelling. The keyword is in a resource file imported by another resource rather than directly, and resource imports are not transitive for the importing file in the way people assume. Or two libraries define it and the error is actually ambiguity rather than absence.

What they are assessing

Systematic debugging.

Model answer

Start with the log from the failing run rather than guessing, since Robot logs every keyword and its arguments and usually shows exactly which step failed and with what values. Then check the usual differences: headless versus headed browser, screen resolution affecting element visibility, timing on a slower or more loaded agent, test data that exists locally but not in the CI environment, and ordering if the local run was a single test while CI runs the whole suite. Reproducing headless locally at the CI resolution resolves a surprising proportion of these before any real investigation is needed.

What they are assessing

Tooling depth.

Model answer

The Dialogs library pauses execution and waits for input, which is crude but effective for inspecting application state mid-test. The RobotDebug library gives an interactive shell where you can run keywords against the live session, which is much better. Setting --loglevel TRACE gives full argument and return-value logging. For custom Python libraries, an ordinary breakpoint works since they run in the same process. And for Selenium specifically, pausing with the browser open and using the browser developer tools to test a locator is usually faster than any of these.

What they are assessing

Optimisation in the right order.

Model answer

Measure first, because the Robot report gives per-suite and per-test durations and the distribution is always uneven. Then, roughly in order of return: remove Sleep keywords, which in an inherited suite are usually responsible for an hour or more on their own and are pure dead time. Replace UI login with an API call and a session injected into the browser. Seed data through the API rather than clicking through setup. Then introduce Pabot for parallel execution, which requires the independence work described earlier. And finally question coverage, since suites of that length usually contain many end-to-end tests duplicating the same path with different data, which a template or a lower-level test would cover faster.

Likely follow-up

Which of those usually gives the biggest single saving?

What they are assessing

Recognition of a syntax-level error.

Model answer

Almost always a separator problem: a line that should contain a keyword starts with the wrong indentation, or an argument has been separated from a keyword by a single space so Robot has parsed the structure differently from what was intended. It is a parse-time error rather than a run-time one, which is the clue that it is syntax rather than logic. Enabling visible whitespace in the editor usually makes the cause obvious immediately.

What they are assessing

Flake handling in Robot terms.

Model answer

Diagnose before suppressing. The usual causes are acting before the element is interactive, acting on an element that has been re-rendered, an overlay intercepting the click, or an animation still running. The fixes in order are: wait on the right condition rather than presence, since visible and enabled are different from present. Re-find the element rather than reusing a reference. Scroll it into view explicitly if the page has sticky headers. And only as a last resort, Wait Until Keyword Succeeds around the interaction, which retries but hides the cause. Clicking with JavaScript via Execute Javascript almost always works and almost always hides a genuine usability defect.

Trap to avoid

Reaching for Execute Javascript to click. It makes the test pass while removing the only check that a real user could perform the action.

What they are assessing

Basic structure.

Model answer

A test case is a single test. A test suite is a collection of them, and in Robot Framework a suite corresponds to a file, while a directory becomes a higher-level suite containing the suites inside it. This means suite structure follows directory structure, which is why organising folders thoughtfully matters more in Robot than in frameworks where suites are declared in code.

What they are assessing

Retry handling.

Model answer

It retries a keyword until it passes or a timeout expires, taking a retry count or timeout and an interval. It is appropriate for genuine eventual consistency: polling an API until a record appears, waiting for an asynchronous backend process, or an element that depends on a background refresh. It is not appropriate as a general wrapper for flaky interactions, because it converts a diagnosable failure into a slow success and removes the signal that something is wrong. The test is whether the thing you are waiting for is genuinely asynchronous or merely unreliable.

What they are assessing

Shared environment problems.

Model answer

Generate it in a keyword rather than hardcoding: a timestamp or random suffix on an email or reference, usually from a Python keyword using the uuid or datetime modules, or the Generate Random String keyword from the String library. The second half, which matters more, is cleanup in teardown through an API call, or a namespacing convention so generated data can be purged in bulk. Robot makes generation easy and gives no help with cleanup, so a suite that generates data without a disposal plan slowly fills the test database until something unrelated starts failing.

What they are assessing

Non-UI testing, which is half of what Robot is good for.

Model answer

With RequestsLibrary, which wraps the Python requests library. You create a session with Create Session, make calls with GET On Session, POST On Session and so on, then assert on the response status and body. JSON bodies are handled as dictionaries, and the JSONLibrary or the built-in Collections keywords handle deeper assertions. For schema validation, a Python keyword using jsonschema is the usual approach. API tests are also the fastest way to seed state for UI tests, which is often their main value in a mixed suite.

Likely follow-up

How would you validate a response against a JSON schema?

What they are assessing

Knowledge of built-in tag behaviours.

Model answer

Tags beginning with robot: have special meaning. robot:exit is set automatically on tests stopped by a graceful shutdown. robot:no-dry-run excludes a keyword from dry-run validation, which matters when a keyword cannot be resolved statically. robot:skip and robot:skip-on-failure control skipping. robot:continue-on-failure and robot:recursive-continue-on-failure change failure behaviour inside a keyword. Knowing they exist matters mostly because a user-defined tag starting with robot: will behave unexpectedly.

What they are assessing

A validation feature that is underused.

Model answer

Running with --dryrun parses and validates the suite without executing keywords: it checks that every keyword exists, that argument counts match, and that imports resolve. It catches typos, missing imports and signature mismatches in seconds rather than discovering them twenty minutes into a run. It is genuinely valuable as a fast pre-commit or pipeline check on a large suite, and it is the cheapest quality gate available in Robot Framework. Keywords that build their behaviour dynamically need the robot:no-dry-run tag to avoid false errors.

What they are assessing

Conditional teardown.

Model answer

A BuiltIn keyword valid only in a teardown, running another keyword only when the test failed. It belongs in test teardown for evidence capture: screenshots beyond the automatic one, page source, browser console logs, application logs, or the current URL. The reason to make it conditional is cost, since capturing full diagnostics on every passing test in a large suite adds significant time and produces artefacts nobody looks at. Its counterparts are Run Keyword If Test Passed and Run Keyword If All Tests Passed for suite teardown.

What they are assessing

Reporting customisation.

Model answer

Suite and test Documentation appear directly in the report. The Metadata setting adds arbitrary name and value pairs at suite level, which is the right place for build number, environment and application version, and it is the single most useful customisation because it answers what was this run actually against. Tags produce per-tag statistics in the report, and --tagstatcombine creates combined statistics for tag expressions. For anything beyond that, output.xml can be parsed to generate a custom report.

Likely follow-up

What metadata would you always include?

What they are assessing

Library authoring detail.

Model answer

With the robot.api.deco keyword decorator, which takes a name and optionally argument types and tags. It is used when the natural Python method name does not read well as a keyword, when you want embedded arguments in the keyword name, or when you need to attach tags to a library keyword. The same decorator is also how you mark which methods are keywords when a library has many public methods that should not all be exposed.

What they are assessing

An architectural feature with specific uses.

Model answer

A mechanism where a library runs as a separate process, potentially on another machine and in another language, communicating with Robot Framework over XML-RPC. The Remote library in the standard distribution is the client. It is used when the library must run somewhere else, such as on a device under test or a different operating system, or when it is written in a language other than Python, since remote library servers exist for Java, .NET, Ruby and others. It is not needed for ordinary Python libraries and adds a failure mode, so it should be a deliberate choice.

What they are assessing

Realistic assessment of the tool’s main selling point.

Model answer

It is one of the better choices, with a caveat. The keyword syntax genuinely is approachable, and manual testers can write tests against a well-built keyword layer much sooner than they could write code. The caveat is that this only works if somebody builds and maintains that keyword layer, which requires real engineering skill. Teams that adopt Robot Framework expecting manual testers to build the whole thing produce suites with raw xpath locators in every test and Sleep everywhere, which collapse within a year. So my answer is yes, provided there is at least one person who owns the framework layer. Without that, the tool choice does not matter.

Likely follow-up

What would you build first in that keyword layer?

What they are assessing

A distinction worth being precise about.

Model answer

Robot Framework ignores the prefixes Given, When, Then, And and But at the start of a keyword name, so you can write tests that read as Gherkin without any extra library. That gives Gherkin-style readability. It does not make the practice BDD, which is about having the conversation with business stakeholders before the code exists and deriving the scenarios from it. A suite written by testers after implementation, using Given and When, is automation with different wording. Being clear about that distinction is usually what the question is really checking.

What they are assessing

Two common practical gaps.

Model answer

Upload is straightforward: Choose File targets the file input element and sets the path directly, without interacting with the operating system dialog, which is why it works headlessly. Download is harder, because the browser writes to disk outside Selenium control. The approach is to configure the browser download directory through browser options at Open Browser, then verify the file from the file system with OperatingSystem library keywords such as Wait Until Created and File Should Exist. Parsing the contents needs a Python keyword for anything beyond plain text.

What they are assessing

Maintenance at scale.

Model answer

A clear ownership rule for where a keyword lives: page-specific keywords in that page resource, cross-cutting ones in a common resource, and nothing defined in a test file except genuinely one-off helpers. Beyond structure, the practical measures are a naming convention so a search finds an existing keyword before someone writes a second one, periodic review using libdoc to produce documentation of what exists, and code review that treats a new keyword as a design decision rather than an addition. Duplication in Robot suites almost always comes from people not knowing a keyword already exists, which is a discoverability problem rather than a discipline problem.

What they are assessing

Recognition of a common beginner failure.

Model answer

That the variable was not resolved, so Robot treated the text literally. The usual causes are a typo in the name, the variable being out of scope because it was set locally inside a different keyword, a missing variable file import, or using the wrong sigil, such as a dollar prefix where the value is a list that needed an at prefix for expansion. Robot does not fail on an unresolved variable in all contexts, which is why it shows up as literal text rather than an error, and that silent behaviour is what makes it confusing.

What they are assessing

A detail that determines whether templates are useful.

Model answer

With a template, every row runs even if an earlier one fails, and each failure is reported separately, so one run tells you which of twenty inputs are broken rather than only the first. That is the main advantage over a FOR loop, where the first failure ends the iteration unless you wrap each step in error handling. The report shows the failures combined under the single test, which is slightly less granular than separate tests but far more informative than a loop. DataDriver goes further by generating a genuinely separate test per row.

What they are assessing

Pipeline strategy.

Model answer

By feedback value against duration. On every commit, a tagged smoke set covering the critical paths, short enough that people wait for it, which in practice means under about ten minutes. Nightly, the full regression suite including the slow, data-heavy and cross-browser cases. The design work is in the tagging, because this only functions if the smoke tag is curated rather than accumulating, and the discipline is that a nightly failure gets triaged the next morning with an owner, not left to accumulate. A nightly suite nobody reads is worse than no nightly suite, because it creates the impression of coverage.

What they are assessing

Suite hygiene.

Model answer

Tag them with robot:skip-on-failure, which runs the test and reports it as skipped rather than failed if it does not pass, so the build stays meaningful while the test keeps running and will show up as passing again once fixed. The alternatives are worse: commenting out loses the test, letting it fail trains people to ignore red, and deleting it means the coverage is silently lost. The condition I attach is that each one links to the defect and has a review date, because this mechanism is how suites quietly end up with thirty permanently skipped tests nobody remembers.

What they are assessing

A considered long-term view.

Model answer

A keyword layer with deliberate abstraction levels, owned by someone, so tests read in domain language and locators live in one place. Independence between tests, so the suite can be run in any order and parallelised, which is what keeps runtime acceptable as it grows. Discipline about Sleep, since a suite accumulates them one at a time and nobody ever removes them. And honesty about what the suite covers, because Robot makes it very easy to produce a large number of readable tests that all exercise the same path. The suites that die are the ones where every test is a flat list of Click Element calls with raw xpath, and a redesign breaks all four hundred at once.

What they are assessing

A considered view rather than advocacy.

Model answer

Its position has narrowed but it is far from obsolete. The strongest case remains mixed-skill teams and organisations wanting one framework across web, API, mobile and desktop with a single report, and in RPA, where it has a genuine second life. Where it has lost ground is to pytest for engineer-heavy teams, who find it more direct, and to Playwright for web specifically, though the Browser library closes much of that gap. What I would not claim is that the readability argument alone justifies it, because a well-written pytest suite is also readable, and the real differentiator is whether non-programmers will genuinely write and maintain tests, which is true in fewer organisations than claim it.