82 Appium interview questions with answers

What they are assessing

Scope understanding.

Model answer

Appium is an open source automation framework for mobile applications, driving native, hybrid and mobile web apps on Android and iOS, with additional drivers for Windows and macOS desktop applications. It exposes the W3C WebDriver protocol, so the client API is the same shape as Selenium, which is why Selenium experience transfers. The defining principle is that it automates the app without requiring it to be recompiled or modified, so you test the same binary you ship.

Likely follow-up

Why does testing the shipped binary rather than a modified build matter?

What they are assessing

Whether your knowledge is current.

Model answer

Appium 2 separates drivers and plugins from the core, so you install them explicitly with appium driver install uiautomator2 rather than everything shipping in one package. That means drivers version independently of the server. The default base path changed: the /wd/hub suffix is gone unless configured. Capabilities must be W3C compliant, with vendor specific ones prefixed appium colon, and the old desired capabilities format is no longer accepted. There is also a plugin system for extending behaviour.

Trap to avoid

Answering with Appium 1 specifics such as JSON Wire Protocol or unprefixed capabilities. It dates the candidate immediately.

What they are assessing

Whether you know what you are automating.

Model answer

A native app is built with the platform SDK, installed from a store, and its controls are platform widgets. A mobile web app runs in a browser and is really a website. A hybrid app is a native shell containing a webview that renders web content, which is what Cordova and Ionic produce, and React Native sits somewhere else again since it renders genuine native components from JavaScript. The distinction matters for Appium because hybrid apps require context switching between native and webview to locate elements.

What they are assessing

Honest assessment.

Model answer

It is slower than platform native frameworks such as Espresso and XCUITest, because every command is an HTTP round trip through the server to the device. iOS real device work requires macOS, Xcode and a signing setup, which is a genuine infrastructure constraint. Gesture support is better than it was but still fiddly for complex interactions. Flutter and some custom rendered UIs need specific drivers or fall back to image matching. And flakiness is higher than on web, mostly from device state and timing rather than from Appium itself.

What they are assessing

The core architectural question.

Model answer

It is client server. Your test uses an Appium client library in Java, Python or JavaScript, which sends W3C WebDriver commands over HTTP to the Appium server. The server, written in Node, translates those into the platform automation framework: UiAutomator2 or Espresso on Android, XCUITest on iOS. That framework runs on the device and performs the action, and the result travels back. The important consequence is that Appium is a translation layer, so anything the underlying framework cannot do, Appium cannot do either.

Likely follow-up

Given that, why is Appium slower than writing Espresso tests directly?

What they are assessing

iOS specific knowledge.

Model answer

WebDriverAgent is an application built by Facebook that Appium installs onto the iOS device or simulator, acting as the on-device server that receives commands and drives the app through XCUITest. It has to be compiled and signed for real devices, which is where most iOS setup problems come from: expired certificates, missing provisioning profiles, or a team identifier not configured. On a simulator it is far simpler because signing is not enforced. Understanding that it is a separate app explains most iOS session failures.

What they are assessing

Driver level understanding.

Model answer

UiAutomator2 is a black box framework operating at the system level, so it can interact with anything on screen including other apps, notifications and system dialogs, but it has no access to the app internals. Espresso runs inside the app process, so it is faster, has automatic synchronisation with the UI thread which reduces flakiness dramatically, and can reach view internals, but it cannot leave the app under test. UiAutomator2 is the default and the right choice for cross app flows; Espresso suits fast in-app testing where the team owns the code.

What they are assessing

Session setup basics.

Model answer

Capabilities are the key value pairs sent when creating a session, telling the server what to automate and how. The essential ones are platformName, automationName which selects the driver such as UiAutomator2 or XCUITest, and either deviceName and udid to identify the device or the emulator. Then the app itself: the app capability pointing at an APK or IPA, or appPackage and appActivity for an already installed Android app, or bundleId on iOS. In Appium 2 the vendor specific ones carry the appium colon prefix.

What they are assessing

A capability trio that causes real confusion.

Model answer

By default Appium stops the app and clears its data between sessions but leaves it installed. noReset true skips clearing, so the app keeps its state including login and cached data, which is faster and is what you want when a suite shares a logged in session. fullReset true uninstalls the app before and after, giving a genuinely clean install, which is what you need for first launch and onboarding tests. The defects here come from assuming a clean state that noReset did not provide.

Likely follow-up

Which would you use for testing the first run experience, and why?

What they are assessing

Knowledge of a setting that causes mysterious failures.

Model answer

It is how long the server waits for a new command before deciding the client has gone and ending the session, defaulting to sixty seconds. It matters because a test doing something slow outside Appium, such as waiting on a backend job or performing a long database setup, can exceed it and find the session dead with no obvious cause. Raising it for suites with long pauses is legitimate; the better fix is usually not having long pauses inside a session.

What they are assessing

A universally encountered problem.

Model answer

On Android, autoGrantPermissions true grants everything declared in the manifest at install, which removes the dialogs entirely. On iOS, autoAcceptAlerts or autoDismissAlerts handles system alerts automatically. Those are the right choice when permissions are not what you are testing. When they are, you turn them off and interact with the dialogs explicitly, which on Android means switching to the permission controller package since the dialog is not part of your app, and that is exactly why UiAutomator2 rather than Espresso is needed.

What they are assessing

Practical scaling detail.

Model answer

On Android, systemPort must be unique per session, because UiAutomator2 opens a port to communicate with the device and two sessions sharing it collide. On iOS, wdaLocalPort must be unique for the same reason with WebDriverAgent. Each session also needs its own udid so the right device is targeted. Forgetting the port capabilities is the single most common cause of parallel runs that work for one device and fail unpredictably with two.

Trap to avoid

Running parallel sessions without unique systemPort or wdaLocalPort. The failures look random and are entirely deterministic once you know.

What they are assessing

Core knowledge.

Model answer

Accessibility id, which maps to content-desc on Android and the accessibility label on iOS. id, which is resource-id on Android. class name. xpath. Then platform specific ones: Android UiAutomator using UiSelector expressions, Android viewtag, and on iOS predicate string and class chain. There is also image based location as a last resort. Accessibility id is the one to prefer because it is the only strategy that works identically on both platforms.

What they are assessing

Whether you know it is worse here than on web.

Model answer

Because on mobile it is far slower than on web. Appium has to serialise the entire view hierarchy from the device into XML and then evaluate the expression against it, and on a complex screen that can take seconds per lookup. Multiply that across a suite and it dominates the runtime. It is also more brittle, since the hierarchy changes between OS versions and between platforms. Accessibility id or resource id resolve directly through the native framework and are orders of magnitude faster.

Likely follow-up

Your suite is slow and full of xpath. What would you change first?

What they are assessing

Platform specific capability.

Model answer

It lets you pass a UiSelector expression evaluated natively on the device, such as new UiSelector().text("Submit").className("android.widget.Button"). Because it runs on device rather than serialising the hierarchy, it is much faster than the equivalent xpath. It also supports things xpath cannot do easily, notably UiScrollable, which scrolls to find an element automatically rather than requiring you to implement scrolling yourself. The iOS equivalents are predicate string and class chain, with class chain being the faster of the two.

What they are assessing

Influence, which is most of the job on mobile.

Model answer

Ask for stable, unique accessibility identifiers on every interactive element, which is the single highest value change. On Android that is content-desc or a resource-id that is not auto generated; on iOS it is accessibilityIdentifier, which is separate from the accessibility label so it does not affect what VoiceOver announces. The argument that lands is usually the accessibility one rather than the automation one, since the same attributes support screen readers, which is often a compliance requirement.

What they are assessing

Practical tooling.

Model answer

Appium Inspector is the primary tool, connecting to a session and showing the hierarchy with the attributes for each element and suggested locators. On Android, Android Studio's Layout Inspector and the older uiautomatorviewer also work. On iOS, Xcode's Accessibility Inspector shows identifiers and labels. The thing Inspector does that the others do not is let you test a locator against the live session before putting it in code, which saves a great deal of guessing.

What they are assessing

Breadth.

Model answer

UiAutomator2 is the default Android driver. Espresso is the alternative Android driver running in process. XCUITest is the iOS driver. Flutter and the newer flutter integration driver handle Flutter apps, which render their own widgets and are otherwise opaque. Mac2 automates macOS applications and Windows automates Windows desktop apps through WinAppDriver. In Appium 2 each is installed separately, so the set present on a machine is explicit rather than assumed.

What they are assessing

Understanding of rendering models.

Model answer

Flutter draws its own widgets onto a canvas rather than using platform native controls, so from UiAutomator2 or XCUITest the screen is essentially one large view with no inspectable hierarchy. The Flutter driver communicates with the app through a Dart VM service extension, addressing widgets by key, type or text as Flutter understands them, which requires the app to be built in a mode that exposes it. The consequence for testing is that you cannot automate a release build the same way, which is a real constraint worth raising early.

What they are assessing

Whether your approach is current.

Model answer

Two modern options. The W3C Actions API, building a pointer sequence of press, move and release, which is cross platform and verbose. Or the mobile colon commands executed through executeScript, such as mobile: scrollGesture and mobile: swipeGesture on Android and mobile: scroll and mobile: swipe on iOS, which are simpler and driver optimised. The older TouchAction and MultiTouchAction classes are deprecated and removed in recent clients, so reaching for them signals out of date knowledge.

Trap to avoid

Answering with TouchAction. It is deprecated and its removal is one of the more visible Appium 2 changes.

What they are assessing

A daily practical task.

Model answer

On Android the cleanest way is UiScrollable through the UiAutomator strategy, which scrolls until the element is found in one call. On iOS, mobile: scroll with a predicate or an element to scroll toward does the same. The generic fallback is a loop performing a swipe and checking for the element with a bounded number of attempts, which works everywhere but is slower and needs a guard so it terminates. Scrolling a fixed number of times and hoping is the approach that produces flaky tests.

What they are assessing

Advanced interaction.

Model answer

With the W3C Actions API using two pointer inputs, each with its own sequence of press, move and release, dispatched together so they execute simultaneously. That is what replaced MultiTouchAction. On some drivers there are also mobile colon convenience commands such as mobile: pinchOpenGesture on Android, which are easier when available. Multi finger gestures are among the least reliable things to automate, so where a pinch is not the thing under test I would avoid depending on it.

What they are assessing

A constant practical annoyance.

Model answer

Call hideKeyboard after text entry, which works reliably on Android and is less predictable on iOS where it may need a tap on a done button or outside the field instead. On Android, setting the unicodeKeyboard and resetKeyboard capabilities uses a keyboard that handles unicode and restores the original afterwards, which also avoids the problem of the default keyboard mangling non Latin input. Sending the enter key sometimes dismisses it as a side effect of submitting.

What they are assessing

Core synchronisation knowledge.

Model answer

An implicit wait is a global setting telling the driver to poll for a period before failing to find an element, applying to every lookup. An explicit wait waits for a specific condition on a specific element, such as visibility or clickability, with its own timeout. Explicit waits are preferable because they express what you are waiting for and can wait for conditions beyond presence. Mixing the two is the classic mistake: the waits compound unpredictably and produce timeouts far longer than either value suggests.

Trap to avoid

Using both implicit and explicit waits together. It is a documented anti-pattern and produces unpredictable timeout behaviour.

What they are assessing

Understanding of device variance.

Model answer

Because device performance varies enormously: an emulator on a build agent, a flagship phone and a three year old budget device have wildly different timings, so any fixed value is either too short somewhere or wastes time everywhere. Network conditions add more variance. A suite built on sleeps is simultaneously slow and flaky, which is the worst combination. Explicit waits on a condition adapt to whatever the device does, which is why they are the only approach that survives a device matrix.

What they are assessing

A genuinely hard mobile problem.

Model answer

Wait on the end state rather than the animation: the element being both present and in a stable position, or a condition that is only true once the transition has finished, such as a button becoming enabled. Appium has no general animation awareness, unlike Espresso which synchronises with the UI thread automatically. The pragmatic approach on Android is disabling system animations on the device, through developer options or an adb command, which both speeds the suite and removes a whole class of timing flakiness.

Likely follow-up

How would you disable animations as part of test setup?

What they are assessing

The defining hybrid question.

Model answer

By switching context. getContextHandles returns the available contexts: NATIVE_APP plus one or more WEBVIEW entries. You switch to the webview context and then locate elements with standard web strategies such as CSS selectors, because inside the webview it is a web page. Switch back to NATIVE_APP for native controls. The common failure is forgetting to switch back, so subsequent native lookups fail confusingly. On Android the webview context requires a matching Chromedriver version, which is the usual setup obstacle.

What they are assessing

A very common real blocker.

Model answer

Automating an Android webview requires a Chromedriver matching the Chrome or System WebView version on that device, and devices in a fleet have different versions. A mismatch produces a session failure when switching context. The solutions are supplying chromedriverExecutable pointing at the right binary, or better, using chromedriverExecutableDir with a directory of versions plus chromedriverChromeMappingFile so Appium selects the correct one automatically. Appium can also download them if the environment allows it.

What they are assessing

A distinction candidates often get wrong.

Model answer

React Native renders genuine native components rather than a webview, so there is no context switching and you automate it as a native app. What it does affect is locators: React Native exposes testID, which maps to accessibility id on iOS and to resource-id or content-desc on Android depending on configuration, so asking developers to set testID consistently is the key ask. Treating React Native as hybrid and looking for a webview context is a common wasted afternoon.

What they are assessing

Coverage judgement.

Model answer

An Android emulator virtualises the hardware, so it behaves fairly closely to a device but slower. An iOS simulator does not virtualise hardware at all; it runs a build compiled for the host architecture, so it is fast but differs more from real behaviour. A real device is the only place you get genuine performance, real sensors, real network behaviour, camera, biometrics, push notifications and battery effects. The sensible strategy is emulators and simulators for breadth in CI, real devices for the critical paths and anything hardware dependent.

Likely follow-up

Which defects would only appear on a real device?

What they are assessing

Data driven coverage.

Model answer

From analytics rather than intuition: the OS versions, manufacturers and screen sizes your actual users have, which usually shows a small set covering the large majority. Then add the extremes that break things: the oldest supported OS version, the smallest screen, and a low memory device, since those surface layout and performance defects that flagship devices hide. Manufacturer skins matter on Android, so including a Samsung device is usually worth it because its customisations differ most from stock.

What they are assessing

Practical cloud experience.

Model answer

The endpoint becomes the provider URL with credentials, and their capabilities are added for build and session naming, which matters because their dashboard is how you triage. Upload of the app binary becomes a step. Then the differences that bite: sessions queue when concurrency is exceeded, so timeouts need to account for it; network conditions differ and some providers restrict access to internal environments, requiring a tunnel; and real device availability varies, so pinning an exact device model can leave tests waiting. Cost is per minute, which changes how you think about suite duration.

What they are assessing

Scaling method.

Model answer

Either one Appium server per device on its own port with each thread targeting one, or a single Appium 2 server handling multiple sessions with unique systemPort and wdaLocalPort per session, which is simpler to manage. The test framework supplies the parallelism, through TestNG parallel modes or pytest-xdist. The prerequisites are the same as any parallel suite: driver held per thread, no shared static state, and test data isolated so two devices do not use the same account.

What they are assessing

Experience of doing it.

Model answer

Port collisions first, from missing systemPort or wdaLocalPort. Then a static driver shared across threads, which on mobile produces commands going to the wrong device. Then test data collisions, particularly logins, since many mobile apps allow only one active session per account and the second device silently logs the first out. Then host resources, because each emulator is heavy and four on one agent will thrash. Then cloud concurrency limits producing queueing that looks like timeouts.

Trap to avoid

Sharing one test account across parallel devices. Single session enforcement in the app makes the failures look like authentication defects.

What they are assessing

Design knowledge.

Model answer

A class per screen holding locators and methods expressing user actions, with the driver injected rather than created inside. Appium clients provide PageFactory with @AndroidFindBy and @iOSXCUITFindBy annotations, initialised with AppiumFieldDecorator, which lets one page object carry both platforms' locators and resolve the right one at runtime. That is the mechanism that makes a single cross platform suite viable. Methods should return the next page object so flows read naturally.

What they are assessing

A real architectural judgement.

Model answer

Share the test layer and the page object interfaces, and keep the locators platform specific, which the dual annotation approach supports directly. That works well when the apps have equivalent flows. Where the platforms genuinely diverge, forcing a shared abstraction produces page objects full of conditionals that are harder to maintain than two implementations. So I would share aggressively at the test and business layer, accept divergence at the locator layer, and be willing to fork a page object when the screens are genuinely different.

What they are assessing

The most valuable mobile skill.

Model answer

In order of return: replace every fixed sleep with an explicit wait on a condition; disable system animations on the device; stop using xpath where a native locator exists; ensure app state is deterministic at test start, through fullReset or by resetting through the API rather than the UI; isolate test data per device; and handle system interruptions such as permission dialogs and update prompts centrally rather than in individual tests. Retries come last and should be measured, not relied upon.

Likely follow-up

How would you measure whether flakiness is actually improving?

What they are assessing

Speed thinking.

Model answer

Through the API or deep links rather than the UI wherever possible. Logging in through the interface on every test costs seconds each time; injecting a session token or using a deep link to land directly on the screen under test costs almost nothing. Android deep links via adb are particularly effective. The UI login flow itself still needs testing, but once, not as a preamble to every test. That single change often halves a mobile suite duration.

What they are assessing

Pipeline knowledge.

Model answer

Start the Appium server on the agent or use a service container, ensure the platform tooling is present, then run the suite pointing at emulators, or at a device cloud which avoids maintaining device infrastructure entirely. The app binary comes from the build pipeline rather than a committed file. Results publish as JUnit XML, with screenshots and device logs archived as artefacts. For iOS the agent must be macOS, which is the constraint that most often determines the approach.

What they are assessing

Triage quality.

Model answer

A screenshot, the page source at the moment of failure since that shows what the hierarchy actually was, the device logs which on Android is logcat and on iOS the syslog, and the Appium server log for that session. A screen recording where the provider supports it is the single most useful artefact for gesture and timing failures. All of it attached automatically through a listener rather than per test. Without the page source, element not found failures in CI are almost impossible to diagnose remotely.

What they are assessing

The most common first failure.

Model answer

Whether the device or emulator is actually connected and visible, with adb devices on Android. Whether the capabilities are correct, particularly appPackage and appActivity, or the bundleId on iOS. Whether the app path resolves and the binary matches the platform and architecture. Whether the required driver is installed, which is explicit in Appium 2. Whether the server is running on the port the client is targeting. And on iOS, whether WebDriverAgent built and signed, which is the usual answer there.

What they are assessing

Systematic diagnosis.

Model answer

Most often you are in the wrong context, looking for a web element in the native context or the reverse. Then the element may be inside a webview, a different window, or an overlay such as a system dialog that owns focus. Then timing, where the lookup ran before the screen settled. Then the locator itself being wrong for this OS version. And occasionally the element is genuinely not in the accessibility hierarchy, which happens with custom rendered views, in which case image matching or a developer change is the only route.

Likely follow-up

How would you confirm which context you are currently in?

What they are assessing

Device variance reasoning.

Model answer

OS version differences changing the view hierarchy or the behaviour of system dialogs. Manufacturer skins on Android, which alter system UI and sometimes add their own permission prompts. Screen size, where an element is off screen on a smaller device and needs scrolling. Performance, where a slower device exposes a missing wait. Locale and timezone. And device state such as a pending OS update notification or low storage, which intercepts taps. Screen size and speed account for most of it.

What they are assessing

Remote diagnosis.

Model answer

Start from the artefacts rather than trying to reproduce: the page source tells you what the screen actually was, which usually distinguishes a timing problem from a genuinely different state. The Appium server log shows the command sequence and where it stalled. Device logs show crashes and ANRs that the test would otherwise report as a lost session. Then look at what differs: emulator rather than real device, headless environment, animations enabled, a colder app start, and network latency to a test backend.

What they are assessing

Distinguishing product defects from test defects.

Model answer

Capture the crash log immediately, from logcat on Android or the device console on iOS, since that is the evidence the developers need and it is gone once the session ends. Report it as a product defect with the stack trace, the steps and the device, rather than as a test failure. Then make the suite resilient: a crash usually manifests as a lost session, so the framework should detect it, capture the log, and fail cleanly rather than cascading confusing failures into subsequent tests.

What they are assessing

A guaranteed comparison question.

Model answer

They share the WebDriver protocol and the client API shape, which is why the code looks similar, but Selenium drives browsers on desktop through browser specific drivers, while Appium drives mobile applications through platform automation frameworks. Appium adds mobile concerns Selenium has no concept of: device capabilities, gestures, contexts for hybrid apps, app installation and reset, and device state. Selenium knowledge transfers directly to the mechanics; the mobile specific parts are what needs learning.

What they are assessing

Precision about launching.

Model answer

The app capability points at a binary, an APK or IPA, which Appium installs and launches, so it is what you use when testing a freshly built artefact. appPackage and appActivity target an app already installed on the Android device, launching a specific activity, which is faster because it skips installation. bundleId is the iOS equivalent for an already installed app. Using appPackage and appActivity in CI while assuming the latest build is installed is a recurring cause of testing yesterday's binary.

Trap to avoid

Relying on an already installed app in CI. It silently tests whatever version happens to be on the device.

What they are assessing

Knowing the last resort.

Model answer

Appium can locate an element by matching a supplied image against the screen, using OpenCV. It is acceptable only where nothing else works: custom rendered canvases, games, and some third party embedded views. The reasons to avoid it are that it breaks with resolution, scaling, theme and font differences, it is slow, and it gives no semantic information so assertions become visual rather than behavioural. If a suite depends heavily on it, the better answer is usually asking for accessible markup.

What they are assessing

A frequently skipped scenario.

Model answer

By shaping the network rather than hoping. Android emulators support network speed and latency settings, and adb can toggle connectivity. Device clouds usually offer network profiles such as 3G or lossy. Charles or a proxy can throttle and inject failures. What you are testing is the behaviour, not the speed: whether the app shows a sensible loading state, times out gracefully, retries without duplicating a transaction, and recovers when connectivity returns. Offline behaviour and queued actions are where the defects are.

What they are assessing

Lifecycle coverage.

Model answer

With runAppInBackground, which sends the app to the background for a duration and brings it back, or by activating another app and returning. What you verify is state preservation: is the user still logged in, is unsaved form input retained, does the screen restore correctly, and does any in progress operation complete or resume. On Android you should also test the process being killed while backgrounded, which the developer options setting for not keeping activities makes reproducible, since that is where state restoration bugs live.

Likely follow-up

How would you force Android to destroy the activity while backgrounded?

What they are assessing

Practical synchronisation.

Model answer

visibilityOfElementLocated, since presence in the hierarchy does not mean it is on screen or interactable. elementToBeClickable, which is the right one before a tap. invisibilityOf, for waiting out a loading spinner, which is often more reliable than waiting for the next screen. And textToBePresentInElement for state changes. Custom conditions are worth writing for app specific states, such as waiting for a progress bar to reach a value or for a list to stop being empty.

What they are assessing

Depth of architectural understanding.

Model answer

It receives the HTTP request with the strategy and selector, routes it to the active driver session, and the driver translates it into the underlying framework's equivalent: a UiSelector query or accessibility lookup on Android, an XCUITest query on iOS. The framework resolves it on device and returns an element reference, which Appium wraps in a WebElement identifier and returns to the client. Subsequent actions on that element send its identifier back. That round trip per command is exactly why chatty tests using xpath are slow.

What they are assessing

A familiar error in a mobile context.

Model answer

It means the element reference you hold no longer corresponds to anything in the current hierarchy, because the screen was rebuilt. On mobile it happens more than on web because lists recycle views aggressively: scrolling a RecyclerView reuses the same view objects for different data, so a reference obtained before scrolling is meaningless afterwards. The fix is relocating the element immediately before use rather than caching references, and avoiding holding element references across any action that changes the screen.

What they are assessing

Robustness design.

Model answer

Centrally rather than in individual tests, because they can appear at any point. A listener or a wrapper around interactions can detect a known interrupting dialog and dismiss it before retrying the action. Beyond that, prevention: disable OS update prompts, sign out of accounts that generate notifications, enable do not disturb, and use a device profile configured for testing. For the interruptions that are genuinely part of the product requirements, such as handling an incoming call during a payment, those become deliberate test cases rather than noise to suppress.

What they are assessing

A specific and common requirement.

Model answer

On simulators and emulators you can enrol and then send a matching or non matching biometric through the platform tooling, which Appium exposes as mobile commands such as fingerPrint on Android emulators and the iOS simulator equivalents. On real devices it is largely not automatable, because the sensor requires an actual finger or face, so that path is manual or stubbed. The usual approach is automating the fallback route, confirming the app handles a failed biometric and offers passcode entry correctly.

What they are assessing

Proportionate automation.

Model answer

No. Mobile suites are slow and device capacity is finite, so a short smoke set on one device per platform for every build, and the fuller matrix nightly or before release, is the realistic split. Unit and integration tests on the app code carry the fast feedback, which is where most coverage should sit anyway. Gating every commit on a device matrix produces a queue, long feedback times and pressure to disable the gate, which is how mobile suites become ignored.

What they are assessing

Cross platform technique.

Model answer

By using accessibility id, which maps to content-desc on Android and accessibilityIdentifier on iOS, and asking developers to set the same value on both. Where that is not possible, the PageFactory annotations let one field carry both an @AndroidFindBy and an @iOSXCUITFindBy, so the page object is shared and only the locator differs. Attempting to write a single xpath that matches both hierarchies is possible and always a mistake, because the hierarchies are genuinely different.

What they are assessing

Setup tooling.

Model answer

A diagnostic utility that checks the environment for the prerequisites Appium needs and reports what is missing: Java and Android SDK paths, adb availability, Xcode and command line tools, Carthage, and various optional dependencies. It is the first thing to run when a setup will not start, because most initial failures are environment rather than configuration. In Appium 2 much of this moved into the driver specific doctor checks, invoked per driver.

What they are assessing

Practical capacity.

Model answer

Fewer than people hope. Each Android emulator needs a couple of gigabytes of memory and meaningful CPU, so a typical build agent manages two to four before performance degrades enough to cause timing failures, which then look like test flakiness rather than resource exhaustion. iOS simulators are lighter and you can run more. The signals to watch are rising failure rates and increasing test duration as concurrency goes up, which means the optimum is the level that gives the shortest reliable run, not the highest number.

What they are assessing

Evidence gathering.

Model answer

Through the driver's log API, which exposes the available log types and lets you retrieve them: logcat on Android, syslog and crashlog on iOS. Capturing them at the end of each test, or on failure, and attaching them to the report is the pattern. It is worth clearing the log at test start so what you capture relates to that test only. These logs are what distinguish an app crash from a test problem, and without them a lost session is genuinely ambiguous.

What they are assessing

Performance of the suite itself.

Model answer

Bypass the UI for setup using API calls or deep links. Use noReset where a clean state is not required, since reinstalling is expensive. Prefer native locators over xpath. Disable animations. Parallelise once isolation allows it. And keep the suite small: mobile end to end tests are the most expensive tests you own, so most coverage belongs in unit and integration tests on the app code, with the device suite reserved for genuine journeys. A suite of four hundred Appium tests is usually carrying several hundred that belong lower down.

What they are assessing

iOS hybrid specifics.

Model answer

Context switching works the same way, but the plumbing differs: iOS webview automation goes through the remote debugging protocol, which historically required ios-webkit-debug-proxy for real devices. On simulators it is more straightforward. Recent Appium versions handle much of this internally. The practical experience is that iOS webview automation is more fragile than Android, so where a flow can be covered natively or through the API instead, that is usually the better choice.

What they are assessing

Common gesture mechanics.

Model answer

With the W3C Actions API: pointer down, a pause for the required duration, then pointer up, which is explicit and cross platform. Or with the driver specific convenience command, mobile: longClickGesture on Android with a duration, and mobile: touchAndHold on iOS. The duration matters: too short registers as a tap, and the threshold differs by platform and sometimes by app, so a value that works on Android may need increasing on iOS.

What they are assessing

A hard area candidates often avoid.

Model answer

Trigger the notification through the backend or the push provider rather than trying to fabricate it on device, so the whole path is exercised. Then interact with it in the notification shade, which on Android means UiAutomator2 reaching outside the app, and on iOS is more restricted. Verify the deep link behaviour when tapped, both with the app backgrounded and closed. Simulators and emulators support pushing a payload directly, which is useful for the handling logic even though it skips delivery. Real devices are needed for the end to end path.

What they are assessing

Judgement rather than a memorised number.

Model answer

Derived from measurement rather than guessed. A short explicit wait of a few seconds for elements that should appear immediately, longer for operations involving a network call, and a generous cap for known slow flows such as first launch. The principle is that a timeout is a failure threshold not a delay, so it costs nothing when things work and should be long enough to absorb the slowest legitimate device in the matrix. Uniformly applying a thirty second wait everywhere makes failures slow to surface.

What they are assessing

Pipeline integration detail.

Model answer

The build pipeline publishes the artefact and the test stage consumes it by version or build identifier, rather than referencing a path or assuming what is installed on a device. On a device cloud that means uploading the binary and referencing the returned identifier. The discipline that matters is recording which build was tested in the results, because without it a passing run cannot be attributed and a failing one cannot be reproduced.

What they are assessing

A recurring iOS reality.

Model answer

Most likely WebDriverAgent needs rebuilding against the new Xcode, or the Appium XCUITest driver version no longer matches. iOS automation is tightly coupled to the Xcode and iOS versions, so an OS or Xcode upgrade routinely breaks it until the driver is updated. Signing can also break if certificates or provisioning profiles were tied to the previous setup. The practical mitigation is pinning tool versions on the agent and treating an Xcode upgrade as a planned change rather than something that happens automatically.

What they are assessing

Data strategy.

Model answer

Created per test through the API so each run is independent, with unique identifiers so parallel devices do not collide, and cleaned up afterwards. Where a shared pool is unavoidable, reserve and release accounts rather than sharing them, which matters especially on mobile because many apps enforce a single active session and a second device will log the first out. Data baked into the app build should be avoided, since it ties the tests to a particular binary.

What they are assessing

Working within constraints.

Model answer

Make the cost visible rather than arguing in principle: show the suite duration attributable to xpath, and the failure rate attributable to hierarchy changes. Frame it as accessibility rather than automation, since the same identifiers support screen readers and are often a compliance obligation, which usually finds a stronger sponsor. In the meantime, prefer the fastest available native strategies, UiAutomator on Android and class chain on iOS, over xpath, and accept that coverage will be shallower in the areas that cannot be located reliably.

What they are assessing

Lifecycle understanding.

Model answer

A session is the connection between the client and one device with one app configuration, created when capabilities are sent and identified by a session id carried on every subsequent command. It ends when the client calls quit, when newCommandTimeout expires with no command received, when the server is stopped, or when the app or device becomes unreachable, for example after a crash. Failing to quit leaves sessions and their associated processes alive, which on a shared agent eventually exhausts resources.

What they are assessing

A specific and common failure.

Model answer

The element exists in the hierarchy but something prevents interaction: it is off screen and needs scrolling, it is covered by an overlay such as a keyboard, a banner or a modal, it is disabled, or it is mid animation and its position is still changing. On mobile the keyboard is the most frequent culprit. Waiting for clickability rather than presence catches most of it, and scrolling the element into view explicitly rather than assuming it is visible catches the rest.

What they are assessing

Consistency across devices.

Model answer

Grant them at install where permissions are not the thing under test, using autoGrantPermissions on Android and the iOS alert handling capabilities, so behaviour is consistent regardless of device. Where they are under test, handle the dialogs explicitly and expect differences: Android permission wording and flow changed across versions, and manufacturer skins sometimes add extra prompts. Testing the denial path matters as much as the grant path, since apps frequently handle a refused permission badly.

What they are assessing

Willingness to recommend against the tool.

Model answer

When the team owns the app code and wants fast, stable tests close to the code, which is most of the time for unit and component level coverage. Espresso synchronises with the UI thread automatically and runs far faster, and XCUITest is similarly better integrated. Appium earns its place when you need one framework across both platforms, when testers rather than app developers own the suite, when flows cross app boundaries, or when you must test the shipped binary. Both approaches coexisting is common and sensible.

What they are assessing

Reporting quality.

Model answer

Results attributed to a device and OS version, because a failure on one device and not another is the most important signal in mobile testing and an aggregated pass rate hides it. Attach screenshot, page source, device log and video per failure. Track the flake rate per test over time rather than per run. And report the device matrix that was actually covered, since a green run on two devices should not be presented as the same assurance as a green run across the supported set.

What they are assessing

Complex gesture handling.

Model answer

With the Actions API: press on the source element, a brief pause to trigger the long press that usually initiates drag mode, incremental moves toward the target rather than a single jump since many implementations ignore an instantaneous move, then release. Android also offers mobile: dragGesture. It is among the least reliable interactions to automate because the app's own gesture recognition thresholds vary, so I would confirm it is worth automating rather than covering it manually.

What they are assessing

A capability with a narrow use.

Model answer

It makes Appium switch to the webview context automatically at session start rather than beginning in the native context. It is useful for apps that are essentially a webview wrapper, where every interaction is web. For a genuine hybrid app with meaningful native chrome it causes confusion, because native elements then cannot be found until you switch back manually. So it is a convenience for one specific app shape rather than a general setting.

What they are assessing

Working with an opaque target.

Model answer

Inspect first to see what the hierarchy offers, since that determines what is feasible. Without accessibility identifiers you are limited to text, class and position, all of which are fragile, so I would set expectations that coverage will be shallower and maintenance higher. Prioritise ruthlessly toward the few journeys that justify the cost. And consider whether API level testing covers more of the risk for less effort, which with a third party app it often does not, making manual testing the honest recommendation for parts of it.

What they are assessing

Precision that prevents flakiness.

Model answer

Presence means the element exists in the hierarchy; visibility means it is also displayed with non zero size. On mobile the gap is significant because elements are frequently in the hierarchy while off screen or behind an overlay, so a presence wait returns immediately and the subsequent tap fails. Visibility is the right default for anything you intend to interact with, and clickability is better still since it also checks the element is enabled.

What they are assessing

Test strategy at the mobile level.

Model answer

Most coverage in unit and component tests owned by the app developers, because they are fast, stable and cheap. A focused Appium layer for genuine end to end journeys across a small device matrix, sized so it runs in a time the team will tolerate. Manual testing retained for the things automation cannot do well: real biometrics, hardware interactions, usability judgement, and exploratory work on new features. The mistake I would guard against is pushing coverage upward into Appium because that is where the test team sits.

What they are assessing

Commercial reasoning.

Model answer

Against the alternative rather than in isolation. An in house device lab costs devices, charging infrastructure, someone maintaining OS versions and replacing hardware, and it still does not cover the matrix. A cloud gives breadth immediately and removes that maintenance, at a per minute cost that makes suite duration a direct financial concern, which is itself a useful pressure. I would model both against the device coverage actually required, and be prepared to find that a small in house set plus cloud for breadth is cheaper than either alone.

What they are assessing

Restoring a broken signal.

Model answer

Quantify what proportion of failures are genuine, because that number is usually why nobody looks. On mobile it is typically low, with most failures coming from timing, device state and data collisions. So stabilise first: remove sleeps, disable animations, isolate data, handle interruptions centrally, and quarantine anything still unstable so the main run goes green and means something. Then fix the quarantined tests in priority order with owners and dates. Coverage comes after trust, not before.

Likely follow-up

How would you stop the quarantine list becoming permanent?

What they are assessing

A considered view rather than buzzwords.

Model answer

Three things I would defend. Platform native frameworks continue to take the fast, stable layer, leaving Appium for cross platform end to end coverage, which is a narrower but legitimate role. Device clouds keep displacing in house labs because the matrix keeps widening. And AI assisted element location and self healing locators are genuinely useful for the brittleness problem, while introducing a new risk that a test silently passes against the wrong element, so they need verification rather than trust. What I would avoid claiming is that any of it removes the need to design tests well.