In mobile interviews, I often discuss one question: what happens to a feature after rollout? Not the ticket in the tracker.The feature itself. How does the team know it didn’t just reach users, but actually works? A feature can be broken without crashing the app once. The hardest kind of mobile release is the quiet one. Pre-release checks didn’t show anything critical, Crashlytics is quiet, alerts are silent. Then a day later you see it: users are entering the flow, but not reaching the result. Somewhere an early return fired, a condition filtered out part of the audience, and the path just stopped. The app is alive. Formally, there is no incident. But for those users, the feature doesn’t work. In mobile development, “doesn’t crash” and “works” are two different system states. Especially when the issue lives in one segment: an older app version, a specific OS, remote config, or staged rollout. The funnel drops a little, support gets a few isolated complaints, and formally everything still looks calm. This is usually where teams don’t have much time left. I’ve lived in that mode many times: the backlog doesn’t end, the release has already moved on, and you can’t manually watch every user flow. I’m not suggesting a post-release watchtower for every button. But I am interested in where the team draws the line between “the task is closed” and “the user got the result”. A screen-open event is useful, but it rarely answers the main question by itself. You need a result signal: order created, card linked, subscription activated. And nearby signals too: errors, retries, conversion drop by app version or segment. This is not one role’s responsibility. QA, product, engineering, and analytics all see different parts of the picture. A good answer usually comes from several signals. In interviews, I don’t expect a perfect answer or the name of the “right” dashboard. I’m interested in where a person looks after rollout: what already means “it works in prod” for them, and what only means “it didn’t crash”. Have you had a release where there were no crashes or alerts, but part of the users still didn’t reach the result? How did you notice it?
Crash-free ≠ successful
Full Article
Original Source
Read the full article at Hackernoon →KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.