Delivery and Performance in Technical Interviews

Coaching by Marie Christine Umali (Looi Consulting) across two emails and a 52-minute mock interview. These points are not about the content of your stories — they are about how you come across when it matters. Related: entrevista-pitch-historias · entrevista-metodo-star · entrevista-elevator-pitch

1. Don’t Sound Rehearsed

The goal of your pitch and stories is to create a conversation, not a polished performance.

Memorize the flow: problem → your responsibility → why the approach → outcome.
Don’t memorize every word. If each sentence sounds scripted, the interviewer will naturally interrupt to go deeper.
If interrupted, respond directly — don’t try to get back to the script. The conversation should feel flexible.

Exercise: Write your pitch as bullet points by hand. Writing by hand builds muscle memory and makes the flow more organic than typing.

2. Slow Down

When you talk about architecture, you get enthusiastic — that’s good. But enthusiasm can turn into speed.

Pause occasionally while describing technical decisions.
Give the interviewer time to absorb and space to ask questions.
A slower pace also makes the conversation feel more natural and gives the interviewer the cue for follow-up questions — which are opportunities, not threats.

3. Be Ready to Defend Every Technical Decision

When you mention a technology or approach, you are implicitly inviting questions about it. Prepare the following for each choice:

Why did you choose this?
What alternatives did you consider and reject?
What problems did it solve?
What were the trade-offs?
How did you verify it worked?
What would you do differently today?

Technologies from your stories that require defense: Module Federation, Redis, DataLoader, React.memo, ISR, SSR, Recharts, React Query, JWT/HTTPOnly cookies.

If you genuinely understand the reasoning behind each decision, follow-up questions become opportunities to demonstrate depth, not risks.

4. Calibrate Your Metrics

Specific numbers strengthen your stories — but they also invite scrutiny.

For any metric you cite, be ready to answer:

Where did this number come from?
How was it calculated?
Who measured it?
In what period and context?

Metrics from your stories and their sources:

Metric	Source
36% FCP reduction	New Relic Browser Agent, monitored in staging before release
NPS +19 percentage points	NPS survey sent to brokers by the Product team
2.7× organic conversion	Google Analytics, comparing pre/post periods with controlled organic traffic
< 1.5-second load time	New Relic Browser, validated in staging
#1 organic SEO ranking	Google Search Console

If you’re unsure about a number, describe the improvement honestly rather than overstating precision.

5. Balance Ownership with Collaboration

Your stories should show that you led — without sounding like everything depended solely on you.

Instead of	Say
“I transformed the engineering culture”	“I introduced practices and worked with the team to establish them”
“I fixed the performance problem”	“I led the investigation and collaborated with the backend to resolve it”
“I decided to use Module Federation”	“I proposed the approach and presented the reasoning to the team”

Use ownership language without excluding collaboration: I designed… I investigated… I proposed… I collaborated with… I verified…

6. Don’t Wait for Follow-Up Questions — Anticipate Them

During the mock, initial answers were correct but too high-level. The desired pattern is different:

Instead of: “We used Module Federation.”
Say: “We chose Module Federation because we evaluated three options — a monolith would create deployment bottlenecks, iframes make shared state nearly impossible. Module Federation solves both: it allows runtime code sharing with independent deployments per domain.”

The interviewer should understand your reasoning without needing to ask “why?”.