PROJECT DEEP-DIVE INTERVIEW GUIDE

Web Billing & Inventory Management System

Python · Flask · JavaScript · Firebase · Random Forest · GAN · Streamlit
Preethi R | PSG College of Technology | Placement 2027
Senior Interviewer Perspective: Cisco · Amazon · Microsoft · Google
■■ SECTION 1 — PROJECT SNAPSHOT ■■

Project Web Billing & Inventory Management System

Built By Preethi R — Team Project (Agile)

Year 2024

Stack Python, Flask, JavaScript, Firebase, Random Forest, GAN, Streamlit

Problem Manual billing and inventory is error-prone and lacks predictive stock management

Key ML Random Forest for demand forecasting; GAN for synthetic training data

■■ SECTION 1 — PITCHES (All 5 Versions) ■■

1. Elevator Pitch (20–30 seconds)

The Web Billing and Inventory Management System is a full-stack web app with Flask and
Firebase that automates order processing, billing, and dispatch workflows for a business. What
makes it distinctive is the ML layer: we applied Random Forest for predictive inventory demand
forecasting and a GAN to generate synthetic training data when real historical data was limited. It
also has a real-time sales analytics dashboard and a product recommendation engine — built as
a team project in an Agile environment.
Why it works: Names the core value prop, the ML components, and the team context in 30 seconds.

2. One-Minute Explanation
In many small and medium businesses, billing and inventory are still managed manually —
spreadsheets, paper records, reactive stock checks. That leads to billing errors, stock-outs, and
no visibility into sales trends. We built a full-stack web application to solve this.
The system has two user roles: Admin and Customer, each with their own dashboard. Admins
manage products, process orders, dispatch, and generate PDF reports. Customers place orders
and track status. The backend is Flask with Firebase as the database — Firebase's real-time
sync keeps both dashboards updated without polling.
The ML component is what makes this more than a CRUD app. We trained a Random Forest
model on historical order data to forecast demand — so the admin can see predicted stock needs
before they run out. Where historical data was sparse, we used a GAN to generate synthetic
training records, improving the forecast model's training set. There's also a product
recommendation engine on the customer side. Built in an Agile team, with shared GitHub
workflow and sprint-based task division.
Why it works: Problem → architecture → ML layer → team process. Covers all angles in 60 seconds.

3. Two-Minute Detailed Explanation

Let me walk through the system end-to-end. The problem was real: manual billing and inventory
management is error-prone, lacks real-time visibility, and gives no predictive insight into stock
 needs. Our goal was to build a production-quality system that automates the workflow and adds
an ML-powered forecasting layer.
Architecture: the backend is Python Flask, exposing RESTful API endpoints for all business
operations. Firebase is the database — we used Firestore for structured document storage
(products, orders, users) and Firebase Authentication for role-based access. The frontend is
JavaScript with a Streamlit-powered analytics dashboard. Flask generates PDF reports using
ReportLab — invoices, dispatch notes, sales summaries.
Role-based access: Admins see the full inventory, process orders, update dispatch status, and
view the analytics dashboard. Customers see their own order history and available products. This
is enforced at the API layer — every endpoint checks the Firebase Auth token's custom role
claim.
ML pipeline: we trained a Random Forest classifier/regressor on historical order data to forecast
demand for each product category over a 7-day horizon. The input features are: day of week,
product category, recent sales velocity, and seasonal flags. The output is a predicted demand
quantity. The admin dashboard displays this as a 7-day forecast with a reorder recommendation.
GAN component: our historical order dataset was small — around 800 records across 6 months.
A Random Forest trained on this volume would overfit. We built a simple GAN to generate
synthetic order records that matched the statistical distribution of the real data. Adding 1,200
synthetic records to the training set reduced overfitting and improved forecast accuracy on the
held-out test set.
Product recommendation: a collaborative filtering approach — users who ordered product A also
ordered product B — surfaced as 'Customers also bought' on the customer dashboard.
Team process: Agile with 2-week sprints. Tasks divided via GitHub Projects. Code reviews on
every pull request. Integration testing before each sprint merge. I was responsible for the ML
pipeline and the analytics dashboard.
Why it works: Shows full-stack depth, ML reasoning, team collaboration, and individual ownership.

4. Recruiter-Friendly Explanation (Non-Technical)

Think of it like an automated store manager. Instead of someone manually writing bills, checking
stock, and guessing when to reorder, our system does all of that automatically. It keeps track of
every order in real time, generates invoices, tells the admin when stock is running low — and our
AI layer actually predicts how much stock will be needed next week based on past patterns. We
even built the system to create its own training data when it didn't have enough real data to learn
from — that's the GAN component. Built as a team project, like a real company sprint.

5. Technical Interview Explanation

Flask RESTful backend with blueprint-based route organisation. Firebase Firestore for NoSQL
document storage: collections for users, products, orders, dispatch_logs. Firebase Auth with
custom claims for role enforcement (admin/customer). PDF generation via ReportLab — invoice
templates rendered server-side. JavaScript frontend with Fetch API calls to Flask endpoints.
Streamlit analytics dashboard consuming aggregated Firestore data. ML stack: scikit-learn
Random Forest Regressor trained on (day_of_week, category, sales_velocity, seasonal_flag) →
demand_quantity. Model serialised with joblib, loaded at Flask startup. GAN: simple
TensorFlow/Keras generator-discriminator pair trained on normalised order tabular data to
produce synthetic records matching real distribution. Product recommendation: item-item
collaborative filtering using order co-occurrence matrix. Agile team: GitHub Projects,
 branch-per-feature, PR reviews, sprint demos.

■■ SECTION 2 — PROJECT DEEP DIVE ■■

Problem Statement
• Manual billing introduces arithmetic errors and lacks audit trails.
• Inventory management is reactive — stock-outs are discovered only after orders fail.
• No real-time visibility into sales trends or customer behaviour.
• Small dataset makes training an accurate demand forecasting model difficult without data augmentation.

System Architecture
Backend (Flask)
• Blueprint-based route organisation: auth_bp, product_bp, order_bp, report_bp, analytics_bp.
• Every API endpoint validates the Firebase Auth token before processing.
• PDF invoice and dispatch note generation via ReportLab — triggered on order confirmation.
• ML model loaded once at startup via [Link]() — serves predictions without re-loading.
• Order processing workflow: place order → inventory check → reserve stock → confirm → dispatch
update.

Database (Firebase Firestore)

• users collection: uid, role (admin/customer), profile metadata.
• products collection: id, name, category, stock_quantity, reorder_threshold, price.
• orders collection: order_id, customer_uid, items (array), status, timestamps.
• dispatch_logs collection: order_id, dispatched_by, dispatch_time, tracking_note.
• sales_aggregates collection: pre-computed daily/weekly rollups for dashboard performance.

ML Pipeline
• Feature engineering: extract day_of_week, product_category (encoded), rolling_7day_avg, is_holiday
flag.
• Target variable: demand_quantity for the next 7 days per product category.
• Random Forest Regressor: 100 estimators, max_depth=10, trained on 12 months of order history +
GAN-generated synthetic records.
• Train/test split: 80/20 chronological (not random — respects time series ordering).
• GAN: Generator network (3 dense layers) produces synthetic order records; Discriminator distinguishes
real vs synthetic. Trained until Discriminator accuracy ≈ 0.5 (Nash equilibrium).
• Synthetic data validated by comparing real and synthetic distributions using KS-test before adding to
training set.

Frontend & Dashboard

• Customer-facing JavaScript UI: product listing, cart, order placement, order status tracking.
• Admin dashboard: inventory overview, order queue, dispatch management, PDF report downloads.
• Streamlit analytics dashboard: sales trend charts, demand forecast visualisation, recommendation
performance.
• Real-time updates via Firebase's onSnapshot listener — no polling required.
Tech Choice Rationale
Technology Why Chosen Alternative

Flask Lightweight, quick to set up REST APIs, familiar Python

Djangoecosystem
— too heavy for this scope

Firebase Firestore Real-time sync, Firebase Auth integration, serverless

PostgreSQL
scaling — no real-time, needs server

Firebase Auth Built-in role claims, Google/email login, integratesJWT

with from
Firestore
scratch
rules
— more work

Random Forest Handles mixed feature types, robust to overfittingXGBoost

with small—data,
marginally
interpretable
better but
feature
less importance
interpretable

GAN Generates synthetic tabular data matching real distribution

SMOTE —tosimpler
expandbut
sparse
less realistic
training set
synthetic data

ReportLab Python-native PDF generation, no external service,

WeasyPrint
invoice templating
— heavier dependency

Streamlit Fast analytics dashboard in pure Python, ideal forReact

internal
dashboard
business—
tools
more work for same output

Challenges and Solutions

Challenge: Small dataset for ML training
Solution: Built a GAN to generate 1,200 synthetic order records matching the real data distribution.
Validated using KS-test before adding to training set. This reduced model overfitting and improved
test-set accuracy.

Challenge: Real-time inventory sync across admin and customer dashboards

Solution: Used Firebase's onSnapshot listener — it pushes updates to all connected clients the moment
Firestore data changes. No polling, no stale data.

Challenge: Role-based access enforcement

Solution: Firebase Auth custom claims carry the user's role. Every Flask endpoint decodes and
validates the token before processing. Firestore security rules also enforce read/write permissions at
the database level — double protection.

Challenge: Agile coordination in a team

Solution: Used GitHub Projects for sprint task boards. Each feature lived on a named branch. PRs
required at least one review before merge. Prevented integration conflicts and gave us a clear audit
trail.

Future Improvements
• Replace GAN with a Variational Autoencoder (VAE) — more stable training, better theoretical grounding
for tabular data augmentation.
• Add LSTM-based time-series forecasting alongside Random Forest — compare both models and serve
ensemble predictions.
• Migrate analytics dashboard from Streamlit to a [Link] frontend for production-grade UI.
• Add email/SMS notification when stock drops below reorder threshold.
• Implement barcode scanning for faster inventory updates via mobile camera.
■■ SECTION 3 — NATURAL SPEAKING SCRIPT ■■

This is a team project — own your specific contributions clearly from the start.
The Web Billing and Inventory Management System was a team project built in an Agile
environment. Let me tell you what the system does and then what I personally built.

The core problem: small businesses manage billing and inventory manually, which leads to
errors, no real-time visibility, and no ability to predict stock needs. We built a full-stack web app to
automate all of that — Flask backend, Firebase for real-time data sync and auth, JavaScript
frontend for the customer side, and a Streamlit analytics dashboard for the admin.

My contribution was the ML pipeline. I trained a Random Forest model on historical order data to
forecast demand per product category over a 7-day horizon. The challenge was our dataset was
small — about 800 records. I built a GAN to generate synthetic order records matching the real
distribution, validated the synthetic data using a KS-test, and added those records to the training
set. That reduced overfitting and improved forecast accuracy on our held-out test set.

I also built the Streamlit analytics dashboard — demand forecasts, sales trends, and a product
recommendation widget using item-item collaborative filtering.

Working in a team taught me things solo projects don't: code reviews, managing merge conflicts,
sprint planning, and the discipline of writing code that someone else will read. That context is
something I'm bringing into a company environment.

Delivery tip: when describing the GAN, say 'I built a GAN' with confidence — most campus candidates have never
touched a GAN. That's a differentiator.
■■ SECTION 4 — 30 BASIC INTERVIEW QUESTIONS + ANSWERS ■■

Q1. What is this project?

Testing: Can you explain a team project clearly?
A full-stack web application that automates billing, inventory, and order dispatch for a business. It has
role-based dashboards for Admin and Customer, real-time data sync via Firebase, PDF report
generation, and an ML layer with Random Forest demand forecasting and a GAN for synthetic training
data generation.

Q2. What problem does it solve?

Testing: Problem framing.
Manual billing is error-prone. Manual inventory management is reactive — you discover stock-outs after
orders fail. There's no visibility into sales trends and no predictive capability. Our system solves all
three: automated billing with PDF invoices, real-time inventory tracking with demand forecasts, and a
sales analytics dashboard.

Q3. What is Flask?

Testing: Backend framework knowledge.
Flask is a Python micro-framework for building web applications and APIs. It's lightweight — you get
routing, request handling, and templating, but not an ORM or admin panel. I used it to build RESTful
API endpoints for all business operations: auth, product management, order processing, dispatch, and
report generation.

Q4. What is Firebase?

Testing: Cloud backend knowledge.
Firebase is Google's Backend-as-a-Service platform. I used two Firebase products: Firestore — a
NoSQL document database with real-time sync — and Firebase Authentication for user identity and role
management. Firebase's real-time capabilities mean both the admin and customer dashboards update
instantly when orders are placed or inventory changes, without polling.

Q5. What is Firestore?

Testing: Firebase depth.
Firestore is Firebase's NoSQL document database. Data is organised into collections and documents
— similar to MongoDB. I used it to store users, products, orders, dispatch logs, and sales aggregates.
Firestore's onSnapshot listener pushes data changes to all connected clients in real time — this is what
keeps both dashboards live without the frontend making periodic polling requests.

Q6. What is role-based access control?

Testing: Auth design.
RBAC restricts system access based on the user's assigned role. In our system, we have two roles:
Admin and Customer. Firebase Auth supports custom claims — I set a role claim on each user's token
at registration. Every Flask API endpoint decodes the token and checks the role before processing.
Firestore security rules also enforce role-based read/write permissions at the database level.
Q7. What is Random Forest?
Testing: ML algorithm knowledge.
Random Forest is an ensemble learning method that builds multiple decision trees on random subsets
of the training data and averages their predictions. It handles mixed feature types, is robust to
overfitting, and provides feature importance scores. I used it as a regressor to predict demand quantity
per product category over a 7-day horizon. 100 estimators, max depth 10, trained on order history
features: day of week, product category, rolling 7-day average, holiday flag.

Q8. What is a GAN?

Testing: ML knowledge — differentiator.
GAN stands for Generative Adversarial Network. It consists of two neural networks: a Generator that
produces synthetic data, and a Discriminator that tries to distinguish real from synthetic. They train
against each other — the Generator improves until the Discriminator can't tell the difference. I used a
GAN to generate synthetic order records to expand our small training dataset. The GAN was trained
until Discriminator accuracy reached approximately 0.5 — the Nash equilibrium point where synthetic
data is indistinguishable from real.

Q9. Why did you use a GAN instead of just collecting more data?
Testing: ML design rationale.
Collecting more real order data would require waiting months for the business to generate it — not
feasible for a semester project. The GAN generates synthetic records that match the statistical
distribution of existing data in weeks. We validated the synthetic data quality using a
Kolmogorov-Smirnov test comparing real and synthetic distributions before adding them to training. This
is a standard technique in data-scarce ML scenarios.

Q10. What is the Kolmogorov-Smirnov test?

Testing: Statistical validation.
The KS-test is a non-parametric test that measures whether two samples come from the same
distribution. I used it to compare the distribution of key features — order quantity, product category
frequencies, day-of-week patterns — between real and GAN-generated data. A p-value above 0.05
means we cannot reject the hypothesis that they come from the same distribution, confirming the
synthetic data is statistically similar to real data.

Q11. What features did you use for demand forecasting?

Testing: ML feature engineering.
Four main features: day_of_week (0–6, captures weekly patterns), product_category (one-hot encoded,
captures category-specific demand), rolling_7day_avg (the average daily orders for that product over
the past 7 days, captures sales velocity), and is_holiday (binary flag, captures demand spikes on
holidays). The target variable is demand_quantity for the next 7 days per product category.

Q12. What is the train/test split strategy?

Testing: ML evaluation awareness.
I used a chronological 80/20 split — the first 80% of time-ordered records are training data, the last 20%
are test data. I did NOT use random splitting because that would allow future data to appear in the
training set (data leakage), which artificially inflates accuracy. For time-series forecasting, chronological
splitting is the correct approach.
Q13. What is ReportLab?
Testing: PDF generation knowledge.
ReportLab is a Python library for programmatic PDF generation. I used it to create invoice and dispatch
note templates — defining the layout, fonts, table structure, and data fields in Python. On order
confirmation, Flask calls the invoice generator, which populates the template with order data and
returns a PDF file that the admin can download or email.

Q14. What is collaborative filtering?

Testing: Recommendation system basics.
Collaborative filtering is a recommendation technique based on the behaviour of similar users or items. I
used item-item collaborative filtering: I built a co-occurrence matrix where each cell (i, j) counts how
many orders included both product i and product j. To recommend products to a customer, I look at their
past orders, find the most co-occurring products that they haven't ordered yet, and surface those as
'Customers also bought'. No user profile needed — just order history.

Q15. What is the difference between SQL and NoSQL databases?

Testing: Database fundamentals.
SQL databases (PostgreSQL, MySQL) use structured tables with a fixed schema, support ACID
transactions, and are ideal for relational data with many foreign keys — like financial records. NoSQL
databases (Firebase Firestore, MongoDB) use flexible document schemas, scale horizontally more
easily, and are better for hierarchical or document-shaped data. I chose Firestore for this project
because of its real-time sync capability and schema flexibility — order documents have varying
structures depending on the number of items.

Q16. What is an API endpoint?

Testing: Fundamentals check.
An API endpoint is a URL that accepts HTTP requests and returns responses. In Flask, I define
endpoints using route decorators: @[Link]('/orders', methods=['POST']) creates an endpoint that
handles order creation. Each endpoint receives a JSON body or URL parameters, processes the
request (validates auth, updates Firestore, triggers PDF generation), and returns a JSON response with
a status code.

Q17. What is the onSnapshot listener in Firebase?

Testing: Real-time feature depth.
onSnapshot is a Firestore method that attaches a listener to a document or collection. Whenever the
data changes, Firestore pushes the updated snapshot to all connected clients that have attached
listeners. I use it on the admin's order queue and inventory page — when a customer places an order,
the admin's dashboard updates instantly without refreshing. This eliminates polling and reduces latency.

Q18. What is overfitting and how did you address it?

Testing: ML fundamentals.
Overfitting is when a model performs well on training data but poorly on unseen data — it memorises
the training set instead of learning generalisable patterns. With only 800 training records, our Random
Forest was at risk of overfitting. I addressed it three ways: first, GAN-generated synthetic data
expanded the training set to 2,000 records; second, I set max_depth=10 on the Random Forest to limit
tree complexity; third, I used chronological cross-validation with 5 folds to evaluate generalisation, not
just held-out test accuracy.
Q19. What is joblib and why did you use it?
Testing: Model serving.
Joblib is a Python library for efficient serialisation of Python objects — particularly NumPy arrays and
scikit-learn models. I used [Link]() to save the trained Random Forest model to disk and
[Link]() to load it at Flask startup. This means I train the model once offline, serialise it, and serve
predictions at runtime without re-training on every request. Loading at startup (not per-request) ensures
low prediction latency.

Q20. What was your role in the team?

Testing: Individual contribution clarity.
I was responsible for two components: the ML pipeline (Random Forest demand forecasting and GAN
data augmentation) and the Streamlit analytics dashboard. Other team members handled the Flask API
structure, Firebase integration, and the customer-facing JavaScript frontend. We divided work by
component in sprint planning, reviewed each other's code via pull requests, and integrated through a
shared GitHub repository with branch-per-feature workflow.

Q21. How does the order processing workflow work?

Testing: Business logic understanding.
Step 1: Customer places an order via the frontend — a POST request with items and quantities. Step 2:
Flask checks inventory — confirms all items have sufficient stock. Step 3: If stock is available, reserve it
(decrement stock quantities in Firestore). Step 4: Create an order document in Firestore with status
'confirmed'. Step 5: Generate a PDF invoice and store it in Firebase Storage. Step 6: Admin sees the
new order in their queue via onSnapshot. Step 7: Admin dispatches, updates order status to
'dispatched', creates a dispatch log entry.

Q22. What is Firebase Authentication?

Testing: Auth mechanism.
Firebase Authentication is a managed identity service. It handles user registration, login, password
management, and token issuance. Users log in with email/password; Firebase issues a JWT signed by
Google. My Flask backend verifies this token on every request using the Firebase Admin SDK. I extend
the token with a custom role claim (admin or customer) set at registration time, which my API uses for
access control.

Q23. What is the difference between authentication and authorisation?

Testing: Security fundamentals.
Authentication is verifying identity — who you are (Firebase Auth handles this). Authorisation is verifying
permission — what you're allowed to do (custom role claims and Flask endpoint checks handle this).
Example: both admin and customer are authenticated users, but only an admin can update inventory
quantities or generate dispatch notes. These are enforced separately in the system.

Q24. What testing did you do on the ML model?

Testing: ML evaluation.
Three evaluation approaches: first, held-out chronological test set (last 20% of time-ordered data) —
evaluated Mean Absolute Error and RMSE of demand predictions vs actual. Second, 5-fold
chronological cross-validation on the training set to detect overfitting. Third, manual inspection of
demand forecast vs actual orders for 3 product categories over the last 2 weeks of data — to verify the
predictions were directionally sensible, not just statistically acceptable.
Q25. What is a REST API?
Testing: Core concept.
A REST API uses HTTP methods to represent CRUD operations: GET (read), POST (create),
PUT/PATCH (update), DELETE (remove). Resources are identified by URLs. The API is stateless —
each request is self-contained. In our system: GET /products returns the product list, POST /orders
creates a new order, PATCH /orders/{id} updates order status, GET /analytics/forecast returns the
demand forecast JSON.

Q26. How did you ensure data consistency between Flask and Firestore?
Testing: Concurrency awareness.
Firestore supports atomic transactions — I used them for the stock reservation step. When an order is
placed, a Firestore transaction reads the current stock, checks availability, and decrements it atomically.
If two customers order the last item simultaneously, only one succeeds — the transaction ensures no
double-selling. Flask's role is to initiate and coordinate the transaction, not to manage state itself.

Q27. What is a PDF invoice and how did you generate it?
Testing: Feature implementation.
An invoice is a billing document containing order ID, customer details, item list with quantities and
prices, tax, total, and payment terms. I built a ReportLab template that defines the layout as Python
code — header with company logo placeholder, an itemised table, totals section, and footer with terms.
On order confirmation, Flask calls the invoice generator, passes the order data as a Python dictionary,
renders the PDF, and saves it to Firebase Storage with a signed download URL.

Q28. Did you deploy this project?

Testing: Deployment awareness.
Yes — the project has a live demo. The Flask backend and Streamlit dashboard were deployed for the
demo. Firebase is cloud-hosted by Google. For a production deployment I'd containerise Flask with
Docker, deploy on a platform like Render or Railway, and use Firebase Hosting for the frontend static
assets.

Q29. What is Agile development?

Testing: Team process.
Agile is an iterative software development methodology with short work cycles called sprints — typically
1–2 weeks. Each sprint delivers a working increment of the product. Key practices: daily standups to
share progress and blockers, sprint planning to assign tasks, sprint reviews to demo completed work,
and retrospectives to improve the process. In our team, we ran 2-week sprints with GitHub Projects as
the task board. This kept us on schedule and made progress visible.

Q30. What would you improve if you rebuilt this?

Testing: Retrospective thinking.
Three things: First, replace the GAN with a Variational Autoencoder — VAEs are more stable to train
and better theoretically suited for tabular data. Second, add an LSTM alongside Random Forest for
time-series forecasting and serve an ensemble prediction. Third, migrate the Streamlit analytics
dashboard to a [Link] frontend for production-quality UI and mobile responsiveness. The core Flask
and Firebase architecture I'd keep — it was the right choice for this scale.
Q31. How does this project demonstrate teamwork?
Testing: Soft skill — important at service companies.
The Agile workflow enforced collaboration: sprint planning required us to agree on task boundaries,
code reviews required us to understand each other's code, and integration required coordinating API
contracts between the frontend and backend teams. I specifically learned to write code that others
would maintain — clear variable names, docstrings, and API documentation. I also learned to give and
receive constructive code review feedback without friction.
■■ SECTION 5 — 20 INTERMEDIATE INTERVIEW QUESTIONS + ANSWERS
■■

Q1. How does a GAN work mathematically?

Testing: Deep ML understanding.
A GAN is a minimax game: min_G max_D V(D, G) = E[log D(x)] + E[log(1 - D(G(z)))]. The Discriminator
D maximises its ability to distinguish real samples x from generated samples G(z), where z is random
noise. The Generator G minimises D's ability to distinguish — it tries to make G(z) indistinguishable
from x. At Nash equilibrium, D(x) = 0.5 for all inputs — the discriminator can no longer distinguish real
from synthetic. I monitored Discriminator accuracy during training as the convergence signal.

Q2. How did you validate the GAN's synthetic data quality?
Testing: Statistical validation depth.
Three checks: First, Kolmogorov-Smirnov test on each feature's marginal distribution — comparing real
and synthetic. KS p-value > 0.05 for all features confirmed statistical similarity. Second, visual
inspection via histograms and scatter plots of real vs synthetic samples — synthetic data should overlap
the real data's density regions. Third, a train-on-synthetic, test-on-real (TSTR) evaluation — I trained a
Random Forest on only synthetic data and tested on real data. Performance close to the model trained
on real data confirms the synthetic data is useful.

Q3. Explain Random Forest's feature importance and how you used it.
Testing: ML interpretability.
Random Forest computes feature importance as the average reduction in impurity (mean decrease in
Gini impurity or MSE for regression) that each feature contributes across all trees. I used feature
importance to validate the model: the rolling_7day_avg should be the most important feature (recent
sales velocity is the best predictor of near-future demand). If day_of_week scored highest, it would
suggest the model was fitting to noise. The importance scores confirmed rolling_7day_avg >
product_category > day_of_week > is_holiday — which is directionally sensible.

Q4. How did you handle class imbalance in the order data?
Testing: ML data quality.
Some product categories had far more orders than others — high-frequency items like stationery vs
low-frequency items like furniture. For the Random Forest, I used sample_weight parameter to upweight
underrepresented categories during training. For the GAN, I generated proportionally more synthetic
records for underrepresented categories to balance the training set. This prevents the model from
defaulting to predicting high-demand items for everything.

Q5. How would you scale the Firebase Firestore as the business grows?
Testing: Database scaling.
Firestore scales automatically — it's serverless and Google manages sharding. But there are design
considerations: avoid storing large arrays in a single document (Firestore has a 1MB document size
limit and a 20,000 field limit). For high-write collections like order_events, use a subcollection structure
rather than a single document. For analytics aggregates, use Cloud Functions triggered on order writes
to maintain pre-computed rollup documents — reading a single aggregates document is faster than
querying and summing thousands of order documents.
Q6. What is the difference between Firestore and Firebase Realtime Database?
Testing: Firebase depth.
Firebase has two database products. Realtime Database: older, JSON tree structure, all data in one
tree, good for simple real-time sync. Firestore: newer, collections and documents model, better querying
(compound queries, range filters), better offline support, scales to larger datasets. I chose Firestore
because our data is naturally document-structured (orders, products, users) and I needed compound
queries — for example, filtering orders by status AND date range — which Realtime Database doesn't
support.

Q7. How would you implement a search feature for products?

Testing: Feature extension thinking.
Firestore doesn't support full-text search natively — it supports exact matches and range queries only.
For product search (partial name match), I'd integrate Algolia or Typesense: on every product
create/update in Firestore, a Cloud Function syncs the product document to the search index. The
frontend sends search queries directly to Algolia, gets ranked results with highlighted matches, and
uses the returned product IDs to fetch full details from Firestore. This is the standard Firebase + search
architecture.

Q8. Explain how you'd add rate limiting to the Flask API.
Testing: API security.
I'd use Flask-Limiter with Redis as the storage backend. Define limits per endpoint: @[Link]('10 per
minute') on the order placement endpoint to prevent order flooding. @[Link]('100 per hour') on the
product listing endpoint for general protection. Rate limits are keyed on the authenticated user's UID
(from the Firebase token) — not IP address, since multiple users might be behind the same NAT. Redis
stores the request counters with TTL-based expiry.

Q9. How did you handle concurrent order placements for the same product?
Testing: Concurrency control.
Using Firestore transactions. A Firestore transaction is atomic and serialisable — if two clients
simultaneously read the same product document and both try to decrement stock, Firestore retries the
transaction that detects a conflict. The transaction reads the current stock, checks if stock >= requested
quantity, decrements if yes, and aborts with an 'out of stock' error if no. This prevents overselling without
requiring application-level locking or a relational database.

Q10. What is the difference between a decision tree and a Random Forest?
Testing: ML algorithm comparison.
A decision tree is a single model that recursively splits the training data on the feature that maximises
information gain. It's interpretable but prone to overfitting — it memorises the training set. A Random
Forest builds N decision trees, each trained on a random bootstrap sample of the training data with a
random subset of features at each split. Predictions are averaged across all trees. Bagging (bootstrap
aggregating) reduces variance without significantly increasing bias — the key insight behind why
ensembles outperform single trees.
Q11. How would you add a time-series forecasting model to complement Random Forest?
Testing: ML extension thinking.
I'd add an LSTM (Long Short-Term Memory) model — a recurrent neural network designed for
sequential data. Input: a sliding window of the last 30 days of daily demand per product category.
Output: predicted demand for the next 7 days. LSTM captures long-range temporal dependencies that
Random Forest misses — for example, seasonal patterns that span weeks. I'd serve both model
predictions and show an ensemble average on the dashboard, with confidence intervals from the
Random Forest's prediction variance.

Q12. What is Firebase Cloud Functions and how would you use it here?
Testing: Firebase ecosystem.
Firebase Cloud Functions are serverless Python/JavaScript functions triggered by Firebase events —
Firestore writes, Auth events, or HTTP requests. I'd use them for: triggering PDF invoice generation on
order confirmation (instead of doing it synchronously in Flask), sending email notifications when stock
drops below reorder threshold, and maintaining pre-computed sales aggregates in real time as orders
are placed. Cloud Functions move heavy processing out of the API request cycle, reducing response
latency.

Q13. What is SMOTE and how does it compare to your GAN approach?
Testing: ML data augmentation comparison.
SMOTE — Synthetic Minority Oversampling Technique — generates synthetic samples by interpolating
between existing samples in feature space: pick a sample, find its k nearest neighbours, create a new
sample at a random point between them. It's simpler to implement than a GAN and has strong
theoretical justification. The downside: SMOTE interpolates linearly — it doesn't capture complex
non-linear distributions or generate samples in sparse regions of feature space. GANs learn the full joint
distribution and can generate more realistic out-of-distribution samples. For tabular data with complex
interactions between features, GAN quality is higher. For simple imbalanced classification, SMOTE is
often sufficient.

Q14. How would you monitor the Random Forest model in production?
Testing: MLOps thinking.
Three monitors: First, data drift detection — compare the distribution of incoming order features against
the training distribution weekly using PSI (Population Stability Index). PSI > 0.2 triggers a retrain alert.
Second, prediction drift — monitor the distribution of predicted demand values. If predictions suddenly
skew high or low without corresponding changes in input, the model may be extrapolating outside its
training range. Third, forecast error tracking — compare each 7-day forecast against actual demand
after the week passes. Track rolling MAE. If MAE increases by more than 20% over a 4-week window,
trigger a retrain.

Q15. How did sprint planning work in your Agile process?

Testing: Team process depth.
Each 2-week sprint started with a planning meeting where we reviewed the backlog, estimated task
complexity using story points (1, 2, 3, 5, 8), and assigned tasks based on capacity and skill. Tasks were
tracked as GitHub Issues linked to a Projects board with columns: Backlog, In Progress, In Review,
Done. Daily async standups via a shared channel: 'Yesterday I did X. Today I'm doing Y. Blocker: Z.'
Sprint review: each member demoed their completed feature. Retrospective: what went well, what to
improve.
Q16. What is the product recommendation engine and how did you evaluate it?
Testing: Recommendation depth.
Item-item collaborative filtering using a co-occurrence matrix. For every pair of products (A, B), I count
how many orders contained both. To recommend for a customer's cart containing product A, I return the
top-3 most co-occurring products not already in the cart. Evaluation: I used a leave-one-out protocol —
for each order in the test set, I removed one item, ran the recommender on the remaining items, and
checked if the removed item appeared in the top-3 recommendations. Hit rate (fraction of test cases
where the removed item was recommended) was the evaluation metric.

Q17. What security vulnerabilities are you aware of in this project?

Testing: Security self-awareness.
Three: First, Firestore security rules — if misconfigured, a client could read other users' orders directly
from Firestore without going through Flask. I enforced rules at both the Flask API layer and the Firestore
rules layer. Second, PDF generation — user-provided order data is inserted into the PDF template.
Without sanitisation, a malicious user could attempt template injection. I sanitise all string inputs before
PDF rendering. Third, Firebase token expiry — Firebase tokens expire after 1 hour. The frontend should
silently refresh tokens using Firebase's built-in token refresh mechanism rather than logging the user
out mid-session.

Q18. How would you migrate from Firebase to PostgreSQL if the business needed it?
Testing: Database migration thinking.
Migration path: First, map Firestore collections to relational tables — users, products, orders,
order_items (line items as a separate table with foreign key to orders), dispatch_logs. Second, write a
migration script that reads all Firestore documents and inserts them into PostgreSQL with appropriate
transformations (flatten nested order items into the order_items table). Third, run both databases in
parallel for one sprint — new writes go to both, reads from PostgreSQL. Verify data consistency, then
cut over reads entirely to PostgreSQL. Flask's SQLAlchemy ORM makes this backend change mostly
transparent to the API layer.

Q19. What is the difference between supervised and unsupervised learning? Which did you use?
Testing: ML fundamentals.
Supervised learning trains on labelled data — each sample has an input and a known correct output.
The model learns the input-output mapping. Random Forest demand forecasting is supervised: inputs
are order features, outputs are demand quantities from historical data. Unsupervised learning finds
structure in unlabelled data. The GAN is technically unsupervised — it learns the data distribution
without explicit labels. GANs fall into the generative model category. Collaborative filtering is also
unsupervised — it finds patterns in order co-occurrence without predefined labels.

Q20. What would a production CI/CD pipeline for this project look like?
Testing: DevOps maturity.
GitHub Actions pipeline: on PR — run pytest for Flask unit tests, validate Firestore security rules using
the Firebase emulator, lint Python with Ruff. On merge to main — build Docker image for Flask
backend, push to container registry, deploy to staging on Render with Firebase pointing to a staging
project, run integration smoke tests (place order, check inventory update, verify PDF generated),
promote to production on pass. ML model retraining runs weekly as a scheduled GitHub Actions job —
fetches fresh Firestore data, retrains, evaluates against held-out set, updates the serialised model file if
MAE improves.
■■ SECTION 6 — 10 ADVANCED INTERVIEW QUESTIONS + ANSWERS ■■

Q1. Design a scalable inventory forecasting system for 1,000 SKUs across 50 stores.
Testing: Large-scale ML system design.
Architecture: ingestion pipeline — daily sales data per SKU per store lands in S3. Apache Airflow
orchestrates the pipeline: clean → feature engineer → retrain or score. Model: a hierarchical forecasting
approach — global model trained on all SKUs (captures cross-SKU patterns), fine-tuned per-SKU
where data is sufficient. Meta-learner combines both. Serving: FastAPI inference service with a Redis
cache for SKU forecasts (TTL 24 hours, refreshed by Airflow). Monitoring: Evidently AI for data and
prediction drift. MLflow for model versioning and experiment tracking. Retrain trigger: PSI > 0.2 on any
SKU's feature distribution or MAE degradation > 20% over 2 weeks.

Q2. What are the limitations of item-item collaborative filtering at scale?

Testing: Recommendation systems depth.
Three limitations: First, cold start — a new product with no order history has no co-occurrence data.
Solution: content-based fallback using product category and description embeddings. Second, sparsity
— at 1,000 products, most pairs (i, j) have zero co-occurrence. The matrix is sparse and uninformative.
Solution: matrix factorisation (ALS or SVD) learns latent representations that generalise across sparse
pairs. Third, popularity bias — high-frequency items dominate recommendations regardless of
relevance. Solution: normalise co-occurrence by item frequency (pointwise mutual information instead
of raw count).

Q3. How would you implement real-time demand forecasting triggered by unusual sales events?
Testing: Event-driven ML architecture.
Use Firebase Cloud Functions triggered on order writes. When a product's orders-in-the-last-hour
exceed 2 standard deviations from the hourly mean (anomaly detection using Z-score), trigger an
immediate forecast refresh — call the Flask forecast endpoint which re-runs the Random Forest on
updated features. Push the refreshed forecast to Firestore. The admin dashboard receives the update
via onSnapshot within seconds. This event-driven architecture supplements the nightly batch retraining
with intra-day reactive updates for unusual demand spikes.

Q4. Compare GANs, VAEs, and diffusion models for tabular data synthesis.
Testing: Generative model depth.
GANs: adversarial training, can produce high-quality samples but suffer from mode collapse (generator
collapses to generating only a subset of the real distribution) and training instability. Good results with
careful hyperparameter tuning. VAEs: encode data to a latent distribution, decode back. More stable
training, principled probabilistic framework, but samples can be blurry/averaged. Better theoretical
grounding for tabular data. Diffusion models: iterative denoising process, currently state-of-the-art for
image synthesis; adapting to tabular data is an active research area (TabDDPM). For tabular data
synthesis at student project scale: CTGAN (a conditional GAN variant designed for tabular data) is the
current practical standard. I'd use CTGAN over a from-scratch GAN in a rebuild.
Q5. How would you detect and handle model degradation in production?
Testing: MLOps production thinking.
Three-layer approach: First, offline evaluation — weekly batch job compares the 7-day forecast made
last week against actual demand. Compute MAE and RMSE per SKU and overall. Log to MLflow. Alert
if rolling 4-week MAE increases > 20% vs baseline. Second, data drift — compute PSI weekly on all
input features. PSI > 0.2 on any feature triggers a retrain flag. Third, concept drift — if MAE increases
without feature drift, the relationship between features and target has changed (e.g., a new seasonal
pattern). Retrain on a sliding window of recent data, weighting recent records higher. Automated
retraining pipeline on drift alert; human review of model card before production promotion.

Q6. How would you build an explainable AI layer for the demand forecast dashboard?
Testing: Explainability and trust.
For Random Forest, I'd use SHAP — SHapley Additive exPlanations. SHAP assigns each feature a
contribution value to the prediction for each individual sample. On the admin dashboard, when showing
a 7-day forecast of 150 units for Product X, I'd display a SHAP waterfall chart: 'Base forecast: 80 units.
+40 because rolling_7day_avg is high. +25 because it's a Friday (day_of_week). +5 because holiday
flag is set.' This makes the forecast interpretable and trustworthy — the admin understands why the
system is recommending a reorder, not just that it is.

Q7. What are Firebase's limitations for a growing business and when would you migrate?
Testing: Technology trade-off at scale.
Firebase limitations: no complex JOINs — relational queries require multiple reads; no full-text search
natively; Firestore's 1MB document limit and 1 write/second per document rate limit can be constraining
at high write volume; vendor lock-in to Google Cloud; limited analytics SQL access without BigQuery
export. Migration trigger: when the team needs complex relational queries (multi-table JOINs for
financial reporting), when write volume approaches Firestore limits, or when compliance requires
self-hosted databases. Migration path: PostgreSQL for transactional data, Elasticsearch for search,
keeping Firebase Auth as the identity layer (it integrates with any backend via token verification).

Q8. How would you implement a fraud detection layer for the order system?
Testing: ML application breadth.
Fraud signals in an order system: unusually high order quantity for a single customer in a short window,
multiple orders to the same address from different accounts, orders placed at 3AM with a new account,
payment method changes immediately before high-value orders. ML approach: train a binary classifier
(Gradient Boosting) on labelled historical orders (fraud=1, legit=0). Features: order_value,
customer_account_age, orders_in_last_hour, is_new_payment_method, time_of_day,
order_quantity_zscore. At order placement, run inference synchronously — if fraud_probability > 0.7,
hold the order for manual review. Serve via a FastAPI microservice called from the Flask order
endpoint.
Q9. Explain the bias-variance trade-off in the context of your Random Forest model.
Testing: ML theory.
Bias is the error from incorrect assumptions in the model — a model with high bias underfits. Variance
is the error from sensitivity to small fluctuations in training data — a model with high variance overfits. A
single deep decision tree has low bias (it fits the training data very closely) but high variance (small
changes in training data produce very different trees). Random Forest reduces variance through
bagging: averaging N trees trained on different bootstrap samples. Each individual tree has high
variance; the average of many uncorrelated trees has low variance. Bias is not significantly increased
because each tree is still a low-bias model. The result: Random Forest sits in a better bias-variance
sweet spot than a single tree.

Q10. If the GM asked you to present this system to the board, what would you say in 90 seconds?
Testing: Executive communication — important at senior FAANG rounds.
I'd say: 'We built a system that replaces manual billing and inventory management with an automated,
data-driven platform. The immediate business impact: billing errors are eliminated because invoices are
generated programmatically from order data. Stock-outs are reduced because the system predicts
demand 7 days ahead — the admin gets a reorder recommendation before the shelf empties. Real-time
dashboards mean the admin always knows exactly what's in stock and what's been ordered. The AI
layer was built to work with limited historical data — we generated synthetic training records to make the
forecast model accurate despite a small dataset. The system is role-secured, generates audit-trail PDFs
for every transaction, and is designed to scale as the business grows. The next capability I'd add is
automated reorder placement — removing the human from the loop entirely for routine restocking.'
■■ SECTION 7 — WEAK AREAS AN INTERVIEWER WILL CHALLENGE ■■

Prepare these cold. These are the questions designed to expose gaps.

Challenge: It's a team project — what did YOU actually build?

Testing: Accountability for individual contribution.
Strong Response: This is a fair challenge. I owned two specific components: the entire ML pipeline —
data preprocessing, GAN training, synthetic data validation, Random Forest training, feature
engineering, and joblib serialisation for Flask serving — and the Streamlit analytics dashboard. I can
walk you through every line of the ML code. The Flask API routing and Firebase integration were built
by other team members. I reviewed their code and integrated the ML predictions into the API
responses, but the core implementation was theirs. I'm not claiming to have built the whole system solo
— the team did. My contribution was the ML layer.

Challenge: Your GAN is hand-built — why not just use CTGAN?

Testing: ML library awareness.
Strong Response: That's a good challenge. CTGAN is a purpose-built, well-validated library for tabular
GAN synthesis — it handles mode-specific normalisation and conditional generation out of the box.
Building a GAN from scratch was a learning choice: I wanted to understand the adversarial training loop
and the Nash equilibrium convergence conditions at an implementation level, not just call a library. In a
production setting, I would absolutely use CTGAN over a hand-built GAN — it's more robust, better
validated, and handles the peculiarities of mixed tabular data types. The hand-built version was the right
choice for a learning project.

Challenge: Random Forest can't capture temporal patterns in time-series data.

Testing: ML algorithm limitation.
Strong Response: That's precisely correct. Random Forest treats each sample as independent — it
doesn't inherently model sequential dependencies or seasonality beyond what's captured in engineered
features. I addressed this by manually engineering temporal features: rolling_7day_avg captures
short-term velocity, day_of_week captures weekly seasonality, is_holiday captures demand spikes. But
you're right that a true time-series model — LSTM, Prophet, or ARIMA — would capture longer-range
temporal dependencies that my feature engineering misses. That's why I listed adding an LSTM as the
top future improvement. For the scope of this project, the engineered features gave directionally useful
forecasts — but the model has a known ceiling.

Challenge: Firestore is expensive at scale — why not use PostgreSQL from the start?
Testing: Infrastructure cost awareness.
Strong Response: For a student project targeting a single business, Firestore's free tier and zero-ops
overhead was the right trade-off. The real-time sync capability — which would require WebSockets or a
polling layer with PostgreSQL — was the key feature we needed and Firebase delivered it for free. The
migration path to PostgreSQL is clear and I've described it — Firestore's collection model maps cleanly
to relational tables. The cost concern is valid at scale: Firestore charges per read/write operation, which
adds up at high volume. At that scale, PostgreSQL with a Redis cache for real-time updates is the
economically correct choice.
Challenge: How do you know the demand forecast is actually helping the business?
Testing: Business impact measurement.
Strong Response: Honest answer: we measured forecast accuracy on held-out historical data, but we
didn't run a controlled A/B test against the business operating without the system. To properly measure
business impact I'd track: stock-out rate before and after deploying the forecast (reduction in stock-outs
is the primary metric), inventory holding cost (over-ordering is also costly — good forecasting should
reduce it), and order fulfilment rate (percentage of orders fulfilled without delay). Without a baseline
measurement, I can only claim the forecast is directionally useful — not that it definitively improved
business outcomes. That's an honest limitation.
■■ FINAL CHEAT SHEET — REVIEW THE NIGHT BEFORE ■■

5 Things to Say Confidently Every Time

• 'I owned the ML pipeline — GAN data augmentation and Random Forest demand forecasting.'
• 'We validated the GAN output with a Kolmogorov-Smirnov test before adding synthetic data to training.'
• 'Random Forest can't capture temporal dependencies natively — I addressed that with rolling average
and seasonal features.'
• 'Firebase's onSnapshot gives real-time updates to both dashboards without polling — that was a
deliberate architectural choice.'
• 'In a rebuild, I'd use CTGAN over a hand-built GAN — better library, better validated for tabular data.'

3 Phrases That Signal ML Maturity

• 'I used chronological splitting, not random — random splitting would create data leakage in time-series
forecasting.'
• 'Feature importance confirmed rolling_7day_avg dominated — which is directionally sensible and gave
me confidence in the model.'
• 'The GAN reached Nash equilibrium when Discriminator accuracy stabilised at approximately 0.5.'

The One Sentence That Will Make Them Remember You

"Most people add ML to a project as a checkbox. I used a GAN because the real
problem was not the algorithm — it was not having enough data to train one."

Preethi R | Web Billing & Inventory Management System | PSG College of Technology | Placement 2027