Behavioral Interview

The interviewer checks whether you can give a short, relevant summary and why you fit this role. Answer in one to two minutes: present (your role, stack and current work), past (how you got here, one result), future (why this role is your next step). Tailor it: lead with what the vacancy asks for; skip school, hobbies and the full CV One result with a number: a faster cold start, a crash rate you cut Red flags: retelling the CV job by job, a five-minute monologue, nothing about what you want next Example Present: "Android developer, three years in Kotlin. I'm on the passenger team of a ride-hailing app: Compose screens and startup time." Past: "I joined as a junior on Java and XML and helped move the app to Kotlin, Compose and MVVM." Future: "I want a team where performance on cheap phones matters, like yours."

The interviewer checks your motivation and whether you would leave them for the same reason. Give one honest reason framed as moving toward something (harder problems, a bigger product, a stronger team), then name two specific things that draw you to this company. Toward, not away: "I've outgrown my tasks" or "I want more scale", never "my manager is useless" Specific about them: their product, stack, a blog post or a talk; "a great company" says nothing A layoff or a short job: say it plainly in one sentence and move on Red flags: badmouthing your employer, "only the money", knowing nothing about them Example "Our app is stable, and the work is now mostly small fixes. You're moving your app to Compose and care about performance on cheap phones, which is exactly what I want to do next."

The interviewer checks the scale of what you have built and what you personally did in the team. Use STAR: the situation and its problem, your task, the actions you took and why, and a measurable result. "I" for your part: "we" only for the team's work; you are scored on what you did One decision in depth: expect "why that and not X?" A number for the result: crash-free users, load time, conversion, tickets Red flags: technologies with no problem behind them, an architecture you cannot explain, the team's success as yours Example Situation: cold start took almost 3 seconds on budget phones, our main audience Task: I led the startup work Action: Macrobenchmark to measure, a Baseline Profile, lazy init of three SDKs that ran in Application.onCreate Result: about 1.8 s on our slowest test phone, and a CI benchmark keeps it there

The interviewer checks self-awareness and honesty. Name two or three strengths that fit the role, each backed by a fact, and one real weakness that does not block the job, together with what you already do about it. Strengths with proof: a fact from your work, not adjectives like "responsible" A real weakness: speaking up in big meetings, asking for help late, little experience in an area the role does not centre on What you do about it: a habit that already works, so the answer ends on progress Red flags: "I have no weaknesses", a disguised boast ("I'm a perfectionist") Example Strength: "Debugging on real devices. I'm usually the one who reproduces the crash nobody else can." Weakness: "I asked for help too late and lost days on problems a colleague solved in an hour. Now I time-box a problem to two hours and then ask."

The recruiter checks whether you fit the budget and know your market value. Name a researched range for your level and market, say whether it is gross or net, per month or per year, and add that the figure depends on the whole offer. Research first: surveys, similar vacancies, peers who changed jobs A real floor: offers land near the bottom, so name a number you accept Know the convention: gross per year internationally; net per month («на руки») in Russian-speaking markets Ask their range: normal here, and a growing number of employers must state it up front Red flags: "whatever you offer", a number from thin air, volunteering your current salary Example International: "For middle Android roles I'm looking at X to Y gross a year. What's your range?" Russian-speaking market: "I'm looking at X to Y a month after tax. What's your range?"

The interviewer checks your interest and what matters to you; "no questions" reads as indifference. Prepare three or four questions about the work itself (the team, how they ship, what success in this role looks like) and pick those that fit the person in front of you. The work: "What would I do in the first three months?", "Who reviews code, and how big is the team?" How they ship: release cadence, testing, on-call, tech debt and who decides about it Success: "How will you know after six months that I'm doing well?" Match the person: process for the team lead, product plans for the manager, conditions for the recruiter Red flags: no questions, asking about holidays in a technical round Example "Which Android versions and devices do you support, and how do you test on them?" "How far along is the move to Compose?"

The interviewer checks how you debug: how you narrow a problem down, which tools you use and whether you fix the cause or the symptom. Tell it as STAR, with most of the time on the actions: your hypotheses, how you tested them, and what stops the bug from returning. Why it was hard: only on some devices, only under load, no stack trace; say it first The search, step by step: crash reports and logs, a profiler, a minimal reproduction, git bisect, the false leads you ruled out The root cause in one sentence: so the interviewer can follow it Prevention: a test, an alert or a lint rule added afterwards Red flags: a trivial typo, "I don't remember", a bug a colleague found, a fix you cannot explain Example Situation: Play Console showed our ANR rate above the bad-behaviour threshold, almost all of it on cheap phones Task: I took the investigation Action: the ANR traces showed the main thread waiting in QueuedWork while an activity stopped: dozens of SharedPreferences.apply() calls queued by an analytics wrapper, which slow storage took seconds to flush. I batched the writes and moved that data to DataStore Result: the ANR rate fell from about 0.6% to 0.2%, below Play's 0.47% threshold

The interviewer checks how you handle Android fragmentation: narrowing a problem by vendor, model and OS version, reproducing it without owning the phone, and fixing it for everyone. Tell it with STAR, with most of the time on how you narrowed it down. Slice the data: Crashlytics and Play Console filtered by manufacturer, model, Android version and app version Reproduce: a device in Firebase Test Lab, a colleague's phone, a user's screen recording Find what differs: vendor firmware, a missing system screen or app, aggressive battery savers, an old WebView Fix the class of bug: the same guard on every similar call, not only the one that crashed Prevent: that vendor's devices join the test matrix Red flags: "works on my Pixel", closing it as "can't reproduce", a fix for one model only Example "Crashlytics showed an ActivityNotFoundException that came 100% from Xiaomi phones: we opened a system settings screen their firmware does not have. I reproduced it on a Test Lab device, wrapped the launch in a try/catch with a fallback to the general settings screen, and audited the other implicit intents in the app. Two Xiaomi models joined our Test Lab matrix."

The interviewer checks ownership: whether you admit the mistake, limit the damage fast and change the process so it does not happen again. Pick a real mistake with limited impact, tell it with STAR, and spend the last part on what you changed. Own it plainly: "I shipped", not "it got shipped"; no blaming QA or the reviewer who missed it Damage control first: who you told and how fast, the rollback or hotfix, how many users were hit Fix the system: a test, a CI check, a review rule or an alert; "I'll be more careful" is not a fix Red flags: "I don't make mistakes", a story where it was someone else's fault, a disaster with no lesson, a tiny typo chosen to look safe Example "I added a column to a Room table and forgot the migration. The database builder had fallbackToDestructiveMigration(), so instead of crashing, the app silently wiped local data, including unsent drafts. Support tickets told us on the second day of a 10% rollout. I halted it, wrote the migration and told support what to say to affected users. Now every schema change has a MigrationTestHelper test, and release builds have no destructive fallback."

The interviewer checks your judgement under pressure: whether you stop the damage first, communicate clearly and only then fix the cause. Walk through it in order: noticing the spike, halting the rollout, telling people, finding the cause, the fix, and what changed afterwards. Notice it fast: an alert on crash-free users per version, not someone stumbling on the dashboard Halt first, investigate second: at 5% a halt costs little, and waiting costs users One message to everyone affected: the impact, what you did, when the next update comes; support needs it too Fix and resume carefully: the hotfix goes through the same stages A short blameless review: why tests and earlier stages missed it, and one concrete change Red flags: pushing on to 100% to see if it settles, a quiet fix nobody hears about, blaming whoever wrote the code Example "At 5%, crash-free users fell from 99.7% to 99.1% within hours. I halted the rollout and posted in the release channel. The crashes came from a new screen restored after process death with a missing argument. I fixed it, added a test that recreates the activity with ActivityScenario.recreate(), and we resumed the next day. We also added an alert so a drop like that pages the release owner."

The interviewer checks whether you can disagree without damaging the working relationship. Pick a real work disagreement, often a technical one or a code review, and show how you moved it from opinions to shared criteria, what was decided and how you worked together afterwards. Talk early and directly: move a long comment thread to a short call or a one-to-one Understand their side first: restate their position fairly before arguing yours Agree on criteria, then decide: numbers, team conventions, a quick prototype; if you still disagree, the decision's owner decides and you commit Losing is fine: a story where you accepted the other approach shows maturity Red flags: "I've never had a conflict", the colleague as a villain, going to the manager first, winning at the cost of the relationship Example "A teammate wanted to move our manual DI to Hilt in one big PR; I thought the build-time cost was unknown. The review thread turned tense, so I proposed we measure instead of arguing. We moved one feature module, compared clean build time and test setup, and Hilt with KSP added about 15 seconds. That was acceptable to both of us, and we migrated module by module."

The interviewer checks whether you plan realistically and raise a risk as soon as you see it, not on the deadline day. Explain how you break work down and estimate, then tell a story where you saw a slip coming, told people early and offered options. Break it down: pieces of half a day to two days, including tests, review, QA and release, which people forget Unknowns separately: a time-boxed spike for anything new to you; give a range, not one number Compare with the past: how long similar tasks really took When it slips: tell the lead or PM the day you know, with options: cut scope, move the date, add help; never quietly work nights and hope Red flags: "I'm never late", an estimate with no breakdown, announcing the slip on release day Example "I estimated a photo upload feature at four days. On day two I found our old camera and gallery code behaved differently on Android 10 and 14 because of storage and permission changes. I told the lead that afternoon and suggested the system photo picker, which needs no storage permission at all. We shipped one day late instead of a week."

The interviewer checks whether you think about the product and push back with arguments instead of silently building or refusing. Show that you asked about the goal, brought evidence of the cost, offered an alternative that reaches the same goal and accepted the final decision. Ask about the goal first: the requirement is often one way to reach it, and a cheaper way exists Bring evidence: a recording on a real device, a measurement, a platform guideline, an estimate for each option Offer an alternative: "Not X by Friday, but Y gives you most of it" Respect the decision: once the product owner decides with the trade-offs on the table, you build it well Red flags: "I just do what I'm told", refusing with no alternative, going over the PM's head Example "The PM wanted to ask for location on first launch so the map would be ready. I explained that a prompt with no context gets denied more often, and that after two denials Android stops showing the dialog at all. We moved the request to the moment the user taps 'Find nearby', and the grant rate went up."

The interviewer checks whether you can hear criticism without getting defensive and tell a colleague about a problem without hurting them. Describe how you do both, and back it with one story where feedback changed how you work. Receiving: listen to the end, ask for a concrete example, thank them, and come back later with what you changed Giving: in private, soon after the event, about the behaviour and its effect rather than the person ("this PR had no tests, and the bug reached QA"), with a suggestion In code review: explain why, separate blocking issues from nits, say what is good Red flags: "I never get negative feedback", arguing with every point, feedback only through the manager, harsh public comments Example "Our QA engineer told me my PRs never said how to test them, so she had to guess the devices and steps. I added a 'How to test' section with the device, Android version and steps to my PR description, and the team made it part of the template."

The interviewer checks whether you multiply the team's output, not just your own. Tell a concrete story: what the person or the team struggled with, what you did regularly (pairing, review, gradually harder tasks, shared practices) and a result you can point to. Start from their gap: ask and watch what actually blocks them; a generic lecture does not help Teach through real work: pair on a task, then give a similar one to do alone; review with explanations and links instead of rewriting their code Grow independence: tasks a little above their level, and room for small mistakes where they are cheap Scale it to the team: a checklist, a lint rule, a PR template, a short internal talk, written decisions A result: they shipped a feature alone, review rounds fell, onboarding got shorter Red flags: "I just fix their code myself", mentoring as giving orders, no example Example "A junior collected flows in lifecycleScope.launch, so screens kept working in the background. I paired with him on repeatOnLifecycle and collectAsStateWithLifecycle, then gave him the next two screens alone, with my review. For the team, I wrote a one-page guide to coroutines in the UI layer, and it became part of onboarding. Half a year later he was reviewing new hires' code himself."

The interviewer checks whether you speak the business's language and prioritise, instead of asking for a rewrite. Translate the debt into a cost the business already feels (slower features, incidents, lost users), propose a small, measurable plan and report the result. Measure the pain: time to ship a typical feature, bugs per release in that area, incidents, build time multiplied by the team Prioritise by cost: debt in code that changes often matters; old stable code can stay ugly Small and continuous: a fixed share of each sprint, or the cleanup bundled with the next feature in that area, not a three-month freeze Report the effect: numbers before and after make the next request easier Red flags: "the code is ugly" as the argument, asking for a full rewrite, hiding the work inside feature estimates Example "A clean build took nine minutes. Build scans showed that across ten developers this cost more than a working day every week. That number got us two sprints to move from kapt to KSP and turn on the configuration cache, and the build fell to about four minutes."

The interviewer checks whether you can lead change with evidence and people rather than authority or enthusiasm. Show how you heard the objections, tested the idea on something small, measured it, made the start easy and kept the rollout gradual. Hear the objections: performance, learning time, interop with existing Views, hiring; each needs an answer A small pilot with numbers: one screen, its development time, size and bugs, plus a performance check with Macrobenchmark Lower the cost of starting: a reference screen, conventions for state and navigation, pairing on each developer's first screen Gradual, with a rule: new screens in Compose, old ones only when touched; ComposeView and AndroidView at the boundary Accept a "not yet": if the numbers do not support it, saying so builds trust for the next proposal Red flags: rewriting screens alone over a weekend and presenting the result, "Google recommends it" as the only argument Example "Two senior colleagues worried about scroll performance in Compose. I rebuilt one list-heavy screen and measured both versions with Macrobenchmark; after we added stable keys, frame timings were within a few percent. I shared the numbers and a short guide, paired with each colleague on a first screen, and we agreed that new screens would be Compose. Six months later our sprint data showed new screens taking about a third less time."