Meta Mobile Developer (Entry Level) - Comprehensive Interview Preparation Guide

Direct answer

Use a single read/write pointer pass: keep a write index starting at 0, and for every element you read that is nonzero, swap it into position write and advance write. By the time the scan finishes, every nonzero element has been moved (in its original relative order) into the front of the array, and every zero has been pushed toward the back, all without any extra array. This is O(n) time and O(1) extra space, a single linear pass with two pointers moving at different speeds.

Structured elaboration

Why a two-speed pointer pair works. The read pointer visits every element exactly once. The write pointer only ever advances when a nonzero element is found, so it always points at the next open slot for a nonzero value. Because write <= read at all times, swapping nums[read] into nums[write] never overwrites an element read hasn't looked at yet; the elements between write and read (if any gap has opened up) are exactly the zeros collected so far, and the swap places one of them further back, which is what keeps zeros trailing.

Why relative order among nonzero elements is preserved. Nonzero elements are written into the front of the array in the exact order the read pointer encounters them, since each one gets a swap into the next available write slot in sequence. No nonzero element ever gets moved past another nonzero element, which is the "keeping relative order" requirement in the question.

Connection to sparse-vector compression. A sparse vector's useful information is its nonzero entries and their positions; long runs of zeros carry no information beyond "there are this many." Once all nonzero values have been compacted to a contiguous prefix of the array (which is exactly what this routine produces), a sparse representation becomes cheap to derive: store just the compacted prefix (the nonzero values and, for a true sparse encoding, their original indices) plus a single count of how many trailing zeros were dropped, rather than storing every zero explicitly. In other words, this in-place partition is the mechanical first step that turns a dense array into something ready to be run-length-encoded or converted into a (value, index) sparse pair list, since it groups all the "real" data together and reduces the zero tail to a single number.

Worked example

Full runnable code with pinned test cases, including the question's own example:

def move_zeroes(nums):
    """In-place: move all zeros to the end, keep relative order of nonzero
    elements. O(n) time, O(1) extra space. Single read/write pointer pass."""
    write = 0
    for read in range(len(nums)):
        if nums[read] != 0:
            nums[write], nums[read] = nums[read], nums[write]
            write += 1
    return nums


if __name__ == "__main__":
    tests = [
        ([0, 1, 0, 3, 12], [1, 3, 12, 0, 0]),
        ([0, 0, 0], [0, 0, 0]),
        ([1, 2, 3], [1, 2, 3]),
        ([0], [0]),
        ([], []),
        ([4, 0, 5, 0, 0, 6], [4, 5, 6, 0, 0, 0]),
    ]
    for arr, expected in tests:
        arr_copy = list(arr)
        result = move_zeroes(arr_copy)
        print(f"input={arr!r:20} -> {result!r:22} (expected {expected!r})")

Output (actual run):

input=[0, 1, 0, 3, 12]     -> [1, 3, 12, 0, 0]       (expected [1, 3, 12, 0, 0])
input=[0, 0, 0]            -> [0, 0, 0]              (expected [0, 0, 0])
input=[1, 2, 3]            -> [1, 2, 3]              (expected [1, 2, 3])
input=[0]                  -> [0]                    (expected [0])
input=[]                   -> []                     (expected [])
input=[4, 0, 5, 0, 0, 6]   -> [4, 5, 6, 0, 0, 0]     (expected [4, 5, 6, 0, 0, 0])

Given [0, 1, 0, 3, 12] -> [1, 3, 12, 0, 0] from the last test above: the nonzero values 1, 3, 12 land at indices 0, 1, 2 in exactly the order they appeared, and the two zeros are pushed to indices 3 and 4. A sparse representation could then be stored as nonzeros=[1, 3, 12] (with original positions [1, 3, 4] recorded separately if needed) plus trailing_zero_count=2, instead of keeping five explicit slots.

Trade-offs and pitfalls

• Building a new array (copy nonzero elements into a fresh list, then append zeros) is simpler to write correctly on the first try, but costs O(n) extra space; naming it as a valid baseline before presenting the in-place two-pointer version shows you understand what the O(1)-space constraint is actually buying.
• A common bug: swapping unconditionally instead of only when nums[read] != 0, which would just be an identity/no-op most of the time but risks a wasted swap when read == write; the code above avoids extra work here since a self-swap is harmless, but it's worth being explicit that the swap is a genuine no-op in that case, not a source of a bug.
• This partition preserves order at the cost of doing real swaps (not just overwrites), which is necessary specifically because order matters; if order among the nonzero elements didn't matter, a simpler two-pointer partition (like Dutch National Flag style) could do fewer writes.
• The "sparse compression" framing is a motivation for why this operation is useful, not an added algorithmic requirement: the core routine here is doing the compaction only, and a full sparse-vector encoder would be a separate downstream step (recording positions, applying run-length encoding to the zero tail) built on top of this compacted array.
• If the array holds -0.0 (a floating-point negative zero) rather than integers, remember that -0.0 == 0.0 is True in most languages, so it should still be treated as a zero for this purpose; the code above already handles this correctly since it uses != for comparison rather than checking sign or type.

Overview — steps to register (iOS & Android)

• iOS (APNs)

  • Enable Push Notifications and Background Modes in Xcode; upload APNs key/cert to your server or provider.
  • Request user permission via UNUserNotificationCenter.requestAuthorization.
  • Call UIApplication.shared.registerForRemoteNotifications().
  • Implement application(_:didRegisterForRemoteNotificationsWithDeviceToken:) to receive the device token (Data), convert to hex string, and send to backend.

• Android (FCM)

  • Add Firebase to project, include google-services.json, and FirebaseMessaging dependency.
  • Ensure correct manifest permissions and services.
  • Use FirebaseMessaging.getInstance().getToken() (or onNewToken in FirebaseMessagingService) to obtain registration token and send it to backend.

How tokens are obtained & refreshed

• APNs: device token issued by APNs after registerForRemoteNotifications; it can change after app reinstall, OS update, or device restore — app should register at each launch and on relevant lifecycle events.
• FCM: getToken() returns current token; onNewToken called when token is rotated (app restore, reinstall, user clears app data). Always handle token refresh callbacks.

Common failure modes

• User denied notification permission
• Network errors when sending token to backend
• Incorrect APNs cert/key or bundle ID mismatch
• Expired/invalid FCM credentials or wrong Sender ID
• Token conversion bugs (truncation or encoding mistakes)

Securely associating tokens with authenticated users

• Require user authentication (e.g., OAuth/JWT) before accepting token updates.
• Send token over HTTPS with short-lived auth token; validate token on backend and tie to user ID.
• Store tokens hashed or encrypted at rest; keep mapping user -> device_id, platform, token, last_seen.
• Verify ownership: on token submit, include device fingerprint (UUID) and require authenticated session; optionally send a confirmation push to verify delivery.
• Revoke tokens on logout, account removal, or detected compromise; implement rate limits and audit logs.

Direct answer
Read the sentence for what it is actually trying to say, restate that meaning in the fewest plain words, and remove verbal padding (filler words, unnecessary qualifiers, and jargon that doesn't add precision) rather than just shortening it mechanically.

Structured elaboration

• Separate meaning from wording first. Read the sentence and paraphrase its actual point out loud in your own words before touching the original text; this stops you from just deleting words from the existing structure and instead lets you rebuild a clean sentence.
• Remove filler and hedges: "um," "like," "you know," "sort of," "basically," "at the end of the day," and throat-clearing openers ("so, I mean").
• Remove unnecessary qualifiers that soften a claim without adding real uncertainty: "kind of important," "a little bit concerning," "somewhat unclear," when the writer actually means "important," "concerning," "unclear."
• Replace jargon with the plain-language equivalent only where the jargon isn't doing real precision work; keep a technical term if a more common word would actually lose meaning.
• Prefer active voice and a direct subject-verb-object order, which is usually both shorter and clearer than passive constructions. Active voice means the subject of the sentence does the action, for example "the team shipped the fix." Passive voice flips this around so the subject receives the action instead of doing it, and often hides or drops who actually did it, for example "the fix was shipped by the team" (actor still named, but buried at the end) or "the fix was shipped" (actor dropped entirely, so the reader can't tell who's responsible).

Worked example
Original: "So, um, basically what we're trying to do here is, like, sort of make the checkout flow a little bit faster, if that makes sense, because right now it's kind of slow for some users."

Rewrite: "We're speeding up checkout. It's currently slow for some users."

Word count drops from 35 words to 10, a 71% reduction, while the two facts (goal: faster checkout; problem: currently slow for some users) both survive intact. Everything removed was filler, hedging, or a qualifier that added no information.

Trade-offs and pitfalls

• Removing every qualifier can accidentally remove real uncertainty the speaker meant to convey; "somewhat unclear" sometimes genuinely means partially unclear, not fully unclear, so check whether the hedge was doing real work before deleting it.
• Jargon isn't always the enemy: "p95 latency" (the 95th-percentile response time) is more precise than "how fast it usually is," and rewriting it away for a technical audience would lose information, not just words.
• This is a skill best practiced by rewriting your own recent messages after the fact; it is much harder to self-edit in the moment than it is with a few minutes of distance.

Situation / problem summary
Saving state in lifecycle callbacks (onPause/onStop on Android; applicationWillResignActive/applicationDidEnterBackground on iOS) is risky when background threads may mutate the same model: you can get race conditions, partial writes, corrupted files, or crashes if the process is suspended mid-write.

Common concurrency issues

• Read/write races: background thread mutates while lifecycle thread serializes -> inconsistent snapshot.
• Lost updates: two threads write concurrently and one overwrites the other.
• Partial/atomicity failure: write interrupted -> truncated file.
• Deadlocks: locking the UI thread during long IO causes ANR or watchdog termination.
• Ordering issues: background work scheduled after lifecycle callback leads to stale persistence.

Robust patterns to avoid corruption (platform-agnostic)

• Snapshot-before-write: create an immutable copy of model state and write that copy.
• Single writer principle: funnel all persistence through one serial/producer (single-threaded writer).
• Atomic file writes: write to temp file, fsync, then atomic rename/replace.
• Transactional DBs: use ACID DB (SQLite/Core Data) with transactions/WAL and background contexts.
• Coordination primitives: lightweight locks only around model copy; avoid blocking main thread.
• Crash-safe fsync: ensure data and metadata flushed when required for critical data.

Android-specific recommendations

• Use a single-threaded Executor / HandlerThread for all disk writes. Example:

// Kotlin: single-writer executor
private val io = Executors.newSingleThreadExecutor()

fun saveSnapshot(state: MyModel) {
  val snapshot = state.copy() // immutable snapshot
  io.execute {
    val tmp = File(filesDir, "state.tmp")
    tmp.writeText(serialize(snapshot))
    tmp.sync() // extension to fsync
    tmp.renameTo(File(filesDir,"state.json")) // atomic replace
  }
}

• For SQLite/Room: perform writes via write transactions on background thread; enable WAL for durability.
• Avoid long blocking in onPause; schedule synchronous persistence on writer thread and wait only briefly if necessary (or use foreground service / lifecycle aware background task).

iOS-specific recommendations

• Use a serial DispatchQueue for file writes or use Core Data’s private queue context / performBackgroundTask.
• Use FileManager.replaceItemAt or write(to: options: .atomic) and call FileHandle.synchronizeFile() if needed.

let diskQueue = DispatchQueue(label: "com.app.disk")
func save(state: Model) {
  let snapshot = state.snapshot()
  diskQueue.async {
    let tmp = url.appendingPathExtension("tmp")
    try snapshotData.write(to: tmp, options: .atomic)
    try FileManager.default.replaceItemAt(url, withItemAt: tmp)
  }
}

• For Core Data: use performBackgroundTask, merge changes on main context; enable journaling and persistent store options for WAL.

Additional best practices

• Minimize work in lifecycle callbacks; trigger the writer so it owns durability, don't perform heavy IO on UI thread.
• Use versioning and checksums: write checksum/manifest to detect corruption and recover.
• Implement retry and recovery: on startup, detect temp files or incomplete writes and recover/rollback.
• Test with stress tests, signal termination and low-memory conditions, and verify atomicity across devices.

Outcome: funneling persistence through a single, background writer, writing immutable snapshots, and using atomic write/transaction primitives yields race-free, crash-safe persistence on both Android and iOS.

Approach summary
Describe runtime validation of server identity by embedding expected public-key hashes or leaf certs in the app and rejecting connections that don’t match. Implement on iOS via URLSession/TLS trust evaluation and on Android via OkHttp CertificatePinner.

iOS (URLSession / Trust evaluation)

• Use URLSessionDelegate’s urlSession(_:didReceive:completionHandler:) or evaluate serverTrust in URLSessionTaskDelegate.
• Example (Swift):

// in URLSessionDelegate
func urlSession(_ s: URLSession, didReceive challenge: URLAuthenticationChallenge,
                completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
  let trust = challenge.protectionSpace.serverTrust!
  // compute SHA256 of public key
  // compare with stored base64 pins
  if matchesPin(trust) { completionHandler(.useCredential, URLCredential(trust: trust)) }
  else { completionHandler(.cancelAuthenticationChallenge, nil) }
}

Android (OkHttp CertificatePinner)

• Use OkHttp’s CertificatePinner with hostname and public-key SHA-256 pins:

val pinner = CertificatePinner.Builder()
  .add("api.example.com", "sha256/AAAAAAAA...=")
  .build()
val client = OkHttpClient.Builder().certificatePinner(pinner).build()

Trade-offs / operational issues

• Pin rotation: embed multiple pins (current + backup) and support server-side rollout; release app updates before retiring old pins.
• Enterprise TLS interception: pinning blocks corporate proxies; provide opt-outs only with explicit user/enterprise workflows.
• Complexity: increases release coordination, more fragile during cert changes, harder debugging for users.
• Security vs availability: strong protection against rogue CAs, but risk of app failures if pins stale.

When appropriate / when to avoid

• Use pinning for high-value apps (banking, health) where MITM risk is critical.
• Avoid in general-purpose apps with many third-party endpoints, or where enterprise interception must be supported; prefer standard TLS + monitoring (CT, HPKP deprecated) and short-lived certs/OCSP stapling instead.

Direct answer: Structure this as a small number of milestones (three to six), each with employer context, title, and approximate timeframe, one line on what you did, and the reason you moved to the next step. Open with a one-line frame of what connects these jobs (your through-line) rather than a start date, and don't treat every job change as equally important.

Structured elaboration

The milestone model, not a diary

Pick three to six career milestones (a promotion, a title change, a deliberate move) rather than narrating every job change. For a deep-technical background, emphasize technical growth across those milestones: scope of systems owned, complexity of problems solved, or seniority of team, not just tenure.

What to name at each milestone

For each milestone, give: the employer context and title (for example, "a small startup, as the second backend hire" rather than a bare timeline), the approximate timeframe, team size and the stack central to that stage, and one sentence on why you moved to the next step. Naming promotions and title changes explicitly signals growth the interviewer would otherwise have to infer from your resume. If you're naming a real former employer, that's fine to do live in the room; when practicing or writing this out generically, use employer type and context rather than a name so the shape of the answer stays reusable across interviews.

Explaining the "why" at each transition

For every step, answer two questions in one breath: how this role prepared you for the next one, and why you moved on. A career that reads as a sequence of things that happened to you reads as passive; a career narrated as a sequence of deliberate choices reads as intentional.

Timeline shape: highlight two moments, not every moment

Across the whole walkthrough, spend real time on exactly two things: one early-career learning moment (a mistake, a skill gap you closed, a foundational lesson) and one major turning point (a promotion, a pivot, a project that changed your trajectory). Everything else gets one line.

Worked example

Skeleton: "I started at [employer type], as a [title], on a team of [size], working mainly in [stack]. [One early-career learning: what I didn't know yet and how I closed the gap]. After [timeframe], I moved to [next employer type/title], because [reason tied to growth] [team size/stack if it changed]. [Major turning point: the milestone that changed my trajectory]. Today I'm at [current stage], where [what prepared me specifically for this next move]."

Filled illustration: "I started at a small agency as a junior data analyst on a two-person team, mostly writing SQL against a single reporting database. I didn't yet know how to translate a stakeholder's vague question into a testable metric, and closing that gap became the thing I got known for. After about two years, I moved into a data analyst role at a mid-size product company, because I wanted to work closer to product decisions instead of reporting after the fact. That's also where I was promoted to senior analyst on a team of six, once I'd built the first self-serve dashboard the product org relied on daily. That promotion was the turning point: it shifted me from someone who answered questions to someone who framed which questions were worth asking. Today I lead analytics for one product area, which is what draws me to a role that combines that ownership with a bigger surface area."

Trade-offs & pitfalls

• A pure date-by-date recitation (title, dates, title, dates) has no through-line and makes the interviewer do the synthesis work themselves.
• Treating every job change as equally important dilutes the two moments that actually matter: the early lesson and the big turning point.
• Omitting why you moved makes moves look reactive (laid off, bored, following a friend) rather than deliberate, even when the real reason was a good one.
• For senior candidates, spending equal time on early junior work as on recent scope is a common miscalibration; weight time toward the stages most relevant to this role.

Approach
Define DTOs, Retrofit interface using Moshi converter, include Authorization header, and call from a coroutine with proper exception handling.

Models

data class Article(val id: String, val title: String, val body: String)

data class PaginatedResponse<T>(
  val items: List<T>,
  val page: Int,
  val pageSize: Int,
  val total: Int
)

Retrofit interface

interface ArticlesApi {
  @GET("articles")
  suspend fun getArticles(
    @Query("page") page: Int = 1,
    @Query("pageSize") pageSize: Int = 20,
    @Header("Authorization") auth: String // e.g. "Bearer <token>"
  ): PaginatedResponse<Article>
}

Retrofit builder (Moshi)

val retrofit = Retrofit.Builder()
  .baseUrl("https://api.example.com/")
  .addConverterFactory(MoshiConverterFactory.create())
  .build()
val api = retrofit.create(ArticlesApi::class.java)

Calling from coroutine with error handling

CoroutineScope(Dispatchers.IO).launch {
  try {
    val response = api.getArticles(page = 1, pageSize = 20, auth = "Bearer $token")
    // process response.items on main thread if updating UI
  } catch (e: HttpException) {
    // handle non-2xx, use e.code() and e.response()?.errorBody()
  } catch (e: IOException) {
    // network failure, timeout, no connectivity
  }
}

Notes: Prefer injecting token via an OkHttp interceptor for cleaner calls and to centralize retry/auth refresh logic.

Direct answer

Maintain a hash map from character to its running count, plus a queue that holds candidates for
"first non-repeating" in the order they first appeared. On each next(char), update the count
and push the character onto the queue if it is new; then pop from the front of the queue while
its count is greater than 1, since a repeated character can never again be the answer. Whatever
remains at the front (or None if the queue is empty) is the current answer.

Structured elaboration

Why a hash map alone is not enough. A hash map of counts tells you WHETHER a character
repeats, but not which non-repeating character came FIRST. You need an ordering structure
alongside it.

Why a plain list of "seen order" is not enough either. If you kept every character ever
seen in a list and re-scanned it on every query, you would pay O(k) per query, where k grows
with the stream. The insight that makes this online and efficient: once a character's count
exceeds 1, it can never become the answer again, so it should be permanently removed from
consideration, not re-scanned every time.

The deque of candidates. A deque (double-ended queue) holds characters that MIGHT still be
the first non-repeating one, in first-seen order. On each new character: increment its count in
the hash map, append it to the deque. Then, while the deque's front character has a count
greater than 1, pop it (it is now permanently disqualified). The deque's new front, if any, is
the answer.

Complexity. Each character is appended to the deque exactly once and popped at most once
over the life of the stream, so total deque work across n calls is O(n), making each
next() call amortized O(1), even though a single call can trigger several pops if multiple
front characters were just disqualified. Space is O(distinct characters seen so far), bounded
by the alphabet size for a fixed character set (for example 256 for byte-level input), not by
stream length.

Worked example

from collections import deque, defaultdict

class FirstNonRepeating:
    def __init__(self):
        self.counts = defaultdict(int)
        self.candidates = deque()

    def next(self, char):
        self.counts[char] += 1
        self.candidates.append(char)
        while self.candidates and self.counts[self.candidates[0]] > 1:
            self.candidates.popleft()
        return self.candidates[0] if self.candidates else None

class BruteForceFirstNonRepeating:
    """O(k) per call: re-scans everything seen so far, no deque pruning."""
    def __init__(self):
        self.seen_order = []
        self.counts = defaultdict(int)

    def next(self, char):
        self.counts[char] += 1
        self.seen_order.append(char)
        for c in self.seen_order:
            if self.counts[c] == 1:
                return c
        return None

stream = "aabcbcd"
fnr = FirstNonRepeating()
fast_answers = [fnr.next(ch) for ch in stream]
for ch, ans in zip(stream, fast_answers):
    print(ch, "->", ans)

brute = BruteForceFirstNonRepeating()
brute_answers = [brute.next(ch) for ch in stream]
print("brute-force cross-check:", brute_answers, "| matches:", brute_answers == fast_answers)

Running this against the stream "aabcbcd" prints:

a -> a
a -> None
b -> b
c -> b
b -> c
c -> None
d -> d
brute-force cross-check: ['a', None, 'b', 'b', 'c', None, 'd'] | matches: True

Tracing it by hand confirms each step: after "a" the only character is a (answer a);
after "aa", a now repeats (answer None); after "aab", b is the only non-repeat (answer
b); after "aabc", both b and c are non-repeating but b came first (answer b); after
"aabcb", b now repeats and c is the earliest remaining non-repeat (answer c); after
"aabcbc", c now repeats too and nothing is left (answer None); after "aabcbcd", d is
the only non-repeat (answer d). The independent brute-force cross-check above (re-scanning the
full seen-order list and counts on every call, an O(k) per-call approach) produces the exact
same seven answers on this stream, confirming the deque-pruning optimization changes performance
without changing the result.

Trade-offs and pitfalls

• Do not use a plain hash map without an ordering structure. A map alone can tell you a
  character's count but has no notion of "which non-repeating character came first," since hash
  maps do not guarantee iteration order matches insertion order in every language and even where
  they do (Python's dict since 3.7), scanning the whole map on every query throws away the
  benefit of an online algorithm.
• A common bug is popping from the deque unconditionally instead of only while the front is
  disqualified; that would discard characters that are still valid candidates.
• This generalizes directly to the first non-repeating word problem if you tokenize on word
  boundaries instead of characters: same data structures, same amortized-O(1)-per-token
  argument, as long as the vocabulary fits in memory.
• For a bounded alphabet (fixed character set), the space bound is a true constant, not just
  "bounded by input"; for an open-ended token vocabulary (arbitrary words), space instead grows
  with distinct tokens seen, which matters for a long-running service.

Brief description
BLoC (Business Logic Component) separates UI from business logic by exposing Streams (output) and Sinks (input). The UI sends events into sinks; the BLoC processes them, interacts with repos/validation, and emits new states on streams the UI listens to.

Streams & Sinks

• Stream<T>: read-only output the UI subscribes to (e.g., Stream<State>).
• Sink<Event>: input where UI adds events (user actions).
• Use StreamController or flutter_bloc package (Bloc/BlocProvider) for lifecycle.

Where to place logic

• Validation: in the BLoC (or small validator helpers) so UI stays dumb.
• Repository/API calls: in repository layer; BLoC coordinates calls and maps results to states.

Paginated list — high level
Events:

abstract class ListEvent {}
class FetchPage extends ListEvent { final int page; FetchPage(this.page); }
class Refresh extends ListEvent {}

States:

abstract class ListState {}
class ListLoading extends ListState {}
class ListLoaded extends ListState { final List<Item> items; final bool hasMore; }
class ListError extends ListState { final String message; }

Flow:

• UI dispatches FetchPage when scrolled near bottom.
• BLoC checks current page, calls repository.fetchPage(page), emits ListLoading or appends to ListLoaded, sets hasMore.
• UI subscribes via StreamBuilder or BlocBuilder to rebuild on state changes.

Best practices

• Keep BLoC testable, small, persist only UI state; handle errors and debounce rapid events (e.g., scroll).

Direct answer

The number doesn't change across audiences, but what it's evidence for does: to a CEO it's a business outcome (conversion, retention, cost), to external developers it's a reliability guarantee they can build on, to internal engineering managers it's a load and capacity signal. Same 30% improvement, three different "so what," each with the one metric that audience should actually track next.

Structured elaboration

The technique is picking, per audience, which consequence of the number they actually own:

1. Translate the metric into the currency that audience is measured on before stating it. A CEO is measured on revenue and retention; an external developer is measured on their own app's reliability; an internal engineering manager is measured on system load and incident risk.
2. Give exactly one metric to track next, not a dashboard's worth. Too many numbers reads as "we're not sure which one matters"; one number reads as a clear owner and a clear signal.
3. State the baseline and direction explicitly, down from 500ms to 350ms, not just "faster," so nobody has to ask what the improvement actually was.
   This same three-move pattern is what you would reuse for a different metric to the same or different audiences: messaging a lazy-loading improvement to executives, sales, and developers, an API deprecation to engineering, customers, and executives, or a throughput doubling to a CTO, operations, and sales. The technique is constant; only which consequence you lead with changes per audience.

Worked example

p95 latency means the response time that 95% of requests are faster than, so it's a measure of how slow the worst-but-common cases are, not the average case.

To the CEO: "We cut the time it takes customers to sign in from half a second to a third of a second, 500ms to 350ms, a 30% improvement, on the slowest 5% of requests, the ones customers actually notice as lag. Faster sign-in means fewer people abandoning at login and less friction on every visit. Metric to track: conversion rate on the sign-up-to-first-action flow over the next two weeks, to see if that translates into fewer drop-offs."

To external developer customers: "Our authentication endpoint's p95 latency, the response time 95% of your calls beat, dropped from 500ms to 350ms. You should see fewer client-side timeouts and retries against this endpoint. Metric to track: your own timeout and retry rate against our auth endpoint, it should trend down."

To internal engineering managers: "We cut auth p95 from 500ms to 350ms through caching and query tuning, which lowers tail latency for every downstream service that calls auth before doing its own work. Metric to track: queue length and tail latency on the services immediately downstream of auth, to confirm the improvement is propagating rather than just moving the bottleneck."

Trade-offs and pitfalls

Reusing the same "30% faster" framing for every audience without a metric attached invites the follow-up "compared to what, and how would I know it's working," which is exactly what the per-audience metric answers in advance. It's also a mistake to promise a business outcome, like "this will increase conversion," as a fact rather than a hypothesis. Latency and conversion correlate but aren't guaranteed to move together for every product, so the honest version says "we would expect to see," not "this will." And if a later measurement shows a segment of customers saw no improvement, say a region or client version, that needs its own honest message rather than folding it quietly into the aggregate number.