Leadership Principles — Behavioral Questions (Part 2)
This is the second part of your Amazon LP behavioral prep. Part 1 covered Customer Obsession, Deliver Results, Ownership, Insist on Highest Standards, and Bias for Action. This file covers the remaining LPs you're likely to be tested on: Earn Trust, Dive Deep, Learn & Be Curious, Frugality, Have Backbone, and Think Big.
Reminder on delivery:
- 2-3 minutes per answer, max
- Concrete details beat vague generalizations every time
- The "Action" section should be the longest part of your STAR answer
- It's okay to reuse a story across LPs, but adjust the emphasis to match the principle being tested
Quick Reference Table
| # | Question | LP Alignment |
|---|---|---|
| 1 | Conflict with a manager and how it was handled | Earn Trust / Have Backbone |
| 2 | Had to convince someone of your approach | Have Backbone |
| 3 | Negative feedback incident and how you worked on it | Earn Trust / Learn & Be Curious |
| 4 | Diving deep on a project you owned end-to-end | Dive Deep |
| 5 | Another project you owned end-to-end and dove deep on | Dive Deep |
| 6 | Frugality — doing more with less | Frugality |
| 7 | How you faced and resolved difficulties in past projects | Dive Deep |
| 8 | New skills you learned recently | Learn & Be Curious |
| 9 | Earning trust of a skeptical team or stakeholder | Earn Trust |
| 10 | Admitting you were wrong | Earn Trust |
| 11 | Rebuilding a damaged working relationship | Earn Trust |
| 12 | Working with a difficult colleague and building trust | Earn Trust |
| 13 | Digging deep into data to solve a problem | Dive Deep |
| 14 | Root cause not obvious, had to investigate | Dive Deep |
| 15 | Noticed something off with a metric or report | Dive Deep |
| 16 | Data told a different story than what people assumed | Dive Deep |
| 17 | Learned something new that changed your approach | Learn & Be Curious |
| 18 | Didn't have skills/knowledge to complete a task | Learn & Be Curious |
| 19 | Proactively sought out a new skill or technology | Learn & Be Curious |
| 20 | Curiosity led to a meaningful improvement or innovation | Learn & Be Curious |
Earn Trust / Have Backbone
"Leaders listen attentively, speak candidly, and treat others respectfully. They vocally self-critical, even when doing so is awkward."
"Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable."
1. Tell me about a conflict with a manager and how it was handled.
LP Alignment: Earn Trust / Have Backbone
What They're Really Testing: Can you disagree with authority respectfully and productively? Do you default to "yes" or do you advocate for what you believe is right while maintaining the relationship?
STAR Framework
Situation: My engineering manager at Pixis wanted to adopt a micro-frontend architecture for our creative platform. His reasoning was that it would let teams deploy independently and reduce merge conflicts. I disagreed — our team was only 5 frontend engineers working on a single product, and I believed micro-frontends would introduce significant overhead (separate build pipelines, shared state complexity, runtime performance costs) that wasn't justified at our scale.
Task: I needed to voice my disagreement constructively without just being the person who says "no" to everything. I wanted to either change his mind with evidence or understand something I was missing.
Action: Instead of arguing in a meeting, I asked for a 30-minute 1:1 to discuss it. I came prepared with specifics: I'd estimated the setup cost (2-3 weeks for build pipeline configuration, Module Federation setup, shared dependency management), the ongoing maintenance overhead (CI/CD for each micro-frontend, version synchronization for shared components), and the runtime cost (additional HTTP requests, duplicate vendor bundles without careful configuration). I also acknowledged the legitimate benefits he was targeting — independent deployability and reduced merge conflicts — and proposed an alternative that addressed those same problems at lower cost: a monorepo with well-defined module boundaries, separate CI pipelines per module, and feature flags for independent releases. I showed him that our merge conflict rate was actually low (about 3 per week, all trivially resolved) and that the real bottleneck wasn't the architecture but our lack of a PR review cadence. I told him I could be wrong and that I was open to being convinced, but I wanted to make sure we weren't solving a problem we didn't actually have.
Result: He appreciated that I came with data instead of opinions. He agreed that the micro-frontend overhead wasn't justified at our current scale but asked me to define a "trigger point" — specific team size and codebase metrics that would signal when we should revisit the decision. I documented those criteria (10+ frontend engineers, 3+ independently deployable product surfaces, CI build time exceeding 15 minutes). We stayed with the monorepo approach, and 8 months later we still hadn't hit any of those triggers. The conversation actually strengthened our working relationship because he knew I'd push back with reasoning, not just compliance.
Tips
- Never frame it as "I was right and my manager was wrong" — frame it as a productive disagreement that led to a better outcome
- Show that you respected the manager's perspective and acknowledged what they were trying to achieve
2. Tell me about a scenario where you had to convince someone of your approach.
LP Alignment: Have Backbone
What They're Really Testing: Can you build a persuasive case with evidence? Do you disagree and commit, or do you hold a grudge if your idea isn't picked?
STAR Framework
Situation: A senior backend engineer on my team proposed using Server-Sent Events (SSE) for our real-time creative preview updates. His argument was that SSE was simpler than WebSockets and sufficient for our use case since the data only flowed server-to-client. I believed WebSockets were the right choice because I could foresee upcoming features (collaborative editing, live cursor tracking) that would require bidirectional communication, and migrating from SSE to WebSockets later would be a painful refactor.
Task: I needed to convince the team — particularly this senior engineer who had more tenure than me — that WebSockets were worth the additional upfront complexity.
Action: I didn't just argue the theoretical point. I built two minimal prototypes over a weekend: one using SSE and one using WebSockets, both implementing the same preview update flow. I benchmarked both on connection establishment time, memory usage, and reconnection behavior. The performance was nearly identical for the current use case, which was actually his strongest argument. But then I extended the WebSocket prototype with a basic collaborative cursor feature in about 40 lines of code, and showed that achieving the same thing with SSE would require adding a separate POST endpoint for client-to-server messages, essentially duplicating the connection layer. I presented both prototypes at our tech design review, acknowledged that SSE was technically sufficient for today's requirements, and asked the team: "Are we optimizing for the next 3 months or the next 12?" I also addressed the complexity concern head-on by showing that our WebSocket setup (using socket.io) was only 15 more lines of code than the SSE implementation.
Result: The team chose WebSockets. The senior engineer was gracious about it and later told me he appreciated that I'd done the work to prove my point rather than just debating in the abstract. Four months later, when we built the collaborative editing feature, the WebSocket infrastructure was already in place and saved us an estimated 2 weeks of refactoring. The experience also established a team norm of "prototype, don't argue" for technical disagreements.
Tips
- Show your work — interviewers love it when you built something to prove your point instead of just debating
- Acknowledge the other person's valid points before presenting your case
Earn Trust / Learn & Be Curious
3. Tell me about a negative feedback incident and how you worked on it.
LP Alignment: Earn Trust / Learn & Be Curious
What They're Really Testing: Are you coachable? Do you get defensive when criticized, or do you treat feedback as a growth signal? Can you demonstrate concrete change?
STAR Framework
Situation: During a mid-year review at Pixis, my engineering manager told me that while my individual output was strong, I had a tendency to "go dark" on complex tasks — I'd disappear for 3-4 days, not update anyone, and then surface with a large PR. He said it made it hard for the team to plan around my work and that the PMs felt out of the loop on feature progress. He also mentioned that two of my recent PRs were 800+ lines, which made them nearly impossible to review meaningfully.
Task: I needed to change my working style to be more transparent and collaborative without sacrificing the deep-focus time that made me productive on complex problems.
Action: First, I accepted the feedback fully — I didn't make excuses. I knew he was right because I'd noticed reviewers rubber-stamping my large PRs, which meant bugs were slipping through. I made three specific changes. First, I adopted a "working in public" approach: for any task longer than 2 days, I'd open a draft PR on day 1 with a description of my approach and update it daily. This let the team see my progress without requiring meetings. Second, I broke my work into stacked PRs — instead of one 800-line PR, I'd have 3-4 PRs of 150-250 lines each, where each one was independently reviewable and mergeable. I used a Git workflow where each PR branched off the previous one. Third, I added a daily async standup message in our Slack channel: one sentence on what I did, one on what I'm doing next, and one on any blockers. This took me 30 seconds and completely eliminated the "going dark" perception.
Result: At my next quarterly review, my manager specifically called out the improvement. PR review quality went up — reviewers were actually catching issues because the PRs were digestible. My average PR size went from 600+ lines to 200 lines. The draft PR approach had an unexpected benefit: twice, a teammate saw my draft and suggested a better approach BEFORE I'd invested days into the wrong path, saving significant rework. I also found that breaking work into smaller pieces actually made ME more productive because each piece was a clear, completable unit.
Tips
- Demonstrate genuine self-awareness — don't pick a "weakness" that's actually a strength in disguise
- Show the specific, measurable changes you made, not just "I tried harder"
Dive Deep
"Leaders operate at all levels, stay connected to the details, no task is beneath them."
4. Tell me about a time you dove deep on a project you owned end-to-end.
LP Alignment: Dive Deep
What They're Really Testing: Can you peel back layers of abstraction to find root causes? Do you understand how things work under the hood, or do you just use frameworks at a surface level?
STAR Framework
Situation: Our creative editor at Pixis had a persistent performance issue: after editing 15-20 creatives in a single session, the editor would become noticeably sluggish — input lag on text editing, delayed drag interactions, and eventual browser tab crashes on lower-end machines. The issue had been in our backlog for 2 months with a "P2" label because it only affected power users in long sessions.
Task: I owned the creative editor module and decided to investigate and fix this end-to-end, even though it wasn't prioritized in the current sprint.
Action: I started with Chrome DevTools Performance tab, recording a session where I edited 20 creatives. The flame chart showed increasingly long "Minor GC" and "Major GC" pauses, which pointed to a memory leak. I switched to the Memory tab and took heap snapshots at creative #1, #10, and #20. Comparing the snapshots, I found that detached DOM nodes were accumulating — each creative edit was creating canvas elements for rendering previews, but they weren't being garbage collected when the user moved to the next creative. The root cause was subtle: our useEffect cleanup function was removing the canvas from the DOM, but the canvas's 2D context held a reference to a large ImageBitmap object that was created from the uploaded asset. The ImageBitmap needed an explicit .close() call to release the GPU-side memory — just removing the DOM element wasn't enough. I traced the issue further and found a second leak: our undo/redo history was storing deep clones of the entire creative state (including base64 image data) for each edit operation. After 50 undoable actions across 20 creatives, this stack held hundreds of megabytes. I replaced the deep clone approach with a structural sharing strategy using Immer, so undo history only stored diffs rather than full copies. I also added an ImageBitmap.close() call in the canvas cleanup and set a maximum undo stack depth of 30 operations, evicting the oldest entries.
Result: Memory usage during a 20-creative session dropped from 1.8GB to 340MB. The tab crash issue was completely eliminated. Input lag after 20 edits went from 200ms+ to under 16ms (within a single frame). I wrote up the ImageBitmap finding as an internal engineering blog post because it's a non-obvious browser API gotcha that any engineer working with canvas could hit. Power user session duration increased by 25% in the month after the fix, which we interpreted as users no longer being forced to refresh.
Tips
- Walk through your diagnostic process step by step — the journey matters as much as the destination for Dive Deep
- Show that you went deeper than the obvious first cause (canvas leak) to find the second issue (undo history)
5. Tell me about another project you owned end-to-end and dove deep on.
LP Alignment: Dive Deep
What They're Really Testing: Second data point — they want to confirm your depth is a habit, not a one-time event.
STAR Framework
Situation: After deploying a new version of our ad creative generator, we started getting sporadic reports from users that generated images had subtle color shifts — a brand's red (#E53935) was rendering as a slightly different red (#E8413E) in the final output. It only affected certain images and wasn't consistently reproducible. The PM initially dismissed it as "monitor calibration differences," but I wasn't convinced because the hex values in our output files were provably different from the input.
Task: I needed to track down why our image processing pipeline was introducing color shifts that were small enough to go unnoticed in testing but meaningful enough for brand-conscious enterprise clients.
Action: I methodically isolated each step of the pipeline. Our flow was: user uploads image, frontend resizes to max 2048px using HTML Canvas drawImage, sends to backend, backend composites with text overlays using Sharp (Node.js image library), returns final image. I wrote a test harness that compared pixel values at each stage. The Canvas resize step was clean — pixel values matched. The Sharp compositing step introduced the shift. I dove into Sharp's documentation and found the issue: Sharp uses libvips under the hood, which defaults to sRGB color space conversion. Our input images from design tools (Figma, Photoshop) were sometimes in Display P3 or Adobe RGB color spaces. The conversion to sRGB was slightly shifting the gamut for colors near the edge of the sRGB space. The fix wasn't just "disable conversion" — that would break images that legitimately needed sRGB. I implemented a color space detection step that read the ICC profile from the input image metadata. If the image was already sRGB, I passed { colorspace: 'srgb' } with no conversion. If it was a wider gamut, I preserved the embedded profile through the processing pipeline and only converted to sRGB at the final output stage with a perceptual rendering intent, which produces more visually accurate conversions than the default relative colorimetric intent.
Result: Color accuracy for brand assets improved to within 1 delta-E (the threshold of human perception) compared to the previous 3-5 delta-E deviation. Two enterprise clients who had flagged color issues confirmed the fix resolved their concern. The investigation took 3 days — most engineers would have just applied a CSS filter as a workaround, but the root cause fix meant we never had to deal with color accuracy issues again. Our CTO shared the technical write-up I did as an example of "going deep vs. applying band-aids."
Tips
- Show that you didn't stop at the first plausible explanation (the PM's "monitor calibration" theory)
- Technical depth is expected here — don't shy away from implementation details like color spaces and rendering intents
Frugality
"Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention."
6. Tell me about a time you demonstrated frugality — doing more with less.
LP Alignment: Frugality
What They're Really Testing: Can you be resourceful when budget, time, or tooling is constrained? Do you default to buying/building expensive solutions, or can you find creative, lightweight alternatives?
STAR Framework
Situation: Pixis was an early-stage startup (Series A), and we needed a design system but couldn't afford to dedicate a full-time engineer to it or purchase a commercial component library license. The PM was pushing to buy a Chakra UI Pro license ($500/year per developer, $2,500/year for the team), but I thought we could build exactly what we needed with less.
Task: I needed to deliver a usable component library that solved our immediate consistency and velocity problems without spending engineering months or licensing budget on it.
Action: Instead of building a full design system from scratch or buying a commercial one, I took a curated approach. I started with Radix UI primitives — fully unstyled, accessible components that are free and open source. These gave us the behavioral layer (dropdowns, modals, tooltips, tabs) without any styling opinions. For styling, I created a thin Tailwind CSS token layer that mapped to our brand values (colors, spacing, typography) and wrote wrapper components around the Radix primitives that applied our design tokens. The entire component library was 12 components, each under 50 lines of code. I built it in 4 days rather than the 6-8 weeks a custom design system would have taken. I also set up Storybook with a free Chromatic tier for visual regression testing, avoiding the need for a paid visual testing tool. For documentation, instead of building a docs site, I used Storybook's built-in docs addon with inline MDX — one tool serving two purposes.
Result: Total cost: $0 in tooling spend and 4 days of engineering time, versus the $2,500/year licensing cost or the estimated 6-8 weeks for a custom build. The component library covered 90% of our UI needs. Development velocity on new features improved by roughly 25% because engineers stopped re-implementing common patterns. When we later needed components that Radix didn't cover (data tables, date pickers), I added them incrementally — the modular approach meant we never over-invested upfront. The PM later acknowledged that the "build what you need" approach was better than paying for a full library where we'd use 15% of the components.
Tips
- Show the comparison: what the expensive option would have cost versus what your approach cost
- Don't make it sound like you're just being cheap — frame it as being strategic about where you invest
Dive Deep (continued)
7. Tell me about how you faced and resolved difficulties in past projects.
LP Alignment: Dive Deep
What They're Really Testing: How do you behave when you're stuck? Do you give up, escalate immediately, or systematically work through the problem? Can you operate in ambiguous, difficult technical territory?
STAR Framework
Situation: I was integrating a third-party rich text editor (Slate.js) into our creative platform for ad copy editing. The integration seemed straightforward initially, but I hit a wall: our app used a controlled component pattern for all form inputs, but Slate's internal state management conflicted with React's reconciliation in ways that caused cursor position to jump to the end of the text field on every keystroke. The issue only appeared when Slate was wrapped in our form context provider.
Task: I needed to get the rich text editor working within our existing architecture without rewriting our form management system, and without forking the Slate library.
Action: I spent the first half-day reading GitHub issues on the Slate repo and found dozens of similar reports with no clear resolution — most people had worked around it by making Slate uncontrolled, which wouldn't work in our case. I decided to go deeper. I added console logs at every stage of the React render cycle to understand the exact sequence: our form context was triggering a re-render on every keystroke, which caused Slate's value prop to update, which caused Slate to reset its internal selection state. The fix needed to break this cycle without breaking our form validation. I implemented a debounced sync pattern: the Slate editor maintained its own internal state (uncontrolled) for real-time editing, but synced its value to our form context on a 300ms debounce. For validation, I added an onBlur handler that did an immediate sync. I also had to handle the edge case of form-level resets (e.g., user clicks "discard changes") — for that, I used a key prop derived from a form reset counter so the Slate instance would remount on form reset. The trickiest part was handling paste events, where large content would trigger multiple rapid state updates. I batched those using requestAnimationFrame to coalesce updates.
Result: The rich text editor worked smoothly within our form system — no cursor jumping, no lost input, proper validation on blur. The debounced sync pattern I developed was reusable enough that we applied it to two other third-party components (a color picker and a drag-and-drop list) that had similar controlled-vs-uncontrolled conflicts. I documented the pattern as a useUncontrolledSync custom hook that other engineers could use out of the box. The total effort was about 3 days, but it saved us from a much costlier decision to either fork Slate or rewrite our form system.
Tips
- Show your debugging methodology — systematic investigation beats random attempts
- Demonstrate resilience — the interviewer wants to see that you didn't give up when the obvious solutions failed
Learn & Be Curious
"Leaders are never done learning and always seek to improve themselves."
8. Tell me about new skills you've learned recently.
LP Alignment: Learn & Be Curious
What They're Really Testing: Are you self-directed in your learning? Do you just learn what your job requires, or do you proactively seek out new knowledge? Can you turn learning into applied value?
STAR Framework
Situation: In mid-2024, the AI landscape was rapidly evolving and our product at Pixis was increasingly integrating AI-generated content. I noticed that our team was treating AI features as black boxes — we'd call an API, display the result, and move on. I realized that to build better AI-powered UIs (loading states, confidence indicators, streaming outputs, error handling for non-deterministic systems), I needed to understand the underlying technology, not just the API contracts.
Task: I set a personal goal to deeply understand LLMs, prompt engineering, and AI application architecture well enough to influence how we designed AI features on the frontend — not to become an ML engineer, but to be a more effective frontend engineer building AI products.
Action: I followed a structured learning path over 3 months. I started with Andrej Karpathy's "Let's build GPT" video to understand transformer architecture from first principles — attention mechanisms, tokenization, how context windows work. Then I took a practical turn: I built a small project using the OpenAI API that generated ad copy variations with streaming responses, which taught me about Server-Sent Events for streamed token delivery and the UX challenges of displaying partial content. I learned about prompt engineering patterns (chain-of-thought, few-shot, structured output) and how prompt design affects response reliability — this directly influenced how I designed our prompt input UI. I also learned about embeddings and vector similarity, which led me to prototype a "find similar creatives" feature using cosine similarity on creative metadata embeddings. At work, I applied what I learned by redesigning our AI generation UI: I added streaming text display instead of a loading spinner (reducing perceived wait time), confidence scores displayed as a visual meter, and a "regenerate with adjustments" flow that exposed prompt parameters to users in a simplified form. I also started sharing weekly "AI for frontend devs" notes with my team.
Result: The streaming text UI reduced user-perceived generation time by 60% (actual time was the same, but users could start reading immediately). The confidence score display reduced "regenerate" clicks by 35% because users could see when output quality was high. My prototype of the "similar creatives" feature got greenlit as a Q4 project and shipped — it's now used by 40% of active users. The weekly knowledge-sharing notes evolved into a team learning session that other engineers started contributing to. Most importantly, I went from being an engineer who consumed AI APIs to one who could meaningfully contribute to AI feature design decisions.
Tips
- Show a progression from curiosity to applied learning to business impact — don't just list courses or tutorials
- Demonstrate that your learning was self-directed with a clear goal, not random exploration
Additional Frequently Asked Questions
Earn Trust — More Frequent Questions
9. Tell me about a time you had to earn the trust of a team or stakeholder who was skeptical of you.
LP Alignment: Earn Trust
What They're Really Testing: Can you recognize when others don't yet trust your judgment, and can you earn credibility through actions rather than demanding it through title or tenure?
STAR Framework
Situation: Pixis acquired a small design agency's ad-ops team to bolster our creative operations. I was assigned to build a new campaign management dashboard that this newly integrated team would use daily. The team of 5 ad-ops specialists were openly skeptical of the engineering team — their previous tool had been built by an outside contractor who ignored their feedback, and they assumed the same would happen again. In our first meeting, their lead said, "Just don't build us another tool we hate."
Task: I needed to earn this team's trust so they would actively participate in the product development process, give honest feedback, and ultimately adopt the dashboard I was building.
Action: Instead of jumping into building, I spent the first week shadowing the ad-ops team. I sat with each team member for 2-3 hours and watched how they actually worked — their existing spreadsheet workflows, the manual copy-paste steps between platforms, where they got frustrated. I documented 23 specific pain points and shared the raw list back with them for validation, which showed I was actually listening. For the first sprint, I deliberately picked the 3 pain points they'd ranked highest (not the ones I thought were most technically interesting) and built quick, functional prototypes. I deployed the first working feature — a bulk creative status view that replaced their 4-tab spreadsheet workflow — in 5 days and put it in front of them immediately. When they gave feedback ("the filter should default to 'active' not 'all'"), I shipped the change the same afternoon. I also made a point of being transparent about trade-offs: when they requested a real-time sync feature, I explained honestly that it would take 3 weeks and showed them a polling-based alternative that updated every 30 seconds, which I could ship in 2 days. I let them choose. They chose the faster option.
Result: Within 3 weeks, the ad-ops team went from reluctant participants to active advocates. Their lead started coming to sprint demos voluntarily and bringing feature requests. Dashboard adoption hit 100% within the team by week 4 — they stopped using their spreadsheets entirely. The ad-ops lead later told my manager that I was "the first engineer who actually listened." The dashboard reduced their daily campaign setup time from 45 minutes to 12 minutes. More importantly, the trust I built created a feedback loop that made every subsequent feature better because they weren't holding back their honest opinions.
Tips
- Show that trust was earned through consistent actions, not a single grand gesture
- Demonstrate empathy — understanding WHY they were skeptical matters as much as what you did about it
10. Tell me about a time you admitted you were wrong.
LP Alignment: Earn Trust
What They're Really Testing: Do you have the intellectual honesty to own mistakes publicly? Can you separate your ego from your ideas? Do you course-correct quickly once you realize you're wrong?
STAR Framework
Situation: I had strongly advocated for using Redux Toolkit as our state management solution for the creative automation platform at Pixis. I wrote a technical design document, presented it to the team, and got buy-in. We spent about 2 weeks building out the Redux store architecture — slices for creative assets, campaign state, user preferences, and template configurations. But as we built features on top of it, I started noticing problems: the boilerplate was slowing us down, the normalized entity state was overkill for our data shapes, and most of our state was actually server-derived data that we were manually syncing and caching in Redux — poorly.
Task: I needed to acknowledge that my architectural recommendation was the wrong choice for our use case, propose a better path, and do it without wasting the trust the team had placed in my technical judgment.
Action: I didn't try to quietly fix it or wait for someone else to point it out. I wrote a brief "lessons learned" document that honestly assessed what went wrong with my recommendation: I had defaulted to Redux because of prior experience, not because I'd evaluated it against our actual data patterns. Our data was 80% server state (campaign data, creative assets from the API) and only 20% true client state (UI selections, editor tool state). I proposed migrating to React Query for server state and Zustand for the remaining client state. Critically, I included a migration plan that was incremental — we wouldn't throw away 2 weeks of work overnight. I presented this at our team retro, opened with "I was wrong about Redux for this project, and here's why," and walked through the specifics. I also took ownership of the migration work so the cost of my mistake didn't fall on others.
Result: The team appreciated the honesty — my tech lead said it actually increased his trust in my judgment because "someone who can't admit mistakes can't be trusted with big decisions." The migration took about 10 days (I did most of it). After migrating, our data-fetching code decreased by roughly 40% because React Query handled caching, refetching, and loading states that we'd been manually implementing in Redux. Feature development velocity measurably improved — our average time to build a new data-connected feature dropped from 3 days to 1.5 days. The Zustand client-state store was 120 lines compared to the 800+ lines of Redux slices it replaced.
Tips
- Lead with the admission clearly and early — don't bury it in caveats or context
- Show that admitting the mistake led to a better outcome, reinforcing that honesty is a strength
11. Tell me about a time you had to rebuild a damaged working relationship.
LP Alignment: Earn Trust
What They're Really Testing: Can you recover from interpersonal setbacks? Do you take responsibility for your role in conflicts, or do you only blame others? Can you be vulnerable and direct simultaneously?
STAR Framework
Situation: I had a strained relationship with our senior product manager after I pushed back hard on a feature spec in a team meeting. She had proposed a complex multi-step creative wizard with 7 screens, and I argued it was over-engineered and could be done in 3 screens. My intent was to simplify for the user, but my delivery was poor — I interrupted her mid-presentation, used phrases like "that doesn't make sense," and essentially steamrolled the discussion. After the meeting, she stopped including me in early spec reviews and routed all communication through my manager instead of talking to me directly.
Task: I needed to repair the relationship because it was hurting the product — without direct communication between engineering and product, we were building features based on second-hand interpretations of requirements, leading to rework.
Action: I started by reflecting on what I'd done wrong. The issue wasn't that I disagreed — it was how I disagreed. I asked her for a 1:1 coffee chat and opened by apologizing specifically: "I was disrespectful in that meeting. I interrupted you, I dismissed your work publicly, and that was wrong regardless of whether I had valid technical points." I didn't add a "but" — I let the apology stand on its own. Then I asked what she needed from me going forward to make collaboration work. She told me she needed me to raise concerns in 1:1s before meetings, not ambush her in front of the team. I agreed and proposed a standing 30-minute weekly sync where I'd review upcoming specs and give early engineering input. For the wizard feature specifically, I went back and looked at her full spec with fresh eyes. I realized her 7-screen flow actually addressed edge cases I hadn't considered (multi-brand accounts, template inheritance, approval workflows). I messaged her acknowledging this and suggested a compromise: 4 screens with progressive disclosure that hid the advanced cases behind expandable sections.
Result: The weekly sync became one of the most productive meetings on my calendar. She started sharing early-stage ideas again, which meant I could flag technical concerns before they were baked into specs — reducing spec revision cycles from an average of 3 rounds to 1. The wizard shipped with the 4-screen compromise and got positive user feedback. Six months later, she specifically requested me as the engineering lead for her next major project (the template marketplace), which was a clear signal that the trust had been rebuilt. In my year-end review, she provided peer feedback saying I was her "most collaborative engineering partner."
Tips
- Own your part of the damage fully — even if the other person contributed too, focus on what YOU did wrong
- Show the specific behavioral change you made, not just the apology
12. Tell me about a time you had to work with a difficult colleague. How did you build trust?
LP Alignment: Earn Trust
What They're Really Testing: Can you work effectively with people whose style or personality clashes with yours? Do you write people off, or do you find ways to build productive relationships?
STAR Framework
Situation: A backend engineer on my team at Pixis was technically strong but had a confrontational communication style. In code reviews, he would leave comments like "This is wrong" without explanation, reject PRs with one-word responses ("No."), and in meetings he would dismiss frontend concerns as "not real engineering." This affected the whole frontend team's morale, but I was impacted most because my features depended on his APIs. I'd submit API contract proposals and get terse rejections with no alternative suggestions, which blocked my work for days.
Task: I needed to find a way to work productively with this colleague — not change his personality, but build enough mutual trust that we could collaborate effectively on shared deliverables.
Action: Instead of escalating to management or avoiding him, I tried to understand his perspective. I noticed that his terseness increased when he felt pressured or when he thought others weren't meeting his technical bar. I started by leveling up the quality of my API proposals — instead of rough sketches, I started including request/response schemas, error handling expectations, and edge case considerations. His review tone shifted immediately when he could see I'd thought deeply about the contract. Next, I started pair-programming with him on integration points. I suggested this as "saving us both async back-and-forth time," not as a relationship-building exercise. In these sessions, I discovered he was actually patient and generous with knowledge when engaged 1:1 — his bluntness was a written communication problem, not an interpersonal one. I also made a point of publicly crediting his API design when presenting features: "The creative generation flow is fast because [name] designed a really clean batching API." Over time, I also gave him direct, private feedback about his review style: "When you write 'This is wrong' without context, I can't learn from it or fix it efficiently. Can you add a one-liner on what you'd do differently?" He was receptive — he said nobody had told him directly before; they just complained behind his back.
Result: Our integration delivery time dropped from an average of 8 days (with 3-4 rounds of async review) to 3 days (one pairing session plus one review round). He started writing more descriptive code review comments across the team, not just with me. He also began proactively sharing API design docs with me before building, asking for frontend input — something he'd never done before. When I was up for a project lead role, he volunteered positive feedback to my manager, which surprised everyone on the team. The relationship went from adversarial to genuinely collaborative.
Tips
- Never position it as "I fixed a difficult person" — show mutual adaptation and respect
- Demonstrate that you invested effort in understanding WHY they behaved that way
Dive Deep — More Frequent Questions
13. Tell me about a time you had to dig deep into data to solve a problem.
LP Alignment: Dive Deep
What They're Really Testing: Can you use data methodically to drive decisions rather than relying on intuition? Do you know how to ask the right questions of a dataset?
STAR Framework
Situation: Our creative automation platform at Pixis had a feature where users could generate multiple ad creative variants and A/B test them. The product team noticed that the variant generation feature had a 68% "start" rate but only a 23% "completion" rate — meaning users were initiating the flow but dropping off before generating their variants. The PM's hypothesis was that the generation was too slow, and she wanted me to prioritize performance optimization.
Task: Before investing engineering time in performance work, I wanted to understand WHERE in the flow users were actually dropping off and WHY — the PM's hypothesis was plausible but unverified.
Action: I dug into our analytics data (Mixpanel events) and segmented the funnel step by step. The variant generation flow had 5 steps: select base creative, choose variation parameters, configure audience targeting, review summary, and generate. The data told a different story than "it's too slow." Step 1 to Step 2 retained 92% of users — fine. Step 2 to Step 3 dropped to 54% — this was the cliff. Step 3 to Step 5 retained well at 85%. So the problem wasn't generation speed at all; it was the variation parameter screen. I pulled session recordings (Hotjar) for 40 users who dropped off at Step 2 and categorized the behaviors. The pattern was clear: 70% of drop-offs happened within 8 seconds of landing on the screen, and users were exhibiting "choice paralysis" — our parameter screen presented 12 variation options simultaneously (headline variants, CTA variants, color schemes, image crops, font sizes, layout options, etc.) with no guidance on which ones mattered. I also cross-referenced with our power users (those who completed the flow successfully) and found they typically selected only 2-3 parameters, not the full 12. I proposed a redesign: a "quick mode" that pre-selected the 3 most impactful parameters (headline, CTA, and image crop — based on our A/B test performance data showing these drove 80% of performance variance) with an "advanced" toggle for the remaining options.
Result: The redesigned flow increased completion rate from 23% to 51% — more than doubling it. Average time on the parameter screen decreased from 45 seconds to 15 seconds. The PM acknowledged that if we'd gone straight to performance optimization, we would have spent weeks on the wrong problem. The "quick mode" insight also influenced our product strategy: we built a "smart defaults" system that pre-configured parameters based on the user's industry vertical, which increased completion rate further to 58%.
Tips
- Show that you challenged the initial assumption with data before acting on it
- Walk through your analytical process step by step — how you segmented, what you looked at, what patterns you found
14. Tell me about a time the root cause of a problem was not obvious and you had to investigate to find it.
LP Alignment: Dive Deep
What They're Really Testing: Can you persist through ambiguity and multi-layered problems? Do you have a systematic debugging methodology, or do you thrash randomly?
STAR Framework
Situation: Users of our template editor at Pixis reported intermittent crashes — the editor would freeze and become unresponsive. The crash reports were inconsistent: different browsers, different templates, different times of day. Our error tracking (Sentry) showed a "Maximum call stack size exceeded" error, but the stack trace pointed to React's reconciliation internals, not our code. The QA team spent a week trying to reproduce it consistently but couldn't.
Task: I needed to find the root cause of an intermittent crash that had no consistent reproduction steps and whose stack trace didn't point to any obvious culprit in our code.
Action: Since I couldn't reproduce it manually, I instrumented the code to catch it in production. I added a try-catch around our top-level render with detailed context logging: which template was loaded, which operations were in the undo stack, the current selection state, and the last 10 user actions (stored in a circular buffer). Within 2 days I had 15 crash reports with full context. The pattern emerged: every crash involved the "paste" operation on a template that contained nested groups. I could now reproduce it: create a group of elements, group that group, copy, paste. The infinite recursion happened in our custom deepClone utility function for pasting. When cloning nested groups, the function recursed into child elements, but our group data structure had a parent back-reference that created a circular reference. The deepClone function didn't detect cycles, so it recursed infinitely. The reason it was intermittent in the wild was that most users didn't nest groups deeply enough to hit the stack limit quickly — the crash only occurred with 3+ levels of nesting, or with large group payloads that consumed more stack per recursion level. I replaced the naive deepClone with a clone function that used a WeakSet to track visited objects and skip circular references. I also replaced the parent back-reference with a flat parentId lookup map, which eliminated the circular structure entirely and made serialization safer across the board.
Result: The crash was completely eliminated — zero recurrences in the following 3 months. The instrumentation approach I built (circular action buffer with context logging) became a standard pattern we added to other complex features. The parentId lookup refactor also simplified our template serialization code, reducing the save/load logic from 200 lines to 80 lines because we no longer needed custom JSON serialization to handle circular refs. The QA team added "nested group operations" to their regression test suite.
Tips
- Emphasize your systematic approach — especially how you dealt with the inability to reproduce the issue initially
- Show the chain: instrumentation led to pattern recognition, which led to reproduction, which led to root cause
15. Tell me about a time you noticed something was off with a metric or report and what you did about it.
LP Alignment: Dive Deep
What They're Really Testing: Do you passively consume dashboards and reports, or do you critically evaluate data? Can you catch silent failures that automated alerts miss?
STAR Framework
Situation: During a weekly product review at Pixis, the PM shared a dashboard showing that our "creative generation success rate" was 97.2% — seemingly excellent. But something felt off to me. I'd been getting Slack messages from users about failed generations that didn't match a 97% success rate. I also noticed the metric had been suspiciously stable at 96-98% for 3 months despite a major backend refactor that I knew had introduced issues.
Task: I needed to verify whether our success rate metric was actually accurate, and if not, find out what was wrong and correct it before we made product decisions based on bad data.
Action: I started by examining how the metric was calculated. Our analytics tracked two events: generation_started and generation_completed. The success rate was completed / started. I pulled the raw event counts and noticed something immediately: generation_started events for the past month were 12,400, but generation_completed events were 12,060. That gave us 97.2%. But then I checked our backend logs for actual generation API calls — there were 15,800. We were under-counting starts by ~3,400. I traced the discrepancy: our frontend fired the generation_started event in a useEffect that ran after render. If a user triggered generation and then navigated away before the component mounted (common when they clicked "generate" and immediately switched tabs), the event never fired. So we were only counting starts for users who stayed on the page. This systematically excluded the most impatient users — who were also the most likely to experience timeouts and failures. I fixed the tracking by moving the event fire to the click handler (before any async operation) and added a generation_failed event that the backend emitted directly, ensuring server-side truth. I also back-filled the metric using backend logs to get the real historical success rate.
Result: The actual success rate was 76%, not 97%. This was a significant finding — the product team had been deprioritizing reliability work because the dashboard said everything was fine. After presenting the corrected data, the PM immediately reprioritized: we allocated a full sprint to generation reliability. Within that sprint, we identified and fixed 3 backend timeout issues and 1 race condition, bringing the real success rate to 94%. I also implemented a data integrity check: a daily job that compared frontend event counts against backend log counts and alerted on discrepancies greater than 5%. This caught two additional tracking issues in the following quarter.
Tips
- Show that your instinct to question the data came from real-world observations (user complaints), not just paranoia
- Emphasize the business impact of the bad data — decisions were being made based on a false metric
16. Tell me about a time the data told a different story than what people assumed. What did you do?
LP Alignment: Dive Deep
What They're Really Testing: Can you let data override popular opinion or HiPPO (Highest Paid Person's Opinion)? Do you have the analytical skills and the courage to present uncomfortable truths?
STAR Framework
Situation: Our product leadership at Pixis was planning to deprecate the manual creative editor in favor of the AI-powered auto-generation tool. The rationale was that AI generation was "clearly the future" and usage data showed AI generation volume was growing 15% month-over-month while manual editor sessions were flat. The deprecation would free up engineering capacity (including mine) to focus entirely on AI features. As the engineer who maintained the manual editor, I was asked to plan the sunset timeline.
Task: Before planning deprecation, I wanted to validate the assumption that the manual editor was becoming obsolete, because the surface-level usage numbers didn't tell me anything about user value or revenue impact.
Action: I built a more nuanced analysis by joining our analytics data with revenue data from our billing system. I segmented users into three groups: AI-only users, manual-editor-only users, and users who used both tools. The results contradicted the narrative. Manual-editor-only users had an average contract value of $2,800/month. AI-only users averaged $800/month. Users who used both tools averaged $4,200/month — they were our highest-value segment. The manual editor wasn't declining in value; it was being used by our most sophisticated (and highest-paying) customers for brand-critical creatives where pixel-perfect control mattered. AI generation was growing because it served a different use case: high-volume, lower-stakes ad variants. I also surveyed 15 enterprise clients and found that 11 of them considered the manual editor a "must-have" for contract renewal. Deprecating it would put roughly $460K in annual recurring revenue at risk. I prepared a presentation with three options: (1) deprecate as planned (risk: $460K ARR), (2) maintain both tools independently (cost: continued engineering split), or (3) integrate AI assistance INTO the manual editor as a hybrid approach (cost: 6-week project, benefit: serves both user segments). I recommended option 3 with specific implementation details.
Result: Leadership chose option 3. I built the hybrid feature — "AI Suggestions" — as a panel inside the manual editor that could auto-generate text, suggest color palettes, and propose layout alternatives while keeping the user in full manual control. The hybrid approach increased manual editor engagement by 30% and upsell conversion from basic to enterprise tier by 18%, because the AI panel became a compelling demo feature for sales. The $460K ARR was preserved, and the feature generated an estimated $120K in new ARR from upsells in the first quarter. The VP of Product later cited this as an example of "letting data drive strategy instead of assumptions."
Tips
- Show that you went beyond the surface metric (usage volume) to find the metric that actually mattered (revenue)
- Present options with trade-offs rather than just saying "you're wrong" — it's more persuasive and more respectful
Learn & Be Curious — More Frequent Questions
17. Tell me about a time you learned something new that changed the way you approached your work.
LP Alignment: Learn & Be Curious
What They're Really Testing: Can you turn new knowledge into behavioral change? Do you just accumulate information, or does learning actually reshape how you work?
STAR Framework
Situation: I had been building React components at Pixis for about 2 years and considered myself proficient. But I kept running into the same class of bugs: components re-rendering unnecessarily, stale closures in event handlers, and race conditions in data fetching. I was fixing these bugs reactively — patching each instance as it appeared — but not understanding the underlying pattern.
Task: I wanted to fundamentally understand React's rendering model well enough that I could prevent these bugs architecturally rather than patching them one by one.
Action: I spent 3 weeks doing a deep dive outside of work hours. I read the React source code for useState, useEffect, and the fiber reconciliation algorithm. I worked through Dan Abramov's "A Complete Guide to useEffect" and every linked resource. The key insight that changed my approach was understanding that React components are functions that run on every render, and hooks are positions in a linked list — not persistent variables. This reframing made me realize I'd been writing components with a "class component" mental model (persistent instance with mutable state) applied to a functional paradigm (pure functions with snapshots). Concretely, I changed three things in my daily work. First, I started using the "dependency array is a constraint, not an optimization" mindset — previously I'd add useCallback and useMemo liberally as performance fixes, but now I structured components so dependencies were minimal by design. Second, I adopted the "derive, don't sync" pattern — instead of using useEffect to sync derived state (a major source of our bugs), I computed derived values directly during render. Third, I started co-locating state with the components that used it instead of hoisting everything to shared context, which reduced unnecessary re-renders without any memoization. I documented these three patterns as a team coding guideline with before/after examples from our actual codebase.
Result: In the 3 months after adopting these patterns, the number of "re-render" and "stale state" bugs in our sprint bug triage dropped from an average of 4 per sprint to fewer than 1. Code review became faster because the patterns were predictable — reviewers knew what to expect. Two junior engineers told me the coding guideline I wrote was the most useful onboarding document they'd read. The "derive, don't sync" pattern alone eliminated an entire category of bugs we'd been fighting: we removed 14 useEffect calls across the codebase that were synchronizing derived state, each of which had been a source of intermittent bugs.
Tips
- Show the before/after in your thinking, not just your code — the interviewer wants to see a genuine shift in mental model
- Tie the learning to measurable impact on your team, not just yourself
18. Tell me about a time you didn't have the skills or knowledge to complete a task. What did you do?
LP Alignment: Learn & Be Curious
What They're Really Testing: How do you handle being out of your depth? Do you panic, delegate, or systematically close the knowledge gap? Are you honest about what you don't know?
STAR Framework
Situation: Pixis needed to build an interactive performance analytics dashboard that visualized campaign performance across multiple dimensions — spend, impressions, clicks, conversions — with drill-down capabilities, time-series charts, and real-time filtering. The data set was large: 500K+ rows for enterprise clients covering 90 days of campaign data. I'd never built a data-heavy visualization application before. My experience was in form-heavy UIs and creative tooling, not data visualization. The PM estimated 4 weeks; my honest assessment was that I didn't know enough to even estimate accurately.
Task: I needed to rapidly learn data visualization in React, build the dashboard within the timeline, and deliver a product that could handle large datasets without performance degradation.
Action: I was upfront with my manager: "I haven't done this before and I need 3-4 days of learning time before I can give a reliable estimate." He agreed. I used those days strategically. First, I evaluated visualization libraries (Recharts, Victory, Nivo, D3 directly) by building the same chart — a multi-series time chart with 10K data points — in each. I found that Recharts and Victory struggled above 5K points because they render to SVG (one DOM element per data point). D3 with Canvas rendering handled 100K+ points smoothly. So I chose D3 with Canvas for the heavy charts and Recharts for simpler summary charts. Second, I learned about data handling patterns for large datasets: I implemented virtual scrolling for the data table (using react-window), request-level aggregation (having the API pre-aggregate by day/week/month depending on the time range), and client-side memoized filtering using Web Workers so filtering 500K rows didn't block the main thread. Third, I studied existing analytics products (Mixpanel, Amplitude, Google Analytics) to understand UX patterns: cross-filtering, comparison modes, and export flows. After the learning period, I gave a revised estimate of 5 weeks and presented a phased delivery plan: week 1-2 for core charts and data layer, week 3-4 for drill-down and filtering, week 5 for polish and edge cases.
Result: The dashboard shipped in 5 weeks as estimated. It handled 500K rows with sub-200ms filter interactions thanks to the Web Worker approach. The Canvas-rendered time-series chart could display 90 days of hourly data (2,160 data points per series, up to 8 series simultaneously) at 60fps during zoom/pan interactions. Client feedback was strongly positive — two enterprise clients cited it as their reason for upgrading to a higher tier. My manager later used my learning approach (structured evaluation period, phased delivery) as a template for other engineers tackling unfamiliar domains. I also created a reusable useWorkerFilter hook and a Canvas chart wrapper component that other team members used in subsequent features.
Tips
- Lead with honesty about the knowledge gap — pretending you know everything is a red flag for Earn Trust
- Show a structured learning approach, not just "I Googled it and figured it out"
19. Tell me about a time you proactively sought out a new skill or technology. Why and how?
LP Alignment: Learn & Be Curious
What They're Really Testing: Do you wait for the job to force you to learn, or do you anticipate what you'll need? Is your learning motivated by genuine curiosity or just resume padding?
STAR Framework
Situation: At Pixis, our frontend test coverage was about 30% and consisted almost entirely of unit tests for utility functions. We had zero integration tests and zero end-to-end tests. Every release was a manual QA process that took 2 days, and we still shipped regressions regularly — roughly one user-facing bug per release. Nobody on the frontend team, including me, had experience with modern frontend testing beyond basic Jest unit tests. I saw this as both a risk to our product quality and a gap in my own skills.
Task: I proactively decided to learn frontend testing methodologies — not because anyone asked me to, but because I was tired of being anxious on every release day and wanted to fix the root cause.
Action: I set a 6-week self-directed learning plan. Weeks 1-2: I read Kent C. Dodds' "Testing JavaScript" course material and his "Testing Library" philosophy of testing user behavior rather than implementation details. This fundamentally shifted my understanding — I'd been thinking of tests as "verifying my code works" when the better frame was "documenting how users interact with my features." Weeks 3-4: I learned Playwright for end-to-end testing and set it up in our CI pipeline. I started with the 5 most critical user flows (login, creative upload, template editing, campaign creation, variant generation) and wrote E2E tests for each. I chose Playwright over Cypress because of its multi-browser support and better handling of our iframe-based template preview. Weeks 5-6: I wrote integration tests for our most complex components using Testing Library — the creative editor, the campaign wizard, and the variant comparison view. I also set up a PR check that blocked merges if test coverage dropped below the current level (a ratchet pattern that prevented backsliding). I ran a 1-hour team workshop demonstrating the testing approach, with live coding of a test for a feature one of the other engineers was building.
Result: Test coverage went from 30% to 62% over the next quarter as the team adopted the patterns. The 5 E2E tests caught 8 regressions in the first month alone — bugs that would have previously reached production. Manual QA time dropped from 2 days to half a day because QA could focus on exploratory testing instead of regression checking. Release-day anxiety measurably decreased: we went from one user-facing regression per release to one every 4-5 releases. The testing infrastructure I built became a standard part of our development workflow. Three months later, when we interviewed a new frontend hire, we could list "strong testing culture" as a selling point — something that was impossible before.
Tips
- Emphasize that the initiative was self-directed — you identified the gap yourself and acted without being asked
- Show the ripple effect: your learning didn't just help you, it raised the bar for the whole team
20. Tell me about a time your curiosity led to a meaningful improvement or innovation.
LP Alignment: Learn & Be Curious
What They're Really Testing: Does your curiosity produce tangible value, or is it just intellectual wandering? Can you connect disparate ideas into practical solutions?
STAR Framework
Situation: At Pixis, our creative template editor allowed users to position text, images, and shapes on a canvas to build ad creatives. Users frequently complained that alignment was tedious — they'd spend minutes dragging elements, eyeballing spacing, and manually entering pixel values to center things. We had basic snap-to-grid, but no smart guides or auto-alignment. This wasn't on any product roadmap because it was seen as a "nice-to-have" polish feature.
Task: Out of curiosity about how design tools like Figma handled spatial relationships, I wanted to explore whether I could bring intelligent alignment assistance to our editor without a significant engineering investment.
Action: I started by reverse-engineering Figma's alignment behavior on my own time. I inspected their UI, read blog posts from their engineering team, and studied the computational geometry behind it. I discovered that smart guides boil down to a simple concept: for any element being dragged, compute the distance to every edge and center of every other element, and snap when a distance is below a threshold. But doing this naively for 50+ elements on a canvas was O(n^2) per frame — too slow for smooth dragging. I got curious about spatial indexing and learned about R-trees, a data structure for efficient spatial queries. I found a lightweight JavaScript implementation (rbush, 6KB gzipped) that could query "which elements are within 10px of this edge" in O(log n) instead of O(n). I built a prototype over two evenings: the R-tree indexed all element edges and centers on canvas load and updated incrementally on element changes. During drag, it queried for nearby edges and rendered guide lines with a magnetizing snap. I also added "equal spacing" detection — if three elements were roughly equally spaced, it would show a measurement indicator and snap to make the spacing exact. I demonstrated the prototype at our Friday show-and-tell with a side-by-side comparison: aligning 5 elements manually took 45 seconds, while with smart guides it took 8 seconds.
Result: The PM fast-tracked the feature into the next sprint. I polished it over 3 days (edge cases around rotated elements, group snapping, and undo integration) and shipped it. User feedback was immediately positive — our NPS survey comments mentioned "alignment" and "snapping" 12 times in the first month. Template creation time decreased by an average of 22% based on session duration analytics. The feature became a key differentiator in sales demos — our sales team started specifically showcasing it to prospects. The R-tree approach I implemented also had a second application: I used the same spatial index to power a "select elements in region" lasso tool that users had been requesting. The entire feature was built on curiosity about how another product solved a problem — and a willingness to learn a data structure I'd never used before.
Tips
- Show the curiosity chain: you noticed a problem, got curious about how others solved it, learned new concepts, and applied them
- Demonstrate that the improvement was meaningful to the business, not just technically interesting to you