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: "iOS developer, four years. I work on a banking app in Swift, half UIKit and half SwiftUI, and own the cards and payments screens." Past: "After freelance apps I joined a product team and moved our networking to async/await." Future: "I want a SwiftUI-first, modular codebase like the one your team describes."

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 "I've grown a lot on our banking app, but it's moving into maintenance and new features are rare. Your app is SwiftUI-first and still growing fast, and that's the product I want to work on."

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: customers kept calling support to ask where their order was Task: I built order tracking on the Lock Screen Action: a Live Activity updated by push, with models shared with the app through a Swift package Result: "where is my order" calls fell by about a quarter in two months

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: "Memory and threading. I found the retain cycle that kept a whole screen alive after it closed." Weakness: "I avoided presenting. Since last year I demo my work at every team review, and it gets easier."

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 iOS 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 "What is your minimum iOS version, and how quickly do you adopt new SDKs?" "How much of the app is SwiftUI, and where are you heading?"

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 app closed by itself on older iPhones with 2 GB of RAM, and Crashlytics showed nothing Task: find out why Action: JetsamEvent reports in the device's Analytics Data showed memory kills. Instruments' Allocations showed the photo picker holding 20 full-size images at once, about 900 MB. I switched to downsampling with ImageIO (CGImageSourceCreateThumbnailAtIndex) to the size on screen Result: peak memory fell to about 150 MB, the kills stopped, and an old iPhone is now part of our release check

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 force-unwrapped a field our API sometimes omits. After the release, about 1% of sessions crashed on the profile screen. I paused the phased release, told the team in the release channel and shipped a fix within a day that decodes the field as optional. Afterwards we enabled SwiftLint's force_unwrapping rule and added decoding tests built from real API responses."

The interviewer checks how you handle a blocker outside your control under deadline pressure: staying calm, keeping the team and the reviewer informed, and fixing the process. Tell it with STAR: the rejection and what was at stake, what you did, how fast it was resolved and what changed. Read before reacting: the cited guideline and the reviewer's notes and screenshots; many rejections are a misunderstanding or a missing detail Tell people early: the PM and marketing hear about the risk to the date from you within the hour, with an estimate One path, one owner: reply in App Store Connect, fix and resubmit, or appeal, decided quickly Prevent the next one: a pre-submission checklist and a working demo account in the review notes Red flags: "Apple is unfair", an angry reply to the reviewer, the team learning about the rejection on launch day Example "Two days before a campaign, the update was rejected under guideline 2.1: the reviewer could not sign in, because our demo account needed an SMS code. I told the PM within the hour. The backend team gave the demo number a fixed code, I replied to the reviewer with the steps, and the build was approved the next day. Our checklist now includes signing in with the demo account on the day we submit."

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 colleague kept rejecting my networking PRs because I used async/await in a module written with Combine. Instead of replying point by point, I suggested we talk. His real concern was cancelling requests in flight. I showed that cancelling the Task cancels the URLSession request, and we agreed: new request code uses async/await, Combine stays where values stream over time. Our reviews got faster after that."

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 "Marketing had a fixed launch date, and my plan included a day for App Review. On day three an edge case with Family Sharing purchases appeared. I told the PM straight away and proposed leaving Family Sharing for the next update. We submitted two days before the date and passed review the first time."

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 "A redesign replaced the system navigation bar with a custom header, which broke the swipe-back gesture and the VoiceOver reading order. I showed both on a device and suggested styling the native navigation bar instead. We kept the look and got the system behaviour back for free."

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 "A colleague told me my review comments sounded like orders. I re-read a few and agreed. Now I write them as a question with a reason ('this closure captures self strongly; should it be [weak self]?') and mark nits as optional. The tone of our reviews changed within a few weeks."

The interviewer checks whether you keep learning and plan platform changes before they become emergencies. Describe a yearly routine: what you watch in June, how you test on betas over the summer, how you plan the required work with the product team, and one release you prepared this way. June: the WWDC sessions that touch your app, split across the team, each with a short written summary Summer: the app built with the Xcode beta and run on a test device with the iOS beta; a list of what breaks, new warnings and deprecations Plan with product: required work gets a slot before September (the new SDK becomes mandatory for uploads the following spring); new features such as widgets or App Intents are offered as options A deployment target policy: for example the last two major versions, checked against your analytics Red flags: learning about changes from September reviews, adopting every new API at once, "I don't follow WWDC" Example "When iOS 26 brought Liquid Glass, we built the app with the Xcode 26 beta in June and found that our custom tab bar and headers clashed with the new look. I listed the screens with screenshots, the designers updated the custom parts over the summer, and we shipped the adapted version the week iOS 26 came out."

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's screens leaked memory: closures captured self, and view controllers were never deallocated. I showed her how to find a cycle with the Memory Graph Debugger, and we added a leak check to the PR template. Within two months she was the one pointing out cycles in other people's reviews. For the team, I ran a one-hour session on ARC that is now part of onboarding."

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 old Objective-C networking layer was behind about a third of our crash reports, and every new endpoint took a day of boilerplate. I showed the PM both numbers and proposed replacing it behind a protocol, one feature at a time, alongside planned work. After a quarter, crash-free sessions went from 99.5% to 99.8%, and a new endpoint took an hour."

The interviewer checks whether you can lead a long change through people, not just write the code. Show how you justified it to the business, started small, set shared rules, spread the knowledge and kept features shipping, with a result in numbers. A reason the business accepts: faster screen development, fewer layout bugs, a minimum iOS version that finally makes it practical A pilot first: one new, low-risk screen; measure how long it took and how many bugs it had Shared rules: how SwiftUI is hosted (UIHostingController), how state and navigation work, what stays in UIKit for now (complex lists, custom transitions) Spread the knowledge: pairing, a reference screen, review by someone who has done it, a short internal session No freeze: new screens in SwiftUI, old ones rewritten only when a feature touches them Red flags: a big-bang rewrite, "I just started writing SwiftUI and the others followed", no plan for the screens that should stay in UIKit Example "Once our minimum target reached iOS 16, I proposed that new screens be SwiftUI. I built settings first, wrote a two-page guide on state and navigation, and paired with each developer on their first screen. A year later about 60% of screens were SwiftUI, new screens took roughly a third less time, and the two complex feeds stayed in UIKit by design."