• Share this post & I'll send you some rewards for the referrals.

You’ve probably been there: You’re sitting across from two engineers (or staring at them through a webcam), and they’ve just asked you to design Instagram’s feed. Or a ride-sharing app. Or some chat system with offline support and end-to-end encryption.

The clock is ticking…

You have 45 minutes to turn a vague prompt into something that looks like you know what you’re doing.

Your mind races: Where do I even start? Do I draw boxes first? Ask about the user numbers? Talk about databases? What if I forget something critical?

Most mobile engineers don’t realize this about system design interviews: They’re NOT testing whether you can build Instagram. They’re testing whether you can take something fuzzy and turn it into something concrete.

This is the same skill you use every day when your PM says, “We need push notifications,” or your designer drops a Figma file in Slack with the message “Thoughts?” in your day job.

MiniMax M2.7 is here, and it’s unlike any agent model released before it.

Built on their proprietary SOTA Cowork Agent Model architecture, M2.7 shows early echoes of self-evolution: the ability to follow complex, layered instructions across long workflows without losing the thread.

At 5 tools, every model looks sharp.

At 40, almost all fall apart silently.

Wrong tool invoked. Step missed. No error thrown. You find out 3 days post-deploy.

M2.7 was tested across 40 complex skills, each exceeding 2,000 tokens.
Skill adherence rate: 97%.

Here’s what that looks like in production:

• Alert fires → metrics correlated → root cause traced across systems

• DB queried to verify → fix submitted

• Recovery time: under 3 minutes. Manual process: 4+ hours.

Most models are built to write code.

M2.7 is built to understand your production systems.

And it ships inside something new: the world’s first subscription plan for an all-modality-capable model. One API key covers M2.7, Speech, Image, Video, and Music generation; the full stack, no provider switching.

MiniMax Token Plan 12% OFF

I want to introduce Tjeerd in ‘t Veen as the guest author.

He recently released the Mobile System Design book bundle based on years of interviewing mobile engineers and building large-scale mobile apps. This newsletter distills the core process (framework) from the books into something you can use to prep for interviews or plan features at work.

If you want to go deeper, the full book bundle has more examples, detailed architecture patterns, and code-level implementation strategies.

There are plenty of great general system design guides. This one is about mobile constraints and how they shape the architecture.

This newsletter walks through the actual process:

• How to take a vague prompt and figure out what the interviewer actually wants

• How to uncover the hidden requirements nobody mentioned (because they’re testing if you’ll think of them)

• How to structure your thinking so you don’t forget the mobile-specific stuff (offline state, battery drain, app lifecycle, memory constraints)

• How to turn abstract architecture talk into concrete implementation details

This works whether you’re in an interview or planning a real feature at work.

The process is the same.

If you’re a mobile engineer (iOS, Android, Flutter, React Native, etc.) and you need to:

• Prepare for system design interviews

• Stop feeling like you’re fumbling when asked to “design something.”

• Learn how to think through mobile architecture in a structured way

• Get good at turning vague requirements into actual plans

Then this is for you…

I’m assuming you already know how to develop mobile apps. You understand the basics of networking, data persistence, and why you shouldn’t do heavy work on the main thread. You’ve shipped something to production and dealt with the consequences.

What you might not have is a structured way to think about system design. That’s what we’re covering here…

Let’s talk about what actually happens in a mobile system design interview:

The format can vary wildly between companies. Some give you 45 minutes, others give you 60. Some want you on a whiteboard, others use tools like CodeSignal or HackerRank. Some companies even ask backend system design questions in mobile interviews, which is a separate discussion entirely.

But most mobile-focused interviews follow a similar arc.

Here’s what you can typically expect…

Most interviews break down roughly like this:

At a high level, the flow is:

• Requirements and scope (5-10 minutes): clarify what you’re designing and the constraints

• API and data needs (5-10 minutes): define what the app needs from the server

• Architecture (10-15 minutes): outline client components and data flow

• Deep dive (15-20 minutes): walk one critical flow or adjust for a new constraint

• Wrap-up (1-5 minutes): summarize decisions and tradeoffs

I’ll go deep on how to execute each phase in the next section…

Interviewers don’t judge all mobile engineers the same way.

Here’s what interviewers are actually looking for based on your level:

You’re expected to:

• Ask clarifying questions (even if they seem obvious)

• Draw a reasonable architecture diagram without major gaps

• Explain common mobile patterns (caching, background tasks, handling lifecycle)

• Discuss basic tradeoffs - ”This approach is simpler but uses more memory.”

You’re not expected to:

• Know every edge case off the top of your head

• Have opinions on monorepo versus multi-repo

• Design for 100 million users on day one

If you get stuck on something complex (like offline conflict resolution), just say so. “I haven’t built a system that merges offline edits before, but I’d start with last-write-wins and ask about requirements,” is fine.

Honesty beats bullshitting.

Everything from junior/mid, plus:

• Proactively uncover hidden requirements without prompting - ”What about users on limited data plans?”

• Propose architecture with clear reasoning for your choices - ”I’m using a repository pattern here because we need to support offline-first”

• Demonstrate deep knowledge of mobile-specific challenges (app lifecycle, memory pressure, battery drain, offline sync)

• Adapt when requirements change mid-interview - ”Okay, if we need to support 50MB video uploads, we’ll need background upload with chunking…”

You should drive the conversation.

The interviewer shouldn’t have to pull answers out of you.

Everything from senior, plus:

• Frame the problem: “Before we design this, let’s talk about whether we even need offline support for this use case.”

• Consider team structure: “If we structure this as a separate module, we can have one team own it independently.”

• Think long-term: “This works for v1, but if we add feature X later, we’ll need to refactor. Let’s design for that now.”

• Make architectural tradeoffs at the system level: modularization strategy, build times, deployment, backward compatibility

You’re expected to think like a tech lead or architect, not just an IC implementing a feature. The interviewer wants to see if you can make decisions that affect the entire team or org.

Now that you know what the interview structure looks like, let’s talk about the actual process you’ll use during those 45 minutes.

The interview structure gives you the timeline. But what do you actually do in each phase?

This is the process you’ll follow, roughly in order, during the first 30-40 minutes of the interview. Think of it as a checklist for making sure you forget nothing critical.

You won’t always do these steps in exactly this order. Sometimes you’ll jump back and forth. Sometimes the interviewer will steer you in a different direction. That’s fine.

But this is the general flow that works:

Most steps look different, but the rhythm is the same:

• Ask 2-3 high-impact questions before designing.

• Restate what you heard and get a clear “yes.”

• Write down decisions: constraints, must-haves versus nice-to-haves, and open questions.

• Call out red flags early instead of waiting.

• You don’t have to solve everything on the spot. Show you see the issue, pick a reasonable tradeoff, and move on.

Here’s how most system design interviews start:

The interviewer says something like, “Design a feed for a social media app,” or “Build a way for users to share photos with friends.”

And your brain immediately starts racing: Should I ask about the backend? Should I start drawing? What if I forget to mention caching?

Before you do any of that, pause.

Your first job is not to design anything. It’s understanding what you’re being asked to design.

This sounds obvious, but most candidates blow past this step in 60 seconds and then spend 40 minutes designing the wrong thing…

In the first 5-10 minutes, you’re trying to turn a vague prompt into something concrete enough that you know what problem you’re solving.

You’re not trying to get every detail. You’re trying to get enough clarity that you’re not completely guessing.

Think of it like this: If someone asks you to “design a messaging feature,” do they want:

• WhatsApp (end-to-end encrypted, real-time, requires phone number)

• Slack (threaded, searchable, integrates with other tools)

• Twitter/X DMs (simple, text-only, tied to social graph)

All of those are “messaging.” They’re also completely different architectures.

So your job is to ask questions that reveal which one they actually want.

Here’s what you should ask:

About success criteria:

• “What does success look like for this feature?” (Are we optimizing for speed? Reliability? Simplicity?)

• “What’s the most important thing this needs to do well?” (If we could only do one thing right, what would it be?)

About scope:

• “Is this the whole app, or are we focusing on one part?” (Don’t design all of Instagram if they just want the feed)

• “What platforms are we targeting?” (iOS only? Android? Cross-platform?)

About constraints:

• “What network conditions should we plan for?” (Always online? Intermittent? Fully offline?)

• “Are there any technical constraints I should know about?” (Existing systems we need to integrate with? Legacy code?)

About users:

• “Who are the primary users?” (Consumers? Enterprise? Internal tools?)

• “What devices are they on?” (Flagship phones? Low-end Android? Tablets?)

Don’t ask everything.

Pick the questions that will most change your design. You have limited time.

Bad example:

Interviewer: “Design a feed for a social media app.”

You: “Okay, so I’ll use MVVM for the architecture. We’ll have a ViewModel that fetches data from a Repository, which talks to both a local database and a REST API. UI will be built with—”

Interviewer (internally): They didn’t ask a single question. Do they even know what they’re designing?

You just spent 3 minutes designing an architecture without knowing:

• Whether it needs to work offline

• Whether it’s a text-based feed or heavy on images and video

• Whether it requires pre-caching for a smoother scrolling experience

That’s a red flag. Interviewers are explicitly looking for whether you ask questions.

Good example:

Interviewer: “Design a feed for a social media app.”

You: “Okay, let me make sure I understand what we’re designing. Is this feed mostly images and video, or mostly text? That affects caching and pre-fetching on mobile.”

Interviewer: “Mostly images, some video.”

You: “Got it. For mobile, I’d plan on disk caching images (and maybe short videos) and pre-fetching upcoming content so the feed loads fast and works offline. Is that aligned with what you want?”

Interviewer: “Yes, basic offline support for previously loaded content is important.”

You: “Makes sense. One more thing: do we need live updates, or is pull-to-refresh enough for v1?”

Interviewer: “Pull-to-refresh is fine.”

You: “Perfect. So, to summarize: we’re designing a media-heavy feed with basic offline support. We’ll cache images (and maybe short videos), pre-fetch upcoming content for fast loads, and start with pull-to-refresh for updates. Does that sound right?”

Interviewer: “Yep, that’s it.”

Reminder: this is a teaser of the subscriber-only newsletter series, exclusive to my golden members.

When you upgrade, you’ll get:

• High-level architecture of real-world systems.

• Deep dive into how popular real-world systems actually work.

• How real-world systems handle scale, reliability, and performance.

Sometimes the briefing is incomplete or contradictory. Call it out early instead of guessing…

Common red flags:

• Requirements that are vague or overly broad - ”make it fast.”

• Contradictory statements - ”we want it simple, but also highly customizable.”

• Missing critical info (no mention of offline, auth, or data sources)

When you spot these, call them out:

“You mentioned we want it to be ‘fast.’ Can you be more specific? Are we talking about load time under 1 second, smooth scrolling, or something else?”

“I’m noticing we haven’t talked about where the data comes from. Should I assume we’re pulling from a REST API, or is there a different data source?”

Don’t rush ahead, hoping it’ll become clear later. It won’t. You’ll end up designing something that doesn’t match what they wanted…

Next steps once the briefing is clear:

• Write down key constraints in the shared doc or on the whiteboard (”Offline support required”, “100k users”, “Existing auth system”)

• Mentally categorize what is a must-have versus a nice-to-have

• Identify the biggest unknowns you’ll need to address

Lesson: Don’t start designing until you know what you’re designing.

This can feel slow, but it’s faster than designing the wrong thing…

Okay, so you’ve asked your questions, and you have a basic understanding of what you’re designing. Now comes the hard part: figuring out what you’re actually going to design.

Here’s the problem: If someone asks you to “design a messaging feature,” there are about 47 different things they could mean. Do they want read receipts? Typing indicators? Group chats? Voice messages? End-to-end encryption? Reactions? Threads?

You can’t fit all of that into v1. You probably can’t even fit half of it.

So your job is to separate what’s essential from what’s nice-to-have.

This is where most people mess up. They either:

1. Try to include everything at once and run out of time

2. Design the wrong things and miss what actually matters

3. Don’t ask at all and just guess

All three are bad. Let’s talk about how to do this right:

You need to answer these questions: