Q1: Tell me about a time you led a project from start to finish

🎯 Google Hiring Criteria Demonstrated

• Leadership - Owned the project across the entire lifecycle, not just coding
• Cognitive Ability - Systematic requirements analysis + system architecture design for reliability at scale
• Role-Related Knowledge - Android architecture (WorkManager, Kotlin Flow, Room), phase-based system design
• Googleyness - Cross-functional collaboration with Design, PM, QA, Server team

📖 Full STAR Answer (2.5–3 minutes)

Situation (30 seconds)

In 2021, I was assigned the Event Effect feature for LINE's Home tab — full-screen celebration animations that show when users have a birthday or when there is a cultural event like New Year. This feature would reach 200 million users across 200+ countries.

The initial requirement I received was very simple: "Show special animation during user birthday or a holiday." At first glance, it sounds straightforward. But as code owner of the Home tab and the main developer for this feature, I immediately knew this simple statement hid many complex edge cases that could cause serious problems if we didn't handle them properly.

Task (20 seconds)

My role was not just to code what was written. I needed to own the entire project lifecycle — from clarifying requirements, through development, to launch. That meant I had to uncover all the ambiguous scenarios first, align with stakeholders, then build the feature in a way that could actually work at scale.

Action (90 seconds)

First — Requirements Discovery

Before writing any code, I systematically mapped out the user journey and identified all the ambiguous situations. For example:

• What if a user opens the app at 23:59:50 on their birthday? Do we show the full 4-second animation, then suddenly dismiss it 10 seconds later at midnight?
• What about users born on February 29? In non-leap years, do we celebrate on Feb 28 or March 1?
• What if a user's birthday falls on the same day as a public holiday? Which animation do we show?
• What if the user has poor network and the animation file fails to download?

I organized an alignment meeting with the Product Manager, Design team in Korea, QA, and the Server team. Rather than just listing problems, I proposed a default behavior for each scenario based on what would give the best user experience. This discussion revealed 15+ scenarios the original requirement didn't address at all. We reached consensus on each one, and I documented everything — input, output, and error handling for every case.

Second — Architecture Design

The tricky part of this feature was not just the UI. The system had to handle many things reliably: downloading animation assets ahead of time, showing the effect at exactly the right moment, handling network failures, managing multiple events at once, and cleaning up resources afterward — all while surviving app restarts and device reboots.

So I designed the system as 4 independent phases, each with its own responsibility and error handling:

• Phase 1 — Event Discovery: Detects when an event should happen (birthday from profile update, holiday from server push), validates it, and kicks off the next phase.
• Phase 2 — Resource Acquisition: Downloads animation assets 5 days before the event. This was a key decision — we don't want to rely on network connectivity at the moment the celebration should show. If download fails, WorkManager retries with exponential backoff automatically.
• Phase 3 — Showtime: When the event time arrives, the state changes to READY. I used Kotlin Flow combined with Room's reactive queries so the UI updates automatically — no polling needed. The system also handles priority: if a birthday and a holiday land on the same day, the personal event wins.
• Phase 4 — Cleanup: Scheduled 1 day after the event ends. This grace period is intentional — a user who opens the app at 23:59:59 on their birthday should still see the celebration, not find it already cleaned up.

The separation of phases meant each part could fail independently without breaking the others. And using WorkManager throughout meant the scheduling survived app kills and device reboots — critical for a feature where timing is everything.

Third — Documentation and Knowledge Sharing

I wrote a technical blog post documenting the engineering approach and all the decisions made during this project, so other teams could learn from it.

Result (30 seconds)

The feature launched successfully with zero bugs related to unclear requirements — the upfront requirements work paid off. The 4-phase architecture made the system reliable at scale — no missed celebrations, no crashes from resource issues, and the design was clean enough that I documented it as a technical blog post for other teams to learn from. The thoroughness of both the requirements process and the system design built trust with PM and Design — they started involving me earlier in future projects.

Key learning: "Owning a project from start to finish means more than just coding. It means making sure the requirements are right, designing a system that handles real-world complexity, and sharing what you learn."

💡 Key Phrases to Practice

• "The simple requirement hid many complex edge cases that could affect 200 million users"
• "Rather than just listing problems, I proposed default behaviors for each scenario"
• "15+ scenarios the original requirement didn't address at all"
• "I designed it as 4 independent phases — each one can fail without breaking the others"
• "We pre-download assets 5 days before the event — we can't rely on network at the moment the celebration should show"
• "Kotlin Flow with Room's reactive queries — the UI updates automatically when the state changes, no polling needed"
• "Zero bugs related to unclear requirements"

🎤 Delivery Tips

⏰ Time Management

• Situation: 30s — Set up the feature, the scale, and the deceptively simple requirement
• Task: 20s — Signal that you owned the whole lifecycle, not just coding
• Action (Requirements): 35s — 2–3 specific edge cases, the alignment meeting, 15+ scenarios
• Action (Architecture): 40s — The 4 phases, why each decision matters (5-day buffer, Flow+Room, priority, cleanup grace period)
• Action (Documentation): 15s — Blog post, quick
• Result: 30s — Zero requirement bugs, reliable system, trust built

✅ DO:

• Only give 2–3 edge case examples in the interview — don't list all 15. Pick the most vivid ones (Feb 29, the 23:59 timing, network failure)
• Make it clear you proposed solutions, not just raised problems — that's what shows senior-level thinking
• When explaining the 4 phases, explain why each decision was made — the 5-day buffer is about not trusting network at showtime, the cleanup delay is about the user at 23:59:59. The reasoning matters more than the structure.
• Mention the blog post naturally — it's concrete evidence you share knowledge

❌ DON'T:

• Don't get lost in technical details of WorkManager API or Kotlin Flow syntax — stay at the concept level
• Don't list all 15 edge cases — the interviewer will lose focus
• Don't mention the post-launch production crisis here — that's a separate, stronger story for a different question
• Don't rush through the architecture — this is the heart of the "led a project" story. It shows you designed a system, not just wrote code

Tone:

• Ownership mindset — you didn't just wait for requirements, you went and figured them out
• Practical about the technical decision — you evaluated options clearly, chose the right trade-off
• Collaborative — you worked with PM, Design, QA, Server team, not alone

❓ Anticipated Follow-Up Questions & Answers

Q1: "Can you give more examples of edge cases you discovered?"

Answer: "Sure. One interesting one was about timing. A user's birthday runs from 0:00 to 23:59. But what if they open the app at 23:59:50? Do we show the full 4-second animation and then suddenly dismiss it 10 seconds later when midnight hits? That would feel very confusing. So we decided — if the user opens the app late at night on their birthday, we let the animation play fully. We don't cut it short. It's a special moment, and we don't want to take that away from the user.

Another one was February 29 birthdays. In non-leap years, when do we celebrate? We decided February 28, so the celebration still happens in the same month as their actual birthday. Small decision, but it affects real users.

And network failures — what if the animation file fails to download right before the event? We solved this by pre-downloading the assets 5 days before the event starts, so we don't rely on the network at the last moment. And if the download fails, we retry with exponential backoff, so it keeps trying without hammering the server."

Q2: "Why did you split it into 4 phases instead of building it as one flow?"

Answer: "The main reason was independent error handling. If everything is in one flow, a network failure during asset download could block the whole system. With 4 phases, each one fails on its own. If Phase 2 fails to download assets, it retries with exponential backoff — but Phase 1 already finished cleanly, and Phase 3 and 4 are waiting independently.

This also made testing much simpler. Each phase has clear input and output. I can test Event Discovery without worrying about what happens during Showtime. And it made the system survive app restarts — each phase is scheduled via WorkManager, so even if the app is killed between phases, the next phase picks up where it left off."

Q3: "Why pre-download assets 5 days before instead of downloading when the event is about to show?"

Answer: "Two reasons for pre-downloading at all: first, we can't control when or where the user will be when their birthday starts. A user in a subway with bad network shouldn't miss their celebration. Second, if the first download fails, WorkManager retries with exponential backoff — we need enough time for multiple retries to succeed before showtime.

But then the question is: why not 30 days? Or 2 weeks? The longer the buffer, the more problems appear. Events can overlap — if we pre-download too far ahead, we might be holding assets for multiple upcoming events at the same time, wasting device storage. And there's also a higher chance that the design team updates or replaces an animation asset closer to the event. If we downloaded 2 weeks ago, we might show an outdated version.

5 days was the balance point — enough time for reliable retries and network recovery, short enough to avoid resource waste and asset staleness."

Q4: "How did you handle disagreements during the requirements meetings?"

Answer: "There weren't major disagreements, but there were scenarios where the right answer wasn't obvious. For example, when a user's birthday falls on the same day as a public holiday — do we show both animations, or pick one? Different stakeholders had different instincts.

My approach was to propose a default behavior first, then explain my reasoning based on user experience. For the birthday vs holiday case, I suggested prioritizing birthday because personal moments have higher priority than general events. Users can experience holiday atmosphere from real life or from friends' profiles, but a birthday celebration on the app is something only we can give them. We discussed it, everyone agreed, and we moved on.

The key was not just asking 'what should we do?' but coming with a proposed answer and a reason. That made the discussions much faster."

Q5: "Why schedule cleanup 1 day after the event ends instead of right when it ends?"

Answer: "Think about a user who opens the app at 23:59:59 on their birthday. The event technically ends at midnight. If we clean up resources right at midnight, that user would open the app and see nothing — their birthday celebration is already gone. That feels wrong.

The 1-day grace period means even late-joining users still get their moment. It costs almost nothing — we're just keeping a few animation files on the device for an extra day. But the user experience difference is huge. This kind of decision is what separates a feature that feels polished from one that just technically works."

Q6: "How did you decide which edge cases were important enough to discuss with stakeholders?"

Answer: "I thought about three things for each scenario: how visible it is to the user, how often it would actually happen, and how bad the experience would be if we got it wrong.

February 29 birthdays — rare, but very visible to the people it affects. If we just skip their birthday, that's a bad experience. So we had to decide.

The 23:59 timing case — not super rare, and the confusion would be immediate. So we had to define a clear rule.

Some edge cases I decided were low priority and just documented them without a full discussion. For example, what happens if a user changes their birthday in their profile — that's an edge case, but it's unlikely and the impact is small. We noted it but didn't block on it.

The goal was to focus the stakeholder meeting on decisions that actually mattered, not turn it into a 3-hour session."

📊 Story Strength Assessment

Overall: 9.5/10

Why this works for "led a project from start to finish":

• Clean single narrative arc — requirements → design → launch
• Shows you think like a senior engineer: requirements first, then system design, then code
• The architecture section shows real depth — every decision has a user-facing reason
• The blog post is concrete proof you document and share
• Concrete and memorable details (Feb 29, 5-day buffer, 23:59:59 cleanup grace period)

🎯 Practice Checklist

• [ ] Can explain the vague requirement and why it was actually complex (30 seconds)
• [ ] Can give 2–3 edge case examples smoothly without listing all 15
• [ ] Can explain why you proposed default behaviors, not just questions
• [ ] Can explain the 4-phase architecture and why each phase is separate (not just what it does)
• [ ] Can explain the 5-day buffer reasoning naturally (network reliability, not just "we pre-download")
• [ ] Can explain the cleanup grace period as a user-experience decision
• [ ] Can mention the blog post naturally
• [ ] Practiced all 6 follow-up questions above
• [ ] Timed full STAR answer at 2.5–3 minutes