Python for AI interview questions & answers

Think of programming languages like spoken languages. Some are hard to pronounce with tricky grammar; others feel natural and easy to read. Python is the easy-to-read one — a line of Python often looks almost like plain English. That is exactly why the whole AI world picked it.

In Python, you write less to do more. There are no curly braces {} and no semicolons ; at the end of lines — you just indent your code and Python understands the structure. A beginner can read a Python program and roughly guess what it does, even before learning the language. That low barrier is a superpower when you are learning AI, because you spend your energy on ideas, not on fighting the syntax.

But readability is only half the story. The real reason AI runs on Python is the ecosystem: almost every AI tool, model provider, and library ships a Python SDK first. OpenAI, Anthropic (Claude), Google Gemini, Hugging Face, LangChain, PyTorch — all Python-first. If you know Python, you can plug into the entire Gen AI universe.

🌍 Real-world example: To ask an AI model a question, in Python it can be as little as 3 lines: import the library, create a client, send your message. The same task in a language like Java would take many more lines of boilerplate. Fewer lines = fewer bugs = faster learning.

💡 SDK = Software Development Kit — a ready-made library that lets your code talk to a service (like an AI model) without you writing the low-level networking yourself.

💡 Ecosystem = the whole collection of libraries, tools, and community built around a language. Python's AI ecosystem is the biggest in the world.

You do NOT need to be a Python expert to build AI apps. You need the basics — variables, functions, lists/dicts, and calling an API. This chapter gives you exactly that, from zero.

When Python is the right choice: anything touching the AI ecosystem — model libraries, data tooling, notebooks, research code. You are choosing the libraries and the community, not the syntax.

When another language is better: a high-throughput API layer, a CPU-bound service, or a team already productive elsewhere. Most production AI systems are Python for the model work and something else for the serving layer, and that is a normal architecture rather than a compromise.

Trade-off: Python is slow at raw computation and almost never the bottleneck, because the heavy work happens inside C/CUDA libraries it is only orchestrating. Where it does cost you is at the edges — packaging, environment reproducibility and deployment size are genuinely harder than in most ecosystems.

Standard definition: Python is a high-level, readable, interpreted programming language, and it is the default language for AI/ML because every major model provider and framework ships a Python-first SDK.

from openai import OpenAI

client = OpenAI()  # reads your API key from the environment

response = client.responses.create(
    model="gpt-4o-mini",  # model IDs change — check the provider's current list
    input="Explain what an LLM is in one line."
)

print(response.output_text)

Think of a recipe card. It has labeled ingredients ("sugar = 2 cups"), and it has steps written one under another, some steps nested under a condition ("if the batter is runny, add more flour"). Python code reads the same way — you label values with names, and you write steps line by line, with nested steps indented underneath.

In Python, a variable is just a labeled box for a value: name = "Riya" puts the text "Riya" in a box called name. You don't declare a type upfront — Python figures it out from the value. The core building-block types are int (whole numbers like 25), float (decimals like 3.14), str (text like "hello"), bool (True/False), and None (Python's way of saying "nothing here"). To print a value mixed with text, use an f-string: f"Hi {name}" — the f before the quotes tells Python to fill in {name} with the variable's value. print(...) shows output on screen.

Decisions use if / elif / else, and repetition uses for (loop over a known sequence, e.g. for i in range(5):) or while (loop while a condition stays True). The single biggest rule that trips up every beginner: Python has no { } braces to mark a block — indentation itself is the block. Everything at the same indent level under an if, for, or while belongs to that block; the moment you un-indent, you're back outside it.

🌍 Real-world example: When you build an AI chat app, you'll write something like: read the user's message into a variable, if the message is empty, print an error; else, loop for each word to count tokens roughly. Every AI script is built from exactly these basic pieces.

💡 Variable = a named box that holds a value, which can change ("vary") later.

💡 f-string = a text string prefixed with f that lets you drop {variable} values straight inside it.

💡 Indentation = the spaces at the start of a line; in Python it is not just style, it defines which lines belong inside a block.

Use 4 spaces per indent level (the Python community standard) and never mix tabs with spaces — mixing them is the #1 cause of a confusing IndentationError. Comments start with # and are ignored by Python — use them to explain why, not what.

When f-strings are the right tool: almost all string building, including every prompt in this course. They are readable and fast.

When NOT to use one: building SQL or a shell command. An f-string interpolates whatever it is given, which is exactly how injection happens — parameterised queries exist for that.

Trade-off: Python's indentation-as-syntax makes code readable and makes whitespace a real error class — a mixed tab and space is a crash, and a wrongly indented line is silently a different program. It is why every Python project standardises on a formatter rather than arguing about it.

Standard definition: Python defines code blocks (for if, for, while, functions, etc.) purely through consistent indentation rather than braces or keywords, and it is dynamically typed — a variable's type is inferred from the value it's assigned, not declared upfront.

# A tiny script using every basic piece
name = "Riya"          # str
age = 21                # int
height = 5.4             # float
is_student = True        # bool
mentor = None             # None = nothing assigned yet

print(f"{name} is {age} years old.")

if age >= 18:
    print("Adult")
elif age >= 13:
    print("Teenager")
else:
    print("Child")

for i in range(3):
    print(f"Loop iteration {i}")

count = 0
while count < 2:
    print(f"While count = {count}")
    count = count + 1

What we're building: A tiny, complete script — maybe 12 real lines — that talks to a real AI model. This is the moment every piece of Chapter 1 clicks together: variables hold your key and prompt, a dict shapes the request and the response, a file (.env) keeps your secret safe, and requests/the openai SDK carries your message over the network and brings the answer back. By the end you will have run your first real AI call from Python.

---

Step 0 — The mental model (read first, 30 seconds)

Every AI API call is the same five-beat dance, no matter which library you use:

1. Load a secret — your API key, kept OUT of your code, read from a .env file.
2. Build a request — a small dict describing what you want (model, your input/prompt).
3. Send it — over HTTPS, to the provider's server (OpenAI, in this project).
4. Get a response — the server replies with JSON; your code turns it into a Python dict.
5. Read the answer out of the dict and print it.

💡 API key = a secret password that proves the request is coming from you (and lets the provider bill your account). Never hardcode it, never commit it to git.

Keep those five beats in your head — every step below is just one beat, in code.

---

Step 1 — Store the secret in a .env file

Create a file named .env in your project folder (NOT inside your .py file):

OPENAI_API_KEY=sk-your-real-key-here

What's happening: .env is just a plain text file of KEY=value lines — nothing magic about it. It sits next to your script but is never imported or hardcoded. Add .env to your .gitignore so it never reaches GitHub — a leaked key means someone else spends your money.

🌍 Real-world example: every real AI startup does exactly this — local .env for your machine, and the same variable set as an "Environment Variable" in the hosting dashboard (Vercel, Render, etc.) for production. The code never changes; only where the key comes from changes.

---

Step 2 — Load the key into Python with python-dotenv

import os
from dotenv import load_dotenv

load_dotenv()
api_key = os.environ["OPENAI_API_KEY"]

What's happening, line by line:

• import os — the standard library module that reads environment variables.
• from dotenv import load_dotenv — from the python-dotenv package (pip install python-dotenv).
• load_dotenv() — opens .env in the current folder and copies every KEY=value line into the process's environment variables. This is a file being read, exactly like with open(...), just automated for you.
• os.environ["OPENAI_API_KEY"] — os.environ behaves like a dict: square brackets look up a key and return its value. api_key is now just a normal Python string variable sitting in memory — never printed, never logged.

💡 Environment variable = a value that lives outside your code, in the process running it. .env + load_dotenv() is the beginner-friendly way to set one for local development.

---

Step 3 — Build the client

Install the SDK first: pip install openai

from openai import OpenAI

client = OpenAI(api_key=api_key)

What's happening: OpenAI(...) is a function call that returns an object — the client. It stores your api_key and knows the provider's base URL, so every call you make through client is already authenticated. You built exactly one object and you'll reuse it for every request in this script (and in a bigger app, for the whole program's lifetime).

---

Step 4 — Build the request

Under the hood, every AI API call wants a small dict shaped roughly like this:

{
  "model": "gpt-4o-mini",  # model IDs change — check the provider's current list
  "input": "What is one interesting fact about the Moon?"
}

What's happening: model picks which AI model answers you; input is your prompt — plain text, the exact same string type you've used since Step 1 of this chapter. The SDK will turn this dict into the JSON body of an HTTPS POST request for you — you never write raw JSON by hand.

💡 Payload = the data you send in the body of a request — here, your model choice + prompt, as a dict that becomes JSON on the wire.

---

Step 5 — Send it and get a response back

response = client.responses.create(
    model="gpt-4o-mini",  # model IDs change — check the provider's current list
    input="What is one interesting fact about the Moon?"
)

What's happening — trace the network round trip:

1. client.responses.create(...) packs model + input into that dict, converts it to JSON text, and sends it as the body of an HTTPS POST request to OpenAI's servers, with your api_key in the headers proving it's you.
2. Your script pauses here — this is a blocking, synchronous call — while the request travels over the internet, the model generates an answer, and the reply travels back. (In Chapter 1's async lesson you saw await exists to not block like this; for one call at a time, blocking is fine.)
3. The server's reply arrives as raw JSON text. The SDK automatically parses it and hands you back a Python response object — this already did the json.loads() step for you.

---

Step 6 — Parse the response into a dict

data = response.model_dump()
answer = data["output"][0]["content"][0]["text"]

What's happening: response is a rich Python object, but underneath it is just structured data — the same shape as the JSON the server sent. .model_dump() converts it into a plain dict (nested dicts and lists, exactly like json.loads() would give you from raw JSON text). Then data["output"][0]["content"][0]["text"] walks down into it: "output" is a list of message blocks, [0] grabs the first one, "content" is its list of content pieces, [0] grabs the first piece, and "text" is the actual answer string. This is exactly the list/dict-indexing you practiced in working-with-json — real API responses nest exactly like this.

💡 In practice, the SDK also gives you a shortcut — response.output_text — that does this exact walk for you. Knowing how to do it manually (like above) is what lets you debug when a response looks unexpected, or when you switch to a provider without a shortcut.

---

Step 7 — Print the answer

print("AI says:", answer)

What's happening: answer is a plain str at this point — all the API machinery is done. print takes it to the terminal, exactly like every print() you've written since Step 1 of this chapter. The AI's reply is now on your screen.

---

🔁 The raw requests alternative

You don't need the openai SDK — it's a convenience wrapper. Here's the exact same call using plain requests (install it first: pip install requests), which makes the JSON parsing fully visible:

import requests

url = "https://api.openai.com/v1/responses"
headers = {"Authorization": f"Bearer {api_key}"}
payload = {
    "model": "gpt-4o-mini",  # model IDs change — check the provider's current list
    "input": "What is one interesting fact about the Moon?"
}

resp = requests.post(url, headers=headers, json=payload)
data = resp.json()  # <-- this line does the json.loads() for you
answer = data["output"][0]["content"][0]["text"]
print("AI says:", answer)

What's different: requests.post(url, headers=headers, json=payload) builds and sends the exact same HTTPS request the SDK built for you in Step 5 — json=payload tells requests to turn your dict into a JSON body itself. resp.json() is the line to notice: it reads the raw JSON text the server sent back and converts it straight into a Python dict — the manual version of what the SDK did automatically. Same five beats, same dict-walking in the end. The openai SDK exists so you don't have to remember the URL, headers, or endpoint shape by hand.

---

🔎 The full flow (recap the wiring)

1. .env file on disk holds OPENAI_API_KEY=... — a secret, never in your .py file.
2. load_dotenv() reads that file and copies it into environment variables; os.environ["OPENAI_API_KEY"] pulls it into a Python string variable.
3. OpenAI(api_key=api_key) builds a client object that already knows how to authenticate.
4. model + input form a small dict — the request payload.
5. client.responses.create(...) sends that payload as JSON over HTTPS, blocks until the model replies, and parses the JSON reply back into a Python object automatically.
6. .model_dump() turns that object into a plain dict; dict/list indexing (data["output"][0]["content"][0]["text"]) pulls out the answer string.
7. print(...) puts it on your screen.

Every single piece — variables, dicts, files, functions, requests/SDKs, JSON — that you learned across this chapter shows up in these 12 lines. This is Chapter 1, assembled.

---

✅ What you just learned — and what's next

• Secrets live in .env, loaded with python-dotenv — never hardcoded, never committed.
• os.environ behaves like a dict — square-bracket lookup by key.
• A "client" object wraps your key + the provider's connection details so every call is pre-authenticated.
• Every AI request is a dict (model + input/prompt) that becomes a JSON body.
• Every AI response is JSON, parsed into a Python dict (.model_dump() or resp.json()) — then you index into it like any nested dict/list.
• requests (raw HTTP) and the openai SDK (convenience wrapper) do the same underlying HTTPS POST + JSON parse — the SDK just remembers the details for you.

You just wrote and ran your first real AI script. Chapter 2 (LLM Foundations) builds directly on this: what a "prompt" really is, how models use tokens, system vs. user messages, temperature, and how to design prompts that get reliable answers — all sent through the exact same client.responses.create(...) shape you just used.

Standard definition: A minimal AI script loads an API key from environment configuration (never hardcoded), builds a request payload as a dict, sends it to the provider's HTTPS endpoint (via an SDK or raw requests), parses the JSON reply into a dict, and reads the answer out of it — the same five-step pattern behind every LLM API integration.

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()  # reads .env and loads it into environment variables

api_key = os.environ["OPENAI_API_KEY"]
client = OpenAI(api_key=api_key)

response = client.responses.create(
    model="gpt-4o-mini",  # model IDs change — check the provider's current list
    input="What is one interesting fact about the Moon?"
)

data = response.model_dump()  # response object -> plain Python dict
answer = data["output"][0]["content"][0]["text"]

print("AI says:", answer)