For every project, be ready to answer six things: what problem it solves, how it's architected, why
you made each technical choice, the hardest thing you debugged, what would break at 100x scale, and
what you'd change if you started over.
Scribe — real-time chat (Flask + Socket.io)
- Your resume says "supports up to 5 concurrent users per room." Why that limit? What would
break at 500?Be honest: Python's GIL, single Flask process, in-memory room state. At
500: move to Redis pub/sub for room distribution across servers.
- If I close my laptop mid-conversation and reopen it, what happens to my messages? Do I see
what I missed?MongoDB persistent storage handles history. But: no mechanism for
"unread since disconnect" — explain how you'd add it.
- How would you make Scribe work across multiple servers?Socket.io with Redis adapter —
each server subscribes to a shared Redis pub/sub channel per room
Delivery Hub — logistics platform (Node.js + MySQL)
- Your resume mentions simulating "race conditions" in tests. Give me a concrete example of
one you found and how you fixed it.Two delivery partners accepting the same order
simultaneously — fixed with SELECT FOR UPDATE / optimistic locking
- How does order assignment work? Can two drivers both be assigned the same delivery?If
not handled: yes. Walk through your solution — atomic DB update, first writer
wins
- If Delivery Hub had 100,000 active orders, what's the first thing in your current
architecture that breaks?MySQL without read replicas, no caching on order status
queries, no queue for assignment events
UCC DICOM app — AES-256 encryption (Flask)
- Explain what a timing attack is, like I'm a backend developer who's never done security
work.Attacker measures how long operations take to infer information — e.g., password
comparison that exits early on first mismatch leaks the correct prefix
- Why does every encryption operation use a different IV (initialization vector)? What goes
wrong if you reuse one?Same key + same IV + same message = same ciphertext every time
— patterns become visible to an attacker
- You added "random delays" to prevent timing attacks. But can't an attacker just average out
many measurements?Yes — this is why constant-time operations are the real fix. Random
delay only raises the bar. Acknowledge this trade-off.
Student Portal — PHP + MySQL (1,500+ users)
- 1,500 students hit the attendance page at 9am every day. How does your system handle the
spike?If it doesn't have caching: be honest. Then explain what you'd add: Redis cache
for read-heavy attendance data, 5-minute TTL
- How did you secure the admin dashboard so students can't access faculty data?Walk
through your role-based access control implementation — middleware check on every
protected route