ATM Machine — OOD Interview Walkthrough

Phase 1: Requirements & Use Cases

Interviewer: "Design an ATM machine."

Candidate: "Let me restate what I think we're building before touching any classes. An ATM is a self-service terminal that allows a bank customer to insert their card, verify their identity via PIN, and perform financial transactions — withdrawals, deposits, balance inquiries, and transfers — without a human teller. Does that align with your expectations?"

Interviewer: "Yes. Who are the actors?"

Candidate: "I see three actors:

1. Customer — the primary user; inserts card, enters PIN, performs transactions
2. Bank (external system) — validates credentials, authorizes transactions, updates account balances; I'll model this as an interface since we don't own it
3. ATM Technician — refills cash, services hardware; relevant to operational concerns but out of scope for the core class design

For use cases, I want to cover:

1. Insert card — read card data, initiate session
2. Authenticate PIN — validate against bank, lock card after N failed attempts
3. Withdraw cash — verify balance, dispense notes, update account
4. Check balance — retrieve and display account balance
5. Deposit cash/check — accept envelope or notes, credit account
6. Transfer funds — move amount between two accounts
7. Eject card — end session cleanly, return card"

Interviewer: "What about multi-currency support and international cards?"

Candidate: "I'd scope that out of V1. Multi-currency requires exchange rate lookups, foreign bank network routing (Visa/Mastercard interchange), and denomination management per currency — each is a system in its own right. The core OOD challenge here is the state machine, transaction hierarchy, and hardware…