RV College of Engineering Students: Python Backend Engineering Internship Interview Preparation

To prepare for a Python backend internship interview, practise five areas in this order: API design, database transactions, caching, concurrency, and debugging scenarios. Interviewers at the internship level mostly test whether you can reason about a request from client to database and back, and explain trade-offs in plain words. This guide gives you a question bank with model answers, a self-scoring table, and a worked example you can adapt for RV College of Engineering (RVCE) coursework and projects.

How backend internship interviews are usually structured

Formats differ by company, so treat the following as a common pattern rather than a rule. Many interviews open with a short introduction and a walk-through of one project. They continue with Python fundamentals, then a few backend design or SQL questions, and often finish with a small debugging or coding exercise. Some companies add an online test before any conversation.

For a fresher, the strongest signal is not memorised definitions. It is the ability to say “here is what happens, here is why, and here is what I would change if traffic grew.” Each model answer below follows that shape.

The preparation scorecard

Before reading the answers, rate yourself honestly. Score each row from 0 to 3: 0 means you cannot explain it, 1 means you can define it, 2 means you can explain it with an example, and 3 means you can explain it and describe a failure you have seen or reproduced in your own project. Anything under 2 goes to the top of your revision list.

Part 1: API design questions and model answers

Q1. When would you use PUT versus PATCH versus POST?

Model answer. POST creates a new resource, or triggers an action where the server decides the identifier. PUT replaces a resource at a known URL with the full representation you send, and repeating it leaves the same final state. PATCH changes only some fields. The point worth stating aloud is idempotency: PUT and DELETE are defined to be idempotent, POST is not, and that decides which calls are safe to retry after a timeout.

Q2. Which status codes do you return for common outcomes?

• 200 for a successful read or update that returns a body.
• 201 for a successful create, ideally with a Location header.
• 204 for success with no body, such as a delete.
• 400 for a malformed request, and 422 where your framework uses it for validation failures.
• 401 when the caller is not authenticated, and 403 when they are authenticated but not allowed.
• 404 for a missing resource and 409 for a conflict, such as a duplicate unique value.
• 429 for rate limiting, and 500 only for genuine server faults.

Interviewers often probe the 401 versus 403 distinction, so have a one-line answer ready.

Q3. How would you design pagination for a list endpoint?

Model answer. Offset pagination (limit and offset) is simple but slows down on deep pages and can skip or repeat rows when data changes between requests. Cursor (keyset) pagination uses the last seen key, for example “id greater than 1050, ordered by id, limit 20”. It stays fast and stable, but it does not allow jumping to an arbitrary page. For an internal admin table, offset is fine. For a feed that grows continuously, choose a cursor.

Q4. How do you make a payment or order endpoint safe to retry?

Model answer. The client sends a unique idempotency key with the request. The server stores the key with the result in the same transaction as the business change, protected by a unique constraint. If the same key arrives again, the server returns the stored result instead of repeating the work. This handles the case where the client never saw the first response.

Q5. How should errors be returned?

Model answer. Use one consistent JSON shape, for example a machine-readable code, a human message and an optional field list. Never leak stack traces or SQL text. Log the detail server-side with a request ID, and return that ID to the client so support can find the log line.

Q6. How would you version an API?

Model answer. The common choice is a path prefix such as /v1/. Adding optional fields is backward compatible, while removing or renaming fields needs a new version. Mention that you would announce a deprecation window rather than switch off the old version abruptly.

Part 2: Database transaction questions and model answers

Q7. What does ACID mean, in practice?

• Atomicity: all statements in the transaction succeed, or none do.
• Consistency: constraints such as foreign keys and checks hold after the transaction.
• Isolation: concurrent transactions do not see each other’s half-finished work, to a degree set by the isolation level.
• Durability: once committed, the data survives a crash.

Link each letter to a bank transfer: debit and credit must happen together (atomicity), and the balance must not go negative (consistency).

Q8. Explain isolation levels and the problems they prevent.

The exact behaviour of each level differs between database engines, so say “in PostgreSQL” or “in MySQL” if you name a specific one, and only if you have checked its documentation.

Q9. How do you prevent two users booking the last seat?

Model answer. There are three standard options. First, a pessimistic lock: SELECT ... FOR UPDATE on the seat row inside a transaction, so the second request waits. Second, an atomic conditional update such as “set status to booked where id is 7 and status is available”, then check that exactly one row changed. Third, optimistic concurrency with a version column, retrying on conflict. Add that a unique constraint on (show, seat) is the final safety net regardless of application logic.

Q10. What is the N+1 query problem?

Model answer. You run one query for a list of N parents, then one query per parent for its children, giving N+1 queries. In an ORM it hides behind attribute access in a loop. Fix it with a join, eager loading (for example select_related or prefetch_related in Django, or selectinload in SQLAlchemy), or a single batched query using an IN clause.

Q11. When does an index help, and when does it hurt?

Model answer. An index speeds up filters, joins and sorts on the indexed columns, at the cost of extra storage and slower writes. It helps little on low-selectivity columns such as a boolean. For composite indexes, column order matters: put the equality-filtered column first. Back your claim by running EXPLAIN before and after.

Part 3: Caching basics questions and model answers

Q12. What are the main caching strategies?

• Cache-aside: the application checks the cache, falls back to the database on a miss, then fills the cache. It is the most common pattern.
• Write-through: writes go to the cache and database together, keeping them aligned at the cost of write latency.
• Write-back: writes go to the cache first and reach the database later. It is fast but risks data loss on failure.

Q13. How do you handle cache invalidation?

Model answer. The simplest approach is a time-to-live (TTL) so stale data expires on its own. For data that must be fresh, delete or update the key in the same code path that changes the database row. Be candid that there is a window where the cache can be stale, and that you pick the TTL according to how much staleness the business can tolerate.

Q14. What is a cache stampede and how do you reduce it?

Model answer. When a popular key expires, many requests miss at once and all hit the database. Mitigations include a short lock so only one request rebuilds the value, adding random jitter to TTLs so keys do not expire together, and serving slightly stale data while one worker refreshes it.

Q15. What should you never cache carelessly?

Model answer. User-specific or permission-dependent responses cached under a shared key, since one user could see another’s data. Include the user or tenant in the key, or skip caching. Also avoid caching error responses for long periods.

Part 4: Concurrency questions and model answers

Q16. What is the GIL, and how does it affect a Python backend?

Model answer. In standard CPython, the Global Interpreter Lock lets only one thread execute Python bytecode at a time. Threads therefore do not speed up CPU-bound pure Python code, but they work well for I/O-bound work such as network calls, because the lock is released while waiting. For CPU-bound tasks, use multiple processes or move the work to a worker queue. Newer CPython releases have experimental free-threaded builds, so mention that the details depend on version.

Q17. Threads, processes or asyncio?

Q18. What is a race condition? Give a backend example.

Model answer. It is a bug where the result depends on the timing of concurrent operations. Example: two requests read a counter of 10, each add 1 and write 11, so one increment is lost. Fixes include an atomic database update (SET count = count + 1), a lock, or a queue that serialises the operation.

Q19. What is a deadlock and how do you avoid it?

Model answer. Two transactions each hold a lock the other needs, so neither proceeds. Databases usually detect this and abort one. Avoid it by acquiring locks in a consistent order, keeping transactions short, and retrying the aborted one.

Q20. Why use a task queue such as Celery or RQ?

Model answer. Work like sending email or generating a report should not block the HTTP response. The API enqueues a job and returns quickly, and a separate worker process runs it. Mention retries, making jobs idempotent, and a way to check job status.

Part 5: Debugging scenarios with model approaches

Scenario questions test method. A good structure is: reproduce, narrow, form a hypothesis, test it, fix, then prevent a repeat.

Scenario A: An endpoint became slow after a release

1. Confirm the symptom with numbers: which endpoint, what latency, since when.
2. Compare the release diff for new queries, loops or external calls.
3. Check the slow query log and run EXPLAIN on suspect queries.
4. Look for N+1 patterns and missing indexes.
5. Fix, then confirm the latency recovered and add a test or alert.

Scenario B: Intermittent 500 errors under load only

1. Pull logs by request ID and group the exceptions by type.
2. Suspect resource limits first: exhausted database connection pool, file descriptors, or worker timeouts.
3. Suspect shared mutable state, such as a module-level dictionary written by several threads.
4. Reproduce with a small load test in a staging setup.

Scenario C: Users see stale profile data

1. Check whether the response comes from a cache by inspecting headers or the cache key.
2. Check whether the update path invalidates that key.
3. Check for read replicas lagging behind the primary database.

Scenario D: Duplicate orders were created

1. Look for client retries or double clicks reaching the server twice.
2. Check for a missing unique constraint or idempotency key.
3. Check whether the check-then-insert logic runs outside a transaction.

Worked example (illustrative): fixing a lost-update bug

This example is illustrative. It shows the kind of answer you could give at a whiteboard, and the code has not been executed here, so test any version you adapt.

Interviewer prompt: “Our wallet endpoint adds credits. Two simultaneous top-ups sometimes record only one. Why, and how would you fix it?”

Buggy version (illustrative):

def add_credits(user_id, amount):
    wallet = db.get_wallet(user_id)      # read
    wallet.balance = wallet.balance + amount
    db.save(wallet)                       # write

Diagnosis you would say: “Both requests read the same starting balance, say 100. Each computes 150 and 130 respectively, and the last write wins, so one top-up is lost. This is a lost update caused by a read-modify-write cycle without isolation.”

Fix 1, atomic update (illustrative):

UPDATE wallets
SET balance = balance + :amount
WHERE user_id = :user_id;

Fix 2, row lock (illustrative):

BEGIN;
SELECT balance FROM wallets WHERE user_id = :user_id FOR UPDATE;
-- compute in application code
UPDATE wallets SET balance = :new_balance WHERE user_id = :user_id;
COMMIT;

Follow-up you would add: “I would also record each top-up in a ledger table with a unique transaction reference, so that a retried request cannot credit twice. Then I would write a test that fires concurrent requests and asserts the final balance.” Finish by naming the trade-off: the atomic update is simplest and fastest, while the row lock suits cases where business rules must run between the read and the write.

A seven-day revision roadmap

1. Day 1: Python fundamentals that surface in backend rounds: mutable defaults, generators, decorators, context managers, exceptions.
2. Day 2: API design. Build or review a small service and write down your status-code choices.
3. Day 3: SQL joins, grouping, indexes, and one EXPLAIN exercise.
4. Day 4: Transactions and isolation. Reproduce a lost update on a local database.
5. Day 5: Caching with a local Redis or an in-memory dictionary with TTL, and practise stampede answers.
6. Day 6: Concurrency: compare threads, processes and asyncio on a downloading task.
7. Day 7: Mock interview with a friend. Answer five questions aloud, then a debugging scenario.

Building project evidence while you prepare

Answers land better when attached to something you built. A free option is the CareerSwami free two-week online internship, which runs for 14 days and offers a free offer letter and a free completion certificate after successful completion, across 26 tracks. Whatever project you pick, keep a short write-up covering the problem, your design choices, one bug and how you fixed it. That write-up is the raw material for the “tell me about a project” question.

RVCE and the Python backend internship: what the college documents say

RVCE describes itself as an autonomous institution affiliated to VTU, Belagavi, and approved by AICTE, as shown on a 2021 scheme-and-syllabus document for the first two semesters. The college’s PG academic handbook (2018 Scheme) says each department’s Board of Studies plans the scheme and syllabus, and the Academic Council approves it. For a student preparing for a backend internship, this means the rules that count are RVCE’s own documents, not a general rule from this guide.

Timing is the first practical point. The 2018-scheme Information Science and Engineering III and IV semester syllabus notes that the internship is taken in the vacation after the 4th semester. That is a 2020-era document for one branch, so confirm whether your branch and batch follow the same pattern. Interview preparation (API design, transactions, caching, concurrency) is best finished before applications open in that window.

RVCE’s 2022 internship page described a six-week industry-certified internship for 4th-semester students, in blended mode, registered through Centres of Excellence and carrying a fee. That is a past-year offering, so check whether a current equivalent exists. Separately, the PG handbook states a minimum of 6 weeks of internship, a mid-term presentation after 3 weeks, and a final assessment by an internal guide and an external examiner. These are PG rules from 2019-20 and may not apply to you, but they show the likely shape: a duration floor, a mid-point review and a rubric-based assessment. Keep weekly notes and a record of the tasks you complete, such as an API built or a query optimised, so a presentation or report is easy to prepare.

For placement-related questions, the Department of Placement & Training lists the email placement@rvce.edu.in.

Checks before you accept a backend internship

• Ask your department which scheme and admission-year rules apply to you, and read the internship clause in that scheme document.
• Ask whether the internship must fall in the vacation after the 4th semester, or whether other timing is allowed for your branch.
• Ask whether a self-found, remote Python internship is accepted, and what minimum duration (the PG handbook’s 6 weeks is only a reference) applies.
• Ask about the review format: whether a mid-term presentation, an internal guide or an external examiner is involved for UG students.
• Email placement@rvce.edu.in to ask whether an outside internship affects placement registration, and keep the reply.
• Check whether the college’s internship page still lists a current programme, with its fee and registration route.

Common mistakes to avoid in the interview

• Reciting definitions without an example from your own code.
• Saying “I would use microservices” or “I would use Kafka” for a small problem. Start simple and scale on need.
• Ignoring failure cases: what if the call times out, the row is missing, or the request repeats?
• Going silent while debugging. Narrate your hypotheses.
• Claiming skills you cannot explain. Interviewers follow up on every line of your resume.

Frequently Asked Questions

Which Python framework should I learn for a backend internship?

Pick one and know it well. Django suits those who want built-in ORM, authentication and admin. FastAPI and Flask suit lighter services. Interviewers care more about concepts such as routing, validation and database access than about the framework name.

How much SQL do I need for a Python backend internship interview at a company like those RVCE students apply to?

Be comfortable with joins, GROUP BY with HAVING, subqueries, indexes and transactions. Being able to write a query on a whiteboard and explain its cost is usually enough at internship level.

Do I need to know system design as a fresher?

Not deeply. Expect simple prompts such as designing a URL shortener or a rate limiter. Cover API shape, data model, one bottleneck and one caching or queue decision.

Is knowing Redis necessary?

It is not mandatory, but it is a common way to discuss caching. If you have not used it, you can still explain cache-aside and TTL with an in-memory dictionary example.

How should I explain the GIL without confusing myself?

Say that threads help with waiting on I/O but not with heavy CPU work in standard CPython, and that processes or workers handle CPU-bound jobs. Then stop. Add detail only if asked.

What if I cannot solve a debugging scenario?

Describe your method: what you would check first, what data you would collect and how you would narrow it down. A clear process earns more credit than a lucky guess.

Will an online internship certificate alone get me an offer?

No certificate guarantees a job or an offer. It is useful as evidence of work when paired with a project you can explain. CareerSwami’s internship offers no stipend, academic credit or placement.

Can I use an internship from outside college for my RVCE requirements?

That depends on your department’s rules for your batch. Use the verification list above and get the answer in writing before you rely on it.

Related Python & Backend Engineering guides

• BMS College of Engineering Students: Structuring a Python Backend Internship Report
• Ramaiah Institute of Technology Students: Backend Engineering Internship Skills to Build in Python
• PSG College of Technology Students: Python Backend Internship Offers, Red Flags and Questions to Ask
• All Python & Backend Engineering internship guides