Q10: Tell me about a time you failed or made a mistake

🎯 Google Hiring Criteria Demonstrated

• Cognitive Ability — Honest self-reflection, clear analysis of what went wrong and why
• Leadership — Took ownership of a crisis caused by a team decision, rallied cross-office help to deliver on time
• Role-Related Knowledge — Android architecture trade-offs, understanding why an overlay approach broke message state
• Googleyness — Learned from the mistake, applied lessons to future projects

📖 Full STAR Answer (2.5–3 minutes)

Situation (30 seconds)

In 2019, my team at LINE Hanoi was working on a chat menu redesign. The task was split into two parts — one person worked on the chat menu itself, and I worked on the visual content inside it. We only had 2 members for the whole project.

Early on, we made an architectural decision to overlay the new chat menu on top of the existing Chat screen instead of building a completely new screen. The reason was simple — we wanted to reuse existing APIs and reduce workload. At the time, it seemed like a smart shortcut. We didn't assess deeply enough what this overlay would break.

Task (20 seconds)

That decision turned out to be the mistake. When the new chat menu covered the full screen, any new message that arrived was automatically marked as read — even though the user never actually saw it. This was completely unacceptable UX.

The problem was architectural. The only real fix was to rewrite the chat menu as a separate screen, which meant redoing almost everything my teammate had built over 5 months. And we had a hard deadline we could not change.

The situation was very tight:

• 3 weeks to rewrite 5 months of work
• 2 of those 3 weeks fell during the holiday
• My teammate who built the chat menu was off during the holiday
• Most members from other offices were also on leave — almost no one available for code review

Action (90 seconds)

I sat down and made a quick but honest assessment. It was possible to finish, but I had to be realistic about what it would take.

First — I reached out across offices. I contacted members from other offices that I had worked with before. I was lucky — one in Tokyo, one in Korea, and one in Taiwan were still working during the holiday. The Korea and Taiwan members also agreed to help with some implementation tasks. Having even a small amount of help was critical.

Second — I planned the work carefully. I analyzed which parts of the existing code could be reused, which parts needed to be rewritten, and which just needed fixes. I prepared simple, self-contained tasks that didn't require deep knowledge of our system — tasks I could assign to the colleagues who agreed to help.

Third — I maximized my own throughput. I applied a top-down and bottom-up implementation strategy at the same time. This meant I could keep writing code on one part while waiting for code review on another part. Nothing was blocked. I worked from 8 AM to 10 PM every day, including weekends.

Fourth — I kept the review process moving. I sent pull requests to one of the overseas members for review. Even though they weren't familiar with our codebase, the tasks were structured clearly enough to review.

Result (30 seconds)

We delivered on time. The chat menu was released before the deadline.

Looking at the GitHub stats, I was the only person on the team who had ever submitted 100+ commits in a single day, for 2 consecutive weeks. It was not something I want to repeat.

But more importantly, I learned three things from this experience:

• Prepare more before committing to an approach. The overlay decision saved time on paper but created a much bigger problem later. A short design review upfront could have caught this.
• Assess the risk more carefully. We had only 2 people on the project. There was no safety net. Choosing a risky architecture in that situation made no sense.
• Learn from others earlier. If I had discussed the overlay approach with more experienced engineers before we started, someone likely would have flagged the message-state issue. I now always involve others in architecture decisions, especially when the team is small.

💡 Key Phrases to Practice

• "We made an architectural shortcut that seemed smart at the time — but we didn't assess what it would break"
• "The only real fix was rewriting 5 months of work in 3 weeks"
• "I applied top-down and bottom-up at the same time so nothing was blocked"
• "100+ commits a day for 2 weeks — not something I want to repeat"
• "A short design review upfront could have prevented all of this"

🎤 Delivery Tips

Tone — This Is the Most Important Part

This question is specifically testing whether you can be honest about mistakes. The interviewer is not looking for a story where everything went well. They want to see:

• You can admit the mistake clearly — don't hide it or make excuses
• You can explain why it happened — not just what happened
• You learned something real and applied it later

Don't make the story about how hard you worked or how many commits you pushed. That's impressive, but it's not the point. The point is the lesson.

Time Management

• Situation: 30s — set up the context and the team size
• Task: 20s — explain the mistake and the pressure clearly
• Action: 90s — show you handled the crisis, but keep it brief
• Result: 30s — spend most of this time on the 3 lessons learned

✅ DO:

• Be direct about the mistake: "We didn't assess deeply enough"
• Acknowledge it was a team decision, not just yours — you were part of it
• Show the lessons are specific and actionable, not generic
• Connect the lessons to how you work now

❌ DON'T:

• Blame your teammate for the bug
• Make the story sound like "I heroically saved the day"
• Skip the lessons — they are the most important part of this answer
• Say the mistake was "just bad luck" — it was a decision that could have been avoided

❓ Anticipated Follow-Up Questions

Q1: "Why did you choose the overlay approach in the first place?"

Answer: "Two reasons. First, we wanted to reuse existing APIs from the legacy chat menu — building a completely new screen meant rewriting a lot of backend integration code too. Second, we only had 2 people, so reducing workload felt important. In hindsight, we optimized for short-term speed without thinking about what the overlay would affect. The message-read state was tightly coupled to the screen lifecycle, and overlaying on top of it broke that without us realizing it early enough."

Q2: "How did you know it was possible to finish in 3 weeks?"

Answer: "Honestly, I wasn't 100% sure at first. I sat down and did a quick analysis — which parts could be reused, which needed rewriting, which just needed fixes. Once I mapped that out, I could see a path. But I also knew I couldn't do it alone during the holiday. Reaching out to colleagues in other offices who were still working was the key decision. Even small help — a few tasks taken, some code reviews done — made the difference between possible and impossible."

Q3: "What do you do differently now because of this experience?"

Answer: "Three things. First, before committing to an architecture, I always do a quick design review — even if it's just a 30-minute discussion with one or two other engineers. Second, when the team is small, I choose safer approaches even if they take more upfront effort. The risk of a small team is that there's no one to catch mistakes early. Third, I now involve others earlier in technical decisions. I learned that other people's experience can save you from mistakes you can't see yourself."

Q4: "Was there a moment you thought you wouldn't make the deadline?"

Answer: "Yes, the first few days. I was mapping out the rewrite and realizing how much work it actually was. The holiday made it worse — I knew I'd be mostly alone. But once I finished the analysis and confirmed that the Korea and Taiwan members could help, the plan became concrete. After that, it was just execution. The top-down and bottom-up strategy helped a lot — I was never waiting for anything. Every hour was productive."

📊 Story Strength Assessment

Overall: 9/10

Why this works well for "failure" questions:

• The mistake is real and specific — not vague or generic
• The cause is a decision, not bad luck — shows self-awareness
• The lessons are concrete and applied — not just "I learned to communicate better"
• The recovery shows competence without overshadowing the lesson

🎯 Practice Checklist

• [ ] Can explain the overlay mistake clearly in 1-2 sentences
• [ ] Can state the 3 lessons naturally without sounding rehearsed
• [ ] Practiced keeping the "action" section brief — don't overload on the heroics
• [ ] Can answer all 4 follow-up questions smoothly
• [ ] Timed full STAR answer at 2.5–3 minutes
• [ ] Tone is honest and reflective, not defensive