Python backend internship interviews usually test five things: whether you understand HTTP and REST, whether you can reason about SQL and indexes, whether you know what an ORM does for you and what it hides, whether you can explain authentication, and whether you write tests. This guide gives RGPV students a question bank for each area, with model answer outlines and a rubric for scoring yourself before the real interview.
How to use this question bank
Interviewers for internships rarely expect production experience. They want to see clear fundamentals, honest reasoning and one or two small projects you can discuss in detail. Treat each question below as a prompt to answer aloud in 60 to 90 seconds, then compare your answer with the outline and score it.
- Pick one area per day. Answer the questions aloud without notes.
- Write down your answer in three or four bullet points. Compare with the outline.
- Score yourself with the rubric near the end of this article.
- For every weak answer, build a tiny runnable example on your own machine. Reading about an index is different from watching a query plan change.
The outlines are deliberately short. They show the shape of a good answer, not a script to memorise. Interviewers can tell when a definition is recited, and a follow-up question like “when would that fail?” exposes it quickly.
Part 1: HTTP fundamentals
Most backend interviews begin here because everything else sits on top of it. Expect short, precise questions.
| # | Question | Model answer outline |
|---|---|---|
| H1 | What happens when you type a URL and press Enter? | DNS lookup; TCP connection (and TLS handshake for HTTPS); HTTP request sent; server routes it to application code; response returned with status, headers, body; browser renders. Mention that a backend developer owns the middle part. |
| H2 | What is the difference between GET, POST, PUT, PATCH and DELETE? | GET reads and must not change state. POST creates or triggers an action. PUT replaces a resource fully. PATCH changes part of it. DELETE removes it. Tie each to a concrete resource such as an order. |
| H3 | What does it mean for a method to be idempotent? Which methods are? | Repeating the request gives the same server state as sending it once. GET, PUT and DELETE are idempotent by definition; POST is not. Explain why retries after a network timeout make this matter. |
| H4 | Explain 200, 201, 204, 400, 401, 403, 404, 409, 422 and 500. | Group them: success (200 OK, 201 created, 204 no content), client error (400 malformed, 401 not authenticated, 403 not allowed, 404 missing, 409 conflict, 422 failed validation), server error (500). The 401 versus 403 distinction is a favourite follow-up. |
| H5 | What are headers used for? Name five. | Metadata about the request or response. Examples: Content-Type, Accept, Authorization, Cache-Control, Set-Cookie. State what each controls in one line. |
| H6 | HTTP is stateless. What does that mean and how do apps still keep users logged in? | Each request carries all information needed to handle it. State is carried by cookies, session IDs looked up server-side, or signed tokens sent with every request. |
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
Part 2: REST and API design
| # | Question | Model answer outline |
|---|---|---|
| R1 | What makes an API RESTful? | Resources identified by URLs, standard HTTP methods, stateless requests, representations such as JSON, consistent status codes. Admit that many “REST” APIs are only partly RESTful and that this is acceptable in practice. |
| R2 | Design endpoints for a library system with books and members. | Use nouns and plurals: GET /books, POST /books, GET /books/{id}, GET /members/{id}/loans. Avoid verbs in paths such as /getBooks. Mention nested resources only where the relationship is real. |
| R3 | How would you paginate a list endpoint? | Offset and limit are simple but slow and unstable on large or changing tables. Cursor-based pagination uses the last seen key and is steadier. Return total or next-cursor information in the response. |
| R4 | How do you version an API? | URL prefix like /v1/ or a header. Explain that the goal is to avoid breaking existing clients when fields change. |
| R5 | How should errors be returned? | Correct status code plus a consistent JSON body with a machine-readable code and a human-readable message. Never leak stack traces. |
| R6 | Flask, Django or FastAPI: how would you choose? | Flask is minimal and flexible. Django includes ORM, admin, auth and migrations. FastAPI uses type hints for validation and generates interactive docs. Choose based on project size and what the team already uses; say which you have actually used. |
| R7 | What is rate limiting and why add it? | Caps requests per client in a time window to protect the service from abuse and accidents. Respond with 429. Mention token bucket or fixed window as an approach. |
Part 3: SQL, indexing and transactions
Many students can write a SELECT but stall when asked why a query is slow. Prepare for the “why” questions.
| # | Question | Model answer outline |
|---|---|---|
| S1 | Explain INNER JOIN versus LEFT JOIN. | INNER keeps only rows with a match in both tables. LEFT keeps every left row and fills missing right columns with NULL. Give an example: customers with and without orders. |
| S2 | What is an index and how does it speed up a query? | A separate sorted structure, commonly a B-tree, that lets the database find rows without scanning the whole table. Cost: extra storage and slower writes, because the index must be updated. |
| S3 | When would an index not help? | Very small tables, low-selectivity columns such as a boolean, queries that wrap the column in a function, or a leading wildcard in LIKE '%abc'. |
| S4 | What is a composite index and why does column order matter? | One index over several columns. It serves queries that filter on a leftmost prefix of those columns. An index on (city, age) helps filtering by city, or city and age, but not by age alone. |
| S5 | How do you find out why a query is slow? | Run EXPLAIN (or EXPLAIN ANALYZE where supported) and read whether it does a sequential scan or an index scan. Then adjust the index or the query and compare again. |
| S6 | Primary key versus unique key versus foreign key. | Primary key identifies each row and cannot be NULL. Unique key prevents duplicates. Foreign key enforces a link to another table’s key. |
| S7 | What are ACID properties? What is a transaction? | Atomicity, consistency, isolation, durability. A transaction groups statements so they all succeed or all roll back. Use a bank transfer: debit and credit must not be separated. |
| S8 | What is normalisation and when might you denormalise? | Splitting data to remove redundancy and update anomalies. Denormalise selectively for read-heavy cases, accepting duplication as the cost. |
Part 4: ORMs and database access in Python
| # | Question | Model answer outline |
|---|---|---|
| O1 | What is an ORM and why use one? | Maps tables to Python classes and rows to objects, so queries are written in Python. Benefits: less boilerplate, parameterised queries by default, migrations. Cost: hidden SQL and possible inefficiency. |
| O2 | What is the N+1 query problem? | Loading a list of N parents, then issuing one query per parent to fetch children, giving N+1 queries. Fix with eager loading, such as select_related or prefetch_related in Django, or joinedload or selectinload in SQLAlchemy. |
| O3 | What is a migration? | A versioned, reviewable change to the database schema, kept in source control, so every environment can reach the same structure. |
| O4 | How do you prevent SQL injection? | Never build SQL by concatenating user input. Use parameterised queries, which ORMs do by default. Validate input as a second layer. |
| O5 | When would you write raw SQL instead of using the ORM? | Complex reporting queries, database-specific features, or performance-critical paths where the generated SQL is poor. Still parameterise. |
| O6 | What is a connection pool? | A set of reusable open database connections, avoiding the cost of opening one per request and capping load on the database. |
Part 5: Authentication and authorisation
| # | Question | Model answer outline |
|---|---|---|
| A1 | Authentication versus authorisation? | Authentication confirms who you are; authorisation decides what you may do. Link to 401 and 403. |
| A2 | How should passwords be stored? | Never in plain text or with a fast hash alone. Use a slow, salted algorithm such as bcrypt, scrypt or Argon2, usually through the framework’s built-in tooling. |
| A3 | Session cookies versus JWTs? | Sessions keep state on the server and are easy to revoke. JWTs are signed tokens the client sends each time; they scale statelessly but are harder to revoke before expiry. Neither is always better. |
| A4 | What is inside a JWT and why is it safe to read? | Header, payload, signature. Payload is encoded, not encrypted, so never put secrets in it. The signature only proves it was not altered. |
| A5 | Where should secrets such as API keys live? | Environment variables or a secrets manager, never committed to Git. Provide a sample env file without real values. |
| A6 | What is CORS? | A browser rule restricting cross-origin requests unless the server allows them through headers. It is enforced by the browser, not by the server as a security wall. |
Part 6: Unit testing in Python
| # | Question | Model answer outline |
|---|---|---|
| T1 | Unit, integration and end-to-end tests: what is the difference? | Unit tests check one function in isolation. Integration tests check components together, such as the API plus database. End-to-end tests drive the whole system. Many fast unit tests, fewer slow ones. |
| T2 | pytest versus unittest? | unittest ships with Python and is class-based. pytest uses plain functions and assert statements, fixtures and parametrisation, with less boilerplate. |
| T3 | What is a fixture? | Reusable setup and teardown, such as a temporary database or test client, injected into tests by name. |
| T4 | What is mocking and when is it a bad idea? | Replacing a dependency, such as an email service, with a controlled stand-in. Overmocking makes tests pass while real behaviour is broken, so mock boundaries, not your own logic. |
| T5 | How do you test an API endpoint? | Use the framework’s test client, send a request, assert status code and JSON body. Cover success, validation failure, unauthenticated and not-found cases. |
| T6 | Does 100% coverage mean no bugs? | No. Coverage shows lines executed, not whether assertions are meaningful or edge cases are handled. |
Worked illustrative example: slow endpoint question
Interviewers often combine areas in one scenario. The following is an illustrative example of such a question and a strong answer structure. The code is a teaching sketch and has not been executed here.
Question: “GET /orders?customer_id=42 takes several seconds on a table with a few million rows. How do you investigate and fix it, and how do you make sure it stays fixed?”
Step 1: Reproduce and measure. Capture the SQL the ORM generates, then run it with EXPLAIN. A sequential scan on orders suggests that customer_id has no index.
-- Illustrative only
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;
CREATE INDEX idx_orders_customer_id ON orders (customer_id);
Step 2: Check the application layer. If the endpoint also returns each order’s items, look for N+1 queries. Add eager loading so the item rows are fetched in one extra query, not one per order.
Step 3: Limit the response. Add pagination, so a customer with thousands of orders does not produce a huge payload.
Step 4: Lock it in with a test. A regression test cannot easily assert speed, but it can assert behaviour and query count.
# Illustrative pytest sketch
def test_orders_endpoint_returns_only_that_customers_orders(client, make_orders):
make_orders(customer_id=42, count=3)
make_orders(customer_id=7, count=2)
response = client.get("/orders?customer_id=42")
assert response.status_code == 200
body = response.json()
assert len(body["results"]) == 3
assert all(o["customer_id"] == 42 for o in body["results"])
Step 5: Name the trade-off. The new index speeds reads but adds a small cost on every insert and update. A good candidate says this unprompted.
Notice what earns marks here: a measurement before a fix, a specific tool (EXPLAIN), awareness of both database and ORM causes, and an acknowledgement of cost. None of it requires memorising syntax.
Scoring rubric for self-assessment
Score each answer from 0 to 4 on each of the five criteria below, then average. A friend, senior or mentor can play interviewer so you are not marking your own work alone.
| Criterion | 0 to 1 (weak) | 2 (adequate) | 3 to 4 (strong) |
|---|---|---|---|
| Correctness | Wrong or confused definition | Mostly right with gaps | Accurate, with correct terms and limits |
| Depth | Definition only | Definition plus one example | Explains why, when it fails and the alternative |
| Trade-offs | None mentioned | Mentioned when prompted | Raised unprompted with a concrete cost |
| Practical grounding | No link to real code | Refers to a tutorial | Refers to something you built or tested yourself |
| Communication | Rambling or silent | Understandable but unstructured | Clear in about 60 to 90 seconds, easy to follow |
Reading your average
- Below 1.5: Go back to fundamentals. Rebuild a small CRUD API and write the SQL by hand.
- 1.5 to 2.4: You know the vocabulary. Add depth by running
EXPLAINyourself and writing tests for every endpoint. - 2.5 to 3.2: Interview-ready for most internship rounds. Practise explaining out loud and tie answers to your projects.
- Above 3.2: Practise system-flavoured follow-ups such as caching, queues and background jobs.
These bands are a practice aid for your own planning. They are not a prediction of how any company will assess you.
A one-week practice plan
| Day | Focus | Output to produce |
|---|---|---|
| 1 | HTTP and status codes | A written one-page note, plus a small script that calls a public API and prints headers |
| 2 | REST design | Endpoint list for a small app, with methods and status codes for each |
| 3 | SQL and indexes | A table with generated rows, one slow query, and its EXPLAIN output before and after an index |
| 4 | ORM | Same query written in ORM and raw SQL; deliberately create and then fix an N+1 |
| 5 | Authentication | Register and login endpoints with hashed passwords and a protected route |
| 6 | Testing | Five pytest tests covering success, validation error, unauthenticated and not-found |
| 7 | Mock interview | Ten random questions from this bank, scored with the rubric |
RGPV and the Python backend interview: where internships, coursework and placement support fit
RGPV describes itself as the State Technological University of Madhya Pradesh, Bhopal, with programmes across engineering, pharmacy, management and applied sciences. This guide is independent and is not connected with the university. What follows covers only the facts that bear on preparing for a backend internship interview.
Internship rules appear in the scheme documents, and they vary by batch. A 2018 flexible-curricula B.Tech scheme excerpt lists Internship-I as 60 hours at institute level, with evaluation and credit added in the third semester. A 2019 CSE third-semester scheme excerpt lists a 90-hour Internship-II based on using various software. A 2023 School of Information Technology CSBS scheme excerpt lists a 90-hour Internship-III in the sixth semester. These are older excerpts, so a project built with Python, a database and tests may fit such a slot, but only the scheme for your own batch can confirm that.
For interview practice, the useful point is timing. The 2022 excerpt for a different branch says Internship-II is completed in the fourth semester and evaluated in the fifth. Dates for 2026-27 sit in the official Academic Calendar page, which links the annual calendar PDF. Check it before planning application and practice weeks around exams.
For enquiries, the School of Information Technology placement page lists the Training & Placement Cell on the 2nd floor of the Knowledge Resource Centre, Bhopal, for recruitment and internship questions (tpo@rgpv.ac.in). A UIT Shivpuri page says students must register with the T&P cell and that training classes are mandatory for placement support. Rules at other colleges may differ. Nothing here guarantees an interview, selection or offer.
Checks before you rely on an internship for credit
- Find the scheme PDF for your branch and admission year on the RGPV scheme page and note the internship hours and semester.
- Ask your department whether the evaluation needs a report, certificate or faculty sign-off, and in what format.
- Ask whether an online or remote backend internship is acceptable for your scheme, since no rule on this was confirmed.
- Read the 2026-27 calendar PDF to find exam and break dates before setting a practice plan.
- Check whether your college’s T&P cell requires registration before you apply to companies.
Building real evidence for your answers
Rubric scores of 3 and 4 depend on “practical grounding”, so you need something to point to. Free options include a self-built project on GitHub and short structured programmes. One such option is the free two-week online internship from CareerSwami, which runs for 14 days and offers a free offer letter and a free completion certificate after successful completion, across 26 tracks. Choose the track that matches your goal, and treat the certificate as a record of work done, not as a replacement for being able to explain it.
Whatever you pick, finish with something you can open in an interview: a repository with a README, a short list of endpoints, a schema, and a test folder.
Common mistakes in backend interviews
- Reciting definitions without examples. “An index speeds up queries” is incomplete. Add what it costs and when it is ignored.
- Confusing 401 and 403. Unauthenticated is 401; authenticated but forbidden is 403.
- Claiming skills on your CV that you cannot demonstrate. If you list Django, be ready to explain a model, a migration and a view you wrote.
- Treating JWT as encryption. It is signed, not secret.
- Skipping tests in projects. A few meaningful tests set you apart from many candidates.
- Staying silent when stuck. Say what you know, state your assumption, and reason forward. Interviewers value visible thinking.
Checks before you rely on an internship for credit
Before you rely on any internship for academic purposes, put these questions to the right people, preferably in writing so there is a record.
- Is an internship mandatory in my scheme and semester? Check the scheme and syllabus document for your admission year on the university website, and ask your department head.
- Does an online or remote internship qualify? Ask your training and placement officer or internship coordinator, and request the answer by email.
- What proof is required? Ask for the exact format for offer letter, completion certificate, report and any faculty signature.
- Are there duration or credit rules? Ask whether the hours or weeks must meet a minimum and whether any credit applies. Do not assume credit from an internship provider’s certificate.
- Who is my internal guide or evaluator? Get the name and the submission deadline.
- Can my backend project double as my project submission? Ask your project coordinator what originality and documentation rules apply.
Frequently Asked Questions
Which Python framework should I know for a backend internship interview?
Know one well. Django is common for full-featured apps and Flask or FastAPI for lighter services. Interviewers usually care more that you can explain routing, request validation, database access and testing in the framework you chose than that you list three.
How much SQL do I need for a Python backend internship interview?
Be fluent with joins, GROUP BY, subqueries, primary and foreign keys, transactions and indexes. Be able to read a basic EXPLAIN output. Window functions are a useful bonus but rarely required for internships.
Will I be asked data structures and algorithms as well?
Often yes, alongside backend questions, though this varies by company. Prepare arrays, strings, hash maps and basic recursion in Python. This article covers only the backend portion.
Is it enough to know the ORM without knowing SQL?
No. When an ORM query is slow, you need SQL knowledge to read the generated statement and fix it. Interviewers commonly ask for the SQL behind an ORM call for this reason.
What should I put in a backend project to discuss in interviews?
A small API with a relational database, user registration and login with hashed passwords, at least one protected route, pagination on a list endpoint, and a pytest suite. Document the endpoints in the README.
How many tests should a student project have?
There is no fixed number. Aim for tests on each endpoint’s main success path and its main failure paths, plus unit tests for any non-trivial business logic. Quality of assertions matters more than the count.
Does a free internship certificate help in interviews?
It can show that you completed structured work, but interviewers will probe what you built. Be ready to walk through your code and decisions. The certificate does not guarantee selection or any other outcome.
How should I answer a question I do not know?
Say so plainly, then reason from related knowledge. For example, if asked about database sharding, relate it to partitioning and indexes, state your assumptions and ask a clarifying question. Honest reasoning scores better than a confident guess.
Related Python & Backend Engineering guides
- KTU Students: Comparing Django, Flask and FastAPI for a Python Backend Internship
- VIT Students: Building a Demo-Ready Python Backend Internship Project with Docker and Tests
- SRM Students: Python Backend Engineering Internship Prerequisites to Master First
- All Python & Backend Engineering internship guides
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Python & Backend Engineering. The internship, the offer letter and the completion certificate are free.
