Experience Interview — 40 min

Pick 2-3 stories. Use STAR (Situation / Task / Action / Result). Match the resume metrics.

Full STAR with key phrases and follow-ups for each story is in ../behavior/. The summaries below are the short version to use during the interview.

Self-introduction (~75 seconds, use in the intro block)

Hi, I'm Tuan. I'm an Android engineer with about 10 years of experience. Currently, I work at LY Corporation in Tokyo, where my work impacts over 200 million users worldwide.

My focus has evolved from developing individual features to building the foundation that helps our entire engineering team. I now concentrate on engineering excellence, platform development, and mentoring — creating systems, standards, and guidelines that enable faster and more stable feature development across the organization.

This includes establishing coding conventions, defining architecture guidelines, building frameworks that help our 100+ engineers across multiple dev centers deliver high-quality code consistently and efficiently, and mentoring developers to grow from junior to senior level.

On the side, I built MonoSketch — a browser-based ASCII diagram editor in Kotlin/JS. ~1800 stars, 1000+ MAU, featured once on Hacker News.

Delivery tips:

• Pause after "200 million users worldwide" — let the scale land.
• Hit the "individual features → foundation that helps the entire team" line clearly. That's the central signal.
• The third paragraph is concrete proof of the second. Don't rush it.
• End on MonoSketch — shows you build outside work too.
• "Why Komoju" was already covered with HR — don't repeat it here.
• Total target: 60-75 seconds. Do not exceed 90.

Story bank

Story 1 — Doze mode server spike (90% reduction, 200M users)

Best for: most complex technical problem, debugging, deep dive, dive into platform.

• S: Server team reported request spikes on the recommendation API at midnight and 5-6 AM. I owned the Home tab that triggered the calls but not the recommendation logic itself. The code looked correct. No bugs, no retry loops.
• T: Find why spikes happened despite correct code. Flatten the traffic without breaking freshness.
• A: I analyzed server stats and saw spikes only at 0-minute marks every hour. The biggest were midnight and 5-6 AM. I studied Android Doze mode and connected the dots: at midnight, people plug in their phone → Doze exits → all queued WorkManager jobs run at once. At 5-6 AM, alarms wake the screen → same thing. The code was fine. The problem was the interaction between WorkManager and Android system behavior. Solution: only sync when the app is actually opened. People don't all open LINE at exactly the same minute, so traffic distributes naturally.
• R: 90% reduction in nighttime requests. No UX impact. Wrote up Doze behavior so the team would not hit the same trap.
• Lesson: "The most complex problems are not in the code you wrote. They are in how your code interacts with the system it runs on."

Komoju hook: this is the closest story to their world. State machine + WorkManager + server cost. Use it if they ask about "complex bug" or "performance".

Story 2 — APNG memory crisis (500MB → 5MB, same-day hotfix)

Best for: production crisis, failure, performance improvement, learning from mistakes.

• S: Right after launching Event Effect (full-screen birthday animations) to 200M LINE users, Android crashes started. Even high-end phones crashed if many apps were running. The Design team and PM had just announced the feature.
• T: Stop the bleeding now. Find root cause. Ship a proper fix. Improve the process.
• A: Inside hours, I confirmed the pattern (Android, memory-related), called an emergency meeting, and proposed the hard call: "Disable Event Effect on Android via feature flag while we fix it properly." Crashes stopped that day. With users protected, I profiled the APNG library — it decoded all frames upfront, so a full-screen 4-second animation took 500MB. Test devices were clean; real users had 30-50 apps running with no headroom left. I evaluated three options (fix in-house C++ library, find an OSS library with JIT decoding, build from scratch) and picked OSS. Benchmarked: 500MB → 5MB, 100x improvement. Same visual quality, less battery. Rolled it out to my feature, then app-wide via a Glide loader and migration guide. Stickers used 80% less memory after.
• R: Crisis resolved same day. Proper fix in 2 weeks. Feature re-enabled with zero crashes. App-wide benefit because Stickers and other APNG features moved over too. New testing standard added: simulate 30+ apps running and memory pressure before launch.
• Lesson: "Test in real-world conditions, not lab ideals. And: temporary mitigation + proper fix beats rushing under pressure."

Komoju hook: shows you handle production incidents well. Two-phase thinking (mitigate → fix → improve) is exactly what a payments shop wants.

Story 3 — Event Effect end-to-end (200M users, 4-phase architecture, zero requirement bugs)

Best for: led a project from start to finish, handling ambiguous requirements, system design.

• S: I was assigned Event Effect for the LINE Home tab — full-screen celebration animations for birthdays and holidays, 200M users, 200+ countries. The initial requirement was one sentence: "Show special animation during user birthday or a holiday." It looked simple. It wasn't.
• T: Own the whole lifecycle: clarify requirements, design the system, deliver, share.
• A: First, I mapped the user journey and listed every ambiguous case. Some examples: user opens the app at 23:59:50 on their birthday (let the animation play fully); a Feb 29 birthday in non-leap years (celebrate Feb 28); birthday + holiday on the same day (personal moments win); animation download fails (pre-fetch 5 days ahead, retry with backoff). I ran an alignment meeting with PM, Design (Korea), QA, and Server team. Instead of just asking "what should we do?", I proposed a default for each case. The discussion uncovered 15+ scenarios the original requirement did not cover. Then I designed the system as 4 independent phases: Discovery → Resource Acquisition (5 days early) → Showtime (Flow + Room reactive queries, no polling) → Cleanup (1 day grace period). Each phase fails on its own and survives app kill / device reboot via WorkManager. Finally, I wrote a tech blog so other teams could reuse the pattern.
• R: Launched on time. Zero bugs caused by unclear requirements. No missed celebrations. Blog became a reference. PM and Design started involving me earlier in future projects.
• Lesson: "Owning a project means making the requirements right and designing for real-world complexity, not just coding what is written."

Komoju hook: the 4-phase pattern is similar to a payment state machine (PENDING → PAID/EXPIRED/FAILED with cleanup). Pre-fetch + WorkManager retries = backoff in your take-home.

Story 4 — Home tab / Smart Channel redesign (60% fewer bugs, adopted across LINE)

Best for: technical leadership, architecture, refactor without freezing delivery, pattern propagation.

• S: Home tab and Smart Channel were two different features but had the same problems: messive data flow, unclear layers, no single source of truth, and many ad-hoc anti-corruption shims piled up over time. Every new feature was slow and risky. Nobody could predict what would break.
• T: Untangle the code. Clear layers, one-direction data flow, one source of truth. Without freezing feature delivery.
• A: I saw the same root cause across both features — not "fix Home" + "fix Smart Channel" separately, but one fix that helped both. Designed a layered architecture with one-direction data flow. Pushed back on over-design ("we do not need a DSL"). Migrated step by step. Old and new code lived together for one release. Wrote it up so other teams could use it.
• R: 40% faster onboarding and feature work. 60% fewer bug reports on those features. Other teams across the LINE app then used the same architecture.
• Lesson: Senior-IC impact comes from patterns other teams adopt, not just code I ship. The win was naming the shared root cause across two different-looking features.

Tips when telling this story:

• When asked what: name the four problems (tangled flow / unclear layers / no SSoT / ad-hoc shims).
• When asked how: emphasize that I saw the common root cause across two features.
• When asked impact: lead with "other teams used it", then back it up with metrics.
• When asked what was hard: getting buy-in for step-by-step migration instead of a rewrite. Resisting over-abstraction.

Story 5 — TLA Architecture Committee (influence without authority, 150+ engineers)

Best for: influencing without authority, challenging the status quo, pushing back on seniors.

• S: I joined the TLA (The Layer Architecture) Committee for the LINE app — a group setting Android architecture standards across 150+ engineers. iOS guidelines were already written, Android discussions had run for months. I had no formal authority and was joining a group of senior engineers and managers who were already aligned. After reading the docs, I felt the direction was wrong — too theoretical, too much abstraction, designed for big features when 50% of LINE's features stay small.
• T: Change direction without authority. Respect the work already done. No month-long delay. Keep the main goal (iOS/Android alignment).
• A: I gathered data, not opinions. Wrote a bash script to count files and lines per module across the LINE Android codebase. Result: 50% of features are small, 75% considerably small. Only Home and Smart Channel are truly large. Then I drafted specific feedback with proposed changes that saved the prior work and still hit the Phase 1 target. Suggested Google's Android architecture as a more practical reference. Organized a face-to-face meeting because written feedback was not landing. In the meeting I showed the data, walked through the trade-offs, and made my intent clear: this is for the product, not for ego.
• R: Committee accepted my proposals. Phase 1 finished on time. The TLA iOS author told me he saw my view and respected the data + compromise approach. My manager (who was not happy with me at first) was happy with the outcome.
• Lesson: "Influencing without authority needs data, respect for prior work, and a path forward — not just criticism."

Story 6 — Junior iOS mentor (promotion, no single-person dependency)

Best for: mentoring, growing people, taking calculated risks.

• S: My manager assigned me and a junior iOS engineer to a video autoplay feature (similar to FB/X feed). The junior was usually given simple tasks only. His direct iOS mentor did not believe in him. My manager focused on results, not growth.
• T: Convince stakeholders to let the junior lead. Set up safety nets. Deliver the project.
• A: Instead of taking the lead myself, I proposed: "Let him be the main person in charge." I told my manager: "If the project fails, I take responsibility." Set up a checkpoint system — if he missed a checkpoint, I jump in. Gave him real ownership: he wrote the design doc, identified edge cases, drove communication with PM. I guided him on structure and clean code; iOS seniors guided him on platform details. First checkpoint: deadline was 2 weeks; he delivered in under 1 week with deeply observed patterns from other apps and thoughtful edge case handling.
• R: Project shipped successfully with few bugs (especially on iOS). Junior was promoted to mid-level after this project. Manager and iOS senior changed their view about him. Team gained confidence in growing people, not just delivering features.
• Lesson: "People often have more capability than they are given credit for. The key is structured support — not throwing them in, not blocking them."

Story 7 — Chat menu rewrite (the failure story)

Best for: tell me about a failure, project that did not go well, mistake.

• S: In 2019 at LINE Hanoi, my teammate and I (just 2 people) worked on a chat menu redesign. Early on we made an architectural shortcut: overlay the new menu on top of the existing Chat screen instead of building a separate screen. Reason: reuse APIs, reduce workload. We did not deeply assess what the overlay would break.
• T: After 5 months of work, we found the bug: when the new menu covered the screen, incoming messages were marked read even though the user never saw them. The only real fix was to rewrite the menu as a separate screen. 3 weeks left, 2 of them during the holiday, my teammate off, most reviewers off too.
• A: I sat down and made an honest plan. Reached out to engineers in Tokyo, Korea, Taiwan who were still working over the holiday — Korea and Taiwan helped with implementation, Tokyo helped with reviews. Prepared small, self-contained tasks that did not need deep system knowledge so they could pick them up. Worked top-down and bottom-up at the same time so I was never blocked waiting for review. Worked 8 AM to 10 PM every day, including weekends. 100+ commits per day for 2 weeks. (Not something I want to repeat.)
• R: Delivered on time. The chat menu shipped before the deadline.
• Lessons (this is the most important part of the story):
  1. Prepare more before committing to an approach. The overlay saved time on paper but cost much more later. A short design review upfront could have caught this.
  2. Match risk to team size. With only 2 people, there is no safety net. A risky architecture in that situation made no sense.
  3. Pull in others earlier on architecture decisions. Someone with more experience would likely have flagged the read-state coupling.

Tip: Spend most of the "Result" time on the lessons, not the heroics. The point of a failure story is what you learned, not how hard you worked.

Story 8 — MonoSketch (1500+ stars, 60fps with 500+ elements)

Best for: side project, end-to-end ownership, learning new tech.

• S: I wanted ASCII diagrams in the browser.
• T: Build a custom rendering engine in Kotlin/JS.
• A: Tile-based viewport. Dirty-region invalidation. Canvas API. Owned every layer: editor model, undo stack, infinite scroll, GitHub Actions CI/CD.
• R: 1500+ stars. 60fps with 500+ elements.
• Lesson: "Shipping a side project end to end teaches what frameworks hide from you."

Likely behavioral questions — which story to use

Pre-built answers for common questions

Two principles to thread through every answer:

1. Data-driven. I measure before I decide. I don't argue with opinions — I bring numbers. → Doze (server stats found the pattern), APNG (500MB → 5MB benchmark), Lottie vs APNG (8x memory measured = 6-month debate ended), TLA (50% of features were small = data-backed push for the committee).
2. Business impact orientation. Every technical choice ties back to a business outcome. → Doze fix = 90% server cost reduction. APNG fix = zero crashes (user retention). Event Effect = zero requirement bugs at launch (no rollback cost). Smart Channel = 60% fewer bugs (team velocity). MonoSketch standards = long-term project health (no rewrite cost).

When in doubt, frame the answer around: "What did this save / earn / unlock for the business?" And if you make a claim, follow it with a number.

"What methodology do you apply when you're assigned a new feature?"

5 steps. Don't recite — let them flow. Anchor each to a story.

1. Understand the requirement, not the spec. The spec is one paragraph; the requirement is the full user journey + every edge case. List ambiguous cases and bring proposed defaults, not open questions. → Event Effect surfaced 15+ scenarios that way.
2. Design in phases with clear boundaries. Most features split into 3-4 stages that each fail on their own. → Event Effect: discovery → pre-fetch → showtime → cleanup. Take-home: create payment → poll → render result. Each phase has its own state and survives process death.
3. Plan for failure before happy path. List failure modes first — network off, app killed, duplicates, races. Design idempotency and retry boundaries around them. Payments make this non-negotiable; I do it anyway.
4. Build a vertical slice end-to-end. One full path, even rough, before adding variants. Stops over-design.
5. Document for reuse. Hard problems (Doze, APNG memory) → write up so the next team doesn't repeat the trap. Foundation work compounds.
6. Risk analysis doc — for foundation/platform changes. When the change touches shared code, I write a risk doc before coding: blast radius (which features are affected), severity, migration path, rollback plan, owners per area, rollout strategy (canary, feature flag). Foundation work has wide side effects — one mistake = many regressions. The doc forces me to think before everyone else has to react. → APNG migration: rolled to my feature first, then app-wide via a Glide loader + migration guide. Stickers and other features adopted it without breakage.

Two principles run through every step: data-driven (measure before deciding) and business-impact orientation (every step ties to a business outcome — cost, crash rate, launch quality, velocity). Senior signal lives in steps 1, 3, 5, 6. Junior engineers jump to step 4 first. Make sure 1 and 3 land before you talk about coding. Step 6 is what separates "I ship features" from "I ship across the company".

"How do you align with product/design when the feature is hard or vague?"

Concrete techniques, not just "I ask questions":

1. User journey map first. I draw the screens/states the user moves through, in order. Forces concrete thinking and exposes gaps the prose hid.
2. Edge case list with proposed defaults. Instead of "what if the user opens the app at 23:59 on their birthday?", I write "if user opens at 23:59 on their birthday, I propose we let the animation play fully because [reason]. Agree?" PMs answer 10x faster when the default is concrete.
3. Single alignment meeting with everyone in the room. PM + Design + QA + backend at once, not bilateral chats. Stops re-litigation. → On Event Effect, that one meeting uncovered 15+ scenarios.
4. Decision log. Every clarification → written down with the rationale. So nobody forgets and nobody reopens. "On YYYY-MM-DD, we decided X because Y."
5. Bring data, not opinions, for technical disagreements. Lottie vs APNG: I measured 8x memory difference. The number ended a 6-month debate. If I disagree with PM on a "feel" thing, I prototype both and let the data lead.
6. Pre-mortem. "Imagine launch day. What could go wrong?" — in front of PM. Helps them see why edge cases matter to users, not just engineers.

Lesson behind it: ambiguity isn't the PM's fault. It's the cost of being early. My job is to convert ambiguity into decisions cheaply.

"Tell me about a time you disagreed with a senior engineer."

Story 5 (TLA). Frame: "I had no authority. I gathered data. I respected the prior work. I proposed a path forward, not just criticism." Use the 50%-of-features stat as your anchor.

"How do you mentor junior engineers?"

Story 6. Concrete: checkpoint system, take responsibility on their behalf, guide on structure not implementation. Goal: they own a domain end to end.

"Why Komoju?" (already given to HR — keep the engineer-round answer consistent)

"LINE is a stable product — there's limited room for bigger impact at this stage. Komoju's app is early, which is exactly where my foundation work has the most leverage: I can bring in the standards, conventions, and architecture patterns I've spent years building, without having to convince 150+ engineers or navigate committee processes first. Less policy, faster adoption, almost immediate launch.

I do the same thing on my own project, MonoSketch. Even as a solo developer, I apply high standards on module design, architecture, backward and forward compatibility, and commit log discipline. I don't always follow them perfectly — but discipline is what keeps the project healthy in the long run. I want to bring that same discipline to Komoju, where the stakes are real."

Delivery: lead with the LINE-stable / Komoju-early contrast. The MonoSketch line is the proof — say it as "I do this even on my solo project". Don't oversell payments; the foundation-work fit is the real reason.

"Tell me about a feature you killed or descoped."

Take-home example: "I deliberately did not add a debug UI menu. I chose ADB instead. I also did not add Hilt. I did not split into use-cases. Each was a yes-then-no." Or: Story 2 — temporarily disabling Event Effect on Android to protect users.

"What is a technology you tried and abandoned?"

Compose (from NOTES.md): MVVM-overkill trap, easy to mix presentation and UI logic. Show nuance — you still chose it for this take-home. Or Lottie: profiled it, found 8x more memory than APNG, recommended against it for full-screen animations.

"What is the hardest bug you have debugged?"

Story 1 (Doze). The "code looked correct" angle is strong. Backup: Story 2 (APNG) — debugging a memory issue under production crisis pressure.

"How do you handle code review disagreements?"

"I separate facts from preferences. If it is a fact (correctness, performance, security), I dig until we agree. If it is a preference (style, naming), I default to the author once concerns are heard. The Code Review Committee at LINE wrote this down."

"Tell me about a project that failed."

Story 7 (Chat menu). Be honest about the overlay decision. Spend most of the time on the 3 lessons, not the recovery effort.

"Tell me about working under pressure."

Story 7 (Chat menu) for hard deadline. Story 2 (APNG crisis) for production pressure. Pick based on what they want — speed of decision-making vs cross-office coordination.

"Why are you leaving LY/LINE?"

Be diplomatic. Talk about growth and scope, not negatives. "I have run the playbook of LINE-scale legacy migration. I want to apply that thinking earlier in a product's life."

Questions YOU should ask (last 5-10 min)

These show seniority. Pick 2-3:

1. "How is the SDK team structured? Is the merchant POS app a separate codebase from the customer-facing payment SDK?"
2. "What is the test and release cadence? Manual QA, or test automation plus canary rollout?"
3. "How do you handle PCI-DSS scope on the Android side? Tokenization at source, or is the SDK in scope?"
4. "What is the hardest concurrency or state machine bug you have shipped recently?" — pulls them into a real story. Tells you about the culture.
5. "What does the first 90 days look like? What would I own?"
6. "How does Komoju think about SDK API stability — semver, deprecation, multi-version support?"
7. "What is the ratio of engineers to PMs to designers? How are mobile-specific decisions made?"