After going through a final-round interviews as a senior iOS engineer, I’ve learned that technical skills alone aren’t enough. The best candidates excel across multiple dimensions: system design thinking, behavioral storytelling, code review acumen, and interview presence. This post captures the hard-won lessons from my recent interview experiences—what worked, what didn’t, and what I’d do differently next time. These aren’t theoretical tips, but practical insights that came from real feedback and reflection.

General Preparation

Often the final round is 4 rounds of interview. Ask if you can do it in two days. Gives your a proper breather in between.

Prepare a nice introduction for yourself and your main career accomplishments. Within it mention where you’re trying to get to next (in your career).

Ask the recruiter which of interviewers are from the team you’re interviewing for. Know who’s the Hiring Manager. That way you can tailor your questions at the end better.

Wherever you’re interviewing at, you must know the CEO’s name. Know the company’s mission statement. Don’t need to study it. Buy maybe just spend 10 minutes to get a baseline. In my interview, the interviewer was saying “Alex said”, and I was like “who the hell is Alex”. Then I realized “Alex” is their CEO. It might make you stand out if you asked something about the CEO or mission statement.

Stop doing everything 30 minutes before. Have water and snacks by your side. Comb your hair. Maybe even brush your teeth. Have pen and paper. Make sure you have battery.

Systems Design

Your overall approach with your interviewer should be to maximize breadth. Try to cover as many aspects of the design as possible. Yet don’t get bogged down in one area unless your interviewer explicitly wants you to. Like mention just mention CDN when needed, but don’t go deep into it unless asked.

In System Design. Explain your thought process when there are multiple choices. Example: If you’re asked “how would your API contract be between client and server for tracking different stock prices”, your answer shouldn’t just be “websockets” It should explain why regular http request or polling is bad and why sockets is good.

There are a lot of obvious stuff that you’ll forget or ignore to talk about in a system design interview just because you think it’s not worth talking about or you in your mind just consider it out of scope. Ex: you might just think authentication isn’t worth discussing since you’re assuming you’re always logged in, but: 1. That’s not always true. 2. Talking about it, helps your interviewer better understand your thought process. 3. Occasionally just by thinking about Authentication, then in addition to thinking about a simple login, your brain might actually realize that you forgot to talk about API Gateway and its benefits. Which is very important. This was my case.

Keep a living system design cheat sheet that you refine over time—reference it regularly until these patterns become second nature. Like for an app that tracks stock prices, your cheat sheet might include:

  • websockets, caching as backup, authentication, API Gateway, batching websocket messages, offline support, rate limiting, data compression, pagination, push notifications for critical updates.

The book: Mobile System Design Interview - Manual Vicente Vivo (ByteByteGo) was phenomenal. Worth its weight in gold.

Behavioral Design

After watching this I realized how key behavioral interview is and how severely I was lacking. It doesn’t take a lot of planning but it has huge impact.

You typically explain things in a STAR format. My interviewer was far less focused on the context and far more focused on my actions and their measurable results. I struggled to highlight results clearly. Results aren’t only numbers — they can be reputation changes, operational gains, or strategic impact. Examples include:

Quantitative Results

  • Success rate improved from 80% → 88%.
  • App size reduced by 20%, which increased install-through-rate and decreased uninstall likelihood.
  • Feature introduction usually drives 10–15% engagement lift, translating into about 1% revenue growth.
  • Architecture improvements enabled the team to ship new features 3× faster due to code reuse and simplified planning.
  • Reduced API error rates by 40% after restructuring request logic.
  • Increased test coverage from 50% → 85%, reducing regressions by ~25%.

Reputation & Influence Results

  • Became known as someone who can lead work across 4+ teams and align cross-functional initiatives.
  • Director and peer teams now reach out proactively for architecture reviews, planning, and guidance.
  • Became my manager’s go-to person for initiating new tasks or de-risking ambiguous projects.
  • Was nominated for promotion due to consistent delivery and leadership.
  • Became regarded as the person who “unblocks complicated work” or “owns delivery”, which increased trust in my execution.

Team & Organizational Results

  • Unblocked a failing initiative and allowed the business to hit its Q3 milestone after being at risk.
  • Enabled another team to deliver 2–3 weeks faster because my code or documentation removed dependencies.
  • Established a reusable pattern that is now used by 3 other teams.
  • Improved onboarding by writing clearer docs, reducing ramp-up time for new engineers from 4 weeks → 2 weeks.

Product & Customer Results

  • Reduced crash rate by 15%, improving customer experience and App Store ratings.
  • Improved login flow performance by 40%, reducing drop-offs.
  • Introduced a Live Activity/feature that improved user satisfaction and retention metrics.

Role Clarity

Be explicit about your individual contribution. Don’t be vague. If you architected something and wrote the code, say:

“I was the architect and the primary implementer. I designed the flow, wrote the core components, and coordinated with backend + QA to ship it.”

Clarity on your role helps interviewers understand ownership, leadership, and execution ability.

💡 Match your examples to the role level. When answering conflict resolution questions, be mindful of the seniority signal your story sends. If you’re interviewing for a senior role, sharing how you resolved a disagreement with a junior teammate might inadvertently suggest limited scope. Instead, choose examples involving peer seniors, managers, or cross-team stakeholders—situations that demonstrate navigating complexity, organizational influence, and high-impact problem-solving appropriate for the level you’re targeting.

Have reasonable questions to ask from interviewers.

  • Where is the team headed in next 6-18 months?
  • What would you change in your company?
  • Are people appreciated / promoted in reasonable time?
  • What does your company do that makes you think the company is in a stable market position for the next decade?
  • For this role, are there any technical or soft skills that are unique to your company and required?
  • Other than Swift X used for the project, what other languages should one use?
  • If you think you and your interviewer have connected, then maybe at the end ask them “Do you have any feedback on my answers. I’ll promise to not tackle your feedback. I honestly want to know where my answers lacked as I learn the most from my failures not my successes. I always cherish these feedbacks. It would mean a world to me.”

What’s interesting is, while most interviewers shouldn’t give you feedback right there and then, I’ve had good success with this.

Technical Challenge

When asked to review a piece of code, then in addition to saying “This variable / function should be private, we should do dependency injection, we need documentation”, you should also be on the lookout for business inconsistencies:

  • Often there’s some business logic that’s incorrect in the code. Ex: if you’re asked to generate history of a user at time X, then you shouldn’t create a history off of events within last 5 seconds. It’s better if it’s off of last 5 events within a maximum window of time.
  • What happens if user backgrounds when polling and comes back?

Other Notes

Write down the questions you were asked (perhaps you can do this during the interview on paper. As often you forget the questions). Also write down your answers. Review your answers later with yourself and friends. You learn a lot from doing that.

If you are intrigued by a question in a way that it’s novel, then just say “Hah. This is a very though provoking question. I like it. It’s refreshing”. It just shows that you appreciate the game. Makes you stand out as a better opponent, much like how two players in a fierce match show each other professional respect.