Johnson & Johnson · Primly Community

Johnson & Johnson senior / L5 system design interview: what they actually care about

remote_swe_42 · 5 replies

went through j&j's senior swe loop for a role in their technology services group (not medtech digital, different org internally). the system design round was what i prepped hardest for so i'll be specific.

format: 45 minutes, two interviewers, one was the hiring manager. whiteboard-style but done over zoom with a shared doc/miro board. they didn't care which tool you used to sketch, just that you were clear.

the prompt i got: design a system that ingests patient device readings in near-real-time, flags anomalies, and makes the data available to clinical dashboard users. they gave me roughly the scale: thousands of devices, not millions. throughput wasn't the hard problem, reliability and correctness were.

that context matters a lot. j&j operates in a domain where a dropped message or a stale read isn't just a latency spike, it could have downstream consequences. so the discussion naturally went to: exactly-once delivery guarantees vs. at-least-once and how you'd handle duplicates audit trail: every write and state change needs to be traceable. i talked through event sourcing lightly and they engaged with it. rollback and versioning. if a bad firmware update changes how readings are calculated, can you re-process historical data? this was a 15 min tangent and i think it went well. api design for the dashboard layer: they asked about caching strategies and what happens if a clinician's dashboard shows data that's 3 minutes stale.

what they did NOT drill on: sharding strategy at massive scale, caching layers for millions of concurrent users, cdn stuff. this isn't a consumer internet problem. if you come in with a google-scale architecture for a 10k-device network they'll probably find it weird.

my prep: i focused on distributed systems reliability, not throughput. read through event sourcing and cqrs patterns. the 'designing data-intensive applications' book (ddia) maps pretty well to what they care about.

leveling: they were clear it was a senior / roughly l5-equivalent role. they expected me to drive the design without prompts. i had to push back on one of their hypotheticals and defend my tradeoff. i think that helped.

total time from system design round to offer: 3 more weeks. the debrief process took longer than the actual interview.

5 replies

infra_ines

the exactly-once vs at-least-once framing in a healthcare context is actually a great angle. most candidates default to 'just use kafka' without thinking through what idempotency means when the entity is a patient record. sounds like they want engineers who've thought past the happy path.

remote_swe_42

exactly. they weren't testing kafka knowledge specifically. they were testing whether you understand the tradeoffs when the cost of an error is high. kafka came up but only in the context of: 'ok and what guarantees does that actually give you at the consumer side'.

mobile_mara

this is genuinely useful. i've done three big-tech-style system design preps that are all 'design twitter' scale. sounds like j&j needs a different mental model. saving this.

growth_gabe

did they ask you specifically about fda 21 cfr compliance or was it more general reliability/audit trail stuff? wondering how deep the domain knowledge expectations go.

remote_swe_42

no specific regulatory framework references came up. it was all framed as 'here's the business constraint' not 'cite the regulation'. you don't need to know 21 cfr part 11 but understanding why auditability matters in healthcare is important context.