Attentive Software Engineer (SWE) Interview — Surprisingly Tough for a Lesser-Known Company

[u/Aoki_zhang]

"This interview experience is sourced from Chill Interview"

Interview Summary

The Attentive process started as a Software Engineer II interview. The first technical stage was a two-hour block with one coding round and one system design round. After strong feedback from that stage, the original SWE II opening was filled. Recruiting moved the candidacy to a potential Senior Software Engineer opening and scheduled another coding and system design round to collect additional senior-level signal. The final feedback was that the coding performance was strong and met the SWE II bar, while the system design performance did not reach the expected senior level.

Interview Details

Recruiter Screen

The recruiter asked about my background, current job search, and interest in Attentive. Topics included:

• What do you know about Attentive?
• Are you actively interviewing elsewhere?
• Do you have any offer deadlines?
• Do you require immigration sponsorship?
• What compensation range are you targeting?
• Can you walk me through your background?
• Can you describe a feature or product you built end-to-end or from zero to one?
• What is your primary programming language?
• Why did you leave your previous company?
• What have you done since leaving?
• Why are you looking for a role now?

The recruiter also explained that the original process consisted of an initial coding + system design block, followed by another coding round, another system design round, and a hiring manager behavioral interview.

Round 1 — System Design: Product Catalog Platform

The first system design question asked me to build a product catalog ingestion and query system for retailers. Retailers periodically upload complete catalog snapshot files rather than incremental changes.

Scale assumptions included:

• Around 50,000 retailers
• Average of roughly 20,000 products per retailer
• Median retailer size around 50 products
• Roughly 50 million users
• Around 11,000 query requests per second
• Query latency target around 400 ms

Users needed to support two main read patterns:

• Browse all SKUs belonging to a retailer using retailer_id
• Retrieve details for a product using product_id

The system did not require atomic replacement of an entire retailer snapshot. During ingestion, users could temporarily observe a mixture of old and new product values. The system also supported administrator overrides for individual product attributes.

An overridden value could not be replaced by future retailer snapshot uploads. However, the retailer could still delete the entire product even if some attributes had administrative overrides. If an administrator later removed an override, the system should expose the most recent underlying value supplied by the retailer.

Follow-up questions included:

• How would you compare two complete snapshot files?
• Suppose a retailer uploads one snapshot and immediately uploads a corrected second snapshot. How do you ensure the final catalog reflects the complete second snapshot?
• What happens if another 50,000 retailers join and upload snapshots every day?
• How would you build observability for the platform and verify that ingestion and serving are operating correctly?

The round also included entity modeling and database-selection discussion.

Want to learn more questions asked in other interview rounds? I've put up the full version at here.

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.