Amazon Mobile Developer (Junior Level) Interview Preparation Guide

Direct answer
A decision genuinely reflects a stated value, rather than merely being compatible with it, when the value actually changed what you chose to do, not just how you described it afterward. The strongest answers make that causal link explicit: what you would have done differently if the value hadn't been a factor.

Structured elaboration

• Situation and task: the decision point, described briefly.
• The counterfactual test: name what the default, easier choice would have been, and what specifically made you choose differently.
• Action: what you actually did, including who you had to convince or coordinate with.
• Result: the outcome, and ideally a signal that the choice was validated rather than merely feeling principled at the time.

Worked example
Faced with a choice between shipping a quick, directionally useful analysis in time for a decision meeting, or spending an additional two weeks on a more rigorous version, the default and professionally "safer" choice would have been to wait for rigor. Choosing to ship the quicker, clearly caveated version instead, because the business decision had a hard deadline and a rigorous-but-late analysis would have been useless, shows a genuine trade-off rather than a reflexive one. The decision was validated when the more rigorous follow-up analysis, completed afterward, confirmed the same direction, meaning the faster call hadn't cost the business a wrong decision.

Trade-offs and pitfalls
A story where the value and the easy choice happen to be the same thing doesn't actually demonstrate anything, since no real trade-off was made; choose a story with genuine tension in it. Naming the value first and building a story to fit it, rather than the reverse, tends to produce something that sounds rationalized rather than genuine; a genuinely reflective answer usually names the counterfactual without being asked. A result stated only as "and it felt right" is weaker than any concrete validation signal, even an imperfect one.

Approach summary
Propose layered changes: reduce JS-native roundtrips by batching/coalescing, relocate frequent logic to native, and use JSI/Hermes for direct, low-latency paths (bypass bridge).

1) Batching / coalescing

• Buffer frequent small events (sensor samples, animation deltas) on JS or native side and send in frames (e.g., 16ms/60Hz) or when buffer full.
• Example pattern (JS): collect and flush on requestAnimationFrame or setInterval.

// collect and flush example
const buffer = [];
function onSensor(sample) { buffer.push(sample); }
function flush() {
  if (buffer.length===0) return;
  NativeModules.Sensors.receiveBatch(buffer);
  buffer.length = 0;
}
requestAnimationFrame(flush);

• Use compact binary formats (ArrayBuffer/TypedArray) to minimize serialization cost.

2) Move logic to native

• Implement filtering, aggregation, sampling, interpolation on native (Swift/Kotlin/Objective-C) so only necessary updates reach JS.
• Expose higher-level APIs to JS (e.g., startSmoothStream({rate:50, filter:true})).

3) JSI / Hermes / TurboModules

• Implement critical paths via JSI with host objects so JS can call into native functions synchronously without async bridge overhead.
• Example: create a JSI animation host that applies transforms and writes directly to native views or Skia canvas.
• Use Hermes for lower GC latency and faster FFI.

4) Additional patterns

• Use one-shot events + shared memory: share a NativeArrayBuffer for sensor frames; JS reads via JSI without copying.
• Throttle and backpressure: drop frames when JS busy.
• Profile and measure: CPU, wall-clock, energy (Instruments / Systrace).

Trade-offs

• Native/JSI increases complexity and maintenance. Favor incremental rollout: batch first, then native, then JSI for hottest path.

Approach (why it matters)
I’d design prompts to be explicit, minimal, and contextual so users understand value before OS-level ask—this raises acceptance and trust while minimizing privacy surprises.

What I’d show (copy + flow)

• Pre-prompt (in-app modal, before OS dialog): short title, one-line reason, clear benefit, optional CTA for “More info” and “Not now”.
  Example: “Allow Location to show nearby events.” Body: “We use precise location only while the app is open to list events within 5 miles.” Buttons: “Allow while using app” / “Not now” / “More info”.
• “More info” expands on data use, retention, sharing, and how to change later (link to Privacy settings).

Progressive disclosure strategy

• Defer request until feature is first used (just-in-time).
• Start with coarse permissions (approximate location) if possible, then prompt for precise only if feature requires it.
• Provide an in-app settings center showing current permissions, examples of benefits, and an easy way to revert.

Implementation notes (mobile developer)

• Use platform best practices: iOS NSLocationAlwaysAndWhenInUse descriptions, Android runtime rationale API.
• Test flows for different denial paths and deep-link to OS settings.
• Log anonymized telemetry on acceptance rates to iterate copy without leaking PII.

This balances transparency, usability, and privacy while meeting platform requirements.

Clarify scope & goals

• Target screens, timeline, platforms (Compose for Android, SwiftUI for iOS), OS min versions. Goal: incremental migration, zero-touch regressions, ability to roll back.

High-level plan

1. Strangler pattern: wrap new declarative views inside hosts (ComposeView/AndroidView, UIHostingController/UIViewRepresentable) and vice-versa where needed.
2. Migrate one feature/module at a time (non-critical first), expand based on stability.

Interoperability strategies

• Android: use ComposeView inside existing Activities/Fragments; expose View-based APIs for measurement/events. For backwards, use AndroidView to host Views in Compose.
• iOS: host SwiftUI in UIHostingController; use UIViewRepresentable/UIViewControllerRepresentable to wrap legacy UI.
• Shared contracts: define ViewModel interfaces (Flow/LiveData or Combine/Observable) for state/events so both UIs consume same business logic.

Incremental rollout & feature toggles

• Add runtime feature flags (remote + local) per screen or component to switch implementations.
• Canary releases: user cohort targeting, A/B metrics collection.

Testing & QA

• Unit tests for ViewModels and business logic before UI swap.
• Snapshot tests for pixel regressions (Paparazzi/Shot for Android, iOS snapshot testing).
• E2E tests covering user flows with both old and new UIs (Espresso/XCUITest).
• Performance benchmarks: measure jank, memory, startup with new components.

Performance & safety

• Keep heavy work off the main thread; reuse existing optimizations (lazy lists, image caching).
• Monitor frame drops, allocation rate. Roll back toggle if regressions exceed thresholds.

Rollback & deployment

• Feature flags + kill-switch allow immediate rollback without app update.
• Maintain compatibility layer for telemetry and analytics.
• Gradual ramp with health dashboards (crash-free rate, ANR, CPU/frame metrics).

Collaboration with Designers & QA

• Create design tokens and component spec that both systems implement.
• Designers validate visual parity via storybook-like catalog (Compose Preview/SwiftUI Previews).
• QA test matrix includes old vs new comparisons, spotlighting input, animation, accessibility.

Risks & trade-offs

• Short-term complexity from two UI stacks; mitigate via clear contracts and cleanup plan to remove legacy code after full migration.

This plan enables safe, measurable, incremental migration while preserving performance and providing fast rollback paths.

Requirements & goals

• Fast smooth scrolling, low memory, minimal network, quick appearance of images, cancel wasted work on cell reuse.

High-level architecture

• UI layer (FeedCell) → ImageLoader API → MemoryCache (NSCache) → DiskCache (file store with LRU index) → NetworkFetcher (URLSession with prioritized tasks).
• Worker pool for decoding/downsampling off main thread (OperationQueue/GCD).

Components

• MemoryCache: NSCache keyed by URL+size; stores UIImage. Auto-evicts on memory pressure.
• DiskCache: on-disk files with metadata (lastAccess). LRU eviction by total size (e.g., 100MB).
• NetworkFetcher: URLSession with configurable concurrent ops, exponential backoff, conditional GET (ETag).
• Decoder: background downsampling using CGImageSourceCreateThumbnailAtIndex with max pixel dimension to reduce memory.
• Request Manager: maps requests to in-flight operations, supports deduplication and priorities.

Eviction policy

• Memory: NSCache + count/totalCostLimit (cost = pixels * bytesPerPixel).
• Disk: LRU by lastAccessTime, evict when total > limit.

Cancellation & reuse

• FeedCell calls imageLoader.load(url:size:priority) -> returns CancellableToken.
• On prepareForReuse call token.cancel(). Loader cancels network/decoder op if no remaining subscribers.
• Deduplicate: multiple subscribers share same operation; only cancel when all cancel.

API surface (Swift example)

protocol Cancellable { func cancel() }
final class ImageLoader {
  func load(url: URL, targetSize: CGSize, priority: Int, completion: @escaping (Result<UIImage,Error>)->Void) -> Cancellable
  func prefetch(urls: [URL], targetSize: CGSize)
  func clearMemoryCache()
}

Off-main-thread decoding/downsampling

• Fetch raw Data -> feed to CGImageSource on background queue -> create downsampled CGImage -> UIGraphicsImageRenderer for correct scale -> return UIImage on main thread.
• Use Image I/O to avoid allocating full-size bitmaps.

Measuring & optimizing scrolling

• Metrics: FPS (Core Animation instrument), Main thread CPU, Allocations, Memory growth, network bytes.
• Tools: Instruments (Time Profiler, Core Animation, Allocations), Network profiler.
• Optimizations:
  • Downsample to cell size, avoid extra layout work.
  • Prioritize visible cells, prefetch next N cells.
  • Limit concurrent decoders to avoid CPU spikes.
  • Use progressive loading placeholders and fade-in to mask late images.
  • Batch disk reads and use mmap/efficient IO.
  • Use compressed image formats (WebP/HEIF) if supported.

Trade-offs

• Stronger downsampling reduces quality but improves performance; tune per device.
• Disk TTL vs storage limit: prefer size-based LRU for predictable disk use.

This design balances responsiveness, memory, network efficiency and offers a simple, testable API for feed cells.

Clarify requirements
I’d design a cursor-based API optimized for mobile infinite-scroll: small payloads, low latency, deterministic ordering, and robust handling of dataset changes.

Request parameters

• GET /v1/items
• Query:
  • cursor (string, optional) — opaque server token
  • limit (int, optional) — client requested page size
  • snapshot_id (string, optional) — optional read-consistent snapshot token
    Example: GET /v1/items?cursor=abc&limit=25

Rules

• Server enforces max_limit = 50.
• Default limit = 20.
• Cursors are opaque, time-limited (e.g., 24h) and include last-seen item id + sort key + snapshot metadata (signed).

Sample JSON response

{
  "items": [
    {"id":"i123","title":"A","updated_at":"2026-02-28T10:00:00Z"},
    {"id":"i122","title":"B","updated_at":"2026-02-27T09:00:00Z"}
  ],
  "next_cursor":"eyJpZCI6Iml122Iiwi...signed"},
  "has_more": true,
  "limit": 20
}

Handling expired/invalid cursors

• If cursor expired/invalid -> 400 with code CURSOR_INVALID or CURSOR_EXPIRED and include fallback instructions:
  • Suggest first-page link (cursor omitted) or include a fresh snapshot token.
    Response example:

{"error":"CURSOR_EXPIRED","message":"Cursor expired; retry from start or use snapshot token"}

Mitigating duplicates/missing items

• Stable ordering: order by (primary sort key desc, unique id) to guarantee deterministic tiebreaker.
• Optional snapshot_id: server can provide a snapshot token to read a consistent view for the session; if provided, server serves from that snapshot to avoid missing/duplicated items.
• Server-side tombstones: keep deleted items as tombstones for a TTL so cursors remain valid; they can be skipped client-side but help preserve offsets.
• Client-side dedupe: mobile client should deduplicate by item id when appending pages.
• Idempotent cursors: encode last-seen item id + sort position to resume exactly.

Mobile considerations

• Keep payload small (only necessary fields).
• Preload next page when user nears end.
• Backoff and retry on cursor errors; show lightweight UI refresh if resync required.

This approach balances mobile performance, simplicity, and consistency when the underlying dataset mutates.

Approach overview
Describe client-side throttling as a cooperative layer: limit request rate locally (token/leaky bucket), respect server signals (Retry-After, 429), queue non-urgent work, and surface graceful degradation to users.

Token-bucket vs Leaky-bucket

• Token-bucket: tokens added at rate r, request consumes token; supports bursts up to bucket size. Good for user-initiated actions that can burst (e.g., search).
• Leaky-bucket: fixed outflow rate; smoothes traffic strictly — simpler if you must strictly pace background syncs.

Practical mobile implementation (Kotlin pseudo)

// simple token-bucket
class TokenBucket(val capacity: Int, val refillPerSec: Double) {
  var tokens = capacity.toDouble()
  var last = System.nanoTime()
  fun tryConsume(n:Int=1):Boolean {
    val now = System.nanoTime()
    tokens = min(capacity.toDouble(), tokens + (now-last)/1e9*refillPerSec)
    last = now
    if (tokens >= n) { tokens -= n; return true }
    return false
  }
}

Retry / Backoff

• Honor Retry-After and 429: parse header, schedule retry after suggested delay.
• If missing, use exponential backoff with full jitter to avoid stampedes:
  backoff = random(0, base * 2^attempt)

Queueing & Background Work

• Classify tasks: real-time (UI) vs opportunistic (sync, prefetch).
• Keep a persisted queue (SQLite/Room, file) for background jobs; drain when network unconstrained and tokens available.
• Integrate with OS background constraints (WorkManager / BGTasks).

UX & Graceful Degradation

• Surface minimal, actionable feedback: inline "Try again later" or spinner with countdown when Retry-After known.
• Disable or de-prioritize non-critical features (image prefetch, analytics) under throttling.
• Offer offline fallbacks: show cached content, save actions locally and sync later; show clear status (e.g., "Limited connectivity — background sync paused").

Monitoring & Telemetry

• Log 429s, Retry-After usage, queue length and retry attempts to help tune token rates server-side.

This approach preserves battery/network, avoids server penalties, and keeps users informed while maximizing useful behavior.

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.

Situation & goal
Design an end-to-end program (automated + manual) so regulators can verify location/contacts are accessed only when declared — before every release.

High-level approach

• Prevent: static checks to ensure declarations exist and code doesn’t call APIs anonymously.
• Detect: runtime instrumentation in CI and prod debug builds to record actual API calls and prompts.
• Prove: generate signed audit artifacts (reports, screenshots, logs, SBOM).

Automated CI checks

• Manifest/Info.plist rule: fail if required keys missing or extra keys present.
  • Android: verify AndroidManifest.xml contains only declared uses-permission and rationale strings.
  • iOS: verify Info.plist has NSLocation*UsageDescription and NSContactsUsageDescription matching policy.
• Source-scan: run static analyzer + custom grep/AST rules to flag direct calls to LocationManager, FusedLocationProvider, ContactsContract, CNContactStore, and popular libs. Example CI step: run a Kotlin/Swift AST script that errors on blacklisted API usage outside guarded wrappers.
• Lint rules: add Android Lint and SwiftLint custom checks to enforce use of permission-wrapper functions.

Static analysis & policy enforcement

• Implement single permission-wrapper APIs (e.g., RequestLocation(), RequestContacts()) — require annotation @PermissionGate.
• Static analyzer enforces that only annotated wrappers call OS permission APIs. Use tools:
  • Android: ErrorProne or custom ASM/ktlint plugin.
  • iOS: SourceKit/clang-tidy script to find un-wrapped calls.
• Check that runtime prompt strings equal approved compliance text (regex compare to approved list).

Runtime monitoring (CI + release)

• In CI:
  • Instrumented UI tests (Espresso/XCUITest) that exercise flows and capture prompt screenshots and accessibility labels for consent.
  • Inject debug wrappers that log: timestamp, caller stack, permission type, decision, and purpose tag. Store logs as artifact.
• In release/debug builds:
  • Lightweight telemetry (privacy-preserving, hashed IDs) that records permission grants/uses and purpose tags, with user opt-out. Use local logs for auditable builds.
• Implement method interception:
  • Android: ProGuard rules + wrapper around FusedLocationProvider and ContentResolver; prohibit reflection to bypass.
  • iOS: Use function interposition in debug builds or method swizzling in Obj-C/Swift to log CNContactStore and CLLocationManager accesses.

Manual testing

• QA checklist and flows that must be executed: first-run flows, background access, denied-then-grant, edge OS versions.
• Capture:
  • Screenshots of OS prompts on typical devices (iOS 14/15+, Android 11+).
  • Screen recordings of full flows.
  • Repro steps and device logs (adb logcat / Console) collected into the release folder.

Audit artifact generation

• For each build produce signed bundle with:
  • Permission matrix CSV: declared permissions vs. code-flagged usages vs. runtime-use events.
  • Prompt screenshots and hashes.
  • Instrumented test results and logs (stack traces for each access).
  • Static-analysis report listing files and line numbers for permission API calls.
  • SBOM and third-party libs list.
• Automate packaging and GPG-sign artifact; upload to compliance storage with retention policy.

Verification & metrics

• Gate release by failing CI if:
  • Any runtime log shows permission use without matching declaration/purpose.
  • Static scan finds unwrapped API usage.
  • Prompt strings differ from approved text.
• Track KPIs: number of flagged accesses, time-to-fix, coverage of instrumented flows.

Trade-offs & safeguards

• Minimize runtime overhead by enabling heavy instrumentation only in CI/debug; use sampling/aggregation in production.
• Ensure telemetry is privacy-preserving and regulator-approved.

This combination of enforced wrapper patterns, static/AST checks, CI instrumented tests, runtime interception, curated manual flows, and signed audit artifacts provides determinism and reproducible evidence that location and contacts are only accessed as declared.

Situation & goal
Design a push-driven sync trigger so server tells mobile apps “new data” while avoiding battery drain, background limits and thundering-herd.

High-level strategies

• Interest-based routing: subscribe devices to topics/segments (user, conversation, interest tags). Only notify relevant clients.
• Stagger + jitter: add randomized delay (e.g., 0–30s jitter) per-device or per-topic to avoid simultaneous wake-ups.
• Batching: coalesce rapid events on server into one notification window (e.g., 1–5s buffer); send one trigger for multiple changes.
• Exponential backoff / client-side rate-limits: if app recently synced, ignore additional triggers for a cooldown; server tracks last-sync timestamp per-client and respects minimum interval.

Server-side rate limiting & prioritization

• Prioritize urgent vs informational: assign priority flag; only high-priority sends immediate trigger. Low-priority go to batched queue.
• Global and per-user QPS caps to protect APNs/FCM and backend.
• Backpressure: if backend overloaded, convert non-critical pushes to silent flags to be pulled later.

Platform background limits

• iOS: content-available pushes can be throttled by the OS; don't rely on guaranteed delivery or execution time. Use VoIP/pushkit only when appropriate and allowed.
• Android: data messages may be blocked under Doze/Background restrictions—use high-priority sparingly; prefer WorkManager for guaranteed background work after wake.
• Always design for missed pushes: implement periodic background fetch or resume-on-open full sync.

Payload vs wake-only

• Wake-only (minimal): send no data when server simply needs client to fetch latest; best when payloads large, sensitive, or when you want server-side consistency checks.
• Small payload (delta): embed tiny JSON (version id, changed IDs, lightweight delta) when it reduces round-trips and fits platform limits; ensure payload < 4KB for APNs.
• Never include sensitive data in push; treat pushes as hints only.

Client implementation patterns

• On receiving trigger: check lastSyncTime, apply jitter, decide to full/paged/delta sync.
• Ack/heartbeat: client optionally confirms sync success so server can stop retrying.
• Retry/backoff policy: exponential backoff with random jitter on failed syncs.

Metrics & instrumentation

• Track push delivery, wake callbacks, sync latency, battery impact, and failed/queued notifications to tune jitter, batch windows and rate limits.

This design balances responsiveness with battery and platform constraints by combining targeted routing, jittered delivery, server and client rate-limiting, and choosing payload vs wake-only on a per-priority basis.