Common Mistakes

Patterns that hurt candidates

Frequent mistakes: jumping into a diagram or code before agreeing on scope; designing for imaginary scale (sharding a system that fits on one machine); naming technologies instead of explaining why ("use Kafka" with no reason); ignoring the interviewer's hints; spending the whole round on one component; in LLD, creating a single god class, overusing inheritance where composition fits, or forcing design patterns in for show; and never mentioning failure, concurrency or edge cases. Silence is also costly: interviewers can only credit reasoning they hear.

Weak versus strong phrasing

How to justify a choice.

weak:   "We will use Cassandra."
strong: "Writes dominate (assumed ~10x reads), access is by user id,
         and we can accept eventual consistency for this feed, so a
         wide-column store partitioned by user id fits. If we needed
         multi-row transactions I would choose a relational store."

weak:   class ParkingLot { ...40 methods... }
strong: ParkingLot -> Floors -> Spots; pricing in a separate
        PricingStrategy; ticketing in TicketService

Check in at milestones

After requirements and after the first diagram, ask whether the interviewer wants you to go deeper anywhere. It keeps you aligned with what they score.

Quick check: Which is a common LLD mistake?

• Mentioning thread safety
• Separating pricing into its own strategy
• Asking about requirements
• Putting most logic in one large god class