Streamlit Overview - Interview Questions

1. What is Streamlit and what is it for?

Streamlit is a Python library for building data-and-ML web apps from a single script — no HTML, CSS, or JS required. You write Python; Streamlit renders the UI, handles state, and serves the app over HTTP.

It is not a general-purpose web framework. It is a tool for:

• Internal data tools and dashboards.
• ML / LLM demos and prototypes.
• Quick UIs around Python scripts (file processing, model evaluation).
• Read-write internal apps that don’t justify a React + FastAPI stack.

It is the wrong tool for: public-facing high-traffic websites, complex multi-user apps with fine-grained auth, or anything with custom interaction patterns the widgets don’t cover.

2. How does Streamlit compare to Flask, FastAPI, Dash, and Gradio?

Rule of thumb: Streamlit for “I have a Python script, give it a UI in 50 lines.” Reach for Dash if the dashboard needs callbacks at the cell level; reach for FastAPI + React if it’s a real product.

3. What is Streamlit’s execution model?

Streamlit re-runs the entire Python script from top to bottom on every user interaction (button click, widget change, slider drag). There is no event loop, no controller, no view layer.

import streamlit as st

# This whole block runs again every time the user types in the input.
name = st.text_input("Your name")
if name:
    st.write(f"Hello, {name}")

Implications:

• Long-running computations re-run on every interaction unless you cache them.
• Variables defined in the script are re-initialized each rerun. Use st.session_state to persist values across reruns.
• Order matters: widgets appear in the order they are called.
• Side effects (DB writes, API calls) re-fire on rerun. Guard them with if button: or callbacks.

This model is what makes Streamlit fast to write and easy to read. It’s also the source of nearly every “why is my app behaving weirdly?” bug.

4. What are Streamlit’s main building blocks?

• Display elements — st.write, st.markdown, st.dataframe, st.image, st.plotly_chart, st.pyplot.
• Widgets — st.button, st.text_input, st.selectbox, st.slider, st.file_uploader, st.checkbox, st.radio, st.multiselect, st.date_input.
• Layout — st.columns, st.tabs, st.expander, st.container, st.sidebar.
• State — st.session_state (dict-like, persists across reruns).
• Caching — @st.cache_data, @st.cache_resource.
• Flow control — st.stop, st.rerun, st.form.
• Status — st.spinner, st.progress, st.toast, st.error, st.warning, st.success.
• Chat — st.chat_message, st.chat_input, st.write_stream.

A typical app uses 5–10 of these.

5. When should you NOT use Streamlit?

• Public, high-traffic websites. Streamlit holds a WebSocket per user; horizontal scaling needs sticky sessions. It’s fine for hundreds of internal users, painful for thousands.
• Custom UI / animations. The widget set is fixed. Building a Figma-grade interface needs custom components or a different framework.
• Multi-tenant SaaS. No native auth, no tenancy, no row-level security. You can bolt some on, but you’re fighting the framework.
• Complex forms with cross-field validation. Possible with st.form and session state, but tedious. Pydantic + a real frontend wins past a few fields.
• Background jobs, schedulers, queues. Streamlit is a foreground UI. Run jobs in Celery / a worker; Streamlit just displays the result.
• APIs. It’s a UI, not a JSON server. Use FastAPI.

If you find yourself fighting the rerun model, you’re past Streamlit’s sweet spot.

6. What does a minimal Streamlit app look like?

# app.py
import streamlit as st
import pandas as pd

st.title("Sales Dashboard")

uploaded = st.file_uploader("Upload CSV", type="csv")
if uploaded is not None:
    df = pd.read_csv(uploaded)
    st.metric("Rows", len(df))
    st.dataframe(df.head(20))
    st.bar_chart(df.groupby("region")["revenue"].sum())

Run it:

streamlit run app.py

That’s the entire app: title, file upload, metric, table, chart. ~10 lines vs. ~200 in Flask + Jinja + Chart.js.

7. What ships in the box vs. what you bolt on?

In the box: widgets, layout, caching, session state, file upload, charts (Plotly / Altair / Matplotlib / Bokeh), dataframes, chat UI primitives, multipage support, secrets management, theming.

Not in the box (you bring it):

• Auth — Streamlit Community Cloud has Google login; otherwise use streamlit-authenticator, OAuth proxy (oauth2-proxy), or put it behind an SSO gateway.
• Database — use SQLAlchemy / psycopg / MongoDB drivers as you would anywhere else.
• Background work — call out to Celery / RQ / threadpool; Streamlit just kicks off jobs and polls status.
• Real-time push — limited; use st.fragment(run_every="2s") or a manual rerun loop.
• Heavy customization — write a Streamlit Component (React under the hood).

8. Cross-links to related topics

• Widgets & layout: 01_basics_and_widgets.md
• Session state: 02_session_state.md
• Caching: 03_caching.md
• Multipage apps: 04_multipage_apps.md
• LLM chat apps: 05_llm_chat_apps.md
• Deployment & secrets: 06_deployment_and_secrets.md
• Testing & advanced: 07_testing_and_advanced.md

Interview angle

• “What is Streamlit for, and what is it not?” - rapid internal tools, dashboards and LLM demos in pure Python. It’s not for public multi-tenant products: the execution model re-runs the whole script per interaction and each user holds a WebSocket.
• “How does the execution model work?” - every interaction re-runs the script top to bottom. State that must survive lives in st.session_state; expensive work must be cached, or it repeats on every keystroke.
• “When would you move off it?” - when you need real auth, fine-grained UI control, or more than a few hundred concurrent users. At that point a proper frontend against an API is the answer.