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: "Flutter developer, three years. For the last two I've worked on a delivery app with 200,000 monthly users, mostly checkout and offline mode." Past: "I started on native Android and moved to Flutter when the company merged its two apps." Future: "I want a larger mobile team with real code review, which this role offers."

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 "For three years I've been one of two developers on one Flutter app, so I often review my own code. You have a mobile team of a dozen people and a shared widget library, and I found you through your talk on modular Flutter apps."

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: couriers lost signal in basements, and confirmations got lost Task: I owned offline mode Action: a local drift queue replayed actions in order when the network returned; the server dropped duplicates by idempotency key Result: lost-confirmation tickets fell from about 30 a month to near zero

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: "Performance. I found why our product list dropped frames on cheap phones and fixed it with DevTools." Weakness: "I underestimated platform-specific work. Now every estimate has a line for iOS and Android differences."

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 Flutter 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 parts of the app are native, and who maintains that code?" "How do you release: how often, and with staged rollouts?"

The interviewer checks that your choice was deliberate and that you know Flutter's limits from experience, not from articles. Give your reason in a sentence or two, then tell one real case where you had to go native or work around the framework, and how you handled it. An honest reason: one codebase for two platforms with a small team, hot reload, a custom design that looks the same everywhere; a personal reason is fine if it is true A real limit: home-screen widgets, a native SDK with no plugin, background work, platform views, app size What you did: a platform channel or a small plugin, a native screen, or a change to the design Balance: the right tool for this product with known costs, not a religion Red flags: "Flutter can do everything", a comparison from articles with no experience behind it, no Kotlin or Swift at all Example "We picked Flutter because three developers had to ship to both stores. It held us back on the iOS home-screen widget: WidgetKit needs SwiftUI in a separate extension. I wrote the widget in Swift, shared data with the app through an App Group and refreshed it from Dart over a small method channel. It took a week, mostly learning WidgetKit, and taught me to check platform features before promising them."

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: the catalogue list stuttered on budget Android phones, and store reviews mentioned it Task: my code, so my bug Action: on a real low-end phone in profile mode, DevTools showed slow raster frames: full-size photos decoded for 100-pixel thumbnails, and every card inside an Opacity widget. I set cacheWidth to the thumbnail size and replaced Opacity with a semi-transparent colour Result: slow frames fell from about 20% to under 3%; a frame-time test on a real device now runs before each release

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 renamed a field in a model we also cached on disk. Users who updated opened an empty home screen, because the old cache no longer parsed. Crash reports were clean, since the exception was caught, so I learned about it from reviews the next morning. I told the lead, shipped a hotfix that drops unreadable cache entries, and since then every model change comes with a test that reads a saved copy of the previous format."

The interviewer checks how you act under pressure and whether you know that one Dart codebase still means two builds. Tell it with STAR: how you found out, how you limited the damage, how you kept people informed, the cause, and what you changed in the release process. Detection: crash reports and store vitals split by platform and version Limit the damage: halt the Play rollout or pause the iOS phased release; switch off the feature if it is behind a remote flag Communicate: one message to the team and support with the impact and the time of the next update The cause is usually below Dart: R8 rules, a plugin's native code, Info.plist or manifest entries, a minimum OS version Afterwards: release builds tested on real devices of both platforms before each rollout Red flags: "we test only on iOS, the code is shared", blaming the plugin author and stopping there Example "A release crashed at login on Android only, and only in release builds. At a 5% rollout Crashlytics showed it within an hour; I halted the rollout and posted in the release channel. R8 had removed a class that a native SDK loaded by reflection. I added a keep rule, the fix shipped the same day, and CI now runs a smoke test on a release APK before each rollout."

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 senior colleague and I disagreed on state management for a new feature: I wanted Riverpod, he wanted Bloc, which the rest of the app used. Thirty PR comments got us nowhere, so I asked for a 20-minute call. We agreed the criteria were consistency and onboarding time, and on those Bloc won. I rewrote the feature in Bloc, and we wrote the rule down so the next newcomer would not repeat the argument."

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 in-app subscriptions at five days. On day two I found that iOS sandbox renewals and Android grace periods needed separate handling. I told the PM that day: we could ship on time without promo codes, or ship everything three days later. We dropped promo codes from the first release and added them the next sprint."

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 designer wanted a blurred bottom sheet over a scrolling video feed. On a budget Android phone, BackdropFilter over video dropped us to about 30 frames per second. I recorded the screen on that phone, showed it at our design sync and proposed a semi-transparent sheet without blur. After seeing the recording, the designer agreed."

The interviewer checks whether you can turn a design system into code both sides trust and handle the gap between a mockup and a real device. Describe a shared source of truth (tokens and components), a review loop with designers and a story where you settled a disagreement. Same names on both sides: colours, type and spacing from the Figma variables become tokens in ThemeData and a ThemeExtension; screens never hard-code values A catalogue designers can open: every component in Widgetbook or a gallery app, so they review the real widget, not a screenshot Golden tests: a visual change shows up in review instead of in production A rule for one-offs: a new variant goes into the library, or the design changes; no private copies in features Device reality: text scaling, dark mode, small screens and right-to-left layouts, which mockups rarely show Red flags: "I build exactly what's in Figma", or the opposite, changing the design without asking Example "Designers had drawn a primary button in seven slightly different sizes across screens. I put all seven on one Widgetbook page and showed them side by side at our weekly sync. We agreed on three sizes, I replaced the rest, and new screens since then use only the library."

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 "My lead told me my pull requests were too big to review: one had 1,500 lines with a new feature and a refactor mixed together. I asked what size works for the team, and now I keep PRs to about 400 lines and send refactors separately. Reviews went from three days to one."

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 on our team kept using BuildContext across async gaps and calling setState after dispose. We paired twice a week for a month on his own tickets, and in review I left explanations with links to the docs instead of fixing the code. Three months later he shipped the profile section on his own. For the team, I enabled stricter lints, including use_build_context_synchronously, so the analyzer catches what I used to catch by hand."

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 "Our checkout mixed setState, Provider and global singletons and had no tests. I counted: 7 of the last 10 production bugs came from it, and every change there took twice as long as elsewhere. I proposed moving it to Bloc one screen per sprint, with tests for each screen. Two months later checkout regressions had stopped, and the PM asked which module was next."