Meta Senior Mobile Developer Interview Preparation Guide

Approach (brief)
Store refresh tokens encrypted at rest using platform-provided secure stores: AndroidX Security (EncryptedSharedPreferences + MasterKey) and iOS Keychain with access control. Rotate keys by re-encrypting tokens; migrate by detecting legacy storage and moving to secure store on next app start.

Android (Kotlin)

// build.gradle: implementation "androidx.security:security-crypto:1.1.0-alpha03" (or stable)
import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKey

val masterKey = MasterKey.Builder(context)
  .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
  .build()

val prefs = EncryptedSharedPreferences.create(
  context,
  "secure_prefs",
  masterKey,
  EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
  EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

fun storeRefreshToken(token: String) {
  prefs.edit().putString("refresh_token", token).apply()
}

fun getRefreshToken(): String? = prefs.getString("refresh_token", null)

• Migration: if legacy (plain SharedPreferences or custom crypto) exists, read, write into EncryptedSharedPreferences, then securely erase legacy copy.
• Key rotation: recreate MasterKey with new key alias/version and re-encrypt by reading token and writing back; consider atomic swap (write to new store then delete old).

iOS (Swift)

import Security

func storeRefreshToken(_ token: String, useBiometry: Bool = false) {
  let data = token.data(using: .utf8)!
  var attributes: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.app.refresh",
    kSecAttrAccount: "refresh_token",
    kSecValueData: data
  ]
  if useBiometry {
    let access = SecAccessControlCreateWithFlags(nil,
                 kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
                 .biometryAny, nil)!
    attributes[kSecAttrAccessControl] = access
  } else {
    attributes[kSecAttrAccessible] = kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
  }
  SecItemDelete(attributes as CFDictionary) // replace existing
  let status = SecItemAdd(attributes as CFDictionary, nil)
  assert(status == errSecSuccess)
}

func getRefreshToken() -> String? {
  let query: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.app.refresh",
    kSecAttrAccount: "refresh_token",
    kSecReturnData: true,
    kSecMatchLimit: kSecMatchLimitOne
  ]
  var result: CFTypeRef?
  let status = SecItemCopyMatching(query as CFDictionary, &result)
  guard status == errSecSuccess, let data = result as? Data else { return nil }
  return String(data: data, encoding: .utf8)
}

• Use kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly for background access, or device-only + biometry for extra protection.
• Migration: detect tokens in older keychain keys or insecure storage, copy to new item, and delete old.
• Key rotation: because Keychain items are protected by system keys, rotate by creating a new keychain item (new service/account/version metadata), write token, then delete old item; for Android rotate MasterKey and re-encrypt.

Security notes:

• Minimize lifetime of tokens in memory; clear buffers after use.
• Use device-only options to prevent iCloud/keychain sync if undesired.
• Log rotation/migration events securely (no tokens).

Approach — key points

• Represent UI state with a sealed UIState (Loading/Success/Error).
• Expose immutable StateFlow via asStateFlow().
• Use viewModelScope.launch to fetch and ensure cancellation on ViewModel clear.
• Catch exceptions and emit Error; provide a retry function.

Kotlin implementation

// Kotlin
sealed class ItemsUiState {
    object Loading : ItemsUiState()
    data class Success(val items: List<Item>) : ItemsUiState()
    data class Error(val message: String) : ItemsUiState()
}

class ItemsViewModel(private val repository: Repository) : ViewModel() {
    private val _uiState = MutableStateFlow<ItemsUiState>(ItemsUiState.Loading)
    val uiState: StateFlow<ItemsUiState> = _uiState.asStateFlow()

    init { fetchItems() }

    fun fetchItems() {
        _uiState.value = ItemsUiState.Loading
        viewModelScope.launch {
            try {
                val items = repository.getItems() // suspend
                _uiState.value = ItemsUiState.Success(items)
            } catch (e: Exception) {
                _uiState.value = ItemsUiState.Error(e.message ?: "Unknown error")
            }
        }
    }

    fun retry() = fetchItems()
}

Explanation

• MutableStateFlow holds current state; asStateFlow prevents external mutation.
• viewModelScope ensures coroutines cancel when ViewModel is cleared.
• Init loads immediately; retry exposes explicit re-fetch.

Important tests

• Success: repository returns list -> uiState transitions Loading -> Success(items).
• Error handling: repository throws -> Loading -> Error(with message).
• Cancellation: simulate long-running repository and verify coroutine cancels when ViewModel cleared.
• Retry behavior: initial failure then success on retry -> states reflect both attempts.
• Concurrency: multiple rapid fetch/retry calls produce deterministic final state (last call wins).
• Empty list: repository returns empty list -> Success(emptyList) and UI handles it.

Direct answer
I treat a company's published culture and values as a claim to be tested, not a fact to accept, and I look for evidence in three places: how people describe real, specific incidents (not slogans) when I ask about them, whether the org's actual structures and incentives would make the stated behavior easy or hard to practice, and whether the story is consistent across different people I talk to in the process.

Structured elaboration

1. Ask for a specific recent incident, not a description of the value. A question like "tell me about a time the team had to choose between shipping fast and following the documented review process" forces a real story; a question like "how would you describe the engineering culture here" invites a rehearsed, values-page-adjacent answer that tells you little.
2. Check whether the org's structure actually supports the stated value, independent of what anyone says. If a company claims to value psychological safety but every interviewer you meet is visibly guarded about naming any team problem, or if a company claims strong autonomy but every technical decision in the loop turns out to require a director's sign-off, the structural evidence contradicts the claim regardless of the wording used to describe it.
3. Triangulate across multiple people, ideally at different levels and tenures. A single enthusiastic interviewer proves little; a hiring manager, a peer-level engineer, and someone from a different function independently describing the same specific behavior (not the same slogan) is much stronger evidence.
4. Ask what the company would do differently if it stopped believing the value, and watch for a concrete, structural answer versus a vague one. People who work inside a genuinely lived value can usually name a real trade-off it costs them; people describing marketing usually cannot.
5. Treat your own discomfort as data. If a described norm (pace, feedback directness, decision-making style) makes you visibly uneasy during the process itself, that is a more reliable signal about fit than anything printed on the careers page, because it is your own live reaction rather than a claim you are being asked to evaluate secondhand.

Worked example
Suppose a company's careers page says it "empowers engineers with high autonomy." During the loop, ask the hiring manager for a specific recent example: "Tell me about the last time an engineer on this team made a production architecture decision without it going through a review committee first." A genuine, lived-autonomy answer sounds like: "Last quarter one of our engineers decided independently to switch a service from synchronous to async processing after noticing latency complaints; she looped in two people for a sanity check, shipped it, and reported the outcome in the next team sync." A marketing-only answer sounds like: "We really believe in empowering our engineers," repeated with no specific incident when pressed twice. If a peer engineer you speak to separately can also describe a comparable specific incident in their own words, that consistency is strong corroborating evidence; if the hiring manager's story turns out to be the ONLY example anyone can produce company-wide, that is itself informative about how common the behavior actually is.

Trade-offs & pitfalls
The main failure mode is accepting an interviewer's fluent, confident description of the culture as sufficient evidence on its own; confidence and specificity are not the same thing, and a well-rehearsed answer to a values-page question is exactly what a company under-delivering on its stated culture is most likely to have prepared. A second pitfall is over-weighting a single glowing anecdote from one enthusiastic interviewer without checking whether it generalizes; one great story is an anecdote, not a pattern. A third is treating any inconsistency you find as automatically disqualifying: it is normal for a large or growing organization to have real variance across teams, so the useful conclusion is usually about the SPECIFIC team and manager you'd actually join, not the company as a monolithic whole.

Direct answer

The partnerships that pay off under deadline pressure are almost never built in the moment you need them. They come from investing time in a working relationship with a team before there's a specific ask attached, understanding their priorities and vocabulary well enough that when you do need something urgent, they already trust your judgment and don't need to re-derive context from scratch.

Structured elaboration

1. Choose deliberately where to invest. You can't build deep relationships with every team you might someday depend on. Invest ahead of need in the teams whose dependencies are likely to become recurring or critical-path (on the chain of dependent work that directly determines a deadline), based on how your roadmap or their roadmap is shaping up.
2. Invest with no immediate ask attached. Show up to their planning or triage occasionally, offer help on something low-stakes, or spend time understanding how they prioritize their own queue. The absence of a request is what makes it relationship-building rather than a transaction.
3. Learn their vocabulary and criteria, not just their org chart. Knowing how a team actually decides what's urgent (their SLA, or service level agreement, tiers, meaning their committed response and turnaround times, and their escalation triggers) is what lets you frame a future ask in terms they'll immediately recognize as legitimate.
4. Share your own context too. A partnership that pays off later is two-directional: they should understand your team's constraints and cadence well enough that an urgent ask from you doesn't sound out of character.
5. When the moment comes, lean on the relationship, not authority. The payoff isn't that they're obligated to help, it's that they already trust your scoping and don't need to independently verify the ask is real before acting on it.

Worked example

As a backend engineer, I noticed my team periodically needed fast turnaround from the support team but had no real relationship with them beyond ticket queues. Over a few months, with no active request pending, I started sitting in on their triage session once a month, just listening and asking questions about how they decided what jumped the queue. In one of those sessions I noticed a complaint that kept resurfacing: a specific error support couldn't explain, so they were closing the tickets as "can't reproduce." I flagged it to the engineer on our side who owned that area, and made sure support knew we were looking into it even though nothing was urgent yet.

Months later, that same underlying issue caused a customer escalation with a tight deadline attached. I reached out directly to the support lead I'd built rapport with, framed the ask using the same triage language they used internally, and was specific about why it was time-sensitive. Because they already trusted that I didn't cry wolf and that my scoping was accurate, they fast-tracked the escalation ahead of their standard queue without needing the usual back-and-forth to validate it was real.

(Swap the domains freely: the same pattern works with a platform team, a design team, or a data team in place of support, as long as the investment happens before there's an active ask.)

Trade-offs & pitfalls

• Pitfall: relationship-building that's transparently transactional (showing up only when you're about to need something) reads as insincere and doesn't produce the trust you're after.
• Pitfall: investing broadly and shallowly across every team instead of selectively where dependencies are likely to matter. That spreads your own team's time thin for little return.
• Pitfall: treating the payoff as owed. A relationship earns goodwill; it doesn't guarantee compliance, and presuming it does damages the very trust you built.
• Senior differentiator: recognizing which dependencies are likely to become critical-path before they do, and investing ahead of the need rather than starting the relationship the day you first need a favor.

Overview of headers

• Cache-Control: directives like max-age, public/private, no-cache, no-store, must-revalidate. Mobile: use max-age for safe-to-cache responses; private for user-specific content.
• ETag: opaque validator (usually a hash). Server returns ETag; client later sends If-None-Match to check freshness.
• Last-Modified: timestamp validator; client sends If-Modified-Since.
• Vary: tells caches which request headers affect response (e.g., Vary: Accept-Encoding, User-Agent).
• Conditional requests: If-None-Match / If-Modified-Since let server return 304 Not Modified to avoid full payload.

How mobile apps should use them

• Persist responses to disk (HTTP cache or custom) and honor Cache-Control/Expires to avoid network/wake-ups.
• Implement conditional GET: when cache is stale, send If-None-Match; accept 304 and update timestamps without downloading body.
• Prefer ETag when content can change unpredictably; Last-Modified is lightweight when timestamps are reliable.
• Respect Vary to avoid serving wrong cached variant (e.g., different locales, encodings).
• Use short max-age for dynamic UI data, longer for assets; background sync to refresh quietly.

Battery & bandwidth tips

• Batch conditional requests, avoid frequent polling; use exponential backoff.
• Use network-type checks (Wi‑Fi vs cellular) and only refresh large resources on Wi‑Fi unless user opts in.
• Leverage platform HTTP caches (NSURLSession/OkHttp) which handle validators and 304s efficiently.

Common pitfalls

• Ignoring Vary → cache wrong variant.
• Using no-cache/no-store unnecessarily prevents ETag benefits.
• Relying solely on Last-Modified when server clocks are inconsistent.
• Not persisting cache across app restarts.
• Mistakenly caching sensitive auth-protected responses as public.

Implement validators + sensible Cache-Control, respect Vary, and coordinate refresh strategy for best battery/bandwidth savings.

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.

High-level approach
Store a small versioned envelope in local storage that contains a header (version, schema id, timestamp), an integrity tag, and an encrypted payload. Use authenticated encryption, per-install keys backed by platform secure storage, and explicit schema migration logic with safe fallbacks.

Format

• Header: { magic: "UISTATE", version: int, schema: string, created: iso8601 }
• Payload: encrypted bytes (serialized protobuf/CBOR)
• MAC/AEAD tag appended

Encryption & key management

• Use AES-256-GCM or ChaCha20-Poly1305 (AEAD) for confidentiality + integrity.
• Derive a data-encryption-key (DEK) per-install from a randomly generated master key (MK).
• Store MK in Keychain (iOS) / Android Keystore with hardware-backed protection; mark non-backupable if secret must not survive device transfer.
• Use envelope encryption for rotation: encrypt DEK with MK; on rotate generate new DEK, re-encrypt payload offline or lazily on next save.
• Support optional user-bound key (Biometric/Passcode) via Keychain/Keystore access control for higher protection.

Schema & versioning

• Use compact binary schema (protobuf/CBOR) with explicit fields and schema version.
• Each envelope header includes schema id + version.
• Implement migration functions: migrate_v1_to_v2(obj) ... keep a chain or upcast path on restore.
• Prefer additive changes; avoid renaming fields without aliases.

Restore & error handling

• On restore:
  1. Verify header magic and AEAD authenticity tag; if verification fails -> treat as corrupt.
  2. Decrypt using current DEK (unseal DEK from MK).
  3. Parse by schema version. If older version, run migrations in order. If newer/unknown version:
     • If forward-compatible: ignore unknown fields and proceed.
     • Else: fallback to safest behavior (discard payload, prompt user to re-enter or offer partial read of known fields).
• Corrupt/missing cases:
  • Log telemetry (no PII) + increment corruption metric.
  • Offer UX: "Restore failed; continue with default state" or "Retry with biometric" depending on policy.
  • If salvageable (partial parse), only restore non-PII with explicit user consent.

Implementation notes (Kotlin-style pseudocode)

val envelope = readFile()
if (!verifyMagic(envelope.header)) throw CorruptException()
val dek = unwrapDEKFromKeystore()
val plaintext = AEAD.decrypt(dek, envelope.ciphertext, associatedData = envelope.headerBytes)
val state = parseByVersion(plaintext, envelope.version)
val migrated = migrateToCurrent(state)

Trade-offs

• Hardware-backed keys increase protection but complicate backups/device transfer; choose per-app policy.
• Eager rotation re-encrypts immediately; lazy rotation defers cost but leaves old DEK briefly valid.

This design ensures confidentiality, integrity, controlled key lifecycle, explicit schema evolution, and robust UX paths for corruption or version mismatch appropriate for mobile apps.

Direct answer
Coaching a genuine underperformer starts with diagnosing why (skill gap, unclear expectations, motivation, or something outside work like a health or personal issue) before assuming it's a will problem, then moving to a private, honest conversation with specific examples, a written and time-bound improvement plan with objective checkpoints, and a clear, stated understanding of what happens if the bar still isn't met. The hard part isn't the first conversation, it's staying honest and consistent through every checkpoint after it.

Structured elaboration

Diagnose before you coach

Below-the-bar performance has different root causes that call for different responses:

• Skill gap: they don't yet know how to do the thing. Response: targeted teaching, pairing, smaller scoped tasks.
• Unclear expectations: they don't know what "good" looks like here. Response: make the bar explicit and concrete, with examples.
• Motivation or engagement: they can do it but aren't. Response: a more direct conversation about what's changed and why.
• Something outside work: a health issue, a personal crisis, burnout. A private, non-judgmental check-in on wellbeing belongs early in this process, both because it's the right thing to do and because it changes what the right intervention is (support and possibly a formal accommodation, not a performance plan).

Getting this wrong (coaching a skill gap like it's a motivation problem, or the reverse) wastes the improvement window on the wrong intervention.

The conversation and the plan

• Deliver the message privately, plainly, and with specific examples: what's below the bar, what the bar actually is, and why it matters.
• Put the plan in writing: two or three concrete, observable goals, a defined timeframe, and what evidence would count as "met."
• Set a regular check-in cadence shorter than your normal 1:1 rhythm; below-the-bar performance needs tighter feedback loops, not the same cadence as everyone else.

When to involve HR formally

This is a judgment call many candidates get wrong by either never mentioning HR (naive) or looping HR in immediately (overcautious, and it can undermine trust). A reasonable line: loop in HR or your manager as soon as the conversation could plausibly lead to a formal employment outcome (a documented warning, or separation), even if you're optimistic it won't get there, because that's exactly when documentation and process need to be right from the start rather than reconstructed after the fact.

Protecting the team

The rest of the team usually already knows something is off; silence reads as either denial or unfairness. Without disclosing private performance details, it's reasonable to acknowledge you're aware of the gap and are addressing it, and to be transparent about redistributing work if needed, so the team doesn't quietly conclude the issue is being ignored.

Worked example

Situation

An engineer on a team I was supporting had been reliably strong for over a year, then their output quality and delivery reliability dropped off sharply over a couple of months: reviews were taking longer, deadlines were slipping, and the pattern didn't match a normal bad sprint.

Diagnosis

Before assuming a motivation problem, I had a private, low-pressure conversation focused on checking in rather than accusing. That surfaced that part of the issue was a skill gap on a newer part of the codebase they'd been assigned to without much ramp-up, but there was also something going on outside work affecting their focus.

Action

We set a short, explicit improvement plan: two concrete, observable goals tied to real upcoming work, a shorter check-in cadence, and pairing time on the unfamiliar codebase area. I also made sure they knew about the option to talk to HR about support resources for the personal situation, kept separate from the performance conversation so the two didn't get conflated.

Result

Performance recovered within the plan's window once the skill gap closed and the external situation stabilized. Because the conversation started from genuine diagnosis rather than an assumption, the plan addressed the actual cause instead of just adding pressure, and the person stayed on the team and rebuilt trust with the group.

The other branch (when it doesn't turn around)

Not every case ends this way. When someone doesn't meet a documented plan's criteria despite real support, the path is a harder, well-documented conversation, formal HR involvement, and eventually separation if there's no path forward. The mentor's job at that point shifts from "close the gap" to making sure the process is fair, well-documented, and handled with dignity, and to being honest with the rest of the team (without violating privacy) that a change is coming so it doesn't land as a surprise.

Trade-offs & pitfalls

• Treating every case as a motivation problem. The single biggest junior mistake here is skipping diagnosis and going straight to "try harder" messaging, which fails skill-gap and external-cause cases and can be actively harmful if there's something like burnout or a health issue underneath.
• Involving HR too late (or too early). Too late, and you've lost the documentation trail that protects everyone, including the underperformer, if it does become formal. Too early or too visibly, and it can read as punitive before the person's had a real chance, damaging trust unnecessarily.
• Optimizing for the individual at the team's expense, or the reverse. A senior answer holds both: real support for the person, and honesty with the team about workload and timeline impact, rather than pretending nothing's happening.
• No exit criteria stated up front. A plan without a clear "what does not-met look like, and what happens then" isn't actually a plan, it's a delay, and it's unfair to the person because they don't know what they're actually being measured against.

Direct answer

A high-quality test fails when, and only when, the behavior it's supposed to protect actually breaks. A brittle test fails for unrelated reasons, a refactor, timing, execution order, and a misleading test passes even when the behavior is broken. Reviewing test code means checking specifically for those two failure modes, not just confirming a test exists.

Structured elaboration

Worked example

A PR adds a test for a discount-calculation function. Weak version: assert calculate_discount(100, 0.1) is not None, which passes even if the discount math is completely wrong, as long as something is returned. Strong version: assert calculate_discount(100, 0.1) == 90, which fails immediately if the discount logic is wrong, plus a boundary case, calculate_discount(100, 0) == 100. Tracing it: if the discount subtraction were removed entirely (the function just returned the input unchanged), the weak assertion would still pass, but the strong one would fail right away, confirming the strong version actually tests the behavior it claims to.

Trade-offs and pitfalls

Line-by-line scrutiny of every test on every PR isn't realistic; prioritize new business logic and edge cases, and be more lenient on straightforward tests for simple getters and setters. A common wrong turn is treating "there's a test" as sufficient without checking whether it would actually catch a real regression, which is the same blind spot a raw test-coverage percentage has, since a line can be "covered" by a test that never meaningfully asserts anything about it.

Definition — Lamport clocks

• Lamport clocks assign a single integer counter per process. On each local event: counter += 1. On send, include counter; on receive, set counter = max(local, received) + 1.
• They give a partial ordering that respects causality (if A -> B then L(A) < L(B)) but cannot determine concurrency precisely.

Definition — Vector clocks

• Each node keeps a vector of counters (one entry per node). On local event: V[i] += 1. On merge/receive: for all j, V[j] = max(V[j], V_recv[j]) and then increment local entry.
• Comparing vectors: V <= W if every component V[k] <= W[k]. If neither V <= W nor W <= V they are concurrent.

Short example (two devices A and B)

• Start: V_A = [0,0], V_B = [0,0].
• A updates: V_A = [1,0]; sync not yet sent.
• B independently updates: V_B = [0,1].
• When synced, compare [1,0] vs [0,1] — neither <= other ⇒ concurrent updates => conflict detected and need merge/resolution.

Why Lamport can be insufficient in mobile sync

• Lamport might assign L(A)=1 and L(B)=2 (depending on message timing). Since integers are totally ordered, L(A)<L(B) could imply an order that didn’t actually exist; concurrent updates may appear ordered, hiding conflicts. In mobile apps with offline edits on multiple devices, vector clocks are necessary to reliably detect true concurrency so the app can prompt merge, auto-merge, or use CRDTs.