82 Maven interview questions with answers

What they are assessing

Basic orientation.

Model answer

Maven is a build automation and project management tool for Java projects. It compiles code, resolves and downloads dependencies, runs tests, packages artefacts and can publish them. Its defining idea is convention over configuration: projects follow a standard directory layout and a standard build lifecycle, so a Maven project is immediately familiar to anyone who has seen another one, and the build file describes what the project is rather than how to build it.

Likely follow-up

What is the standard directory layout?

What they are assessing

Convention knowledge.

Model answer

Source code in src/main/java, resources in src/main/resources, test code in src/test/java and test resources in src/test/resources, with build output in target. For an automation project this matters because test classes and anything on the test classpath belong under src/test, and putting a test utility in src/main means it ships in the packaged artefact. Configuration files such as a testng.xml or a properties file belong in src/test/resources so they are on the classpath at test time.

What they are assessing

Relevance to the role.

Model answer

Dependency management first: a test framework pulls in Selenium, a test runner, assertion libraries, reporting and WebDriver utilities, each with their own dependencies, and resolving that by hand is impractical. Repeatable builds second, so the suite runs identically on a developer machine and a CI agent. Standard test execution, so a single command runs the suite with configurable parameters. And integration with CI, since every CI system understands a Maven build without custom scripting.

What they are assessing

Comparison with the common alternative.

Model answer

Maven uses declarative XML with a fixed lifecycle, which makes builds predictable and uniform at the cost of flexibility. Gradle uses a Groovy or Kotlin DSL that is effectively a programming language, so it is far more flexible and generally faster thanks to incremental builds and a daemon. For test automation projects the practical differences are modest, and Maven is still more common in enterprise Java and better understood by more people. I would choose Gradle where build logic genuinely needs programming, and Maven where the team values uniformity and the build is straightforward.

What they are assessing

The central artefact.

Model answer

The Project Object Model, held in pom.xml, which describes the project: its coordinates, dependencies, plugins, properties, build configuration and modules. Maven reads it to determine everything about the build. Every Maven project has one, and in a multi module project each module has its own alongside a parent POM that holds the shared configuration.

What they are assessing

How artefacts are identified.

Model answer

The groupId, artifactId and version, together often written as GAV, which uniquely identify an artefact. groupId is usually a reversed domain name identifying the organisation, artifactId is the project name, and version is the release. Packaging and classifier extend this where needed. Every dependency is declared by coordinates, and those same coordinates determine the path in the repository, which is why a typo in a version produces a resolution failure rather than silently using something else.

What they are assessing

A diagnostic concept many candidates have not met.

Model answer

The POM Maven actually uses after merging your project POM with its parent, any imported POMs, the super POM that supplies defaults, active profiles and settings. You see it with mvn help:effective-pom. It is the first thing I check when a build behaves unexpectedly, because the file you are reading is frequently not the configuration being applied: a parent may set a plugin version, a profile may override a property, and the effective POM shows what actually took effect.

Likely follow-up

When would the effective POM differ most from what you wrote?

What they are assessing

Maintainability practice.

Model answer

Named values defined in the properties block and referenced with the dollar brace syntax, typically used for dependency versions, the Java source and target level, and the file encoding. The reason to use them is that versions then appear once rather than scattered through the file, so upgrading Selenium means changing one line. They can also be overridden on the command line, which is how a parameter such as a browser name or an environment URL is passed into a test run without editing the POM.

What they are assessing

A distinction that matters in multi module projects.

Model answer

The dependencies section declares dependencies the project actually uses. The dependencyManagement section declares versions and scopes without adding the dependency, so it acts as a centralised version policy: a child module declaring the same groupId and artifactId without a version inherits the managed version. It is how a parent POM keeps versions consistent across modules without forcing every module to carry every dependency. The same mechanism with scope import is how a bill of materials such as the Selenium or Spring BOM is consumed.

What they are assessing

Core structure.

Model answer

Three built in lifecycles: default, which handles compilation, testing, packaging and deployment; clean, which removes build output; and site, which generates project documentation. Each lifecycle is a sequence of phases, and running a phase executes every phase before it in that lifecycle. So mvn package runs validate, compile, test and then package.

What they are assessing

Phase order, asked frequently.

Model answer

validate, compile, test, package, verify, install and deploy, with several finer grained phases between them such as process-resources, test-compile and integration-test. The ones that matter day to day are compile, test which runs unit tests through Surefire, package which builds the jar, verify which runs integration tests through Failsafe and checks their results, install which puts the artefact in the local repository, and deploy which publishes it to a remote one.

Likely follow-up

What runs between package and verify?

What they are assessing

A distinction candidates often blur.

Model answer

A phase is a stage in the lifecycle, such as compile or test. A goal is a specific task provided by a plugin, such as surefire:test or clean:clean. Goals are bound to phases, so running a phase executes the goals bound to it. You can also invoke a goal directly, as in mvn surefire:test, which runs only that goal without the preceding phases. That distinction matters in practice, because invoking a goal directly skips compilation and will therefore run against whatever was last built.

Trap to avoid

Running a plugin goal directly and assuming the code was recompiled. It uses the existing target output, which is a common cause of changes appearing not to take effect.

What they are assessing

Understanding of a command people type without thinking.

Model answer

It runs the clean lifecycle to delete target, then the default lifecycle up to install. The clean guarantees no stale output from a previous build, which removes a class of confusing failures. The install puts the artefact into the local repository so other local projects can resolve it. For a test automation project install is often unnecessary, since you are not producing an artefact others consume, and mvn clean test or mvn clean verify is the more appropriate command.

Likely follow-up

When is clean actually necessary rather than habitual?

What they are assessing

The distinction that determines how a suite is wired.

Model answer

mvn test runs the test phase, which executes Surefire and conventionally runs unit tests. mvn verify runs through package and integration-test to verify, which is where Failsafe executes integration and end to end tests and then checks their results. For a UI or API automation suite, verify is usually correct, because Failsafe is designed so that a failure does not halt the build before post-integration-test cleanup runs, such as shutting down a server or a container. Using Surefire for end to end tests works and loses that cleanup guarantee.

What they are assessing

The most basic operation.

Model answer

By adding a dependency element inside the dependencies block with its groupId, artifactId and version, and optionally a scope. Maven then resolves it from the configured repositories on the next build, downloading it and its transitive dependencies into the local repository. Coordinates come from the library documentation or from a repository search, and getting the version wrong produces a resolution failure rather than a silent fallback.

What they are assessing

A frequently asked topic with practical relevance.

Model answer

compile, the default, available everywhere and packaged. provided, available at compile and test time but expected to be supplied by the runtime, so not packaged. runtime, not needed to compile but needed to run. test, available only on the test classpath and not packaged, which is where Selenium, TestNG, JUnit and assertion libraries belong in a mixed project. system, which points at a file path and is deprecated. And import, used only in dependencyManagement to pull in a bill of materials.

Likely follow-up

Which scope would you use for Selenium in a project that also ships application code?

What they are assessing

The mechanism behind most dependency problems.

Model answer

A dependency of a dependency, which Maven resolves and includes automatically. It is what makes Maven convenient and also the source of most difficulty, because a project ends up with libraries nobody declared. The practical consequence is version conflict: two direct dependencies may each require a different version of the same transitive library, and Maven has to choose one. Understanding how that choice is made is what the question usually leads to.

What they are assessing

Depth on the most common build problem.

Model answer

By nearest wins, formally the shortest path to the root of the dependency tree. If a library appears at depth two through one path and depth three through another, the depth two version is used. Where two paths are the same depth, the first declared in the POM wins. This is not necessarily the newest version, which surprises people, and it is why a build can end up with an older library than any dependency asked for. The remedies are declaring the version explicitly as a direct dependency, which makes it depth one and therefore nearest, or managing it in dependencyManagement.

Trap to avoid

Saying Maven picks the newest version. It picks the nearest, and the difference is exactly what produces NoSuchMethodError at runtime.

What they are assessing

Practical tooling.

Model answer

mvn dependency:tree shows the full resolved tree with omitted and conflicting entries marked, and the verbose flag shows what was excluded and why. Filtering with the includes parameter narrows it to a specific artefact, which is what you want when hunting one library. mvn dependency:analyze reports dependencies used but not declared, and declared but unused, both of which are worth fixing. For runtime failures such as NoSuchMethodError or NoClassDefFoundError, the tree is the first place to look, because those almost always mean a version was resolved that differs from the one compiled against.

Likely follow-up

What does NoSuchMethodError usually indicate about the classpath?

What they are assessing

Conflict resolution technique.

Model answer

An exclusions block inside a dependency that prevents a specific transitive dependency being pulled in. It is used when a library brings in something that conflicts with another version you need, when it pulls in a logging implementation that clashes with yours, or when it brings a large dependency you do not want. The caution is that excluding something the library genuinely needs produces a NoClassDefFoundError at runtime rather than a build failure, so the exclusion must be paired with providing an alternative version.

What they are assessing

Versioning convention.

Model answer

A version ending in -SNAPSHOT, indicating a development version that is expected to change. Maven treats snapshots differently: it re-checks remote repositories for newer builds according to the update policy rather than trusting the local copy indefinitely. That makes them useful during development and unsuitable for anything that must be reproducible, because the same snapshot coordinate can resolve to different content on different days. A test suite depending on a snapshot can therefore pass and fail with no change to its own code.

What they are assessing

Basic infrastructure.

Model answer

A directory on the machine, by default .m2/repository in the user home, where Maven caches every artefact it downloads and where mvn install places locally built artefacts. Maven checks it before going to a remote repository, which is why a second build is much faster than the first. Its location can be changed in settings.xml, which matters on CI agents where the default home directory may not persist between runs.

What they are assessing

Enterprise setup awareness.

Model answer

A repository is a store of artefacts, such as Maven Central. A repository manager, such as Nexus or Artifactory, is a server an organisation runs that proxies remote repositories, caches artefacts locally for speed and resilience, hosts internally built artefacts, and can enforce policy on what is allowed. Most enterprises route all Maven traffic through one, which is why settings.xml on a corporate machine usually contains a mirror entry redirecting everything to the internal manager.

What they are assessing

Configuration separation.

Model answer

A file in .m2 holding environment and user specific configuration rather than project configuration: repository mirrors, server credentials, proxy settings, the local repository path and active profiles. The important principle is that it is not checked into the project, so credentials and machine specific paths live there rather than in the POM. On CI, settings.xml is usually provided by the agent configuration or injected as a secret, which is the mechanism by which a build authenticates to an internal repository without the credentials being in source control.

Trap to avoid

Putting repository credentials in the POM. It is the common way internal repository passwords end up in a git history.

What they are assessing

A very common real failure.

Model answer

The artefact is in your local repository but not in any configured remote one, usually because it was built locally with mvn install and never published. The agent uses a different settings.xml without the repository that hosts it. The agent has no credentials for an authenticated repository. A proxy or firewall blocks the repository from the agent network. Or the dependency is a snapshot that has since been overwritten. The diagnostic is to clear the local repository locally, or build with the -U flag to force update, which reproduces the agent condition.

Likely follow-up

Why does building after deleting your local repository catch this class of problem?

What they are assessing

How Maven actually does anything.

Model answer

Maven itself does very little: every task is performed by a plugin providing goals bound to lifecycle phases. The compiler plugin compiles, Surefire runs unit tests, Failsafe runs integration tests, the jar plugin packages. Plugins are resolved from repositories like dependencies and are declared in the build section with their own configuration. Pinning plugin versions explicitly matters, because an unpinned plugin can resolve differently over time and change build behaviour without any change to the project.

What they are assessing

The most commonly configured plugin.

Model answer

It compiles source and test code, and the configuration that matters is the Java language level. In modern Maven that is the maven.compiler.release property, or source and target in older setups, and setting it wrongly produces either compilation failures on modern syntax or class file version errors at runtime. The encoding property is also worth setting explicitly, because the platform default differs between a developer machine and a Linux CI agent, which produces character corruption that only appears on one of them.

What they are assessing

Build customisation.

Model answer

With an executions block inside the plugin declaration, giving an id, the phase to bind to, and the goals to run. This is how you make something happen at a defined point: starting a container before integration-test and stopping it in post-integration-test, generating code before compile, or producing a report after verify. The id matters because it identifies the execution, which is what lets a child module override or disable an execution inherited from a parent.

What they are assessing

The plugin testers interact with most.

Model answer

The plugin that runs tests during the test phase, supporting JUnit and TestNG. It discovers test classes by naming convention, by default classes named Test followed by something, something followed by Test, or something followed by Tests. It produces reports in target/surefire-reports as both plain text and XML, and the XML is what CI systems parse to display results. A test class that does not match the naming convention is silently not run, which is one of the most common reasons a suite appears to pass while executing nothing.

Trap to avoid

A test class named incorrectly is not reported as skipped, it is simply never discovered, so the build is green and no tests ran.

What they are assessing

A distinction specific to automation work.

Model answer

Surefire runs unit tests in the test phase and fails the build immediately on failure. Failsafe runs integration tests in the integration-test phase and, crucially, does not fail the build at that point: it records results and the separate verify goal checks them afterwards. That design exists so post-integration-test cleanup runs even when tests fail, which is what stops a failing suite leaving a container or an application server running. They also use different default naming conventions, with Failsafe looking for IT prefixed or suffixed classes.

Likely follow-up

Why does the deferred failure matter for an end to end suite?

What they are assessing

A very common practical requirement.

Model answer

By configuring the Surefire plugin with a suiteXmlFiles element pointing at the testng.xml, usually held in src/test/resources. Surefire then hands execution to TestNG with that suite definition, so groups, parallel settings, listeners and parameters defined in the XML apply. The path can be parameterised with a property so the suite file is selectable on the command line, which is how a single project runs a smoke suite or a full regression suite without editing anything.

What they are assessing

Execution scaling.

Model answer

Through the parallel and threadCount parameters on Surefire, where parallel accepts values such as methods, classes or both, and forkCount controls how many separate JVM processes run. The distinction matters: threads share a JVM so static state is shared, while forks are isolated processes. For TestNG, parallelism can also be defined in the suite XML, and configuring it in both places causes confusion about which applies. The prerequisite in all cases is that the tests are genuinely independent, since parallelising a suite with shared state produces intermittent failures that look like application defects.

Likely follow-up

What is reuseForks and when would you set it to false?

What they are assessing

The standard parameterisation question for automation projects.

Model answer

Through a system property on the command line with the -D flag, read in the test code with System.getProperty, usually with a sensible default so the suite runs without it. Surefire needs to forward it, which it does for properties set on the command line, or explicitly through systemPropertyVariables in its configuration, which is how you map a Maven property to a system property the test sees. A common pattern is a Maven property with a default, overridable on the command line, passed through systemPropertyVariables, so the same POM serves every environment.

What they are assessing

Day to day command line fluency.

Model answer

With the -Dtest flag, giving a class name, a pattern, or a class and method separated by a hash. Several can be listed comma separated, and patterns with wildcards work. For Failsafe the equivalent is -Dit.test. A detail worth knowing is that in a multi module project this fails if the named test does not exist in every module, which is resolved with -DfailIfNoSpecifiedTests=false, or by targeting the module with -pl.

What they are assessing

A specific and very common failure.

Model answer

Naming convention first, since Surefire only discovers classes matching its include patterns and a class named otherwise is silently ignored. Whether skipTests or maven.test.skip is set, possibly in a profile or in settings rather than visibly in the POM, and the difference matters because maven.test.skip also skips test compilation. Whether the test source is in src/test/java rather than somewhere else. Whether a suite XML is configured and points at an empty or wrong suite. And whether the correct plugin is being used, since end to end tests named with an IT suffix are invisible to Surefire and need Failsafe with verify.

Trap to avoid

A green build with zero tests executed is worse than a red one, because it reports success. Checking the executed count rather than the exit code is the habit that catches it.

What they are assessing

Environment handling.

Model answer

A named set of configuration that can be activated conditionally, allowing different behaviour for different circumstances without changing the POM. A profile can override properties, add dependencies, change plugin configuration or include different modules. For automation projects the usual use is environment selection, so a profile sets the base URL and credentials source for development, staging or production, and suite selection, so a smoke profile runs a different suite XML from a regression profile.

What they are assessing

Mechanism detail.

Model answer

Explicitly with the -P flag on the command line, which is the clearest and the one I would prefer. Or automatically through an activation block, triggered by a property being set, a JDK version, an operating system, the presence or absence of a file, or by being marked activeByDefault. Profiles can also be activated in settings.xml. The caution with automatic activation is that it makes the build behave differently depending on the machine, which is exactly the class of problem that produces works on my machine.

Likely follow-up

What is the pitfall with activeByDefault?

What they are assessing

Practical design.

Model answer

A profile per environment, each setting the same set of properties to different values: base URL, API endpoint, and a pointer to where credentials come from, never the credentials themselves. The test code reads those as system properties with no knowledge of which environment it is in. I would avoid putting anything secret in a profile, since the POM is in source control, and instead have the profile name the source so CI supplies the value as an environment variable. I would also keep one profile as the local default so a developer can run the suite with no flags.

What they are assessing

Project structure at scale.

Model answer

A parent POM with packaging type pom that lists child modules, each with its own POM, built together as a reactor. The parent holds shared configuration: dependency versions in dependencyManagement, plugin configuration, and common properties. For a test automation project the common split is a module for shared framework code such as drivers, utilities and page objects, and separate modules per application or test type, so the framework is built once and consumed by the others.

What they are assessing

Reactor behaviour.

Model answer

From the dependency relationships between modules rather than from the order they are listed, so a module depending on another is built after it. This is the reactor, and it is why a correctly declared dependency between modules does not need manual ordering. The practical consequences are that a circular dependency between modules is a hard failure, and that the -pl flag to build a subset needs -am to also build the modules it depends on, otherwise resolution falls back to whatever version is in the local repository.

Likely follow-up

What does the -am flag do and when do you need it?

What they are assessing

A subtlety people often miss.

Model answer

A parent POM provides inheritance: children declare it in their parent element and inherit its configuration. An aggregator POM lists modules so they are built together. They are usually the same file, which is why the distinction gets lost, but they need not be: a module can inherit from a parent that does not aggregate it, which is common when an organisation publishes a shared corporate parent POM. Knowing the difference matters when a child inherits unexpected configuration, since inheritance comes from the parent element rather than from being listed as a module.

What they are assessing

A frequently used flag with a subtlety.

Model answer

-DskipTests compiles the tests but does not run them. -Dmaven.test.skip=true skips both compilation and execution, which is faster and means compilation errors in test code go undetected. The second is the more dangerous because a test source file that no longer compiles will not be noticed until someone tries to run the suite. For a build that must produce an artefact quickly, skipTests is the safer choice.

What they are assessing

Selective execution.

Model answer

With TestNG, groups are defined on tests and selected either in the suite XML or through the Surefire groups and excludedGroups parameters. With JUnit 5, the equivalent is tags, selected through the same Surefire parameters. Both can be driven from a property so the group is chosen on the command line, which is the usual mechanism for running a smoke subset in a pipeline and the full set on a schedule.

What they are assessing

Reactor control.

Model answer

With the failure behaviour flags: --fail-at-end builds everything it can and reports failures at the end, --fail-never never fails the build, and --fail-fast is the default stopping at the first failure. For a test suite spanning modules, fail-at-end is often what you want in a nightly run, so one broken module does not hide the results of the rest. I would not use fail-never in a gating pipeline, since it reports success regardless of what happened.

What they are assessing

Output knowledge.

Model answer

Surefire writes to target/surefire-reports and Failsafe to target/failsafe-reports, producing a plain text file and an XML file per test class. The XML is the important one, because it follows the JUnit XML schema that essentially every CI system understands, so publishing it gives native test reporting with history and failure details. Reporting frameworks such as Allure or ExtentReports produce their own output elsewhere, typically also under target, and need their own publishing step.

What they are assessing

Pipeline basics.

Model answer

By invoking mvn with the appropriate goal, typically clean verify or clean test, with the environment selected by profile or property, then publishing the surefire or failsafe XML as test results and any report directories as artefacts. The Maven exit code drives the build outcome naturally. The practical additions that matter are caching the local repository between runs to avoid redownloading everything, using the -B flag for batch mode so output is not cluttered with download progress, and pinning the Maven and JDK versions on the agent.

Likely follow-up

Why does caching the .m2 directory matter so much in CI?

What they are assessing

Security practice.

Model answer

Through the CI secret store, injected as environment variables and read either by the test code directly or passed in as system properties on the command line. For repository credentials, a settings.xml provided by the agent, either from the CI configuration or written from a secret at the start of the build, with server entries referencing the credentials. Maven also supports password encryption through a master password in settings-security.xml, though in practice CI secret injection is cleaner. What should never happen is credentials in the POM or in a properties file in source control.

What they are assessing

Build hygiene.

Model answer

Pin everything that can drift. Explicit versions for every plugin, since an unpinned plugin resolves to whatever is latest and can change behaviour without any code change. No version ranges on dependencies and no reliance on snapshots for anything that must be stable. The Java version fixed and enforced, which the enforcer plugin can check. Encoding set explicitly rather than relying on the platform default. And ideally the dependency set verified, since a build that resolves differently next month is a build whose failures cannot be attributed.

What they are assessing

Diagnosing the classic classpath problem.

Model answer

That the version of a class present at runtime differs from the one compiled against, so a method that existed at compile time is absent at run time. It is almost always a transitive dependency conflict where nearest wins has selected an older version. The diagnosis is mvn dependency:tree filtered to the library in question, which shows which versions are present and which was chosen. The fix is to declare the required version as a direct dependency, or to manage it in dependencyManagement, or to exclude the path bringing in the wrong one.

What they are assessing

A universal scenario.

Model answer

Whether the local repository is masking a problem, since an artefact installed locally may not exist in any remote repository, and deleting it locally or building with -U reproduces the agent condition. Then the Java version, since agents often default to a different JDK. Then settings.xml, since the agent has a different one. Then environment specific values: file paths, encoding, timezone and locale all differ between a Windows developer machine and a Linux agent, and encoding in particular produces failures that look like test defects. Then whether the test needs a display, which a headless agent lacks.

Likely follow-up

Why does file encoding differ between a developer machine and a Linux agent?

What they are assessing

Diagnostic tooling.

Model answer

mvn help:effective-pom to see the configuration actually in force after inheritance and profiles, which frequently differs from the file being read. mvn help:active-profiles to confirm which profiles are active, since an automatically activated profile is a common surprise. The -X flag for debug output, which shows plugin execution and resolution in detail. mvn dependency:tree for classpath questions. And for a plugin behaving oddly, mvn help:describe with the plugin name, which lists its goals and parameters including the defaults being applied.

What they are assessing

A flag with a specific purpose.

Model answer

It forces Maven to check remote repositories for updated snapshots and to retry failed resolutions rather than honouring the cached failure. Maven records a failed lookup and will not retry until the update interval expires, which is why a dependency that was unavailable earlier continues to fail even after it has been published. -U is the fix for that, and it is also how you ensure a snapshot dependency is current. It is commonly added to CI invocations for exactly those reasons.

What they are assessing

A common beginner failure.

Model answer

Usually a missing dependency, or one declared with a scope that excludes it from the test classpath, though test scope includes compile scope so that is rarer than the reverse. Also a typo in the import, a dependency version that no longer contains the package after a major upgrade, or the class being in src/main while the dependency is test scoped. For Selenium specifically, the package reorganisation across major versions is a frequent cause: code written for Selenium 3 does not compile against Selenium 4 without changes.

What they are assessing

Version management at scale.

Model answer

A bill of materials is a POM containing only dependencyManagement entries, published so consumers can import a consistent set of versions. You use it by declaring it in your own dependencyManagement with type pom and scope import, after which you declare the individual dependencies without versions and inherit the managed ones. It solves the problem of a family of libraries that must be version aligned, where mixing versions produces subtle incompatibilities, and it is the reason modern Selenium and JUnit 5 both publish one.

What they are assessing

Project type.

Model answer

The packaging element determines the artefact type and influences the default lifecycle bindings. jar is the default and the usual choice. pom is used for a parent or aggregator project with no code of its own. war and ear apply to deployable applications. For a test automation project, jar is correct even though nothing consumes the jar, because it gives the standard lifecycle. The one case where it matters more is a shared framework module that other projects genuinely depend on, where the jar is the deliverable.

What they are assessing

Build governance.

Model answer

A plugin that fails the build when stated rules are violated: a minimum Maven or Java version, banned dependencies, no snapshot dependencies, dependency convergence, or no duplicate classes on the classpath. I would use it on a shared framework or a project with several contributors, because it converts a convention into an enforced rule. The dependency convergence rule in particular is worth enabling once a project is stable, since it fails the build when transitive versions conflict rather than letting nearest wins silently pick one.

What they are assessing

A practical configuration need.

Model answer

Through the argLine parameter on Surefire or Failsafe, which sets JVM arguments for the forked test process. Setting MAVEN_OPTS affects the Maven JVM rather than the forked test JVM, which is why increasing it there appears to have no effect, and that is a common confusion. If another plugin such as JaCoCo also sets argLine, it must be composed rather than overwritten, typically by referencing the property the other plugin sets, otherwise coverage instrumentation silently stops working.

Trap to avoid

Setting MAVEN_OPTS to fix an OutOfMemoryError in tests. Tests run in a forked JVM, so argLine is the setting that applies.

What they are assessing

Pipeline reliability.

Model answer

With Failsafe, this is handled by design: the integration-test goal records results without failing, and verify checks them afterwards, so anything bound to post-integration-test still runs. With Surefire, the equivalent is testFailureIgnore, which lets the build continue, but it has to be paired with something that actually fails the build later or the pipeline reports success on a failing suite. In CI the more common approach is to publish reports in an always block regardless of the build result, which is cleaner than changing Maven behaviour.

What they are assessing

Final lifecycle phases.

Model answer

install places the built artefact into the local repository on the machine, making it available to other local builds. deploy publishes it to a remote repository defined in distributionManagement, making it available to everyone. For a test automation project neither is usually needed, unless the project produces a shared framework jar that other projects consume, in which case deploy to an internal repository is how it is distributed.

What they are assessing

Design for reuse.

Model answer

As a separate versioned project rather than a module inside one team project, published to the internal repository so consumers depend on a released version. That gives consuming teams control over when they upgrade, which a shared source module does not. Internally I would split it: a core module with drivers, configuration and utilities, and optional modules for concerns not everyone needs such as database or mobile support, so consumers take only what they use. And a BOM, so consumers get aligned versions without managing each dependency.

Likely follow-up

Why is a published artefact better than a shared source module here?

What they are assessing

Hygiene tooling.

Model answer

It reports two things: dependencies used in the code but not declared, which are being resolved transitively and will break when the intermediate dependency changes, and dependencies declared but not used, which bloat the build and the classpath. Both are worth fixing. The first is the more important, because relying on a transitive dependency means a version bump in an unrelated library can remove it, producing a failure that appears to come from nowhere.

What they are assessing

A practical warning from experience.

Model answer

By keeping them few and keeping them to properties rather than structure. A profile that changes which modules build, or which plugins run, creates a build whose behaviour is hard to reason about, and the effective POM becomes the only reliable description of what happens. I would prefer a small number of environment profiles setting values, with everything structural the same across all of them, so the build is identical and only the configuration differs. Automatic activation I would use sparingly, since it is the main reason a build behaves differently on two machines.

What they are assessing

A practical automation concern.

Model answer

Not by committing binaries to the repository, which is the approach that produces version mismatches when browsers auto update. The options are WebDriverManager as a dependency, which resolves and caches the correct driver at runtime, Selenium Manager which is built into Selenium 4 and does the same without an extra dependency, or a container image with browser and driver pinned together, which is the most reproducible and the usual answer for CI. The container approach also removes the headless display problem on Linux agents.

What they are assessing

A frequent and confusing situation.

Model answer

Classpath and resource differences, which is the usual cause. The IDE may put src/test/resources on the classpath differently, or include a resource that Maven filters or excludes. Working directory differs: the IDE often runs from the module directory while Maven may not, which breaks relative file paths. The IDE may use a different JDK from the one Maven is configured with. And the IDE typically runs the single test in isolation while Maven runs the whole class or suite, so shared state and ordering become relevant. Running the single test through Maven with -Dtest isolates which of those it is.

What they are assessing

Property resolution.

Model answer

With the dollar brace syntax. Properties can come from the properties block in the POM, from a parent POM, from an active profile, from the command line with -D, from settings.xml, from environment variables using the env prefix, and from Maven built in properties such as project.version and project.basedir. The resolution order matters when the same property is defined in several places, with command line taking precedence, and that is the mechanism by which a default in the POM is overridden at run time.

What they are assessing

A useful feature with a specific purpose.

Model answer

Filtering replaces property placeholders inside resource files during the build, so a properties file in src/test/resources can contain a placeholder that becomes the active environment URL at build time. It is enabled per resource directory in the build section. It is useful for baking configuration into the test classpath, though I would weigh it against reading system properties at run time, which is simpler and avoids the surprise of a file whose content differs from what is in source control. Filtering also silently mangles binary files if applied too broadly, so the directories it covers should be narrow.

What they are assessing

Where defaults come from.

Model answer

The implicit parent of every Maven project, built into Maven itself, which supplies the default configuration: the standard directory layout, the default plugin versions bound to lifecycle phases, Maven Central as a repository, and default resource locations. It is why a minimal POM with only coordinates still builds. It appears in the effective POM output, which is often the first time people see the amount of configuration they inherited without writing it.

What they are assessing

Practical execution control.

Model answer

Surefire supports a rerunFailingTestsCount parameter, which reruns failures within the same execution and reports them as flaky if they then pass, which is useful information in itself. For rerunning in a separate invocation, Surefire does not provide a built in equivalent of a failed test list, so the usual approaches are a TestNG failed suite XML, which TestNG generates automatically in the output directory, or parsing the surefire XML and passing the names to -Dtest. The TestNG mechanism is the cleaner of the two when TestNG is in use.

Likely follow-up

What is the risk of routinely rerunning failures in a pipeline?

What they are assessing

Reproducibility.

Model answer

Because a range means the resolved version can change without any change to the project, so a build that passed yesterday can fail today with no commit in between. That makes failures impossible to attribute and makes a build from a tagged commit non reproducible. Maven supports ranges, and the convention in practice is strongly against them. Where upgrades need to be kept current, the right tool is a dependency update checker or a bot that proposes version changes as commits, so the change is visible and reviewable.

What they are assessing

Optimisation.

Model answer

Cache the local repository between runs, which is usually the largest single saving since a cold build downloads everything. Use -o for offline where the cache is reliable, or at least -B to reduce output. Build only what changed with -pl and -am in a multi module project where the CI system can determine the affected modules. Use -T for parallel module builds, which helps when modules are genuinely independent. And separate concerns: a commit build that compiles and runs unit tests, with the long end to end suite on a different trigger, since most of the duration in an automation project is test execution rather than build.

What they are assessing

Build behaviour.

Model answer

Surefire fails the build by default, so subsequent phases such as package and install do not run. That is usually correct, since you do not want to package an artefact whose tests failed. It is also why end to end tests placed in the test phase prevent the build completing, which is one of the arguments for using Failsafe and the integration-test phase for them instead, where failure is deferred until verify and cleanup still runs.

What they are assessing

A conceptual question with a balanced answer.

Model answer

Dependency hell is the situation where transitive dependencies conflict irreconcilably, typically two libraries each requiring an incompatible version of a third. Maven solves the easy case by resolving transitively and applying nearest wins, which removes the manual work of assembling a classpath. It causes the hard case by making it trivially easy to accumulate hundreds of dependencies nobody chose. The practical defences are keeping direct dependencies few, using dependencyManagement or a BOM to pin the contested libraries, and enabling dependency convergence enforcement so conflicts fail the build rather than being silently resolved.

What they are assessing

Reporting setup.

Model answer

Through a dependency providing the test framework integration, which writes result files during execution, plus the reporting plugin to generate the report from them. For Allure specifically, the adapter usually needs an AspectJ weaver passed through argLine so step annotations are captured, which is the part that catches people out because without it the report generates but contains no steps. The results directory then needs publishing from CI, or the report generated as a build step and published as an artefact.

What they are assessing

Maintenance practice.

Model answer

The versions plugin reports available updates with versions:display-dependency-updates and can apply them, which gives visibility without automation. Beyond that, an automated dependency bot raising a pull request per upgrade is the better pattern, because each change is isolated, reviewed and tested by the pipeline rather than arriving as one large upgrade. The principle either way is that upgrades should be deliberate commits rather than something that happens silently, which is the argument against version ranges and against relying on unpinned plugin versions.

What they are assessing

Design rather than operation.

Model answer

A single module to begin with, since multi module structure added before it is needed is overhead. Standard layout, with the Java version, encoding and all plugin versions pinned explicitly. Dependencies kept minimal: the test runner, Selenium or the API client, an assertion library and a reporting adapter, with versions in properties. Surefire or Failsafe configured to take a suite file and environment values as overridable properties, so the same project runs locally and in CI with only flags changing. No credentials in the repository. Then a CI pipeline from the first week, because a build that has only ever run on one machine is not a build.

Likely follow-up

When would you split it into multiple modules?

What they are assessing

A less common but meaningful feature.

Model answer

It marks a dependency as not transitive, so projects depending on yours do not inherit it. It is used by libraries that support several optional integrations, where a consumer should choose which they want rather than receiving all of them. For a test framework published to other teams it is a useful mechanism, allowing optional support for a database or a mobile driver without forcing every consumer to download it. The consumer then declares it explicitly if they need it.

What they are assessing

Flake handling at the build level.

Model answer

Separate build flake from test flake, because they need different investigation. Build level intermittency usually points at network resolution, a snapshot dependency changing, parallel module builds with a race, or a shared local repository being written by two concurrent builds. Test level intermittency is a test problem. The diagnostic that distinguishes them is whether the failure occurs before tests run. For resolution flakiness specifically, routing through a repository manager and caching aggressively removes most of it, since direct access to many remote repositories is inherently less reliable.

What they are assessing

The standard parameterisation requirement, phrased practically.

Model answer

Declare a property with a default in the POM, pass it through Surefire with systemPropertyVariables, and read it in the test code with System.getProperty including a fallback. Then overriding is simply a -D flag on the command line. The same pattern covers the environment URL, the suite file and the thread count. The point of the default is that a developer can run the suite with no arguments and get sensible behaviour, which is what stops people maintaining a private copy of the command.

What they are assessing

A design question with genuine trade-offs.

Model answer

For unit and component tests, unquestionably yes. For an end to end suite it is a real decision. Same repository means tests version with the code, a change and its test coverage arrive in one commit, and the pipeline is straightforward. Separate repository suits a suite spanning several applications, or one owned by a team separate from the developers, at the cost that the suite and the application can drift out of step. My default is same repository where the suite tests one application, because the alternative reliably produces a suite testing a version of the system that no longer exists.

What they are assessing

Packaging knowledge with a practical judgement.

Model answer

It builds an uber jar containing the project and all its dependencies, optionally relocating packages to avoid conflicts. An automation project rarely needs it, because tests are normally run through Maven where the classpath is already resolved. The case where it is useful is distributing a suite as a standalone jar to be run somewhere without Maven, such as handing a smoke test to an operations team. Even then, a container image is usually the better answer, since it carries the browser and driver as well.

What they are assessing

Selective building.

Model answer

It restricts the reactor to named modules, which is how you build or test one part of a large project quickly. The safety consideration is that modules it depends on are not rebuilt, so resolution falls back to whatever version is in the local repository, which may be stale. Adding -am builds the required dependencies too, and -amd builds the modules that depend on the selected ones. For a CI pipeline that builds only what changed, -pl with -am is the correct combination, and omitting -am is a common source of a build that passes against stale dependencies.

What they are assessing

A closing question revealing what the candidate considers essential.

Model answer

Enough to be unblocked rather than Maven expertise. Specifically: reading a POM and knowing where to add a dependency, understanding scopes well enough to put test libraries in test scope, running a subset of tests from the command line, passing environment and browser as properties, and reading a dependency tree when a classpath error appears. Beyond that, knowing the difference between Surefire and Failsafe and why the suite is wired to one of them. Release management, packaging and site generation matter far less in this role, and candidates who have memorised the full phase list but cannot diagnose a NoSuchMethodError have studied the wrong half.