DEV Community: Ayusch

Android System Design: Design a Notes App - by Mockingly

Ayusch — Mon, 06 Apr 2026 15:00:00 +0000

Android System Design: Design a Notes App

This post was originally published on MockinglyAI. It's the best resource to prepare for system design interviews. Try a free Mock Interview.

This question shows up at Google, Microsoft, Notion, Dropbox, and pretty much any company building productivity tools on Android. It's popular precisely because it's a clean, bounded problem that happens to touch every hard Android topic at once: offline-first design, Room schema decisions, background sync with WorkManager, multi-device state reconciliation, and rich text storage.

The best candidates don't just describe a notes CRUD app — they treat it as a distributed systems problem running on a constrained mobile device.

Step 1: Clarify the Scope

Interviewer: Design a notes app for Android.

Candidate: Before I dive in — a few questions. Are we designing a local-only notes app or one that syncs across devices? If it syncs, do we need real-time collaboration, or is eventual consistency between the user's own devices acceptable? Do notes support rich text — bold, italics, lists, embedded images — or plain text only? Do we need folder organisation, tagging, or search? And what's the offline expectation — can the user create, edit, and read notes without network access?

Interviewer: The app syncs across the user's own devices. No real-time collaboration — just eventual consistency. Rich text support — at least bold, italic, bullet lists. Tags and search are in scope. Full offline support is a hard requirement. Assume Google Keep or Apple Notes as the reference.

Candidate: Perfect. Offline-first is the most important architectural constraint here — it shapes every single decision from schema design to sync strategy. Let me start with requirements and then walk through the architecture.

Requirements

Functional

Create, edit, and delete notes fully offline
Notes contain rich text (bold, italic, bullet lists) and optionally images/attachments
Tag notes for organisation; filter notes by tag
Full-text search across note content and title
Notes sync across the user's own devices when connectivity is available
Handle conflicts when the same note is edited on two devices while offline
Archive and pin notes

Non-Functional

Offline-first — all core operations must work without a network connection
Zero perceived latency — UI writes must feel instant; syncing happens in the background
No data loss — a note written offline must never be silently dropped
Battery-safe — background sync must not drain the battery
Conflict resilience — concurrent edits across devices must be resolved correctly and predictably

Back-of-the-Envelope Estimates

Interviewer: Give me a sense of the numbers.

Candidate: For a per-device estimate:

Notes per user:             ~500 average (active user)
Average note size (text):   ~5 KB
Notes with attachments:     ~10%
Average attachment size:    ~500 KB (photos, audio clips)

Local storage (text only):
  500 notes × 5 KB = ~2.5 MB — trivially small, no concern

Local storage (with attachments):
  50 attachments × 500 KB = ~25 MB — manageable per device

Sync payload per session:
  Assume user edits 5 notes per day
  5 × 5 KB = 25 KB delta upload — negligible bandwidth

Search index:
  Room FTS4 overhead is ~2× the text content size
  500 notes × 5 KB × 2 = ~5 MB — fine for SQLite

The numbers confirm this is not a scale problem on the client. Notes apps don't have high write throughput or large data volumes per device. The interesting challenge is correctness — not performance. Specifically: how do you guarantee offline writes don't get lost, and what happens when two devices edit the same note while offline.

Client Architecture

Interviewer: Walk me through the overall architecture.

Candidate: Clean Architecture with MVVM, Room as the single source of truth, and WorkManager handling all background sync.

UI Layer
  NoteListScreen / NoteEditScreen  ←  ViewModel (StateFlow / Compose State)

Domain Layer
  Use Cases: CreateNote, UpdateNote, DeleteNote, SearchNotes, SyncNotes

Data Layer
  NoteRepository
    ├── Local Source  → Room (all reads and writes, always)
    └── Remote Source → Retrofit (sync only, never on the critical path)

Sync Layer
  NoteSyncWorker (WorkManager CoroutineWorker)
  SyncStatusTracker (exposes sync state to UI)

The critical principle: the UI never talks to the network directly. Every read and write goes through Room. The ViewModel observes Room via Flow — when a note is saved, Room emits the update and the UI reacts. Sync happens entirely in the background.

This is what makes offline feel seamless. When a user types a note with no internet, the experience is identical to when they have full connectivity. Room doesn't know or care about the network.

Room Schema Design

This is the first place interviewers probe in depth. A weak schema here cascades into problems with sync, conflict resolution, and search.

Interviewer: Walk me through the Room schema for a notes app.

Candidate: Let me walk through each entity and explain why each field exists.

@Entity(tableName = "notes")
data class NoteEntity(
    @PrimaryKey val id: String,          // UUID — client-generated, not server auto-increment
    val title: String,
    val contentJson: String,             // rich text serialised as JSON (covered below)
    val contentPlainText: String,        // stripped plain text — for FTS indexing
    val isPinned: Boolean = false,
    val isArchived: Boolean = false,
    val color: String? = null,           // hex colour string, nullable
    val createdAt: Long,                 // epoch millis, set on creation, never changes
    val updatedAt: Long,                 // epoch millis, updated on every local edit
    val serverUpdatedAt: Long? = null,   // the server's last-modified timestamp — for conflict detection
    val syncStatus: SyncStatus,          // SYNCED, PENDING, CONFLICTED
    val isDeleted: Boolean = false       // soft delete — never hard-delete before sync
)

enum class SyncStatus { SYNCED, PENDING, CONFLICTED }

A few decisions to call out explicitly.

Client-generated UUID. If the primary key were a server-assigned integer, the client couldn't create a note offline — it would have no ID until the server responds. A UUID generated on the device means the note has an ID from the moment of creation, before any network interaction.

contentPlainText alongside contentJson. Rich text content is stored as JSON (explained below). But Room FTS can't tokenise JSON structure — it needs plain text. So we maintain a stripped version for search indexing.

syncStatus. This is the heartbeat of the offline-first design. Every note is in one of three states: SYNCED (local and server agree), PENDING (local change not yet sent to server), or CONFLICTED (a conflict was detected that needs resolution). The sync worker queries for PENDING notes; the UI surfaces CONFLICTED notes to the user.

Soft delete with isDeleted. Never hard-delete a note before it's synced. If you delete a note locally and it's never been synced, you need to inform the server on the next sync. A hard delete loses that signal.

Tags schema:

@Entity(tableName = "tags")
data class TagEntity(
    @PrimaryKey val id: String,
    val name: String,
    val userId: String
)

@Entity(
    tableName = "note_tags",
    primaryKeys = ["noteId", "tagId"]
)
data class NoteTagEntity(
    val noteId: String,
    val tagId: String
)

FTS virtual table for full-text search:

@Fts4(contentEntity = NoteEntity::class)
@Entity(tableName = "notes_fts")
data class NotesFts(
    val title: String,
    val contentPlainText: String
)

Room's @Fts4 annotation creates a SQLite full-text search virtual table backed by contentPlainText and title. FTS4 tokenises content at write time, enabling MATCH queries that are orders of magnitude faster than LIKE '%term%' on large note collections. We'll use this for the search feature.

Rich Text Storage

Interviewer: How do you store and render rich text in the note editor?

Candidate: This is an area where candidates often say "use a WebView" and move on. Let me give a more considered answer.

What it is: Android's native text system uses Spanned / SpannableString — in-memory objects that hold text alongside formatting ranges (bold from position 5 to 10, italic from 20 to 25, etc.). These are great for rendering in EditText but can't be directly persisted to Room.

The storage strategy: serialise the rich text document to JSON. The format stores the raw text plus an array of spans with their type, start, and end positions:

{
  "text": "Meeting notes\nDon't forget to review the PRD",
  "spans": [
    { "type": "BOLD", "start": 0, "end": 13 },
    { "type": "ITALIC", "start": 29, "end": 43 }
  ]
}

On write: convert SpannableString → JSON, store in contentJson. Also extract text as contentPlainText for FTS.

On read: deserialise JSON → rebuild SpannableString and display in EditText.

Markdown as an alternative: some notes apps (Notion, Bear) store content as Markdown strings. This is simpler to serialise and portable, but rendering Markdown in Android requires either a third-party library (Markwon is the standard) or a WebView. The trade-off: Markdown is easier to sync and diff across devices (it's just text), but native Markdown rendering is heavier than SpannableString. For a Google Keep-style app with basic formatting, JSON-serialised spans is the right call. For a Notion-style app with complex block structures, consider a block-based document model.

What not to do: never store HTML in the database. HTML is verbose, hard to diff, and the WebView it requires for rendering is expensive for list scrolling.

Offline-First Architecture: The Write Path

Interviewer: Walk me through what happens when the user creates a note with no internet connection.

Candidate: This is the critical path, and it's entirely local:

User types in NoteEditScreen
  │
  ▼
ViewModel.saveNote()
  │  Called on a debounced timer (500ms after typing stops)
  ▼
NoteRepository.save(note)
  │
  ▼
Room.insert/update(note.copy(syncStatus = PENDING, updatedAt = now()))
  │  Returns immediately — sub-millisecond
  ▼
UI observes Room Flow → updates note list with "saving..." indicator
  │
  ▼
WorkManager enqueued with CONNECTED constraint
  (No-op if already enqueued for this note — idempotent enqueue)

The user sees their note saved instantly. There's no loading spinner, no "waiting for network" state. The PENDING status is invisible to the user at this point — it's an internal state that drives the sync pipeline.

The debounce is important. Notes apps don't save on every keystroke — that would flood Room with writes. A 500ms debounce means one Room write per burst of typing, not one per character. On process kill, the ViewModel's onCleared() triggers an immediate save of any pending debounced content so nothing is lost.

Additionally: You should learn about stuff like http vs https, REST vs GraphQL vs WebSockets. Mockingly.AI has a GYM where you can practice these exact questions and more. Try it out.

Background Sync: WorkManager

What WorkManager does: WorkManager is the Jetpack-recommended solution for background work that must complete, even if the app is killed or the device restarts. It persists work to a Room-backed queue, respects battery constraints, and retries with exponential backoff on failure.

Interviewer: How does sync work in the background?

Candidate: The NoteSyncWorker runs in three scenarios: when the user explicitly triggers a sync, when the network becomes available (via ConnectivityManager.NetworkCallback), and on a periodic schedule (every hour).

The worker runs as a CoroutineWorker — safe to do Room reads and API calls without blocking the main thread:

NoteSyncWorker.doWork():
  1. Query Room for all notes where syncStatus = PENDING
  2. For each PENDING note:
     a. Try POST/PUT to sync API with { id, contentJson, updatedAt }
     b. Server responds with { serverId, serverUpdatedAt, conflicted: bool }
     c. If no conflict:
           Room update: syncStatus = SYNCED, serverUpdatedAt = response.serverUpdatedAt
     d. If conflict:
           Room update: syncStatus = CONFLICTED
           Store server version alongside local version
  3. Pull new notes from server (delta pull — send lastSyncTimestamp)
     For each server note:
        If note not in Room: INSERT (syncStatus = SYNCED)
        If note in Room and serverUpdatedAt > local serverUpdatedAt:
            Check for PENDING local changes → potential conflict
  4. Return Result.success() or Result.retry() on transient failure

Enqueue the worker as unique work using ExistingWorkPolicy.KEEP. This prevents multiple simultaneous sync workers from racing each other:

WorkManager.enqueueUniqueWork(
    "notes_sync",
    ExistingWorkPolicy.KEEP,
    syncRequest
)

For the periodic sync, use enqueueUniquePeriodicWork with ExistingPeriodicWorkPolicy.KEEP to prevent redundant periodic sync registrations across app restarts.

Conflict Resolution: The Hard Part

This is where the interview gets interesting, and where the most valuable answers live. A notes app syncing across devices will inevitably have conflicts — the same note edited on two devices while both were offline.

Interviewer: The user edits a note on their phone while offline. The same note was edited on their tablet while that was also offline. Both devices reconnect. What happens?

Candidate: This is the classic offline sync conflict, and there are three resolution strategies — each with different trade-offs.

Strategy 1: Last-Write-Wins (LWW)

Compare updatedAt timestamps. The version with the more recent timestamp wins; the other is discarded.

Phone version:  updatedAt = 14:00, content = "Meeting agenda: review PRD"
Tablet version: updatedAt = 14:05, content = "Meeting agenda: cancelled"
Winner: Tablet (newer timestamp)
Phone's changes silently discarded.

Simple to implement, zero user friction — but can silently discard work the user cares about. Acceptable for apps where notes are short and the cost of a lost edit is low. Not acceptable if a user writes a 500-word note on their phone and later fixes a typo on their tablet.

Strategy 2: Show Both — User Resolves

When a conflict is detected, mark the note as CONFLICTED in Room. Store both versions: the local version and the incoming server version. Surface the conflict in the UI — a "conflict detected" badge on the note list item. When the user taps it, show a diff view with both versions and let them choose which to keep, or manually merge.

This is the safest option for user data — nothing is lost. But it requires a UI for conflict resolution (a diff view is non-trivial to build) and puts cognitive load on the user.

Strategy 3: Auto-Merge (Best for Text)

If the conflicting edits touch different parts of the text — one user added a paragraph at the top, the other edited the middle — they can be automatically merged. Use a three-way merge algorithm: find the common ancestor (the last synced version), apply both sets of changes independently, and combine them.
Ancestor:  "Meeting notes"
Version A: "Meeting notes\nAction items:\n- Review PRD"  (appended)
Version B: "**Meeting notes**"  (bolded title)
Merged:    "**Meeting notes**\nAction items:\n- Review PRD"  (both applied)
If the edits genuinely conflict (both edited the same sentence differently), fall back to Strategy 2 and surface the conflict to the user.

What I'd recommend: Strategy 3 with a fallback to Strategy 2. Auto-merge handles the majority of real-world conflicts silently; user resolution handles the hard cases. The implementation uses a CRDT-inspired approach or a Myers diff algorithm for text merging. This is what Notion and Apple Notes approximate in production.

Interviewer: What's a CRDT and when would you use one?

Candidate: A Conflict-free Replicated Data Type is a data structure designed to be merged from multiple sources without conflicts — mathematical guarantees, not heuristics. Every individual character insertion/deletion is tracked as an operation with a logical clock. Merging two CRDT documents always produces the same result regardless of order.

The trade-off: CRDT-encoded documents are significantly larger (each character has metadata), more complex to implement, and require a CRDT-aware server. For a simple notes app, the three-way merge approach is simpler and correct for most cases. CRDTs make sense if you're building real-time collaborative editing where multiple users type simultaneously — like a Notion or Google Docs clone. For a single user's notes syncing across their own devices, last-write-wins or three-way merge is almost always sufficient.

Delta Sync: Don't Send Everything

Interviewer: How does the client know which notes to pull from the server on sync?

Candidate: Delta sync. Rather than downloading every note on every sync, the client sends its last successful sync timestamp and the server returns only what changed since then.

Client → GET /sync?since=1733990400000&deviceId=abc123
Server → {
    updated: [note1, note2],   // created or modified since that timestamp
    deleted: ["note_id_5"]     // deleted on another device since that timestamp
}

The client stores lastSyncTimestamp in DataStore<Preferences> — not Room. It's a scalar value, not structured data. DataStore is the modern replacement for SharedPreferences and avoids the thread-safety issues that SharedPreferences has when accessed from multiple coroutines.

On the server side, every note update touches a updated_at server timestamp that the delta query uses. Deletions are soft-deleted and tracked in a deleted_notes table so they appear in the delta response before the record is permanently purged.

If you want to practice explaining exactly this kind of trade-off — why DataStore over SharedPreferences, why delta sync over full refresh — under interview pressure, Mockingly.ai has Android system design simulations that put you in exactly these conversations.

Full-Text Search with Room FTS4

Interviewer: How does search work?

Candidate: Room's @Fts4 annotation creates a virtual table backed by SQLite's FTS4 extension. FTS4 tokenises text at insert time and maintains an inverted index, enabling fast prefix and phrase matching.

What FTS4 is: SQLite's Full-Text Search extension creates a separate virtual table alongside the main notes table. When a note is inserted or updated, FTS4 tokenises the text and updates its index. Queries use MATCH syntax rather than LIKE, and the lookup is O(log n) against the index rather than a full-table scan.

The DAO query:

@Dao
interface NoteDao {
    @Query("""
        SELECT notes.* FROM notes
        INNER JOIN notes_fts ON notes.id = notes_fts.rowid
        WHERE notes_fts MATCH :query
          AND notes.isDeleted = 0
          AND notes.isArchived = 0
        ORDER BY rank
    """)
    fun searchNotes(query: String): Flow<List<NoteEntity>>
}

The caller appends * to enable prefix matching: "meet*" matches "meeting", "meetup", "meetings". Without the wildcard, FTS4 only matches exact tokens.

What Room FTS4 doesn't handle: fuzzy matching ("meetting" → "meeting"). If fuzzy search is important, consider maintaining a trigram index manually or preprocessing the query to expand common misspellings. For most notes apps, prefix matching is sufficient.

Attachments: Images and Files

Interviewer: How do you handle image attachments in notes?

Candidate: Never store image bytes in Room. SQLite is not an object store, and large blobs in a Room database degrade query performance for the entire database.

The pattern:

User attaches photo to a note
  │
  ▼
Copy photo to app's internal private storage
  → /data/data/com.example.notes/files/attachments/{uuid}.jpg
  (Internal storage — not accessible to other apps, no storage permission needed)
  │
  ▼
Store only the local file path in Room:
  AttachmentEntity { id, noteId, localPath, remoteUrl, syncStatus }
  │
  ▼
On sync: upload file to remote storage (S3 / GCS) via pre-signed URL
  (same pattern as photo apps — direct upload, not through the app server)
  │
  ▼
Update AttachmentEntity.remoteUrl once uploaded

Why copy to internal storage? The original photo might live in the camera roll, accessible via a content URI. Content URIs are temporary and can be revoked if the user deletes the photo from the gallery. Copying to internal storage gives the notes app durable ownership of the attachment.

Attachment sync: attachments are uploaded asynchronously in a separate AttachmentSyncWorker. They don't block note text sync. Note text syncs fast (bytes); attachment upload can take seconds depending on file size and network speed. Separating them keeps note sync latency low and allows attachment upload to retry independently.

Storage quota: warn the user when attachment storage exceeds a configurable threshold (say, 500 MB). Offer a "clear cached attachments" option that deletes locally cached versions of remotely backed attachments — they can be re-downloaded on demand.

Sync Status UI

The UI should reflect sync state transparently without being intrusive.

Interviewer: How does the user know if their notes are synced?

Candidate: A SyncStatusTracker in the ViewModel exposes the aggregate sync state as a StateFlow:

sealed class SyncState {
    object Synced : SyncState()
    object Syncing : SyncState()
    data class PendingCount(val count: Int) : SyncState()
    data class Conflict(val noteId: String) : SyncState()
    object Offline : SyncState()
}

The notes list screen observes this state and renders accordingly:

Synced: no indicator shown — clean state is the default

Syncing: a subtle progress indicator in the toolbar

PendingCount: "3 notes waiting to sync" — visible but not blocking

Conflict: a badge on the conflicted note's list item — red dot

Offline: "Working offline" banner at the top, non-blocking

The key UX principle from offline-first design: optimistic UI. Show the note as saved immediately. The "syncing" state is a background concern. Never block the user from editing while sync is in flight. The phrase "Saved locally — syncing" is more reassuring than a spinner that blocks typing.

Handling Edge Cases

Interviewer: What happens if the user deletes a note on their phone while it was being edited on their tablet?

Candidate: The delete event gets a serverTimestamp when it syncs. On the next sync to the tablet, the server sends a deleted array containing that note's ID. The tablet's sync worker checks: does this note have local unsaved changes (syncStatus = PENDING)?

If no local changes: apply the deletion. Room soft-deletes the note.

If yes, local PENDING changes: surface a conflict to the user. "This note was deleted on another device, but you have unsaved changes here. Keep your version or confirm deletion?" This is a case where auto-merge can't help — explicit user decision is required.

Interviewer: What about the note the user created offline that has the exact same UUID as one already on the server?

Candidate: UUID collision probability with a standard UUID.randomUUID() (Version 4 UUID) is approximately 1 in 2^122. With a billion notes created, the probability of any two sharing a UUID is roughly 1 in 10^27. For practical purposes this never happens. But defensively, the sync API validates UUID uniqueness server-side and returns a 409 Conflict if a collision somehow occurs. The client generates a new UUID and retries. This is a theoretical concern worth acknowledging but not worth over-engineering.

Common Interview Follow-ups

"How would you implement real-time collaboration — two users editing the same note simultaneously?"

This changes the architecture significantly. You'd need a WebSocket connection to a backend that broadcasts operations in real time. The local note model would switch to a CRDT (Conflict-free Replicated Data Type) like Yjs or Automerge, where every character insertion/deletion is represented as an operation with a logical timestamp. Room still holds the local state, but the sync mechanism becomes operation-based (send operations, receive operations) rather than state-based (send full note, receive full note). This is a significantly heavier lift than eventual-consistency sync — worth naming the architectural difference clearly.

"How do you handle the case where WorkManager can't sync because the device has been offline for weeks?"

The server retains notes in a soft-deleted state for a grace period (say, 90 days) before permanent deletion. Notes flagged as deleted by another device more than 90 days ago will simply not appear in delta sync responses. The client's eventual sync catchup handles all changes within that window correctly. If a device reconnects after the grace period, the user might see stale notes that others consider deleted — surface this edge case honestly in the design.

"How would you add a sharing feature — send a note to another user?"

Shared notes are a different data ownership model. A note owned by User A can be granted read or write access to User B. Server-side: a note_shares table with { note_id, owner_id, recipient_id, permission }. Client-side: the shared note appears in the recipient's note list via delta sync. The recipient's edits sync to the server, which fans out to the owner's devices on their next delta pull. Conflict resolution applies across users just as it does across devices.

"How do you prevent data loss if Room's database gets corrupted?"

Room's database file lives in internal storage — not backed up by default by Android's automatic backup. Enable android:allowBackup="true" and android:fullBackupContent rules in the manifest to include the Room database in Google's automatic cloud backup (limited to 25 MB). For production: implement explicit export — a background task that periodically exports all notes to a JSON file in the user's Google Drive or via Android's BlobStoreManager. Defense in depth: if the local database is corrupted, a full re-download from the server is the recovery path. This is why the server is the durable source of truth, not the device.

Quick Interview Checklist

✅ Clarified scope — sync across devices, rich text, tags, search, full offline support
✅ Clean Architecture + MVVM, Room as single source of truth
✅ Client-generated UUIDs — offline note creation without server round-trip
✅ syncStatus enum on every note — SYNCED, PENDING, CONFLICTED
✅ Soft delete (isDeleted) — never hard-delete before sync
✅ updatedAt and serverUpdatedAt — local and server timestamps for conflict detection
✅ Rich text stored as JSON spans, plain text extracted separately for FTS
✅ Room FTS4 for full-text search — @Fts4 annotation, MATCH query, prefix wildcard
✅ Debounced saves in ViewModel — not on every keystroke, immediate save on onCleared()
✅ WorkManager CoroutineWorker for background sync — persists across process kills and reboots
✅ enqueueUniqueWork with KEEP policy — no duplicate sync workers
✅ Three conflict strategies explained — LWW, user resolution, auto-merge with fallback
✅ Delta sync with lastSyncTimestamp — not full re-download on every sync
✅ lastSyncTimestamp in DataStore (not SharedPreferences, not Room)
✅ Attachments copied to internal storage, file path in Room, uploaded separately
✅ AttachmentSyncWorker separate from note text sync — different latency/retry profiles
✅ Optimistic UI — "Saved locally, syncing" pattern
✅ SyncState exposed as sealed class StateFlow from ViewModel
✅ CRDT explained as the real-time collaboration upgrade path

Conclusion

Designing a notes app is a deceptively rich Android interview question. It's not about CRUD — it's about building a system that feels instant, never loses data, handles network absence gracefully, and reconciles state across devices in a way that makes sense to users.

The candidates who impress interviewers at Google, Microsoft, and Notion aren't the ones who describe a simple Room + Retrofit setup. They're the ones who name the offline-first principle explicitly, explain what syncStatus buys you, articulate the three conflict resolution strategies and their trade-offs, know why delta sync matters, and can describe what happens in the edit-on-two-devices-while-offline scenario without blinking.

The design pillars:

Room as single source of truth — UI never talks to the network; all reads and writes go through Room
Client-generated UUIDs — offline note creation requires a device-side identity
syncStatus on every record — the engine that drives the entire sync pipeline
WorkManager with unique work policy — the only tool that guarantees sync survives process kills
Delta sync with DataStore timestamp — don't re-download everything on every sync
Auto-merge with fallback to user resolution — the right conflict strategy for a notes app
Room FTS4 for search — orders of magnitude faster than LIKE at any meaningful note count

Frequently Asked Questions

What is offline-first architecture in an Android notes app?

Offline-first means the app reads and writes to a local database — not a server — as its primary source of truth.

Every note operation (create, edit, delete) goes straight to Room without touching the network. The UI reflects changes instantly. Sync to the server happens in the background, invisible to the user.

Key properties of an offline-first notes app:

All core features work with zero network connectivity
UI never shows a loading spinner waiting for the network
Data is never lost because the device lost signal mid-edit
Server sync runs silently via WorkManager when connectivity returns

Why use Room as the single source of truth?

Room is the single source of truth because it guarantees the UI always has data — regardless of network state.

If the ViewModel fetched data from Retrofit directly, a network failure would leave the screen blank. With Room:

The UI observes Room via Flow and reacts to every local change
The network only writes into Room — it never drives the UI
Cached data from the last session is available immediately on app open
Offline and online states are identical from the UI's perspective

How does WorkManager handle background sync in a notes app?

WorkManager is Android's recommended API for guaranteed background work that must complete even after a process kill or device reboot.

How it handles notes sync:

A NoteSyncWorker (CoroutineWorker) is enqueued with ExistingWorkPolicy.KEEP
WorkManager persists the job to its own Room-backed database internally
The job runs when the NetworkType.CONNECTED constraint is satisfied
If the process is killed mid-sync, WorkManager re-runs the worker on next launch
Multiple triggers (network return, app open, manual sync) never spawn duplicate workers

The KEEP policy is essential — without it, every app open could enqueue a fresh sync job, eventually queuing hundreds of redundant workers.

What is delta sync and why does it matter for a notes app?

Delta sync means uploading and downloading only what has changed since the last successful sync — not the entire note list every time.

How it works:

The client stores lastSyncTimestamp in DataStore (not SharedPreferences — it's thread-safe)
On each sync, the client sends this timestamp to the server
The server returns only notes created or modified after that timestamp
The client applies those changes to Room

Why it matters:

A user with 500 notes who edits 5 per day transfers ~25 KB, not ~2.5 MB
Sync is faster, uses less battery, and completes before the user notices

What is the syncStatus field and why does every note need one?

syncStatus is an enum on every NoteEntity that tracks whether the local state has been confirmed by the server.

The three states:

SYNCED — local and server agree; no action needed
PENDING — local change exists that hasn't been uploaded yet
CONFLICTED — a conflict was detected that needs resolution

Why it's necessary:

The sync worker queries WHERE syncStatus = PENDING to know what to upload
The UI shows a badge on CONFLICTED notes for user attention
Without this field, the app has no reliable way to track unsent edits
On process kill mid-sync, PENDING notes are safely retried on next launch

What are the conflict resolution strategies for a syncing notes app?

A conflict occurs when the same note is edited on two devices while both are offline. There are three standard strategies:

1. Last-Write-Wins (LWW)

Compares updatedAt timestamps; the newer version wins
Pro: simple, zero user friction
Con: silently discards edits the user cares about
Best for: short notes where losing an edit is low-cost

2. User Resolution

Marks the note CONFLICTED, stores both versions, asks the user to choose
Pro: zero data loss
Con: adds friction; requires a diff/merge UI
Best for: apps where every word matters (legal, medical notes)

3. Auto-Merge with Fallback

Uses a three-way merge to combine changes touching different text ranges
Falls back to user resolution only when edits genuinely overlap
Pro: handles most real-world conflicts silently
Con: more complex to implement
Best for: general-purpose notes apps (Google Keep, Apple Notes style)

Recommended approach: auto-merge with a user-resolution fallback. Most conflicts are two edits to different paragraphs — they merge automatically. Genuine overlapping edits are surfaced explicitly.

How does Room FTS4 full-text search work in a notes app?

Room FTS4 creates a SQLite virtual table that tokenises note content at write time and enables instant keyword searches using an inverted index.

How it differs from a LIKE query:

LIKE '%keyword%' scans every row sequentially — O(n)
FTS4 MATCH 'keyword' is a direct index lookup — O(log n)
FTS4 supports prefix matching (meet* matches "meeting", "meetup")
Speed difference is imperceptible at 50 notes; significant at 5,000+

Setup in Room:

Annotate a virtual entity with @Fts4(contentEntity = NoteEntity::class)
Index title and contentPlainText (plain text stripped from rich text JSON)
Query with SELECT * FROM notes INNER JOIN notes_fts WHERE notes_fts MATCH :query
Append * to the query string to enable prefix matching

How do you store rich text in an Android notes app?

Rich text is serialised to JSON and stored in a contentJson TEXT column in Room. A separate contentPlainText column stores the stripped text for FTS indexing.

The JSON format:

{
  "text": "Meeting notes for Q4",
  "spans": [
    { "type": "BOLD", "start": 0, "end": 7 },
    { "type": "ITALIC", "start": 8, "end": 12 }
  ]
}

The two storage approaches compared:

Approach	Pros	Cons
JSON spans	Native Android integration, no library needed	Harder to diff across devices
Markdown string	Easy to diff, portable	Requires rendering library (Markwon)

For a Google Keep–style app with basic formatting, JSON spans integrating with Android's native SpannableString is the cleaner choice. For a Notion-style app with blocks and embeds, a block-based document model (similar to ProseMirror) is more appropriate.

Why are client-generated UUIDs important for offline note creation?

Client-generated UUIDs allow notes to have a stable identity from the moment of creation — before any server interaction.

If the primary key were a server-assigned integer:

The app cannot create a note offline (no ID until the server responds)
The UI must wait for a network round-trip before displaying the new note
Process kill during creation leaves the app in an ambiguous state

With UUID.randomUUID() (Version 4):

The note has an ID instantly — used as the Room PK and the server's document ID
Offline creation, editing, and deletion all work without network
The UUID serves as an idempotency key for sync — if a sync POST is retried, the server rejects the duplicate

Collision probability: ~1 in 10²⁷ with a billion notes. Effectively zero.

Which companies ask the Android notes app system design question?

Google, Microsoft, Notion, Evernote, and Dropbox all ask variants of this question for senior Android engineer roles.

Why it's popular:

It's self-contained — clear product scope, no ambiguity about what to design
It touches every hard Android topic: Room schema, WorkManager, offline-first, conflict resolution
The depth scales cleanly — a junior candidate describes CRUD; a senior candidate explains syncStatus, delta sync, and three-way merge
It maps directly to real products these companies build and maintain

Red flags interviewers watch for:

Designing around Retrofit without mentioning offline handling
Not explaining what syncStatus buys you
Proposing SharedPreferences for lastSyncTimestamp (not thread-safe)
Missing soft delete — hard-deleting before sync drops data silently

*The notes app question rewards candidates who understand that mobile system design is fundamentally about managing two sources of truth — the device and the server — and making the reconciliation between them invisible to the user.

If you want to practice talking through conflict resolution strategies, delta sync, and WorkManager lifecycle decisions under real interview pressure, Mockingly.ai has Android-focused system design simulations specifically built for engineers preparing for senior roles at Google, Microsoft, Notion, and Evernote.*

System Design Interview Tip No One Talks About

Ayusch — Wed, 19 Nov 2025 21:36:26 +0000

System design interviews can feel overwhelming. You draw big boxes. You label them. You sketch arrows.You talk about APIs, queues, caching, scalability, data models, and failure modes.

And even after all that, your interviewer can still say, "What happens when this part fails?" or "Walk me through your data consistency model." It feels endless 😭

But after seeing hundreds of candidates prepare, practice, and interview, one pattern has become incredibly clear.

Why instincts matter more than memorizing architectures

You can memorize dozens of famous system designs from YouTube videos or GitHub repositories. You can replicate architecture diagrams for Netflix, Uber, or Instagram. But real interviews almost never follow that script.

Instead, interviewers test how you think.

They ask questions like:

Explain http vs https
Why would you choose REST over GraphQL here
How would you design pagination for millions of records
When would you use Redis over a database cache
What consistency model would you pick and why
How would you handle offline sync in a mobile app

Solve these questions on https://mockingly.ai/trivia

Image above is a screenshot from Mockingly which has these tradeoff-like questions to help you understand the concepts.

These are all fundamental concepts, not full systems.
If you know the fundamentals well, the interview becomes more like a conversation than an exam. You can explain trade-offs clearly. You can reason on the fly. You can adapt when the interviewer changes constraints.

The problem with most preparation approaches

Most candidates prepare in a way that looks productive, but actually creates a false sense of readiness.

They binge long system design videos. They read architecture posts. They memorize high-level diagrams.

But when the interviewer digs into details, everything suddenly feels shaky.

If your fundamentals are weak, you end up:

Over-explaining obvious things
Forgetting key trade-offs
Struggling to justify decisions
Repeating the same patterns regardless of the question
Freezing when asked about bottlenecks, failure modes, or data flow

Strong candidates look confident because they know the basics so well that they can build any system step by step.

So how do you build these instincts

By practicing the fundamentals in short, focused, repeated bursts.
This is the same way people train for chess, competitive programming, language learning, or fitness. Consistent, small reps beat long, passive study sessions.

These fundamentals are essential for any system design interview preparation: Mockingly Trivia. You want to quickly test yourself on topics like:

REST vs GraphQL vs WebSockets
SQL vs NoSQL
Types of pagination and when to use each
Caching patterns
Rate limiting techniques
Message queues vs streams
Horizontal vs vertical scaling
Types of consistency models

These are the high-signal areas that show up in almost every interview.

A faster way to build interview instincts I built mockingly.ai for exactly this reason. One feature in particular, Interview Trivia, gives you short, high-value quizzes that target the most important fundamentals.

These quizzes help you:

Strengthen your understanding of core concepts
Build the reflexes needed during live interviews
Learn trade-offs in a practical, memorable way
Train your brain to respond faster and with more clarity

Each quiz takes only a minute or two, and covers real topics that candidates struggle with in actual interviews.

If you want to try it, you can check it out here: https://mockingly.ai/trivia

Combine fundamentals with real practice

Trivia alone is not enough. But it gives you a solid foundation. Once your fundamentals are strong, full mock interviews become far easier.
At that point, practice full sessions where you:

Draw a system diagram
Explain data flow
Handle follow-up questions
Discuss trade-offs
Justify design decisions

This is where everything clicks. A simple preparation plan you can follow. Here is a balanced way to prep without burning out:

Daily (5 to 10 minutes): Do a few Interview Trivia quizzes to sharpen fundamentals.
Weekly (1 or 2 times): Do a full mock system design session.
After each session: Review what confused you and add those topics to your fundamentals practice.

This creates a cycle of steady improvement.

Final takeaway

If you want to improve your performance in system design interviews, stop trying to memorize giant architectures. Focus on mastering the core concepts and trade-offs. Build strong instincts. Train them often. Keep your practice light but consistent.

This one shift separates average candidates from standout ones.
If you want a structured way to build these instincts, try Interview Trivia and free AI mock interviews at: https://mockingly.ai

The Mobile System Design Interview: My FAANG Prep Journey + Free Practice Resource

Ayusch — Thu, 21 Aug 2025 19:28:09 +0000

Context

When talking about System Design, most resources, experiences written online focus heavily on backend system designs. But if you’re aspiring to be a mobile (Android, iOS) engineer at one of the FAANGs, you’ll have to go through a rigorous mobile system design interview.

I’ve interviewed at 3/5 FAANG companies, and have cleared their system design rounds. And after about 6 years as a mobile engineer, I feel I have a fairly good experience about what consists of a system design round at these companies.

But there’s a dearth of mobile focused system design preparation material. So in this blog, I’ll share my experience interviewing at these companies, and a few tips on how to prep for one. I hope this will help any aspiring mobile devs who have an upcoming interview.

My Experience

The interview at FAANG consists of 3 main components:

Coding interviews: can range from 2 - 3 rounds of Data Structure and Algorithms focused interview.
System Design interview: While mostly 1, recently there’s been a push for 2 rounds of system design interviews. I’ve experienced it at one of the big techs.
Behavioural Interview: These are interviews focused on your past experiences. Questions are situation based and the best way to answer these is using the STAR method.

So let’s talk about System Design.

Here’s some of system design questions I’ve encountered so far in my interviews:

Design an image caching library like glide.
Design a 1 to 1 Chat application which can also send images, videos.
Design a App Store.
Design an e-commerce app’s homepage.
Design a stock market app’s ticker page. The page which displays the prices of stocks.

These are some of the major ones that I remember.

And while you can find answers to most of them online, just mugging up is never the solution. When I tried mugging up initially, it made me anxious as the interview day got closer. I became anxious that I might forget to draw a component.

After failing a few interviews, I realised I wasn’t failing because I lacked knowledge, I was failing because I obsessed over details instead of thinking like an architect.

See, for system design interviews, you can direct them in any way you want. It’s up to you how you steer the interview. You can go down the rabbit hole of discussing very specific details, or you can focus on the building blocks of the design and if need be, explain the block which you’re most confident about. Let the interviewer grill you on a component. Don’t make it hard yourself.

My Preparation

As a mobile (android, react native) engineer, I couldn’t find many resources to prepare for the interviews. There were questions sprinkled here and there, but nothing like Grokking the system design interview which was heavily backend focused.

I tried doing some mock interviews with my friends, but they weren’t necessarily helpful. Most of my friends were backend engineers + it was hard to schedule time with them due to our heavy workload. Weekend plans never materialised.

I came across some websites which offered system design interviews with engineer from FAANGs but it was too costly for me.

Plug: I created mockingly.ai to solve for this problem. The first mock interview platform with mobile-specific system design questions, instant AI feedback, and on-demand practice. It’s like having a FAANG engineer available 24/7 to mock interview you. Right now, the first session is free!

Next up, weebox’s github repository was the first resource that was actually helpful for me. It had mobile focused system design questions.

Then I did the worst thing possible, I tried mugging up all the answers. As I said, design interviews are very subjective and mugging never helps. I failed miserably at a design interview for a job I desperately wanted. I was disheartened. I had been fairly confident that I could clear the design round as I had all the answers in my head, so I couldn’t believe I screwed up the interview.

I had screwed up some sys design interviews before, but those weren’t for jobs that I was desperately aiming for, this time it hit different. Something had to change.

And that change was my preparation strategy. I realised that mugging up won’t help. I needed to really understand how system design worked, what are the components to focus on and the concepts. Also, my approach to interviews had to change.

Here’s what I did:

I looked at weebox’s mobile system design questions not as an Android, iOS engineer. But as an architect.
I started thinking in terms of Screens, presentation layer, data layer. I read how repository pattern works.
Actively tried not to think in terms of Android concepts like work manager, foreground services, etc…I wanted to think high level, like an architect.
Picked up 1 question from Weebox, and tried to solve it myself.
Reviewed my diagrams comparing it to Weebox’s answers.
Next, pick up some concepts which I wanted to learn such as http vs https, rest vs WebSocket vs GraphQL.
Started actively critiquing my design choices. eg. why did I choose REST and not WebSocket? What’s the difference, how do they both work.
I tried mock interviewing, but couldn’t find people for it. Moreover, our timings never matched. mockingly.ai would have been really helpful for preparing for system design interviews. I could do the mocks on demand.
Designing libraries was no different. Even though they have no screens, they have an entry point. for example: CacheManager for a caching library, which would talk to other components like repository, file cache, sqlite etc…

It took me almost 4-5 months to get my head around system design interviews. The major change was my thought process. I started to think like an architect instead of a domain expert (like android engineer, iOS engineer).

Then I scheduled some interviews.

Interview experience

Once I got done with my prep, I decided to appear for some interviews, and luckily got a chance at one of the FAANGs.

This time I wasn’t anxious. At least not about my system design interview. I knew I had the concepts in my head, I knew I had prepared well. And if only I could communicate what I was doing and thinking and explain my decisions, it’d be a breeze!

And it was, I got the feedback, and even though I didn’t make it (due to a coding round), I had cleared the system design interview and it was s STRONG hire. Yay! I was overjoyed, I had overcome the only obstacle I had in my interview preparations.

System design had always been a mistery to me. And I had finally solved it.

I still need to prep for system design rounds, just as I need to do for coding rounds, but it’s not daunting to me anymore. I now have my resources that I can pick up just a month before the interview and be ready.

Preparation tips:

Here I’ll collate all the things that you’ll find helpful for your system design interview prep. I’ll keep it mobile focused (sorry backend engineers):

mockingly.ai for practicing system design interviews whenever you like.
Weebox’s Github repository for reading up on the questions and answers. It’s like a question bank.
Alex Lementuev’s youtube channel. Some interviews are helpful. I would not take the answers on face value, but watch the flow of the interview and the candidate’s thought process.
Speak. Speak a lot! Practice thinking out loud. You’ll need this to direct the interview.
Understand how things like http, rest, GraphQL, WebSocket work and why would you pick one over the other.
Think like an architect and not a XYZ engineer.
Practice…

Next up, a step-by-step framework for any system design interview: 

Clarify requirements.
Identify users and flows.
Break down into layers (UI, data, networking).
Highlight trade-offs.
Deep-dive into one component.

Let me know if you found this blog helpful. I wished a guide existed for mobile engineers to prepare for mobile system design interviews. Here’s my attempt at creating one :)

If you’re prepping for mobile interviews, give mockingly.ai a try and tell me what you think. I’d love your feedback — and maybe your success story will be the next one featured there.

Creating a Bottom Sheet in Flutter

Ayusch — Wed, 13 May 2020 11:52:19 +0000

In one of my previous articles, I outlined how to create a bottom sheet in React Native. In this short tutorial, we’ll see how to create a bottom sheet in Flutter.

This is by far the easiest framework I’ve encountered on creating a bottom sheet. It literally just involves calling a simple method. So this’ll be short and quick.

Getting Started

First step of this tutorial is to create a new flutter project. If you haven’t already installed flutter, check out this article on how to install flutter on your machine.

This tutorial will guide you with a step by step tutorial. Next, after you’ve installed flutter, create a new flutter project.

➜  ~ flutter create bottomsheet_tutorial

Creating the bottom sheet

First, get rid of the initial code that you’re provided by default. We’ll write our own.

We’ll create a floating action button, and on clicking it, we’ll display a bottom sheet. To create a floating action button in flutter, you’ll need a Scaffold. Scaffold in flutter allows us to use Material Design elements such as AppBar, floating action button, navigation drawer and so on.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'BottomSheet demo'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'Click the floating action button to show bottom sheet.',
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        child: Icon(Icons.add),
      ),
    );
  }
}

Next up, we'll pass a function reference to onPressed of the floating action button. This is the function where we’ll create our bottom sheet in flutter.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'BottomSheet demo'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'Click the floating action button to show bottom sheet.',
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed:() =>  displayBottomSheet(context),
        child: Icon(Icons.add),
      ),
    );
  }
}

Now call showModalBottomSheet, this is a method provided by flutter. It takes a context and a builder function. We’ll use an anonymous function as our builder function.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'BottomSheet demo'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {

  void displayBottomSheet(BuildContext context) {
    showModalBottomSheet(
        context: context,
        builder: (ctx) {
          return Container(
            height: MediaQuery.of(context).size.height  * 0.4,
            child: Center(
              child: Text("Welcome to AndroidVille!"),
            ),
          );
        });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'Click the floating action button to show bottom sheet.',
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed:() =>  displayBottomSheet(context),
        child: Icon(Icons.add),
      ),
    );
  }
}

Note: I've used MediaQuery to limit the size of bottom sheet to 40% of screen height.

Conclusion

And it’s done! This is all you need to do to create a bottom sheet in flutter. As I said, this is by far the easiest framework I’ve encountered to create a bottom sheet.

In the upcoming tutorial, I’ll show you how to create a bottom sheet using Native Android.

Welcome to AndroidVille :)

AndroidVille is a community of Mobile Developers where we share knowledge related to Android Development, Flutter Development, React Native Tutorials, Java, Kotlin and much more.

We have a SLACK workspace where we share updates related to new job opportunities, articles on Mobile Development/updates from the industry. We also have channels to help you with any questions, dev-help that you require. Just post a question and people would be ready to help you out :)

Click on this link to join the AndroidVille SLACK workspace. It’s absolutely free!

If you like any article, do give it a share on Facebook, Linkedin. You can follow me on LinkedIn, Twitter, Quora, and Medium where I answer questions related to Mobile Development, especially Android and Flutter.

Why every Software Engineer should write - At Least once!

Ayusch — Sat, 11 Apr 2020 07:27:13 +0000

I’ve been writing about Android Development for more than 1 year now. There have been a lot of learnings along the way. It opened my mind up to a whole new domain of content generation and content marketing.

Over time I’ve come to realise that writing about Android has definitely made me a better android developer and a better software engineer overall. So, in this post, I’ll list down all the reasons as to why I believe every software engineer should write - at least once.

1. Writing Helps you stay updated with the latest in the industry.

No matter whatever you do. Android development, iOS development, javascript, backend, frontend. If you have to write regularly, you’ll need to keep yourselves updated with the latest tech.

It’s more rewarding to write about a new tech that was just introduced. Partly because there are a very few articles about it and it would help your content rank higher in the search results.

If you rank higher in search results, more and more people will get to your content and you’ll build credibility as a writer. It’ll enable you to write about topics already covered, but in your own way and be ensured that people are gonna love it.

2. Greater accountability for what you put out.

Once you start putting out content, you’ll see that people will hold you accountable for even small mistakes. So, you better be sure that you know what you are talking about.

This accountability pushes you to go that extra mile, go a bit deeper into those concepts which the average Joe would not care about. It also helps you to answer people’s comments/questions better since you know the whys and hows.

For example, when I wrote this article about ART vs DVM. I had mentioned that a Register Based model is faster and has less code than Stack Based model.

Now, I could’ve easily copied that from anywhere, there would be many articles about that. But I needed to make sure that I was ready to answer any questions that were thrown on me about that point.

Hence, I went the extra mile and learnt about CPU instructions in a Register based model and Stack based model. Although I had read about this during grad school, I definitely needed to brush up on that.

Then I included an example in my post where a simple ADD operation took 3 instructions in stack based model vs 1 instruction in register based model. Even if no one questioned me on that, it was a good feeling to have known about that. It builds your confidence as a writer and an engineer.

3. Recognition

This is probably the most obvious one. Once you start writing and putting your content out there regularly, you’ll definitely start to grow some followers. People who love your style of writing/explanation.

If you’ve built a great android library, it’s no good sitting there on github if people don’t get to use it. But first, people will have to know it exists. For this, you’ll need to put out content related to your library.

Whether it be an article, a tutorial, a demo or even a talk in events such as GDG, ADG etc. Once you gather a following it becomes relatively easier to put out content and get people to use/read it.

Since, I started writing on Medium in early 2019, I’ve gathered around 650 followers and growing.

4. A source for extra income

If you’ve ever tried freelancing on sites such as freelancer.com you’ll know how important is credibility there. As a new freelancer, you’ve got to establish some sort of credibility so that the client can trust you with their projects.

When I used to do some freelance work, I cannot stress how important my writing came in handy. I mentioned my writing in all the proposals and I got replies regardless of the project being awarded or not.

Apart from that I’ve gotten some freelance content writing opportunities (in Android Development) as well.

One of the most brilliant sources in today’s times would be writing articles on Medium. Especially for the Medium Partner Program. You can google it to learn more about how to earn through the Medium Partner Program.

5. Easier to find new opportunities

You must have noticed that many companies now use online tools such as lever to manage candidates.

Many a times I’ve seen fields included such as “What sets you apart from other candidates?/ Tell us something interesting”. Often these fields are a good place to boast about your Medium following/writing.

I don’t know if this helps or not, but I think it is a good way of letting the hiring manager know that you keep your finger at the heart of new developments in your area, while setting you apart from other candidates.

This might intrigue the hiring manager to speak to you and before you know it, you might’ve got yourselves an interview ;)

6. It’s Fun

It’s fun to learn about Content Creation, content generation, SEO, keywords and what not. It’s a separate world altogether.

It’s interesting to know about your user retention, returning users, new users, CTR and other metrics. This tells you how engaging your content is and pushes you to improve.

Conclusion

These were some reasons I believe that one should definitely try writing about their work at least once.

If you want to submit an article for AndroidVille, you’re most welcome to do that at: https://ayusch.com/submit/

or mail a Word document at contact@ayusch.com

Important: Join the AndroidVille SLACK workspace for mobile developers where people share their learnings about everything latest in Tech, especially in Android Development, RxJava, Kotlin, Flutter, and mobile development in general.

Click on this link to join the workspace. It’s absolutely free!

Like what you read? Don’t forget to share this post on Facebook, Whatsapp, and LinkedIn.

You can follow me on LinkedIn, Quora, Twitter, and Instagram where I answer questions related to Mobile Development, especially Android and Flutter.