Free lesson · AWS for System Design Interviews

Why naming AWS services in a system design interview is a trap

Easy8 min readawssystem-designinterview-preparation

The Sentence That Costs You

"For the data layer I'd use DynamoDB."

Six words. It might be the correct choice. And it has told the interviewer almost nothing about whether you should be hired.

Important: A service name compresses a chain of reasoning into a brand, and the interviewer is being asked to evaluate the reasoning - which you just deleted.

The problem is not that the answer is wrong. It is that the same six words are produced by four very different candidates:

• Someone who analysed the access patterns and concluded a partitioned key-value store fits
• Someone who read that DynamoDB is used for high-scale systems
• Someone whose last team used it, so it is the default
• Someone who memorised a mapping from problem types to service names

The interviewer cannot distinguish between them from the sentence alone, so they must spend the next several minutes probing to find out. That probing time comes out of your interview, and it starts from a position where you have given them a reason to doubt.

What The Interviewer Is Actually Assessing

Not which services you know. Service catalogues are searchable and every candidate has access to the same documentation.

What is being assessed is whether you can take an ambiguous problem, extract the properties the solution must have, and reason to a design - because that is the job, and it does not change when the service catalogue does.

graph LR
    P[Problem] --> R[**Requirements**<br/>extracted]
    R --> PR[**Properties needed**<br/>access pattern, consistency,<br/>scale, latency]
    PR --> PRIM[**Primitive**<br/>that provides them]
    PRIM --> S[Service<br/>implementing it]
    P -.->|**What a service<br/>name skips**| S

This diagram shows the reasoning chain in a system design answer. A problem leads to extracted requirements, which lead to the properties the solution must have - access pattern, consistency, scale, and latency. Those properties identify the primitive that provides them, and only then the service implementing that primitive. Naming a service directly from the problem skips every step in between, which is exactly the reasoning being assessed.

Everything of value is in the middle of that chain. The service at the end is a lookup.

Silent Inheritance

The second cost, and the one that produces the worst moments in an interview.

When you name a service you inherit every one of its properties, and you become accountable for all of them - whether or not you knew what they were.

You said DynamoDB. You have now committed to:

Warning: Naming a service invites exactly the follow-ups you are least prepared for, and it invites them immediately.

A candidate who described the requirement - "I need a key-value store partitioned by user ID with predictable read latency" - has framed the conversation around what they understand.

A candidate who named DynamoDB has framed it around what DynamoDB does, which is a much larger surface, most of it not chosen deliberately.

You are answering for properties you did not select.

The Fix Is One Sentence Longer

Describe the primitive, then name the service as an implementation of it.

Tip: The pattern is: requirement, property, primitive, then the service as an aside. It costs about fifteen seconds and it changes what the interviewer learns entirely.

Three things happen when you answer this way.

The reasoning is visible, so the interviewer does not need to probe for it. That time goes to the interesting parts of the design instead.

You control the surface. You committed to the properties you named, not to everything the service does. If a follow-up goes somewhere you did not intend, you can return to the requirement.

You demonstrate that the service is substitutable, which is the actual senior signal. Saying "DynamoDB, or Cassandra" shows you chose a category and then an instance - and it works at a company that runs neither.

The Portability Problem

A large share of the companies you will interview with do not run on AWS, and some are architecturally hostile to it.

Google, Meta, Netflix in significant part, and most large financial institutions run substantial internal infrastructure. An answer expressed entirely in AWS service names lands badly there - not because the interviewer is dismissive of AWS, but because the answer is in a vocabulary they do not use, and it suggests you may not have the concept underneath.

The neutral formulation works everywhere. "A partitioned key-value store with tunable consistency" is understood at every company on earth. "DynamoDB" is understood everywhere and speaks to a subset.

Important: Speaking in primitives is not a compromise you make for non-AWS interviews. It is the stronger answer in every interview, including AWS-heavy ones.

An interviewer at an AWS-native company hearing "I need a partitioned key-value store - DynamoDB here" learns two things: that you understand the category, and that you know the service. They only learn the second from "I'd use DynamoDB."

There is no interview in which the neutral formulation is worse.

The Exception Worth Naming

Sometimes the service is the answer, and refusing to name it is its own failure.

When the interviewer asks directly - "how would you implement this on AWS?" - answer directly. Retreating into primitives when a specific answer was requested reads as evasion.

When the question is explicitly about a managed service's behaviour, the service name is the subject.

When you are asked to optimise cost or operational burden, specifics are the point - the answer depends on actual pricing models and actual managed capabilities.

Module 01 Topic 4 covers reading which situation you are in. The default is primitive-first; the exception is when specificity was requested.

The Interviewer's Position

Worth understanding, because it explains why the penalty is harsher than it feels.

An interviewer has roughly forty-five minutes to produce a hire or no-hire recommendation they will have to defend to other people. They are not looking for reasons to reject; they are looking for evidence they can point to.

Evidence comes from reasoning made visible. A candidate who says "strong consistency here would cost latency on every read, and the actual requirement is that the user sees their own write, so I'll route their reads to the primary for a short window" has handed over a piece of defensible evidence. It can be written down and cited.

A service name produces no evidence. There is nothing to write in the feedback except that the candidate named a reasonable service, which is not a signal.

Important: The consequence is asymmetric and it is worth internalising: an answer that could have been produced without understanding is scored as though it was.

Not because interviewers are uncharitable, but because they cannot write down a conclusion they cannot support. "They said DynamoDB and it was the right choice" is not defensible evidence of depth - the interviewer knows it might have been a lookup, and so does everyone reading the feedback.

You are not being marked on whether your answer is correct. You are being marked on whether your correctness is demonstrably yours. Those diverge exactly where service names substitute for reasoning, which is why this specific habit costs more than its apparent size.

What This Looks Like Under Pressure

The failure mode is not ignorance. It is speed.

Under time pressure, with an interviewer waiting, the service name arrives faster than the reasoning - it is retrieved rather than derived. That is why strong engineers with real experience still do this.

Tip: The countermeasure is a habit, not knowledge: never let a service name be the first noun in a design decision.

Practise it out loud. When you catch yourself starting a sentence with a service name, stop and restart with the requirement. The rehearsal matters - under interview pressure you produce whatever you have practised, and if you have practised naming services that is what will arrive.

A useful self-check while preparing: give your entire answer without naming a single product. If you cannot, you do not yet have the concept - you have the mapping. That is exactly the gap the interview is designed to find.

Common Failure Modes

Warning: Service named before the requirement is stated. The reasoning is deleted.

Inheriting properties you did not choose. Accountable for all of them.

Unable to give the answer without product names. Mapping, not concept.

AWS vocabulary at a company that runs its own infrastructure.

Retreating into primitives when specifics were requested. Reads as evasion.

"I'd use X because it scales." Everything scales; this says nothing.

Naming a service whose guarantees you cannot state.

Treating the service list as the preparation. It is the smallest part.

No alternative offered. Suggests a default rather than a decision.

Practising with product names. You will produce them under pressure.

Why This Matters In An Interview

Interview: This topic is the interview skill, so the whole thing applies. The specific behaviours that separate strong candidates:

• Requirement, property, primitive, then the service as an aside.
• Offering an alternative in the same breath, which proves the choice was made.
• Being able to state what the named service guarantees before being asked.
• Answering specifically when specifics are requested.

Common follow-ups:

• "Why DynamoDB and not a relational database?" → Because the access patterns are all single-entity lookups by a known key with no joins, and the scale requires horizontal partitioning. If cross-entity querying were needed, that answer changes.
• "What if you could not use AWS?" → The design does not change. It is a partitioned key-value store; Cassandra, Bigtable, or a sharded relational layer all provide it, with different operational costs.
• "You said DynamoDB. What is your partition key?" → Have this ready. Naming the service invited it, and not having the answer is worse than never having named the service.
• "Walk me through the design without naming any product." → An increasingly common instruction, and it is a direct test of whether the concept exists underneath.

Practice

Exercise: Starter. Take a design you can already give and deliver it aloud without naming a single product. Note every point where you stall.

Intermediate. For each service you would name in a typical answer, write the one-sentence requirement that justifies it and one alternative implementation.

Advanced. Have someone interrupt each service name you use with "why that one, and what does it guarantee?" The ones you cannot answer are the ones to stop using.

Related Topics

• Topic 2 - The primitive behind each managed service
• Topic 3 - The service-to-primitive map
• Topic 4 - When specificity is expected
• Module 04 Topic 1 - The answers that lose loops

Back to AWS for System Design Interviews