Question 1

How was real-time syncing optimized for the Firestore feed under peak user activity?

Accepted Answer

We structured Firestore with a denormalized database design where post metadata and user profile statistics are cached inside the feed document. Additionally, we implemented local state caching using Hive on the mobile app. This allowed immediate visual responses on the feed, reducing Firestore read calls by 45% and keeping feed loads under 200ms by avoiding multi-collection joins.

Question 2

How do you prevent the Gemini AI assistant from hallucinating when answering tagged questions?

Accepted Answer

We utilized a Retrieval-Augmented Generation (RAG) light strategy within the Flutter app. When a user tags the Gemini bot in a post, we programmatically prepend structural context to the REST request payload. This includes system-level grounding prompts, the post description, related tags, and the top 3 most relevant comments. This bounds the model's response envelope, raising the relevancy rate to approximately 85%.

Question 3

What was the design pattern used to handle gamified XP calculation to avoid database concurrency issues?

Accepted Answer

We avoided direct updates to a single user document for XP gains. Instead, we used a write-only subcollection design pattern where every XP event (e.g., post created, answer accepted) writes a lightweight transaction record. A background Firebase Cloud Function periodically aggregates these events to update the main profile's XP and level. This prevents document-lock contention and scales cleanly during simultaneous activity.

Question 4

Why did you choose Flutter instead of native Android (Kotlin) or iOS (Swift) for DevSphere?

Accepted Answer

DevSphere is a mobile-first developer community where cross-platform reach is critical. Using Flutter allowed us to share 100% of the UI design and network orchestration codebase between Android and iOS. This cut development time in half while maintaining a consistent 60 FPS performance thanks to Flutter's Skia/Impeller rendering engines.

Question 5

How does the application maintain inventory operations in offline pharmacy environments?

Accepted Answer

MedMatch implements Firestore's offline persistence mechanism combined with local database sync. When a pharmacy loses connection, all inventory updates, invoice entries, and stock adjustments are queued locally in SQLite (managed by Android's WorkManager and Firestore SDK). Once connection is re-established, the updates are merged back using timestamp-based conflict resolution, ensuring no records are lost.

Question 6

How are low-stock threshold notifications triggered and delivered proactively?

Accepted Answer

Every inventory item has a configurable minStock threshold. When a stock transaction drops the count below this threshold, a Firestore document write triggers a Google Cloud Function. This function dispatches an FCM (Firebase Cloud Messaging) data payload to the pharmacy owner's device, which triggers a high-priority Android notification channel even if the app is in the background.

Question 7

How did you optimize invoice search in Firestore without SQL-like pattern matching?

Accepted Answer

Firestore lacks support for standard SQL LIKE %search% queries. To solve this, we used search indexing. During invoice creation, we split the medicine names into prefix arrays (e.g., 'Amoxicillin' -> ['a', 'am', 'amo', 'amox', ...]) and stored them as an array field. We then used Firestore's array-contains queries to fetch matching invoices. For complex filters, we integrated clean client-side search logic once the initial scoped dataset is retrieved.

Question 8

Why native Kotlin over Flutter for a business-critical tool like MedMatch?

Accepted Answer

MedMatch is deeply integrated with Android-specific system hardware and APIs. We required low-latency access to the camera (for barcode scanning), local file storage (for PDF invoices), background services (for stock sync), and deep integration with the Google Maps SDK. Writing this natively in Kotlin gave us compile-time safety, direct hardware access, and a smaller application footprint.

Question 9

How does Schedly prevent double-booking issues during concurrent client requests?

Accepted Answer

When a user selects a slot and submits a booking, the backend handles the request in a Firestore transaction. The transaction checks if the slot is still marked as available before confirming. If the slot has already been claimed by another concurrent request, the transaction fails and the client is prompted to select a new slot. This ensures atomic bookings and eliminates race conditions.

Question 10

How is real-time slot availability surfaced to multiple clients at once?

Accepted Answer

Firestore's real-time listeners are attached to the availability document for each owner. When a slot is claimed, the Firestore document updates immediately. All other clients with the booking screen open receive the update via their active listener, graying out the taken slot without requiring a manual refresh.

Question 11

How is the owner's availability configuration structured in Firestore?

Accepted Answer

Each owner has an availability document containing day-of-week templates (e.g., Mon: 10am–5pm, 30-min slots). When a client opens a booking screen for a specific date, the app generates available slots from the owner's template, subtracts already-booked slots, and presents the remaining options. This avoids storing individual slot documents for every future date.

Question 12

Why Flutter for Schedly instead of a web-first approach?

Accepted Answer

Schedly targets small business owners who primarily operate on mobile. Flutter allowed delivery of a polished owner dashboard and a smooth client booking experience in a single codebase, with native-feel performance on both Android and iOS. A web-first approach would have required a separate native app or a compromised mobile web experience.

Question 13

What chunking strategy was used, and how did it improve retrieval precision?

Accepted Answer

Instead of arbitrary character-count splits, we implemented semantic chunking. Documents are split by headings and structural markdown markers, with a target chunk size of 800 characters and 15% overlap. This keeps sentences and paragraphs intact, preserving the semantic context inside the embeddings and improving retrieval precision by 28%.

Question 14

How do you prevent the bot from hallucinating or answering with generic knowledge?

Accepted Answer

We enforced a strict 'groundedness constraint' in our prompt template. The system instruction specifies that the model must only use the retrieved context. If the query cannot be answered using the context, it must state 'I cannot find the answer in the provided documents.' We also set the model temperature to 0.0, which reduces creative language and keeps answers factual.

Question 15

What vector database was selected, and why?

Accepted Answer

We selected Qdrant as our vector database. It supports advanced filtering on metadata payload fields (e.g., document tags, user access levels) alongside cosine similarity searches. This metadata filtering is performed at the index level, ensuring we do not retrieve search matches that a user does not have permission to view, while keeping query latencies under 15ms.

Question 16

How does the Telegram bot interface work alongside the REST API?

Accepted Answer

The FastAPI backend exposes both a webhook endpoint (for Telegram updates) and standard REST endpoints (/api/v1/query, /api/v1/documents/upload, etc.). The Telegram bot registers itself as a webhook target so all commands (/query, /query_doc, /text) are processed by the same pipeline that serves API clients. Both interfaces share the same ingestion and retrieval logic — only the I/O layer differs.

Technical decisions, explained.

How was real-time syncing optimized for the Firestore feed under peak user activity?

How do you prevent the Gemini AI assistant from hallucinating when answering tagged questions?

What was the design pattern used to handle gamified XP calculation to avoid database concurrency issues?

Why did you choose Flutter instead of native Android (Kotlin) or iOS (Swift) for DevSphere?

How does the application maintain inventory operations in offline pharmacy environments?

How are low-stock threshold notifications triggered and delivered proactively?

How did you optimize invoice search in Firestore without SQL-like pattern matching?

Why native Kotlin over Flutter for a business-critical tool like MedMatch?

How does Schedly prevent double-booking issues during concurrent client requests?

How is real-time slot availability surfaced to multiple clients at once?

How is the owner's availability configuration structured in Firestore?

Why Flutter for Schedly instead of a web-first approach?

What chunking strategy was used, and how did it improve retrieval precision?

How do you prevent the bot from hallucinating or answering with generic knowledge?

What vector database was selected, and why?

How does the Telegram bot interface work alongside the REST API?

Curious about a specific design decision?

Technical decisions, explained.

How was real-time syncing optimized for the Firestore feed under peak user activity?

How do you prevent the Gemini AI assistant from hallucinating when answering tagged questions?

What was the design pattern used to handle gamified XP calculation to avoid database concurrency issues?

Why did you choose Flutter instead of native Android (Kotlin) or iOS (Swift) for DevSphere?

How does the application maintain inventory operations in offline pharmacy environments?

How are low-stock threshold notifications triggered and delivered proactively?

How did you optimize invoice search in Firestore without SQL-like pattern matching?

Why native Kotlin over Flutter for a business-critical tool like MedMatch?

How does Schedly prevent double-booking issues during concurrent client requests?

How is real-time slot availability surfaced to multiple clients at once?

How is the owner's availability configuration structured in Firestore?

Why Flutter for Schedly instead of a web-first approach?

What chunking strategy was used, and how did it improve retrieval precision?

How do you prevent the bot from hallucinating or answering with generic knowledge?

What vector database was selected, and why?

How does the Telegram bot interface work alongside the REST API?

Curious about a specific design decision?