Behavioral and system design interview prompts for mid-level engineers

These prompts are written to sound closer to how interviewers actually ask them in live screens and onsite loops. For each one, do more than name a tool or pattern. Explain the decision you made, the trade-offs you considered, and the result you drove.

Behavioral

1. Tell me about a time you disagreed with a teammate or tech lead on an implementation approach. How did you handle it?

A strong answer should cover:

• what decision mattered and why it was worth discussing
• how you aligned on criteria such as risk, effort, performance, or maintainability
• what changed after the conversation and what you learned

2. Tell me about a production issue or incident you were personally involved in resolving.

A strong answer should cover:

• what signals told you something was wrong
• how you communicated status and coordinated with others
• the immediate fix and the longer-term prevention work

3. Describe a time you simplified a system, workflow, or code path that had become too complex.

A strong answer should cover:

• what pain the old design created for engineers or users
• what you removed, merged, or redesigned
• how you verified the change improved things without breaking consumers

System design (mid-level scope)

4. Design a URL shortener for internal company use, not internet scale. What would you ask first, and what would your first version look like?

A strong answer should cover:

• traffic expectations, retention, permissions, and whether links expire
• a simple API and data model before advanced scaling ideas
• how unique codes are generated and what happens on collisions

5. You need to add rate limiting to an existing REST API that already has paying customers. How would you approach it?

A strong answer should cover:

• where rate limiting should live, such as the edge, gateway, or application layer
• the algorithm choice and why it fits the product behavior
• how clients learn they are limited and how you avoid breaking current integrations

6. Search results for job listings are expensive to compute, and the product team wants them cached for five minutes. How would you design that?

A strong answer should cover:

• cache key design and what request attributes belong in the key
• invalidation strategy when jobs are updated or removed
• what stale-data behavior is acceptable and how you would monitor it

7. A monolith endpoint is under heavy load, and the team wants to move it into a separate service without a risky big-bang migration. Walk through your plan.

A strong answer should cover:

• how traffic would be shifted gradually
• whether you need dual writes, backfills, or synchronization during the transition
• rollback strategy if latency, correctness, or cost gets worse

8. Before launching a new checkout flow, what metrics, logs, and alerts would you add?

A strong answer should cover:

• business metrics such as conversion and payment success rate
• technical signals such as latency, error rate, and dependency failures
• how alerts would point responders to meaningful symptoms rather than noisy dashboards

How to use this post

Practice these out loud, not just in your head. For behavioral prompts, use situation → action → result → reflection. For system design prompts, use requirements → constraints → design → trade-offs → rollout. Two clear minutes with specifics will usually outperform a long vague answer.