Ace the Microservice Performance Question at Marriott Tech

Ace the Microservice Performance Question at Marriott Tech | DevMentor

If you're preparing for the Marriott Tech Accelerator program, there's a behavioral question that comes up again and again: "Tell me about a time you improved the performance of a high-traffic microservice." This isn't just a war story question. The interviewer is checking if you can diagnose problems systematically, make data-driven decisions, and communicate impact clearly. Let's walk through exactly how to nail it.

What the Interviewer Is Really Testing#

Here's the thing most people miss — this question isn't about what you optimized. It's about how you think. When I've sat on the interviewer side of this conversation, I'm listening for four things:

Ownership: Did you proactively identify the problem, or did someone hand it to you?
Analytical rigor: Did you instrument, measure, and profile — or did you just guess?
Technical depth: Can you explain why the solution worked, not just what you did?
Business awareness: Do you connect latency/throughput improvements to real user or revenue impact?

A strong answer sounds like an engineer who's been in production, got their hands dirty, and can teach someone else from the experience. A weak answer sounds like someone who Googled "caching strategies" the night before.

The STAR Framework — Done Right#

STAR stands for Situation, Task, Action, Result. Most candidates know this. But most candidates also spend 70% of their time on Situation and Task, and rush through Action and Result — which is exactly backwards. The interviewer wants to live in the Action with you.

Here's the split I recommend:

Section	Time Allocation	What to Emphasize
Situation	10-15%	Context only — keep it tight
Task	10%	Your specific role and ownership
Action	55-60%	Technical decisions, tradeoffs, iterations
Result	20%	Metrics, business impact, lessons learned

Situation: Set the Scene Fast#

Don't over-explain. Give the interviewer just enough to understand the stakes.

"We had a reservation lookup service handling about 12,000 requests per minute during peak hotel booking windows. Response times had crept up to 800ms p95, and our SLA was 200ms."

That's it. Four seconds. They know the scale, they know the problem, and they know there was urgency. Move on.

Task: Claim Your Ownership#

Be specific about your role. Don't say "we" for things you personally did — own it.

"I was the lead engineer on the reliability squad. My task was to diagnose the root cause and bring p95 latency back under 200ms without a full rewrite, since we had a product freeze coming up."

The constraint at the end (no full rewrite, product freeze) shows real-world thinking. Interviewers love constraints — they make your solution more impressive.

Action: This Is Where You Win or Lose#

This is the meat of your answer. Walk through your diagnostic process before your solution. Most candidates jump straight to the fix — that's a red flag. The interviewer wants to see that you measured before you cut.

Here's an example structure for the Action section:

Step 1 — Instrument and profile

"First, I pulled flame graphs from our production tracing tool — we used Jaeger — and found that 60% of our request time was being spent in a single database query. It was a JOIN across three tables with no index on the foreign key used in the WHERE clause."

Step 2 — Validate the hypothesis

"Before touching anything, I ran EXPLAIN ANALYZE on the query in a staging environment with production-mirrored data. Confirmed a full table scan on 4 million rows every single time."

Step 3 — Implement and measure iteratively

Here's where you can show some code. Even in a behavioral interview, walking through a snippet shows technical credibility.

sql

-- Before: No index, full table scan on every request
SELECT r.id, r.guest_id, r.check_in, r.check_out, h.name
FROM reservations r
JOIN hotels h ON r.hotel_id = h.id
JOIN loyalty_profiles lp ON lp.guest_id = r.guest_id
WHERE r.hotel_id = $1
  AND r.check_in >= NOW()
ORDER BY r.check_in ASC
LIMIT 50;
 
-- After: Composite index on (hotel_id, check_in)

"Adding the partial composite index dropped query time from 420ms average down to 8ms. But here's where it gets interesting — that only solved half the problem."

That cliffhanger keeps the interviewer engaged. Continue:

"Profiling again showed we were still making redundant calls to the loyalty service — a downstream microservice — on every request, even for guests who hadn't updated their profile in weeks. So I introduced a short-lived Redis cache with a 5-minute TTL on loyalty profile reads."

python

import redis
import json
from functools import wraps
 
redis_client = redis.Redis(host='loyalty-cache', port=6379, decode_responses=True)
 
def cache_loyalty_profile(ttl_seconds=300):
    def decorator(func):
        @wraps(func)
        def wrapper(guest_id: str):
            cache_key = f"loyalty:profile:{guest_id}"
            cached = redis_client.get(cache_key)

"We chose 5 minutes because loyalty tier changes are low-frequency — a guest isn't going to become a Platinum member mid-session. The cache hit rate settled at about 94% within the first hour of deployment."

Notice how you explained why 5 minutes — the interviewer will absolutely probe your TTL choice. Get ahead of it.

Result: Make It Concrete#

"Two days after the full rollout, p95 latency dropped from 800ms to 140ms — well under our 200ms SLA. Error rates tied to timeout downstream failures went from 0.8% to under 0.05%. We estimated this contributed to a 3% improvement in booking completion rate during peak windows, which the product team flagged as meaningful given the transaction volume we were handling."

Numbers, numbers, numbers. If you don't have exact numbers from your experience, use ranges. "Roughly 4-5x improvement" is fine. "It got a lot faster" is not.

Where Candidates Get Stuck#

Vague metrics: Saying "it improved performance significantly" without numbers is the fastest way to lose credibility. If you honestly don't know the exact metrics, say "approximately" — but always give a number.
Skipping the diagnosis step: Jumping straight to "so I added a cache" makes it sound like you guessed. Always show your measurement process first.
No tradeoffs discussed: Every engineering decision has a tradeoff. Caching introduces staleness. Indexes slow down writes. If you don't mention tradeoffs, the interviewer thinks you didn't consider them.
Saying "we" for everything: In a behavioral interview, own what you did. "We decided" is fine for group consensus, but "I proposed," "I profiled," "I deployed" shows individual contribution.
Choosing a trivial example: Optimizing a script that ran once a week is not a high-traffic microservice story. Match the scale to the question.

How to Talk Through This in an Interview#

Here's example phrasing you can borrow and adapt:

"I'd like to share a situation from my time at [Company], where I worked on a reservation lookup service handling significant peak traffic. Before I dive in, is it okay if I spend a moment on the diagnostic process — I think that's the most interesting part of the story?"

Asking that question does two things: it signals you're a structured thinker, and it gets the interviewer nodding in agreement before you've said anything technical.

When transitioning between STAR sections, use signposting:

"So that was the situation — let me tell you what my specific role was..."
"The action I took was actually a two-phase approach..."
"In terms of results, we measured three things..."

Signposting helps the interviewer follow you and signals that you're organized under pressure.

Follow-Up Questions to Prepare For#

The interviewer will almost certainly ask at least one of these. Prepare your answers now:

"Why did you choose Redis over Memcached?" — Be ready to compare: Redis gives you richer data types and persistence options; Memcached is simpler and slightly faster for pure key-value. For a loyalty profile (which is a JSON object), Redis made sense.
"What happened if the cache went down?" — Talk about your fallback strategy. "We had a circuit breaker that fell back to direct service calls, with an alert threshold if fallback rate exceeded 5%."
"How did you handle cache invalidation?" — This is a famous hard problem. If TTL-based eviction was sufficient for your use case, explain why. If you needed event-driven invalidation, describe it.
"Would you do anything differently?" — Always have a "what I'd improve" answer ready. It shows growth mindset. Maybe you'd add a warm-up strategy for cold starts, or a two-tier cache.
"How did you communicate the change to the team?" — For Marriott specifically, collaboration signals matter. Talk about your PR review process, staging rollout, and monitoring dashboard you set up.

Red Flags to Avoid#

Blaming the previous engineer: Even if the original code was terrible, don't throw someone under the bus. Focus on what you improved, not who created the problem.
No mention of testing or validation: If you don't say "I tested this in staging first" or "I did a canary deployment," the interviewer wonders if you just YOLO'd to production.
Overcomplicating the solution: If you added Kafka, rewrote in Rust, and introduced a service mesh to fix a missing index — that's a red flag for over-engineering instincts. The best engineers solve problems at the appropriate level of complexity.
Forgetting the user impact: Always connect technical improvement back to the user or business. Faster APIs mean fewer abandons, lower cloud costs, better SLA compliance. Make the interviewer feel the impact.

Tailoring This for Marriott Tech Accelerator#

Marriott's tech teams operate at genuine hospitality scale — they're processing millions of reservations, managing loyalty data for 170+ million Bonvoy members, and running integrations across thousands of properties. When you tell your story, lean into:

Reliability under load: Peak booking windows (holiday travel, event seasons) resonate because Marriott has the same challenge.
Data sensitivity: If your example involved user profile or payment-adjacent data, mention your awareness of data hygiene in caches (no caching PII carelessly).
Cross-team collaboration: Marriott's accelerator values candidates who can work across platform, product, and operations teams. Mention how you coordinated your rollout or got buy-in.

Key Takeaways#

Lead with measurement, not solution — Show that you diagnose before you fix. Profiling and instrumentation are signals of seniority.
Spend 55-60% of your time in the Action section — That's where you differentiate yourself from every other candidate.
Always have numbers — Exact or approximate, quantified results are non-negotiable in a strong STAR answer.
Prepare for the TTL / invalidation / fallback follow-ups — They're coming. Having crisp answers shows you've actually lived this problem.
Connect to business impact — "We hit our SLA" is good. "We hit our SLA, which product estimated contributed to a 3% lift in conversion" is great.
Practice out loud — This story should take 3-4 minutes at a natural pace. Time yourself. Most people talk for 90 seconds or 7 minutes. Neither is right.

You've got a great story in you. The goal is to tell it like an engineer who owns their work, learns from it, and can do it again at Marriott's scale. Go get it.