Senior Mobile Developer Interview Preparation Guide - FAANG Standards

Direct answer
Active listening is fully attending to what someone is saying, rather than partially listening while planning your own response, and it shows up as observable behaviors: paraphrasing back what you heard, asking a clarifying question before responding, and not interrupting.

Structured elaboration

• Paraphrasing back. Restating the speaker's point in your own words ("so what I'm hearing is X, is that right?") before responding. This does two things: it confirms you understood correctly, and it visibly signals to the speaker that you were listening rather than just waiting for a gap.
• Asking a clarifying question before responding, rather than jumping straight to your own opinion or solution. This is different from a rhetorical question; it should be a genuine gap in your understanding.
• Not interrupting, and tolerating brief silence rather than filling every pause, which gives the speaker room to finish a thought rather than compressing it because they sense you're waiting to jump in.
• Responding to what was actually said, not to what you assumed they'd say based on the first few words; a common tell of NOT actively listening is answering a slightly different question than the one asked.

Worked example
Not active listening: Colleague: "I'm worried the new deploy process adds risk because nobody's tested the rollback path." You: "Yeah, deploys have been slow lately, we should look at that." (You responded to a different, adjacent complaint, not the actual concern about the untested rollback path.)

Active listening: Colleague: "I'm worried the new deploy process adds risk because nobody's tested the rollback path." You: "So the specific concern is that we've validated the forward deploy but not a rollback, is that right? If so, that does feel like the highest-risk gap; should we run a rollback drill before this ships?"

The second response paraphrases the actual concern back, confirms it, and only then responds, so the colleague can correct you if you got it wrong before you act on a misunderstanding.

Trade-offs and pitfalls

• Paraphrasing everything, including trivial statements, reads as performative rather than genuine; save it for points where a misunderstanding would actually matter.
• Active listening is not the same as agreeing; you can accurately restate someone's point and still disagree with it once you've confirmed you understood it correctly.
• Under time pressure it's tempting to skip the confirmation step; the cost of skipping it is usually higher than the few seconds it takes, especially for consequential decisions.

Swift optionals — brief definition
Optionals represent a value that may be present or nil: Int? can hold an Int or nil. They force explicit unwrapping to avoid runtime nil crashes.

if let vs guard let — comparison

• if let
  • Creates a new scope where the unwrapped value exists.
  • Good for short, nested work when the success path is the inner block.
• guard let
  • Unwraps and keeps the unwrapped value available after the guard.
  • Requires an early exit (return, throw, continue, break) on failure.
  • Improves linear flow and reduces nesting — preferred for input validation.

When to use guard for input validation

• Validate function parameters at the start of a function.
• Fail early when required data is missing and further code assumes presence.
• Keep the happy path unindented and readable.

Example — guard improves readability & safety

func submitProfile(name: String?, ageString: String?) -> Bool {
    // Validate inputs up front; exit early if invalid
    guard let name = name, !name.isEmpty,
          let ageStr = ageString, let age = Int(ageStr), age > 0 else {
        // handle invalid input (log, show UI error, etc.)
        return false
    }
    // Happy path: both name and age safely unwrapped
    saveProfile(name: name, age: age)
    return true
}

This pattern reduces nesting, makes assumptions explicit, and prevents using nil values later in the function.

Plan overview (goal): rename Note.title → Note.name and add relationship owner:User with minimal user-visible risk. Prefer lightweight migration; fall back to a custom mapping if needed.

Lightweight migration steps

• Create a new Core Data model version (Editor → Add Model Version) and set it as current.
• In the new model: rename attribute title → name. Set the attribute's Renaming ID to the old name (title) (in Xcode inspector, set "Renaming Identifier").
• Add relationship owner on Note pointing to User. If owner can be nil for existing records, mark relationship optional.
• Enable automatic lightweight migration when adding the store:
  swift

  let options = [
    NSMigratePersistentStoresAutomaticallyOption: true,
    NSInferMappingModelAutomaticallyOption: true
  ]
  container.persistentStoreDescriptions.first?.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
  container.loadPersistentStores(completionHandler: { _, error in ... })
  

• Reasoning: Renaming with Renaming ID and adding an optional relationship are supported by lightweight inference. This preserves data and requires no custom code.

When lightweight is insufficient

• If owner must be populated from existing info (e.g., Note has ownerID stored externally), or relationship cardinality/transformations are complex, create a custom mapping:
  • Create an explicit Mapping Model (File → New → Mapping Model) between old and new versions.
  • Implement an NSEntityMigrationPolicy subclass for Note to set the owner relationship during migration:
    swift

    class NoteMigrationPolicy: NSEntityMigrationPolicy {
      override func createDestinationInstances(forSource sInstance: NSManagedObject, in m: NSMigrationManager) throws {
        try super.createDestinationInstances(forSource: sInstance, in: m)
        let dest = m.destinationInstances(forEntityMappingName: "NoteToNote", sourceInstances: [sInstance]).first as? NSManagedObject
        if let ownerID = sInstance.value(forKey: "ownerID") as? String {
          // lookup or create User in destination context then set relationship
        }
      }
    }
    

  • Attach the policy to the Note entity mapping in the mapping model.
  • Use NSMigrationManager to run the custom mapping when replacing the store.

Testing strategy (across live data / versions)

• Automated migration tests:
  • Keep an archive of old model .momd versions. Programmatically load an old store seeded with representative records and run migration code to the new model; assert renamed attribute values and owner relationships.
• Manual / integration testing on devices:
  • Build an app binary with the old model, seed devices via TestFlight or local install with realistic data (create notes, set owner scenarios).
  • Install new version over the old on device and run acceptance tests covering UI, CRUD, and background sync. Verify no data loss, name populated, and owner set/optional as expected.
• Edge checks:
  • Test corrupted/partially-migrated stores — ensure graceful error and clear recovery (backup & restore prompt).
  • Test on multiple iOS versions and large stores for performance.
• Rollback / telemetry:
  • Log migration success/failure with non-sensitive metrics and provide a safe rollback path (keep pre-migration backup copy of the sqlite + WAL files and surface an in-app restore option for support).

This approach minimizes user disruption, uses lightweight migration where possible, and provides a clear custom path and test plan when transformations require code.

Approach (brief)
Use Retrofit suspend API on Dispatchers.IO, catch exceptions, map responses to Result<List<User>> so ViewModel can collect via its coroutineScope.

Assumptions / imports

• Retrofit service: interface ApiService { @GET("users") suspend fun getUsers(): List<User> }
• Data class: data class User(val id: Int, val name: String)
• Imports: kotlinx.coroutines.Dispatchers, kotlinx.coroutines.withContext, retrofit2.HttpException, java.io.IOException

Repository implementation

class UserRepository(private val api: ApiService) {
    suspend fun fetchUsers(): Result<List<User>> {
        return withContext(Dispatchers.IO) {
            try {
                val users = api.getUsers() // suspend Retrofit call
                Result.success(users)
            } catch (e: HttpException) {
                Result.failure(Exception("HTTP ${e.code()}: ${e.message()}"))
            } catch (e: IOException) {
                Result.failure(Exception("Network error: ${e.localizedMessage}"))
            } catch (e: Exception) {
                Result.failure(e)
            }
        }
    }
}

Usage from ViewModel

• In ViewModel: viewModelScope.launch { val result = repo.fetchUsers(); handle Result (success/failure) }

Why this works

• withContext(Dispatchers.IO) ensures network runs off main thread.
• Explicit catches distinguish HTTP vs network errors for better UX/ retry logic.
• Result wrapper is idiomatic and easy to handle in UI.

Edge cases

• Empty lists, partial failures, JSON parsing errors (handled by generic Exception), consider mapping errors to sealed types for richer UI handling.

Approach (brief)
Implement platform-specific accessibility actions that let users jump between list categories. On iOS use UIAccessibilityCustomRotor for rotor navigation and UIAccessibilityCustomAction for single actions. On Android add custom AccessibilityAction IDs to AccessibilityNodeInfo and handle them in AccessibilityDelegate/AccessibilityService.

iOS (Swift) — rotor + actions

• Add a rotor to the container (e.g., UITableView/UICollectionView):

let unreadRotor = UIAccessibilityCustomRotor(name: NSLocalizedString("Unread", comment:"Rotor: unread")) { predicate in
    // find next unread cell after predicate.currentItem.targetElement
    return UIAccessibilityCustomRotorItemResult(targetElement: nextUnreadElement, targetRange: nil)
}
UIAccessibility.customRotors = [unreadRotor, /* starred rotor */]

• Add custom actions for long-press or action menus:

cell.accessibilityCustomActions = [
  UIAccessibilityCustomAction(name: NSLocalizedString("Jump to Unread", comment:""), target: self, selector: #selector(jumpToUnread))
]

• Ensure each element has meaningful accessibilityLabel, traits, and accessibilityValue; use accessibilityHint for action purpose.

Android (Kotlin) — actions

• In onInitializeAccessibilityNodeInfo:

info.addAction(AccessibilityNodeInfo.AccessibilityAction(
  R.id.action_jump_unread, context.getString(R.string.jump_unread)
))

• Handle in AccessibilityDelegate or performAccessibilityAction:

override fun performAccessibilityAction(action: Int, args: Bundle?): Boolean {
  if (action == R.id.action_jump_unread) { scrollToUnread(); return true }
  return super.performAccessibilityAction(action, args)
}

• For TalkBack rotor-like motion, expose collection info and custom actions; newer Android releases support accessibility shortcuts and navigation granularity — implement AccessibilityService shortcuts if app-wide rotor is required.

Discoverability

• Provide clear accessibilityHint text and announce actions when focused (UIAccessibility.post(notification: .announcement,...)). Add a visible Help/Accessibility Settings screen that documents rotor names and available actions.
• For iOS, rotors appear in VoiceOver rotor menu; ensure names are short and prioritized by order in UIAccessibility.customRotors.
• For Android, actions appear in TalkBack local context menu and via swipe gestures; ensure action labels are concise.

Localization & Testing

• Localize all action and rotor names with NSLocalizedString / Android string resources, including context comments.
• Test with VoiceOver and TalkBack in multiple languages and with different rotor/action orders. Verify dynamic content changes post notifications to update rotor results.

Trade-offs & Notes

• Rotors are best for repeated granular navigation; custom actions are suited for one-off jumps. Keep rotor count reasonable to avoid clutter.

Direct answer

Find the actual root cause behind the regressions rather than just fixing the two broken flows, since a fast release cadence usually only causes visible damage when it exposes a gap that was already there, then fix what's broken with urgency proportional to its severity, tell stakeholders the truth about what happened, and change the specific process step that let it through.

Structured elaboration

• Root-cause analysis: don't stop at "we shipped too fast." Find the specific gap that a faster cadence exposed, commonly stale or missing automated regression coverage on core flows that everyone assumed was still working.
• Immediate fixes, prioritized by severity: a flow that's fully broken, like login, needs an immediate rollback or kill switch, since it blocks everything downstream of it; a flow that's partially degraded, like one payment path within checkout, can take a fast, targeted hotfix on a slightly longer clock.
• Stakeholder communication: a same-day, specific note naming exactly what broke, who's affected, and the fix timeline, rather than a vague reassurance; credibility comes back faster from precision than from an overly polished apology.
• Process changes to prevent recurrence: rebuild automated regression coverage for the core flows as an actual release gate that blocks shipping without it, and set a floor on how far the QA window can be compressed under deadline pressure, with an explicit escalation path if a deadline would require going below that floor.

Worked example

The mobile app shipped three features in one release; QA afterward found regressions in the login and checkout flows. Root-cause analysis traces this to automated regression coverage for those two flows never being rebuilt after a UI redesign two months earlier, so continuous integration stayed green while real regressions shipped underneath it; a contributing factor was the QA pass window being compressed from its usual 3 days to 1 day to hit the release deadline. Immediate fixes: the login regression, which blocks the flow entirely, gets rolled back via a kill switch within hours; the checkout regression, which only affects one payment path and not the whole flow, gets a targeted hotfix within 24 hours. The same day the regressions are confirmed, stakeholders get a specific note naming both flows, the releases affected, and the fix timeline, followed by a short written retro within a week. Process change: automated regression tests for login and checkout are rebuilt and made a hard release gate, and the QA pass window gets a floor of 2 days that can't be compressed further without the PM formally escalating the trade-off to the mobile team lead first.

Trade-offs and pitfalls

A common mistake is fixing the two visible regressions and stopping there, without asking why the regression coverage that should have caught them wasn't there in the first place; the same gap will produce the next incident. Another failure is being vague with stakeholders about root cause to avoid pointing at the compressed QA window, which reads as evasive once people ask how this happened a second time. Watch also for a process fix that exists only on paper; a release gate that can be silently bypassed under the next deadline crunch doesn't actually prevent recurrence.

Clarify goals & constraints

• Mobile apps update slowly; must preserve backward compatibility for months.
• Minimize bundle/API churn and map persisted queries to server-side implementations.

Safe schema-change rules

• Add only nullable fields or fields with server-side defaults.
• Never remove or rename fields used by older clients; use deprecation first.
• Use @deprecated(reason: "...") on fields and document removal timeline.

Persisted query versioning & mapping

• Persisted queries keyed by stable ID + semantic version (v1, v2).
• Server maps old IDs to current resolver paths via an adapter table so running clients keep working while backend evolves.
• When changing response shape, keep old resolver for legacy ID that projects fields to the new model.

Schema facades / adapter layer

• Implement a façade service that accepts legacy queries and translates them to the current schema/resolvers.
• Facade handles field renames, type conversions, and synthesizes default values for new non-nullable fields.
• Keep logic lightweight and versioned per client-min-version.

Migration timeline & policy

• Deprecation window: announce 90 days; monitor usage for 60 days; schedule removal after 180 days or when usage hits zero.
• Tie removals to app-store release targets; never remove before all supported client-min-versions can be updated.

Tooling & detection

• Instrument GraphQL gateway to record which fields and persisted query IDs are used per client version (mobile app version, OS).
• Build dashboards and alerts for deprecated-field usage.
• Add CI checks: breaking-change detector (schema diff), linting for new non-nullables, and automated tests that run legacy persisted queries against new schema via the façade.

Mobile dev practices

• Use typed client codegen (Apollo/Relay) pinned to a schema snapshot per release.
• Emit analytics with client-version + query-id to help server-side cleanup.
• When adopting new fields, feature-toggle on server and fallback gracefully in client code to preserve UX.

Approach (brief)
Create controller instances in initState and dispose them in dispose to free native resources and stop listeners/animations.

Code example

import 'package:flutter/material.dart';

class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> with SingleTickerProviderStateMixin {
  late final AnimationController _animController;
  late final TextEditingController _textController;

  @override
  void initState() {
    super.initState();
    _animController = AnimationController(vsync: this, duration: Duration(seconds: 1));
    _textController = TextEditingController();
  }

  @override
  void dispose() {
    _animController.dispose();
    _textController.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) => Container();
}

Why dispose matters
Controllers hold native handles, timers, or listeners. If not disposed they remain referenced (listeners still registered), preventing GC → memory leaks, CPU usage from running animations.

How it shows in DevTools

• Heap snapshot shows retained instances (AnimationController/TextEditingController) and their listeners.
• Memory chart may grow over time; object count increases after screen navigation.
• Retaining paths trace shows why GC can’t collect them (active listener from framework).

Direct answer

A PII-safe logging helper redacts common sensitive patterns (emails, Social Security numbers, credit card numbers) from a message before it is ever written to a log, using compiled regular expressions applied consistently across every log call, while also enforcing structured fields (a correlation ID, a job or request identifier), log-level discipline, and an extensibility point for adding new redaction patterns as new sensitive-data types are identified.

Structured elaboration

Redaction via compiled regex patterns. A small set of well-tested regular expressions, compiled once and reused (not recompiled on every log call, which would be wasteful), match common PII shapes: an email address pattern, a Social Security number pattern (\d{3}-\d{2}-\d{4}), and a credit-card-like sequence of 13 to 16 digits (allowing spaces or dashes as separators, since real card numbers are often written with them). Each match is replaced with a fixed [REDACTED] marker before the message is passed to the underlying logging framework.

Performance considerations. Compiling patterns once at startup (not per-call) and running them against every log message adds a small, roughly-constant regex-matching cost per log call; for a very high-throughput logging path this is measurable but usually acceptable, since the alternative (an actual PII leak into a log aggregation system with far broader read access than the original data source) is a materially worse outcome, and the specific cost can be validated by simply measuring log throughput with and without the redaction step in a realistic load test.

Configuration to extend redaction patterns. New PII patterns identified over time (an internal account-number format specific to the business, for instance) should be addable without modifying the core logging class, via a constructor parameter or configuration file accepting additional patterns, so the redaction logic can grow as new sensitive-data types are identified in practice, not require a code change and redeploy of the core logging utility itself for every new pattern.

Testing and validating at scale. Beyond unit tests confirming each pattern redacts correctly and that non-sensitive messages pass through unchanged, validating "at scale" means running the redaction logic against a genuinely large, realistic sample of actual (or realistically-synthetic) log messages and manually or statistically auditing a sample of the OUTPUT for anything that looks like it should have been redacted but wasn't, since regex patterns can have false negatives on real-world data that a small, hand-written unit test suite won't surface (an international phone number format, a differently-formatted SSN with no dashes).

Structured fields, log levels, and INFO versus DEBUG. Beyond redaction, the logging helper should ensure every log entry carries a correlation ID (tying related log lines from the same request or job together) and a job/run identifier where relevant (for a batch context specifically). INFO-level logging should capture what a normal operator needs to see to understand system behavior (a job started, a job completed, a summary count); DEBUG-level logging can include more granular detail useful only during active troubleshooting, but should still be redacted with exactly the same discipline as INFO, since a DEBUG log accidentally left enabled in production is a very common real-world path by which sensitive data actually ends up in logs.

Differences for a batch job versus a real-time service. A nightly batch scoring job's logging strategy centers on a per-run summary (start time, record count processed, error count, completion status) tagged with a job_id and run_id, since a human reviewing a batch job's logs the next morning wants an overview, not necessarily a line per record. A real-time service's logging centers on a per-REQUEST correlation ID and typically much higher log volume, and needs sampling strategies for very high-traffic endpoints (logging a representative fraction of successful requests at INFO, while still logging every failure) to keep log volume and cost manageable without losing visibility into failures specifically.

Worked example

public class PiiSafeLogger {
    private static final Pattern EMAIL = Pattern.compile("[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}");
    private static final Pattern SSN = Pattern.compile("\\b\\d{3}-\\d{2}-\\d{4}\\b");
    private static final Pattern CREDIT_CARD = Pattern.compile("\\b(?:\\d[ -]*?){13,16}\\b");
    private final List<Pattern> patterns = new ArrayList<>(List.of(EMAIL, SSN, CREDIT_CARD));

    public PiiSafeLogger(List<Pattern> extraPatterns) { patterns.addAll(extraPatterns); }

    public String redact(String message) {
        if (message == null) return null;
        String result = message;
        for (Pattern p : patterns) result = p.matcher(result).replaceAll("[REDACTED]");
        return result;
    }
}

Verification note: a Java Development Kit was not available in this execution sandbox, so the exact class above was not compiled directly; the identical regular-expression patterns and replacement logic were instead executed against an equivalent Python translation (Python's re module uses the same pattern syntax for these specific expressions) and confirmed: an email address embedded in a sentence is fully redacted; a dashed Social Security number is fully redacted; a spaced 16-digit credit-card-like number is fully redacted; a message containing no PII passes through completely unchanged; and a null input returns null rather than throwing. This confirms the REGEX LOGIC is correct; it does not confirm Java-specific behavior (for example, java.util.regex.Pattern's exact semantics versus Python's re), which is a disclosed limitation of this verification, not a claim of full Java execution.

Trade-offs and pitfalls

Regex-based redaction is a strong first line of defense but is not exhaustive: a credit card number with unusual formatting, a non-US identification number format, or a PII field that doesn't match any recognizable pattern at all (a person's name in a free-text field, which has no distinguishing shape a regex can reliably catch) can pass through unredacted; this is exactly why validating "at scale" against a realistic log sample, not just a handful of unit tests, matters, and why some organizations pair regex-based redaction with an explicit ALLOWLIST discipline (only log fields you've deliberately reviewed) for the highest-sensitivity data flows, rather than relying on a denylist-style redaction pattern to catch everything. The most common real-world failure mode is a DEBUG-level log statement, written during development and forgotten, that logs an entire request or record object directly (bypassing the redaction helper entirely, since it wasn't routed through it) rather than going through this centralized logging path, which is why enforcing that ALL logging goes through a single, redacting logger (not calling a raw print or an unwrapped logging framework call directly) is as important as the redaction logic itself.

Direct answer

No single signal reliably distinguishes a compromised client from an unusual-but-legitimate one, so the design combines several weak signals into a risk score and lets the score, not any one input, drive the response: a single attestation failure might just be an old device, but an attestation failure plus a replayed token is very unlikely to be anything but an attack. Responses escalate progressively with the score, from silent extra logging at the low end to an immediate token revocation and block at the high end, so the system's confidence and its intrusiveness stay proportional to each other.

Structured elaboration

The signals, and what each one actually tells you.

• Abnormal request patterns. Sudden spikes in call volume, requests to endpoints this client has never called before, or request timing/sequencing inconsistent with normal app usage (calling an "order confirmation" endpoint with no preceding "add to cart" calls from the same session, for example). This signal is good at catching automated abuse but noisy on its own, since a legitimate power user or a background sync burst can look similar.
• Device-attestation failures or low integrity scores. Android Play Integrity and iOS DeviceCheck/App Attest return a verdict on whether the device and app are in an expected, unmodified state. A failing or low-integrity verdict is a strong signal, but not an unambiguous one: it can also mean an old device below the platform's supported baseline, a legitimate power user running a rooted device for unrelated reasons, or a temporary attestation-service outage, none of which are attacks.
• Token replay detection. If refresh tokens rotate on use (the pattern this domain builds elsewhere), presenting an already-rotated token is either a captured, replayed credential or a client-side double-submission race; either way, it is a strong signal something is wrong with this session specifically, though not always attributable to a compromised device rather than a buggy client.
• Geolocation anomalies. Impossible-travel patterns (two requests from locations no real trip could connect in the elapsed time) or a mismatch between IP-derived location and device-reported location when both are available. Reliable for catching credential-sharing or session theft across distant locations, unreliable alone for anything within plausible travel distance, and unusable when location data is unavailable or the user is on a VPN for entirely benign reasons.
• Device-fingerprinting inconsistencies. A client whose reported device model, OS version, screen characteristics, or Transport Layer Security (TLS) handshake fingerprint changes between requests in ways a real device would not (a device model that suddenly changes mid-session, for example), or one that matches a known emulator/automation-tooling profile. Useful as a supporting signal, weak alone since legitimate configuration changes happen too (an operating-system update between sessions is normal; one mid-session is not).

Combining signals to reduce false positives. Two complementary approaches, layered rather than picking one:

• Rule-based combinations for high-confidence patterns. Some combinations are unambiguous enough to act on immediately without needing a learned model: attestation failure together with token replay, for instance, is a specific, well-understood attack shape (a cloned or tampered client attempting to reuse captured credentials) worth an immediate hard response.
• A weighted risk score for the subtler, high-volume cases. Each signal contributes points reflecting its individual reliability (attestation failure and token replay weighted heavily; a single geolocation anomaly or fingerprint inconsistency weighted lightly, since either alone is common among legitimate users), and the combined score crosses defined thresholds that map to different response tiers. Context matters as much as the raw signals: a low-integrity verdict on a device running an operating-system version several years old is a different situation from the identical verdict appearing for the first time mid-session on a device that previously always passed, and the scoring should weight a change from a client's own established baseline more heavily than an absolute reading in isolation, since that distinguishes "this device has always been like this" from "this device just became different."
• Requiring more than one independent signal before a disruptive action, specifically to keep any single noisy signal (geolocation, most often) from unilaterally triggering an account lock on its own.

Automated responses, tiered by confidence.

• Low risk (a single weak signal): log with increased detail, feed into the running baseline for that client/user, take no user-visible action.
• Medium risk (a moderate combined score, or one moderately strong signal): a soft response that adds friction without a hard block: require a fresh attestation check, force a token refresh (which itself will fail cleanly if the underlying session is actually compromised), or present a step-up authentication challenge (a one-time code) before allowing a sensitive action to proceed.
• High risk (a high combined score, or a rule-based high-confidence combination like attestation-failure-plus-replay): immediate, hard response: revoke the session's tokens, block the device identifier and/or originating IP for a defined window, and route to a human-reviewed account-lock workflow rather than an indefinite automated lock, since a false positive at this tier has real user impact and deserves a path back that does not depend entirely on the same automated system that triggered it.

Worked example

A client presents a request with: a Play Integrity verdict of "device integrity: MEDIUM" (below the strongest tier, but not a hard failure), a request rate roughly 3x this user's typical baseline over the past hour, and a geolocation consistent with a plausible same-day domestic flight from their last known location.

• Attestation: MEDIUM is not itself disqualifying (a real, if slightly older or customized, device can legitimately score here), so this contributes a moderate point value, not the heavy weight a hard FAIL verdict would.
• Abnormal request rate: 3x baseline is elevated but not extreme, and could plausibly be the user actively using a new feature; moderate weight.
• Geolocation: physically plausible, so this contributes little to no risk score on its own, since impossible-travel detection specifically requires travel time that exceeds what is physically possible, which this does not.
• Combined: none of the three signals individually crosses a hard-response threshold, and their combination lands in the medium-risk band. The response is a step-up challenge (a one-time code sent to the user's verified email) before the specific sensitive action (say, a large funds transfer) the client was attempting is allowed to proceed, not an outright block. If the user completes the challenge normally, the session continues uninterrupted for everything else; if they cannot, the request is denied and logged for review, without having disrupted a plausibly-legitimate user's whole session over a moderate combination of individually-weak signals.

Contrast with a second request from a different client: attestation verdict FAIL, and the presented refresh token matches one already marked replaced_by in the reuse-detection schema (a replayed, already-rotated token). This is the rule-based high-confidence case: both signals are individually strong and their combination is a known attack shape, so the response is immediate and hard, revoke all tokens for the session, block the device identifier, and route to manual account-security review, with no step-up-challenge grace period, since the confidence here does not call for one.

Trade-offs and pitfalls

• Acting on a single signal without context. The most common mistake in this design space: treating a low-integrity attestation verdict, on its own, as equivalent to a confirmed compromise. Devices fail attestation for many benign reasons (age, region-specific hardware variants, temporary attestation-service issues), and a design that hard-blocks on this signal alone generates a steady stream of legitimate-user lockouts that erode trust in the system faster than it catches real attackers.
• Weighting every signal equally. A naive point-per-signal scoring model treats a weak geolocation anomaly the same as a strong token-replay detection, which either under-reacts to the strong signals or over-reacts to the weak ones depending on where the threshold is set; weight each signal by its individual reliability, not uniformly.
• No path back from an automated high-risk lock. If the only way to recover from a false-positive hard block is the same automated system that triggered it, a legitimate user with an unusual-but-innocent combination of signals (traveling with a new phone right after an operating-system update, for instance) can be left with no recourse. Route high-confidence-but-still-possibly-wrong actions to human review, not a fully automated dead end.
• Ignoring the client's own historical baseline. Scoring every request against a fixed, global threshold instead of also comparing against what is normal for that specific client misses the more informative signal: a device that has always scored MEDIUM integrity is not newly suspicious, but the identical score appearing for the first time on a device that always previously scored HIGH is exactly the kind of change worth weighting more heavily.