Behavioral interviews

In the behavioral round the interviewer asks about your past work. The idea is simple: how you acted before is the best guess of how you will act again.

Do not treat this round as "the easy one". For mid-level and senior roles it often decides your level.

#What interviewers look for

• Ownership: you take responsibility, you do not blame others.
• Impact: your work changed something, ideally with a number.
• Collaboration: you work well with designers, product managers, backend and Android engineers.
• Handling conflict: you disagree politely and use data.
• Learning: you learn from mistakes and change how you work.
• Scope: for senior roles, you lead projects and help other people grow.

#The STAR method

Answer every "Tell me about a time…" question in four parts.

Rules that make STAR work:

• Say "I", not "we". The interviewer is hiring you. "We fixed it" hides your part.
• Spend most of the time on Action. That is where your skills show.
• End with a result. If possible, a number. Then one line on what you learned.
• Keep it to about 2 minutes. The interviewer will ask follow-up questions.

#Prepare a story bank

You do not need a different story for every question. Prepare 6–8 strong stories. Each one can answer several questions.

Write each story in short notes, not full text. Practise saying it out loud.

STORY: Crash fix
S: Fitness app, 500k users, crash-free rate dropped to 97.8% after a release.
T: I was on call. Goal: find and fix it before the weekend.
A: Grouped crashes in the crash reporting tool; 70% from one stack.
   Saw a data race in the workout cache. Reproduced with Thread Sanitizer.
   Moved the cache into an actor. Added a test. Shipped a hotfix with phased release.
R: Crash-free rate back to 99.7% in 3 days. Added Thread Sanitizer to CI.

#10 common questions with sample answers

The answers below are short examples. Use your own real stories. Never invent a story; follow-up questions will find the gaps.

#1. "Tell me about yourself."

This is not STAR. Use: present → past → why this job. 60–90 seconds.

"I am an iOS engineer with 5 years of experience. Right now I work on a fitness app with about 500k monthly users. I own the workout player and offline sync. Before that I built banking apps at an agency, where I learned a lot about security and accessibility. I am looking for a team where mobile is a core part of the product, and where I can grow toward a senior role."

#2. "Tell me about a hard bug you fixed."

S: "After a release, our crash-free rate dropped from 99.7% to 97.8%." T: "I was on call, so it was my job to find and fix it fast." A: "I grouped the crash reports and saw that 70% came from one place: the workout cache. The stack traces pointed to two threads writing to the same dictionary. I reproduced it with Thread Sanitizer. I moved the cache into an actor, so only one task can change it at a time. I added a test that writes from many tasks at once. We shipped a hotfix with a phased release." R: "The crash-free rate went back to 99.7% in three days. After that, I added a Thread Sanitizer run to our CI, and it caught two more races in the next month."

#3. "Tell me about a disagreement with a designer."

S: "Our designer wanted a custom animated tab bar for a redesign." T: "I was building it, and I was worried about accessibility and time." A: "I did not just say no. I built a quick prototype in one afternoon. I tested it with VoiceOver and with the largest Dynamic Type size. Labels were cut off, and VoiceOver did not read the selected state. I showed the designer a short screen recording and suggested a middle option: the system tab bar with custom icons and colours." R: "She agreed, and we kept most of the visual style. We saved about a week of work. Now we test accessibility together early in each design."

#4. "Tell me about a big technical change you led."

S: "Our app was fully UIKit. New screens took a long time to build." T: "I proposed using SwiftUI for new screens and led the work." A: "I wrote a one-page proposal with risks and a plan. We started with one low-risk screen: settings. I built a small bridge using UIHostingController, so SwiftUI screens fit into our existing navigation. I made a shared package for colours, fonts and buttons. I ran two short workshops for the team." R: "Over six months we moved 14 screens. New screens took about 30% less time to build, and the crash-free rate stayed the same. I learned to start small, so the team gets confidence before a big change."

#5. "Tell me about a mistake you made."

S: "I shipped a change to how we stored user settings." T: "I needed to move settings from UserDefaults to a new format." A: "I tested on a fresh install but not on an upgrade from an old version. After release, some users lost their settings. I saw the reports the next morning. I stopped the phased release, wrote a migration that read the old keys, and shipped a fix the same day. I wrote a short post-mortem with no blame." R: "Most users never saw the bug because of the phased release. Since then I always test upgrade paths, and we added an upgrade test to our release checklist."

A good mistake story has a real mistake, fast ownership and a lasting change. Do not pick a "fake" mistake like "I work too hard".

#6. "Tell me about a time you improved performance."

S: "Users complained that the app was slow to open." T: "I took the task to reduce cold launch time." A: "I measured with Instruments and found that 40% of launch time was third-party SDK setup on the main thread. I moved non-critical SDKs to after the first screen appears and made two features load lazily." R: "Cold launch went from 2.4 seconds to 1.1 seconds on our oldest supported device. App Store reviews about slowness stopped."

#7. "How do you handle feedback on your code?"

"I see review comments as free help. For example, a senior engineer once said my view models were too big and hard to test. At first I disagreed, but I asked him to show me an example. He split one view model into a smaller one plus a service. I tried it on my next feature and it was much easier to test. Now I do the same, and I share this pattern with juniors."

Short, honest, with a real example. Show that you changed something.

#8. "Tell me about a time you helped a teammate."

S: "A junior developer joined the team. She came from web development." T: "My lead asked me to help her become productive." A: "We paired for one hour a day in her first two weeks. I gave her small, real tickets with clear goals. I wrote a short guide on our architecture. In code reviews, I explained the 'why', not just the 'what'." R: "She shipped her first feature in four weeks. Later she improved my guide and used it with the next new hire."

#9. "Tell me about a time with unclear requirements."

S: "Product asked for 'offline support' for our notes feature." T: "I had to build it, but nobody had defined what 'offline' meant." A: "I listed questions: read only or also edit? What if two devices edit the same note? I met the product manager for 30 minutes and we agreed on a first version: read and edit offline, and the last edit wins. I wrote it down and shared it with backend and Android, so all platforms did the same." R: "We shipped in five weeks with no scope changes. The written decision saved us from a long debate later."

#10. "Why do you want to work here?"

Not STAR. Be specific. Connect the company to your experience and goals.

"Three reasons. First, your app is used by millions of people every day, and I want to work at that scale. Second, I read your engineering blog post about modularising the app with Swift packages. I did similar work, and I would like to learn from a bigger version of it. Third, the role includes mentoring, which I enjoy."

Do your research. One specific detail is better than three general compliments.

#Common mistakes

• No result. The story ends at "and then we shipped it".
• Only "we". The interviewer cannot see what you did.
• Too long. 5-minute stories lose the listener. Aim for 2 minutes.
• Blaming others. "The backend team was slow" sounds bad. Say what you did about it.
• Negative talk about past employers. Stay neutral and professional.
• Same story for every question. Prepare 6–8 different ones.

#Follow-up questions to expect

After each story, the interviewer usually asks one or two of these:

• "What would you do differently?"
• "What was the hardest part?"
• "How did the other person react?"
• "How did you measure the result?"
• "What did you learn?"

Prepare a one-line answer for "What would you do differently?" for every story. It shows reflection.

#Checklist before the round

• 6–8 stories written in STAR notes.
• Each story has a number or a clear result.
• Each story uses "I" for your actions.
• "Tell me about yourself" is under 90 seconds.
• "Why this company?" has one specific detail.
• Every story practised out loud at least twice.