Interview guides · Albertsons companies

Albertsons companies Software Engineer Interview Guide

Albertsons companies Software Engineer interview guide: four reported rounds, Swift, JVM and JavaScript questions, dashboard design and a 7-day plan.

The 60-second brief

Candidates describe Albertsons companies as the grocery group behind banners such as Safeway, Vons and Jewel-Osco. Software engineers build cloud-based systems for its grocery technology, and candidates mention supply chain platforms, the digital shopping experience and reporting dashboards as areas of work. The requirements candidates describe name a major backend language (Java is the one listed first), cite Swift and JavaScript as other core languages, and add SQL for data-heavy roles plus cloud-native development. Retail media, marketing technology and large-scale reporting platforms are listed as a plus. The advice candidates pass on is to be ready to explain why you chose an architecture, not only to write the code.

This guide is for software engineers preparing for the Albertsons companies loop, whether your core language is Java on the backend, Swift on mobile or JavaScript on the web. It covers the four reported rounds, the fifteen reported questions (language fundamentals, system design and architecture, and behavioral), the topics candidates say the loop touches, and a 7-day plan that ends with spoken practice.

Candidates report four rounds over roughly 3-5 weeks: Initial Screening, Technical Sessions, Behavioral Sessions and Final Evaluation. Some describe the process stretching to a couple of months depending on team and level.

Focus areas

Problem Solving (Coding)
System Design
App System / System Flow Knowledge

Overview

Candidates describe the work as building and maintaining cloud-based platforms for grocery retail: supply chain tooling, the digital shopping experience and data-heavy reporting dashboards. The day-to-day they report includes working with product managers, UX designers and other engineers, turning business requirements into technical specifications, taking part in code reviews, and owning a feature from design through deployment. For preparation, that means you should be able to tell the story of one project end to end: what the requirement was, how the design was shaped, how it was tested and shipped, and what you would change.

The reported technical questions split into two groups. The first is language fundamentals drawn from several ecosystems: structs versus classes in Swift, JVM memory management and garbage collection, concurrency with GCD or async-await, the value of immutability, and let, var and const in JavaScript. You do not need all of them at the same depth, so go deep on the ones that match your own stack and keep a short, correct answer for the rest. The second group is design and architecture: the architecture and tech stack of your latest project, a scalable reporting dashboard over large datasets, a significant design trade-off, API reliability and performance across microservices, and the system flow of a product platform you have worked on. Candidates also list data structures (lists, maps, trees), unit testing, SQL versus NoSQL, caching, load balancing and API gateways as areas to be ready for, and they cite scenarios such as processing a large data stream, tracking down memory leaks in a long-running application, real-time data exports and a traffic spike during a major retail event.

Five behavioral questions are reported: why this company, explaining a technical issue to a non-technical stakeholder, disagreeing with a teammate's approach, pivoting on new data or requirements, and mentoring or cross-functional collaboration. Candidates also pass on a few process tips: map out design answers visually, expect deep questions on every project on your resume, ask clarifying questions when a prompt is vague, and keep a note of when feedback was promised so you can ask the recruiter if it is late, since some report inconsistent communication. Build your preparation around one well-rehearsed project dossier that can feed the architecture, system flow, trade-off and behavioral answers at once.

The Albertsons companies interview process

Candidates describe four stages, from a recruiter conversation to a closing assessment. Which question lands in which stage is not reported, and the behavioral questions are reported without naming a round, so prepare each question type for the stage it most plausibly fits.

Initial Screening

This is the recruiter conversation, the opening stage of the loop. Candidates also describe the early rounds as a check of technical baseline and resume claims, so expect to be asked about the projects and stack you list. Treat it as the first outing of your project narrative.

What to demonstrate

Your background and fit for the role as the recruiter reads it from your resume
How clearly you describe the projects and the languages you list (Java, Swift or JavaScript, SQL, cloud-based work)

How to prepare

Write a short walk through your career that ends on the work closest to grocery retail platforms, reporting or data-heavy services, and be ready to defend every technology on the resume.
Prepare a specific answer to why you want to work for Albertsons companies, built on the kind of work candidates describe rather than on generic praise.
Ask the recruiter what the later rounds will cover and when to expect feedback; note the date, because some candidates report inconsistent communication.

Technical Sessions

Start from the reported areas: data structures and algorithms (lists, maps, trees), language fundamentals such as memory management and concurrency in your main language, and unit testing. Reported scenarios include processing a large stream of data efficiently and handling memory leaks in a long-running application. Prepare to code while talking, then show how you would test it.

What to demonstrate

Efficient use of lists, maps and trees in working code
Memory management and concurrency in your primary language (JVM garbage collection, GCD versus async-await, value versus reference semantics)
Writing code that is testable and covered by unit tests

How to prepare

Answer aloud the language questions that match your stack: structs versus classes in Swift, JVM memory and garbage collection, concurrency with GCD or async-await, the case for immutability, and let, var and const in JavaScript.
Solve a few list, map and tree problems in your main language, then write the unit tests for each, including empty input and duplicate keys.
Write out the steps you would take on a memory leak in a long-running service: watch heap growth, take a heap dump, find what retains the objects, fix and re-measure.
Practice a one-pass solution over a large stream that keeps memory bounded, and state its time and space cost.

Behavioral Sessions

Candidates describe interviews focused on cultural fit and collaboration. The areas they list are conflict resolution (how you handle technical disagreements), adaptability under shifting priorities in a large organisation, and customer focus (linking technical work to the end user's experience). Behavioral questions are reported for this loop without a named round, so keep your stories ready for any stage.

What to demonstrate

How you resolve technical disagreements with teammates
How you adapt when priorities or requirements shift
Whether you connect your technical work to the end user and the business

How to prepare

Write one story per reported behavioral question, each with a decision you made yourself and an outcome you can state in numbers or observable results.
Rehearse each story aloud in the first person singular, so your own contribution is clear and not blended into the team's.
Add a customer angle to at least two stories: who used the thing you built and what changed for them.

Final Evaluation

Reported as the last stage, a wrap-up check on fit for the role. Candidates also describe the later rounds as moving into system design and cultural alignment, and for more senior roles they say discussing trade-offs across performance, maintainability and scalability matters most. Reported design scenarios include a reporting platform with real-time data exports and a sudden traffic spike during a major retail event.

What to demonstrate

Overall fit for the role as the closing check
System design reasoning, with trade-offs between performance, maintainability and scalability
Microservices and data topics: service-to-service communication, eventual consistency, SQL versus NoSQL, caching, load balancing and API gateways

How to prepare

Design the scalable reporting dashboard out loud with a diagram: data volume, freshness, pre-aggregated tables, pagination and asynchronous exports.
Prepare the significant trade-off story, naming the options you rejected and the cost you accepted.
Rehearse the reliability answer for microservice APIs: timeouts, retries with backoff, idempotency, circuit breakers, caching and rate limits. Add the cloud-native angle, since cloud-native development is a listed requirement: stateless services behind autoscaling, managed queues and storage, and health and readiness probes for container deployments, tied to the retail traffic-spike scenario.
Prepare questions about the team's current challenges and the impact of the role.

Where candidates lose points

Defining a language concept without its runtime consequence, such as saying a Swift struct is a value type or that the JVM has a garbage collector

For each fundamentals question prepare three layers: the definition, what happens at runtime (copying and reference counting in Swift, generations and heap regions in the JVM, task scheduling in GCD and async-await, hoisting and scope in JavaScript), and one place it changed a decision in your own code.

Walking through your most recent project as a list of tools instead of reasons

For every technology on the architecture slide, say what it solved, which alternative you rejected and why, and what you would change now. The same dossier then serves the tech stack, system flow and trade-off questions.

Answering the reporting dashboard design by drawing charts and ignoring data volume, freshness and export

Clarify who queries what, how large the data is and how fresh it must be. Then separate the reporting store from the transactional database, pre-aggregate common rollups, page results with keyset pagination, and push large or real-time exports through asynchronous jobs.

Reducing microservice API reliability to 'add retries'

Retries without backoff, jitter and idempotency keys multiply load during an outage. Cover timeouts, bounded retries, circuit breakers, rate limiting, caching, contract tests and the metrics (latency percentiles, error rate) that would tell you the API is degrading.

Telling behavioral stories in the plural ('we decided') with no outcome

Use first person singular for your own decisions, name the evidence you used, and finish each story with a measurable result and what you would change. Do it for all five reported questions, not just the motivation one.

Questions & practice

Discuss JVM memory management, including how garbage collection works.

Medium · Technical and Core Concepts

Approach

Map the runtime areas: the heap (young generation of Eden plus two survivor spaces, and the old generation), Metaspace for class metadata in native memory since Java 8 (it replaced PermGen), a stack per thread holding frames and local references, and the code cache for JIT-compiled code.
Explain reachability: the collector traces from GC roots (live thread stack variables, static fields, JNI references), so anything unreachable is garbage, and reference cycles are collected because this is tracing, not reference counting.
Walk the generational cycle: most objects die young, so a minor GC copies surviving Eden objects into a survivor space, promotes them to the old generation after they pass the tenuring threshold, and old-generation collection marks, sweeps and compacts; pauses are stop-the-world for at least part of each cycle.
Compare collectors by trade-off: Serial for small heaps, Parallel for throughput, G1 (the default since JDK 9) for region-based collection with a pause-time goal via -XX:MaxGCPauseMillis, and ZGC or Shenandoah when very low pause times matter more than raw throughput.
Close with leaks and diagnosis: a Java leak is memory that stays reachable (static maps, caches without eviction, listeners never removed, ThreadLocal values on pooled threads); I would read GC logs (-Xlog:gc), take a heap dump (jmap or -XX:+HeapDumpOnOutOfMemoryError) and look at the dominator tree in a tool such as Eclipse MAT.

Follow-up

A long-running service's old generation keeps growing after every full GC: how do you find the cause?
What are soft, weak and phantom references, and when would you use a WeakHashMap?
How do -Xms, -Xmx and a pause-time target change GC behaviour, and how would you choose them for a latency-sensitive API?

How do you handle concurrency using GCD or async-await?

Medium · Technical and Core Concepts

Approach

Start with GCD basics: serial versus concurrent DispatchQueues, the main queue for all UI updates, global queues picked by QoS (.userInteractive, .userInitiated, .utility, .background), and async versus sync, noting that calling sync on the serial queue you are already running on (such as main.sync from the main thread) deadlocks.
Name the GCD coordination tools: DispatchGroup with enter/leave and notify to join parallel work, a custom concurrent queue with .barrier writes for a reader-writer cache (barriers have no effect on global queues), and DispatchSemaphore to cap concurrency.
Move to Swift concurrency: async/await for sequential-looking code, structured concurrency with async let for a fixed number of children and withTaskGroup / withThrowingTaskGroup for a dynamic number, where cancelling the parent cancels its children.
Protect shared state with actors and @MainActor for UI, and mention actor reentrancy: state can change across an await inside an actor method, so I re-check invariants after each suspension point; Sendable checking flags values that cross isolation boundaries unsafely.
Cover bridging and cancellation: wrap completion-handler APIs with withCheckedThrowingContinuation and resume exactly once on every path; cancellation is cooperative, so long loops call Task.checkCancellation() or check Task.isCancelled.

Follow-up

How would you download twenty images in parallel, limit concurrency, and still show them in their original order?
Give an example of an actor reentrancy bug and how you would fix it.
How would you migrate a GCD-based networking layer to async/await without breaking existing callers?

Explain the significance of immutability in modern application development.

Medium · Technical and Core Concepts

Approach

Define it precisely: an immutable object's observable state cannot change after construction; in Java that means private final fields, no setters, defensive copies of mutable inputs and outputs, and a final class or private constructor so subclasses cannot add mutability.
Give the concrete benefits: thread safety without locks (final fields are safely published under the Java Memory Model), stable hashCode so the object is safe as a HashMap key or Set member, free sharing and caching, and simpler reasoning and testing.
Separate shallow from deep immutability: a final field or a Java record can still point at a mutable list; Collections.unmodifiableList is only a read-only view of a list someone else can change, while List.copyOf takes an unmodifiable copy; JavaScript const and Object.freeze are shallow too.
State the cost and its mitigations: every change allocates a new object, which builders, persistent data structures with structural sharing, and a generational GC that cheaply collects short-lived objects all reduce; for hot loops a local mutable buffer is fine if it never escapes.
Tie it to application code: immutable value objects (money, order lines), events in an event log, configuration, request/response DTOs between services, and UI state where frameworks such as React detect changes by comparing references.

Follow-up

How would you make a class immutable when one of its fields is a mutable Date or List passed in by the caller?
Does marking every field final make a class immutable? Give a counterexample.
How do you reconcile immutability with an ORM such as JPA, which expects a no-arg constructor and mutable entities?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Explain the difference between structs and classes in Swift.

Medium · Technical and Core Concepts

Approach

Lead with semantics: a struct is a value type, so assignment and argument passing give an independent copy; a class is a reference type, so two variables can point at one instance with shared identity (checked with ===).
List what only classes have: inheritance, deinitializers, identity, and ARC reference counting. Structs get an automatic memberwise initializer, conform to protocols instead of subclassing, and need the mutating keyword on methods that change stored properties.
Show the let difference: a let struct instance cannot change any of its properties, while a let class reference still allows changing its var properties, because only the reference is constant.
Cover memory and copying honestly: Array, Dictionary and String use copy-on-write, but a custom struct does not get that for free; a struct that holds class references still does ARC retain/release on every copy, and retain cycles (fixed with weak or unowned) only arise with reference types.
State the decision rule: I default to structs for models and value data, which also avoids shared mutable state across threads, and pick a class when I need identity, shared mutable state, inheritance or Objective-C interop.

Follow-up

How would you give your own struct copy-on-write behaviour (for example with isKnownUniquelyReferenced on an internal class buffer)?
What changes when a closure captures self in a class versus in a struct, and when do you need [weak self]?
Why are SwiftUI views structs, and what does that imply about where view state is stored?

Describe the difference between `let`, `var`, and `const` in JavaScript.

Medium · Technical and Core Concepts

Approach

Scope first: var is function-scoped (or global), while let and const are block-scoped, so a var declared inside an if block is visible in the whole enclosing function.
Hoisting and the temporal dead zone: all three are hoisted, but var is initialised to undefined, while let and const stay uninitialised until their declaration line, so reading them earlier throws a ReferenceError (even typeof does).
Redeclaration and globals: var can be redeclared in the same scope; let and const throw a SyntaxError; a top-level var in a classic script becomes a property of globalThis (window), while top-level let and const do not.
const means the binding cannot be reassigned and must be initialised at declaration; the object or array it holds can still be mutated, and Object.freeze only freezes one level deep.
Use the loop example: for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)) prints 3, 3, 3 because every callback shares one binding, while let creates a fresh binding per iteration and prints 0, 1, 2; my default is const, let when a value must be reassigned, and no var.

Follow-up

Why does for (const x of items) work while for (const i = 0; i < n; i++) throws a TypeError?
How would you deep-freeze a nested configuration object, and what does freezing cost?
What does typeof return for an undeclared variable versus a let variable still in its temporal dead zone?

Explain the architecture of your most recent project and the reasoning behind your tech stack selection.

Medium · System Design and Architecture

Approach

Open with the problem and its numbers before any boxes: who uses the system, request volume, data size and the latency or freshness requirement, so every later choice has something to be judged against.
Draw the components and trace one real request through them: client, gateway or load balancer, services, data stores, cache, queues and external integrations, saying which parts I built and which I inherited.
Justify each stack choice with the requirement it served and the alternative I rejected, for example a relational database because the data needed joins and multi-row transactions, or a queue because a slow downstream step could not sit on the request path.
Give one trade-off that hurt and a measured outcome (latency, cost, incident count, delivery time), plus what I would change now and why, which shows judgment rather than a tour of tools.
Prepare for depth on anything I name: if a technology is on my resume or diagram, I should be able to explain how it behaves under failure and why it fit better than the obvious alternative.

Follow-up

Which component would break first at ten times the traffic, and what would you do about it?
If you started this project again today, which stack choice would you change?
How was this system tested, deployed and monitored?

How would you design a scalable reporting dashboard that handles large datasets?

Medium · System Design and Architecture

Approach

Clarify requirements first: number of concurrent users, data volume and growth, freshness needed (near real-time or hourly/daily), fixed tiles versus ad hoc filters, export needs, and whether users may see only their own region or stores.
Keep analytics off the transactional database: feed a columnar warehouse or OLAP store through batch ETL or change data capture, partitioned by date and clustered on the common filter columns, so scans read only the needed partitions and columns.
Pre-aggregate for the dashboard: rollup tables or materialized views at a grain such as day by store by category, refreshed incrementally; tiles read rollups and drill-downs hit finer tables with filters pushed down; approximate distinct counts (HyperLogLog) keep unique-user tiles cheap.
Serve through an API layer with a result cache keyed on the normalised filter set and a TTL matched to the refresh cadence, keyset pagination for tables, query timeouts and row limits; heavy reports and exports run as async jobs that write files to object storage and return a download link.
Name the edge cases: time zone boundaries when bucketing by day, late-arriving data that forces reprocessing of recent partitions, tiles computed from different refresh snapshots disagreeing, and access control enforced on the server, not in the UI.

Follow-up

A user requests an export of fifty million rows: how does the system handle it without hurting other users?
How would you change the design if the dashboard had to reflect sales within seconds?
How do you keep all tiles consistent while the rollups are being rebuilt?

Describe a situation where you had to make a significant trade-off in a system design.

Medium · System Design and Architecture

Approach

Pick a real decision with two workable options and a binding constraint (deadline, latency target, cost, team skills), and say it in the first few sentences so the listener knows what was at stake.
Name the axes explicitly: for example consistency versus availability, synchronous versus queued processing, normalised versus denormalised storage, cache freshness versus database load, or build versus buy, with rough numbers for each option.
Say what I gave up and how I contained the downside, such as accepting eventual consistency and adding a reconciliation job and idempotent consumers, or accepting stale cache reads with a short TTL and explicit invalidation on writes.
Close with the measured result and the condition that would make me revisit it (traffic level, new requirement, cost threshold), which shows the trade-off was deliberate.
Avoid the common failure: a story where one option was obviously better is not a trade-off; there must be a cost I chose to pay.

Follow-up

What evidence would make you reverse that decision today?
How did you get teammates or stakeholders to agree with the option you chose?
What did you monitor afterwards to confirm the trade-off was paying off?

How do you ensure API reliability and performance in a microservices environment?

Medium · System Design and Architecture

Approach

Define reliability as numbers first: per-endpoint SLOs for availability and p99 latency, measured with request rate, error and duration metrics, distributed tracing (for example OpenTelemetry) and a correlation id propagated on every hop.
Harden every outbound call: a timeout shorter than the caller's own budget, retries with exponential backoff and jitter only for idempotent operations or with idempotency keys, circuit breakers (for example Resilience4j in Java), bulkheads via separate connection pools, and a defined fallback.
Watch for retry amplification: if each of three layers retries three times, one user request can become up to 4 x 4 x 4 = 64 calls at the bottom, so I retry at one layer and cap total attempts.
Protect capacity on the server side: rate limiting (token bucket) at the gateway, load shedding when queues grow, autoscaling behind a load balancer with separate readiness and liveness checks, connection pooling, cache-aside for hot reads, and queues for slow work.
Cut latency and release risk: replace long synchronous call chains with parallel fan-out or an aggregating backend-for-frontend, batch N+1 calls, paginate and compress payloads; ship with contract tests, backward-compatible versioning, canary rollouts, feature flags and fast rollback.

Follow-up

How would you prepare these APIs for a sudden traffic spike during a large sales event?
How would you make an order-creation endpoint safe to retry?
p99 latency on one endpoint doubled after a deploy while p50 stayed flat: how do you find which service caused it?

Walk me through the system flow of a product platform you have worked on.

Medium · System Design and Architecture

Approach

Choose one user journey and trace it end to end rather than listing services, for example an order from cart to confirmation: client, CDN or gateway, authentication, the owning service, its database and cache, then the events that downstream consumers react to.
For each hop say whether it is synchronous or asynchronous, which service owns the data, and what happens on failure: retry, compensating action in a saga, or a dead-letter queue with an alert.
Explain how consistency is kept across services: the single source of truth for each entity, how other services learn about changes (events, ideally written with a transactional outbox), and why consumers are idempotent.
Attach numbers and ownership: traffic levels, latency at the slow hop, where the bottleneck sits, and exactly which part of the flow I designed, built or operated.
Prepare the edge cases for that flow: duplicate submissions, partial failure after payment, overselling limited stock, and a downstream consumer that falls behind.

Follow-up

What happens to this flow if the message broker is unavailable for ten minutes?
Where is the bottleneck in this flow today, and how would you remove it?
How would you add a new step, such as a fraud check, without slowing the main path?

p99 jumped on one listing filter while p50 stayed flat

Medium · query planning · composite index · percentiles

After a release that added an owner_user_id filter to the resource listing, p99 rose from 90 ms to 1.9 s while p50 stayed at 40 ms. Traffic and row counts are unchanged. resource carries the index (tenant_id, status, updated_at DESC, resource_id DESC). The new query filters tenant_id and owner_user_id, orders by updated_at DESC, resource_id DESC, and takes 20 rows. On PostgreSQL, explain the shape of the regression, prove it from a query plan, and give the index you would add.

Approach

Start from the shape. A flat p50 with a moved p99 means a subset of requests changed cost, not all of them, so the first job is naming the subset. Bucket the endpoint's latency by the tenant's row count; the natural hypothesis is that large tenants are a small share of requests and all of the tail.
Get the plan for the new query on a large tenant with EXPLAIN (ANALYZE, BUFFERS). Expect an index scan over the tenant's range, a filter discarding most of it, then a Sort feeding the Limit, possibly reporting Sort Method: external merge Disk. Read actual rows on the scan node, not estimated.
Explain why the existing index cannot serve it. A composite B-tree is seekable only as a left prefix, and with no equality predicate on status the scan cannot treat updated_at as an ordering, because rows in the tenant's range are ordered by status first. Everything matching must be read and sorted before LIMIT 20 can apply, so a tenant with 400,000 rows pays 400,000 rows to return 20.
Add (tenant_id, owner_user_id, updated_at DESC, resource_id DESC). Equality on the first two columns leaves the index ordered by updated_at within that pair, so the plan becomes an index scan that stops after 20 rows with no Sort node. PostgreSQL can scan a B-tree backwards, so the DESC markers matter only if the two sort columns ever disagree in direction; keeping them explicit documents the order the keyset cursor depends on.

Follow-up

The endpoint paginates with OFFSET. What does page 500 cost with your index, and what does the keyset version cost?
How would you have caught this before release, given that a 10,000-row seed database produces the same plan shape at an unnoticeable cost?

Suggested practice checklist

The plan follows the reported loop: language fundamentals and coding first, then reporting and microservice design, then your project narrative, then spoken behavioral practice. Each day ends with something you can produce and reread.

Day 1 — Map the loop and choose your stack

Write the four reported rounds (Initial Screening, Technical Sessions, Behavioral Sessions, Final Evaluation) and mark the one you are least ready for.
Decide which language fundamentals questions match your stack (Swift, JVM, JavaScript) and list the ones you will only skim.
Collect the projects on your resume that you could defend in depth and pick the main one for the architecture and system flow questions.

Deliverable: A one-page loop map, a list of the fundamentals questions you will answer in depth, and the name of your main project.

Day 2 — Language fundamentals out loud

Write a half-page answer for each fundamentals question on your stack: structs versus classes in Swift, JVM memory management and garbage collection, GCD versus async-await, immutability, and let, var and const.
For each answer add the runtime consequence and one real example from code you have written.
Say each answer aloud once and trim anything you could not defend if asked a follow-up.

Deliverable: Written and spoken answers for the fundamentals questions that match your stack.

Day 3 — Data structures, unit tests and memory behavior

Implement a hash-map-plus-linked-list cache, a tree traversal and a one-pass aggregation over a large stream in your main language, with stated time and space complexity.
Write unit tests for each, covering empty input, duplicates and boundary values.
Write a memory-leak checklist for a long-running service: heap growth, heap dump, retaining references, fix, re-measure.

Deliverable: Three solutions with unit tests and a one-page leak-triage checklist.

Day 4 — Reporting dashboard over large datasets

Design the scalable reporting dashboard on a whiteboard or diagram tool: sources, reporting store, pre-aggregation, API, caching and asynchronous exports.
Write a SQL versus NoSQL choice for each store in that design, such as a relational store for orders and a columnar store for reporting rollups, with the query pattern that justifies each.
Write two sentences on how the design changes if exports must be real-time.

Deliverable: A dashboard design diagram with data-volume and freshness assumptions, a store-by-store SQL versus NoSQL rationale, plus a keyset-paging query.

Day 5 — Microservice reliability and performance

Write an answer on keeping APIs reliable and fast across microservices: timeouts, retries with backoff and idempotency, circuit breakers, caching, rate limiting, observability.
Add the spike scenario: how the design behaves in a sudden traffic surge during a major retail event.

Deliverable: A one-page reliability checklist and a written diagnostic sequence for a latency regression.

Day 6 — Project architecture and trade-off story

Draw your main project's architecture and system flow, then explain the reason behind each technology choice.
Write the trade-off story: the options, what you chose, what it cost and what you would change.
Say both aloud, keeping each to a clear beginning, middle and end.

Deliverable: An architecture diagram, a system flow walk-through and a written trade-off story.

Day 7 — Behavioral stories and full mock

Write and rehearse one story for each reported behavioral question, each with a personal decision and a result.
Prepare a specific answer to why you want to work for Albertsons companies.
Run a full spoken mock: a language question, the dashboard design, the trade-off story and two behavioral stories, then list questions to ask the team.

Deliverable: Five rehearsed stories, a company-specific motivation answer and a list of questions for the team.

Behavioral stories for the Albertsons companies loop

Candidates describe the behavioral sessions as covering conflict resolution, adaptability and customer focus. For this role, expect to show how you work with product managers, UX designers and other engineers, how you explain trade-offs to non-technical stakeholders, and how you connect your work to the person using the product. Each story should carry a decision you made and a result.

Tell me about a time you identified a flaw in a design and put forward a better solution.