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 you 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 or possibly ask role-specific questions.

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. Interviewing isn’t about acing it. It’s about being better than all others. It’s about marginal gains. And just knowing a thing or two about the CEO and their mission statement might make you stand out.

Make Chrome your default browser. It works better for certain online coding platforms. It integrates better with Zoom as well. Also make sure you’ve given permission to Zoom for code-sharing, microphone, camera.

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. Stop doing work at least an hour before. Do some light stretches. Meditate if you can. Try to get yourself relaxed and in the zone.

Huge preference that you use your own personal Mac.

  • It doesn’t make you look professional.
  • Work computers often have restrictions for websites and stuff.
  • Work computers will log your actions. You don’t want that.

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. tldr system designs are intended to move quickly. At every moment you need to stay focused on a given scope. But then move off that scope quickly…

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.

Other Tips for System Design

If you’re interviewing for senior / staff position then don’t spend time into writing all fields of a model and its type being String, Integer, etc. It’s a waste of time. Focus on the more important stuff…

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

If you’re also ever trying to make sure you understanding of APIs are correct. Example you want to know how Google Drive upload, YouTube video meta data retrieving, Facebook feed pagination works, then you can either read about it from books and engineering blogs or you can

Look into HTTP requests and the responses and content it’s getting. Like scroll down and then see how pagination works. Or clip into a certain video in Youtube, see how things start. Or upload a large file and see what traffic goes out.

Behavioral Design

Some random notes on behavioral interviews.

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 + Product 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.

I HIGHLY recommend reading Senior vs Staff Engineer answers for behavioral interviews

Some questions and short answers

  • Team member not pulling their weight → “I had a private 1:1 to understand blockers, offered support, set clear expectations with a timeline, and escalated to my manager when improvements didn’t materialize.”

  • Manage 3-4 big items across engineers → “I broke down work into milestones with clear owners, held weekly syncs to unblock issues, tracked progress in a shared doc, cloned myself through architecture documents, run books, dashboards that can create an easy to follow narrative or alerts that automate the look out, prioritized ruthlessly when conflicts arose, and escalated risks early to leadership.”

  • Changes to ship on time → “I cut scope by deferring nice-to-have features, parallelized work across team members (through quick task / ticket defining), broker tasks into smaller chunks and worked with PM to adjust acceptance criteria while maintaining core value.”

  • Resolve conflict on team → “I facilitated a meeting where both sides presented their concerns, identified shared goals, tabulated trade-offs for more robust decision making, proposed a compromise that addressed key concerns, and documented the decision to prevent future confusion.”

  • Convince team about technical decision → “I created a document outlining pros/cons, shared concrete examples of where the approach succeeded elsewhere, ran a proof-of-concept to address concerns, and presented it in a team meeting for consensus.”

  • Mentor someone → “I paired with them on complex tasks, provided constructive code review feedback, shared relevant documentation, and set up regular check-ins to track their progress and answer questions.”

  • Learn something new quickly → “I identified the core concepts needed, consumed focused documentation/tutorials, built a small prototype to validate understanding, and asked senior engineers for guidance on edge cases.”

  • Made a mistake → “I discovered a bug I introduced in production, immediately notified stakeholders, deployed a hotfix, conducted a post-mortem to identify root cause, and implemented safeguards (tests/monitoring) to prevent recurrence.”

  • Deal with ambiguity → “I gathered all available information, identified key unknowns, made reasonable assumptions with stakeholder alignment, started with an MVP approach, and iterated based on feedback.”

  • Influence without authority → “I built consensus (you need consensus when you don’t have authority) by demonstrating value through a proof-of-concept, showed how it solved their pain points, addressed concerns proactively, and earned buy-in through results rather than mandate.”

  • Difficult stakeholder → “You should always leave room on the table as you may not know, but you’re the difficult one yourself, or you lack of knowledge is a hidden impediment towards getting the milestones. I scheduled 1:1 time to understand their concerns, listened actively without being defensive (I made it about understanding them as opposed to them understanding me), found common ground, provided frequent updates to build trust, and adjusted my approach based on their feedback style.”

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?

Questions to ask Interviewer

Have reasonable questions to ask from interviewers.

Product

  • Where is the team headed in next 6-18 months?
  • How does this team and its product position itself relative to the rest of the company and its product? Is this team growing in importance? Can you provide some examples why you think its growing?

Company

  • What is that you like or don’t like about the 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?

Team

  • What’s the team size? What’s the mix of employee vs contractor in the team. Employees must make up at least 50% for it to mean this team and its product are stable and important.
  • Who would I be working under me and next to me?
  • To ask the question differently, you can ask, how many years has this team existed? and how the team size has grown?

Role

  • For this role, are there any technical or soft skills that are unique to your company and required?
  • As a hiring manager, what are the main criteria of success for this role? Could be things like (leadership, ownership, on time delivery, technical acumen, working with the team and moving everyone ahead.)

Feedback

  • 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.

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.