My Elevator Pitch and STAR Stories

Based on real experiences at Seguralta, WeFit/Porto Seguro, and Zarp. Refined with coaching from Marie Christine Umali (Looi Consulting) and Augusto Bretas. References: entrevista-metodo-star · entrevista-elevator-pitch · entrevista-historias-chave

Elevator Pitch (~60–90 seconds)

Three questions to answer before the interviewer asks:

1. Can this person communicate clearly?
2. Does their experience align with our problems?
3. Can I trust them to own complex work?

Present — Who I am today:

“I’m a Senior Front-End Engineer with over 20 years of software engineering experience. For the last seven years, I’ve specialized in building enterprise React, Next.js, and TypeScript applications — with a strong focus on micro-frontend architectures, production performance, and scalable front-end systems.”

Relevant — Two projects that prove it:

"At Seguralta, I architected from scratch the core management platform for Brazil’s largest insurance brokerage franchise. I designed a micro-frontend solution using Module Federation, leading a team of six junior developers to deliver independent features across domains — with complex dashboards loading in under 1.5 seconds.

At WeFit / Porto Seguro, I was the technical lead for a 12-person squad. I investigated and resolved a critical performance issue — pages were taking over 8 seconds to load — cutting First Contentful Paint by 36% while also restructuring engineering standards and bringing QA into the sprint cycle."

Closing — invite the conversation:

“That’s why I’m here — it’s the kind of problem I solve and the environment where I do my best work. If you’d like to dive deeper into any of these stories or discuss how my experience fits your challenges, I’m happy to take your questions.”

STAR Stories

Three stories from three different companies. Each covers a distinct core competency and can be adapted to multiple technical and behavioral questions.

Story 1 — Architecture from Scratch & Mentorship (Seguralta)

Covers: Micro-frontends, Module Federation, Architecture Decision-Making, Multi-layer Caching, Mentoring Junior Engineers, Independent Deployments.

Situation: Seguralta is Brazil’s largest insurance brokerage franchise. When I joined, their entire franchisee management system was running on paper and spreadsheets. The business needed a single unified platform — but with multiple domains (billing, agent management, compliance) that had to be developed and deployed independently. The company put together a team of seven people, but six of them were junior developers with no experience in complex production systems.

Task: I was brought in as Tech Lead on a Greenfield project. My responsibility was twofold: design a robust, scalable, high-performance architecture from zero — and lead and train this junior team to deliver production-quality work.

Action:

• Why Module Federation, not a monolith or iframes: I evaluated three options. A monolith would create deployment bottlenecks — any change would block all teams. Iframes solve isolation but make shared state and design consistency nearly impossible. I chose Module Federation because it enables true runtime code sharing: each team deploys independently, the shell composes micro-frontends on demand, and shared libraries like React are loaded only once. I designed a browser-level event orchestrator to handle cross-domain state and routing without tight coupling between domains.

• Why Redis for caching, not in-memory: The platform consumed heavy brokerage data. An In-memory cache on Node.js would reset on every deploy and wouldn’t scale horizontally across instances. I proposed Redis as a shared persistent cache layer, with smart client-side invalidation using React Query’s staleTime and cacheTime. This kept report pages consistently under 1.5 seconds regardless of dataset size.

• Mentoring — Engineering standards from day one: I established a mandatory Code Review checklist, weekly Pair Programming sessions focused on React patterns and Cypress E2E testing, and a rule that no PR was merged without 80%+ test coverage. I made sure the team understood the reasoning behind every architectural decision before writing a single line.

Result: The platform launched successfully, handling a high daily volume of insurance transactions. Complex report pages load in under 1.5 seconds. The board of directors praised the delivery. All six junior developers gained the autonomy to ship full features end-to-end on their own — a milestone I tracked through their independent PR approvals in the final month.

Likely follow-up questions: Why Module Federation instead of a monolith? How did you handle shared React version conflicts? How did routing work between domains? What would break if two micro-frontends used different React versions?

Story 2 — Production Performance Investigation & Engineering Leadership (WeFit / Porto Seguro)

Covers: Root Cause Analysis, React Profiler, New Relic, React.memo, DataLoader, CI/CD, Code Review Standards, QA Shift-Left, Mentoring.

Situation: At Porto Seguro, I worked on a critical commercial management platform that insurance brokers use daily to track sales goals, schedule visits, and manage client pipelines. The squad had 12 people across the front end, back end, and QA. We had a severe production problem: broker dashboards were taking over 8 seconds to load during peak business hours. This was not a UX inconvenience — brokers rely on this data in real time to close deals. Every second of slowness cost the business money. Beyond the performance issue, the squad also had inconsistent engineering standards: PRs were merged without proper review, tests were sparse, and QA engaged only at sprint end.

Task: I was assigned as technical lead with two interconnected responsibilities: conduct a deep root-cause investigation of the performance problem, and improve the engineering culture of the squad to prevent future issues. My mandate was to determine whether the problem originated in React rendering, the API layer, or back-end services — restore acceptable performance, and build processes that would hold without constant senior oversight.

Action:

Performance investigation (step-by-step):

1. Reproduction: I used the React DevTools Profiler and Chrome Performance panel to reproduce the issue. The flame graph revealed cascading re-renders triggered by a single state update at the dashboard root.

2. Evidence collection: I analyzed New Relic traces simultaneously. They exposed an N+1 query pattern — the dashboard was making dozens of individual API calls per broker instead of batching them. Both the front-end and back-end had independent problems.

3. Ruling out other causes: I isolated the network with mock service workers to confirm that even with instant API responses, re-renders were excessive — proving the front-end issue was independent.

4. Why React.memo before virtualization: Virtualization like react-window, addresses list rendering at scale but not unnecessary re-renders caused by unstable references. I prioritized React.memo and useMemo first for the highest gain with the lowest risk, then layered in virtualization for large broker tables as a second pass.

5. Why Recharts, not the existing library: The legacy chart library was not tree-shakeable and added ~180 KB to the initial bundle. Recharts is composable, tree-shakeable, and has native memoization support. I validated the migration on one dashboard before rolling it out across the others.

6. Why DataLoader for API batching: DataLoader aggregates multiple concurrent requests in a single event loop tick and sends one batched request instead of many. I worked with the back-end team to implement it, eliminating the N+1 at the source.

7. Verification before production: I monitored the fix in staging using New Relic’s browser agent — confirmed FCP dropped from 8+ seconds to under 2 seconds before releasing.

8. Prevention in CI/CD: I added performance budgets to GitHub Actions — the pipeline now blocks merges if the bundle exceeds a defined size or Lighthouse scores fall below baselines.

Engineering culture improvements:

• Code Review standards: I documented a mandatory checklist covering correctness, performance implications, test coverage, and readability. No PR could merge without a senior review and green CI. I wrote educational comments explaining the why — not just flagging what was wrong.
• Mentoring: Weekly Pair Programming sessions with junior developers focused on useCallback boundaries, selector patterns, and Zustand. I kept a shared “anti-patterns found in production” document with real examples from our codebase.
• QA shift-left: I brought QA engineers into sprint planning. They began validating features mid-sprint instead of only at the end — catching regressions earlier and eliminating the last-minute bottleneck.
• Testing in CI: I introduced Cypress E2E tests for critical flows and configured GitHub Actions to run linters, unit tests (Vitest), and E2E on every PR. Merges to main were blocked if coverage dropped below 75%.

Result: New Relic confirmed a 36% reduction in First Contentful Paint. Dashboards became fluid during peak hours. Squad velocity increased as I broke large epics into smaller deliverables. Production incidents caused by front-end regressions dropped to near zero over the following two sprints. The platform’s NPS improved by 19 percentage points. Two junior developers I mentored were promoted to mid-level within six months.

Likely follow-up questions: Why React Query? Why DataLoader instead of GraphQL batching? How did you verify the fix before production? What monitoring remained after the fix? How did you handle pushback from devs who felt reviews slowed them down?

Story 3 — ISR vs SSR Architecture & Business Impact (Zarp)

Covers: Next.js, ISR, SSR, Domain Separation, SEO Strategy, CI/CD, Organic Conversion.

Situation: At Zarp, we were building a platform that connected drivers who needed a car with rental options — essentially an Uber for car rentals. The product had two very different requirements living in the same codebase: public search and catalog pages that needed top-tier SEO to drive organic traffic in Brazil, and a logged-in user funnel (checkout, reservations, user dashboard) that required 100% real-time, session-specific data. The monolithic codebase made isolated deployments risky — a change in one area could break another, and the combined build time created delivery friction between teams.

Task: I was responsible for decoupling the architecture so different product areas could evolve independently, and for implementing advanced rendering strategies to hit our Core Web Vitals targets and ranking goals.

Action:

• Why ISR for catalog pages, not SSR: Applying SSR to high-traffic catalog pages would hit the server on every request, increasing infrastructure costs and introducing latency at scale. ISR generates pages statically and revalidates them in the background at a configured interval — giving CDN-level speed (near-instant for the user) with reasonably fresh content. I chose a 60-second revalidation window based on how frequently the rental inventory actually changed. The result is excellent FCP and Lighthouse scores without additional server load.

• Why SSR for the conversion funnel, not ISR or CSR: The checkout and user dashboard require session-specific, 100% real-time data. A cached ISR page could show stale pricing or incorrect availability — unacceptable in a financial transaction. CSR would expose session logic to the client. I applied SSR with strict HTTP-only cookie-based session validation for these routes: the server validates the session before rendering, so no sensitive data is ever exposed in the client bundle.

• Why domain separation, not a modular monolith: A modular monolith still shares a build pipeline, meaning a CSS change in one area can trigger a full rebuild of the entire application. I split the codebase into subdomain-focused projects (public catalog, user funnel, internal tools) — each with its own CI/CD pipeline, deployment cadence, and Lighthouse budget enforcement. This eliminated cross-team build conflicts and reduced individual build times.

Result: User-perceived latency on entry pages dropped to near-zero after CDN adoption via the ISR. Build conflicts between teams were eliminated. The platform reached first-position organic search ranking for key car rental terms in Brazil. Organic conversion increased by 2.7x. The separated deployment pipelines also improved the team’s release confidence — each team could ship without fear of breaking an unrelated domain.

Likely follow-up questions: How did you decide the ISR revalidation interval? What happens if ISR cache is stale during peak traffic? How did you handle shared components across the separated projects? What would you do differently today?

AI-Powered Workflow — Spec-Driven Development

Instead of a traditional STAR story, AI usage is best communicated by addressing the concerns interviewers typically have:

• Q: How do you integrate AI into your workflow? A: I use what I call Spec-Driven Development. Instead of asking AI to generate loose code, I write strict architectural specifications in Markdown — defining data models, component contracts, error states, and acceptance criteria. The AI consumes the spec and generates the base implementation. This gives me a reproducible, reviewable starting point rather than unpredictable output.

• Q: How do you prevent bad code or hallucinations? A: By establishing guardrails and validation loops. The AI does not commit anything directly. It is forced to run linters and unit tests. If something breaks, it reads the console output and refactors until all tests pass (exit code 0). I do the final human review to verify project patterns are respected.

• Q: What about understanding complex or legacy projects? A: I use NotebookLM to ingest heavy documentation and old repositories. It acts as a Discovery assistant, helping me map business rules and dependencies before writing a single line of code.

• Q: Doesn’t intensive AI usage generate high token or infrastructure costs? A: Yes, and I built a terminal interceptor called RTK (Rust Token Killer) to address this. It filters long bash outputs from AI commands, reducing token consumption by up to 90% without losing context.

Questions for the Interviewer

Prepare 2–3 focused questions. The goal is to signal engineering curiosity — not just role curiosity. Ask about the environment, not the job description.

Block 1 — Technical challenges (signals: you think beyond your own ticket)

• “What are the biggest front-end technical challenges the Web Portal team is actively trying to solve right now?” Why it’s powerful: Shows you care about the real engineering problems, not just the listed requirements.
• “What does the current front-end architecture look like — and where do you see it evolving over the next year?” Why it’s powerful: Demonstrates architectural curiosity and positions you as someone who thinks long-term.

Block 2 — Engineering culture (signals: you value quality and collaboration)

• “How do front-end, back-end, QA, and Product collaborate during the design and delivery of a new feature — from kickoff to production?” Why it’s powerful: Shows you understand cross-functional delivery and are evaluating whether the team’s process matches your standards.
• “What does code review look like on this team — is it a formal process with documented standards, or more informal?” Why it’s powerful: Reveals your commitment to code quality. If they have strong standards, you signal alignment. If they don’t, it opens a conversation.

Block 3 — Ownership and growth (signals: you think about impact, not just tasks)

• “What production responsibilities do front-end engineers have after a feature ships — on-call, incident response, monitoring?” Why it’s powerful: Shows production maturity and that you’re comfortable owning your work end-to-end.
• “What distinguishes the engineers who perform exceptionally well on this team?” Why it’s powerful: Helps you understand success criteria and signals ambition. The answer also tells you a lot about the team’s actual values.

⚠️ English Speaking Notes

Points from English coach Augusto Bretas — practice before the interview. Reference: entrevista-feedback-ingles

1. Relative Clauses — where / that / which, never who for non-people

• ❌ “environments who support collaboration”
• ✅ “environments that support collaboration” / “environments where everyone has a voice”
• who is only for people. Use that or which for things, where for places and abstract contexts.

2. Article Agreement with Irregular Plurals

• ❌ “a different people” — people is already plural; a is only for singular nouns
• ✅ “different people” or “some different people”
• Same rule applies to: children, data, criteria

3. Verbs — Base Form for Routine, not -ing

• ❌ “I like to developing tools”
• ✅ “I like to develop tools”
• After to, always use the base form. Use -ing only for present progressive.

4. Hesitation Markers — Replace with Silence

• ❌ Long sounds: “ãã…”, “mmm…”, “sooo…”
• ✅ A brief pause of 0.5–1 second sounds confident and buys the same thinking time
• It feels uncomfortable at first — that discomfort is the practice working.

5. Pronouns for AI Tools — Always it

• ❌ “I use NotebookLM — he reads the documentation”
• ✅ “I use NotebookLM — it reads the documentation”

Strengths to keep

• ✅ “Show, don’t tell” — already practiced; you illustrate answers with real examples
• ✅ Pacing and clarity — clear for non-native English listeners
• ✅ Verb tenses — generally accurate

Relacionadas: entrevistas-moc · entrevista-metodo-star · entrevista-historias-chave · entrevista-elevator-pitch · entrevista-feedback-ingles