Assam Women’s University Students: Building a Backend Internship Study Group That Works

A backend internship study group works when it has a written charter, a fixed daily rhythm, rotating pairs and a shared board that shows who is stuck. For a 14-day internship, three to four members, a 90-minute daily slot and one pull request review habit are enough to turn solo struggling into steady progress. This guide gives you the full charter, the agendas, the rotation and the review template.

Why a 14-day backend internship needs a group, not just motivation

Two weeks is short. A learner working alone can lose an entire day to a virtual environment error, a confusing traceback or a database connection that refuses to open. A group shortens that loss because someone else has often seen the same error, and explaining your problem aloud frequently solves it before anyone replies.

A group also fixes a quieter problem: backend work is invisible. A frontend page can be shown in a screenshot, but an API that validates input and returns clean errors looks like nothing until someone reads the code. Regular review gives your work an audience, and an audience raises quality.

The free two-week online internship from CareerSwami offers a free offer letter and a free completion certificate after successful completion, across 26 tracks. If you pick a Python or backend-oriented track, the plan below fits inside those 14 days. Treat it as a structure you bring to the work, not as part of the programme itself.

The study-group charter for a Python backend internship (copy and fill in)

A charter is a one-page agreement. Writing it on day zero prevents the usual collapse where two people do everything and two disappear. Paste the template below into a shared document and have every member type their name under it.

STUDY GROUP CHARTER
Group name:
Members (3-4):
Internship track each member is following:
Start date / end date (14 days):

1. PURPOSE
We will finish one small Python backend project each and review each other's code.

2. MEETING RHYTHM
Daily call: ____ to ____ (max 90 minutes), on ______ (Meet / Zoom / WhatsApp call)
Async check-in by ____ pm on a shared board

3. ROLES (rotate every 3 days)
Facilitator: keeps time, runs the agenda
Scribe: updates the progress board
Reviewer-on-duty: first reader of any pull request

4. RULES
- Attend or post an async update before the meeting.
- Ask for help after 30 minutes stuck, not after 3 hours.
- Never paste someone's solution as your own; explain it in your words.
- Reviews are kind, specific and about the code.
- Secrets (passwords, API keys, .env files) are never shared in chat or committed.

5. IF SOMEONE FALLS BEHIND
Pair with them next day; no blame.

6. CLOSE-OUT
Day 14: demo, retrospective, list of next steps.

Signed: ____________

Choosing group size and meeting time

• Three or four members is the practical range. Two is fragile if one person is absent; five or more makes pairing awkward.
• Same time every day beats a flexible schedule. Pick a slot after classes or hostel study hours and protect it.
• Mixed experience is fine. The learner who just got a route working often explains it better than the expert.
• One shared language of work: agree on Python version, a framework (Flask or FastAPI are common beginner choices) and one editor setup, so debugging help transfers.

The 14-day agenda: what the group does each day

The table below is a suggested sequence, not a syllabus. Your internship track will set the actual tasks, so adjust topics to match them. The point is that every day has a group goal and a visible output.

A repeatable 90-minute daily meeting

1. Minutes 0-10: stand-up. Each member answers three questions: what I finished, what I am doing today, where I am stuck.
2. Minutes 10-60: pair-programming block. Pairs work together on today’s focus using the rotation below.
3. Minutes 60-80: solo or review time. Finish code or read a teammate’s pull request.
4. Minutes 80-90: wrap-up. The scribe updates the board and notes tomorrow’s blockers.

Pair-programming rotation for three and four members

In pair programming one person is the driver (types) and the other is the navigator (reads, thinks, spots mistakes). Swap roles every 15 minutes. Rotate partners so everyone sees everyone else’s habits.

Rules that make pairing useful

• The navigator does not grab the keyboard. They ask questions such as “what should this return if the list is empty?”
• If the driver is silent for five minutes, the navigator asks them to say what they are trying.
• Pair on the hard part of the day, not on typing boilerplate.
• Each pair writes one sentence in the board about what they learned.

The shared progress board: columns, cards and a weekly check

Use any free board tool, or a simple shared spreadsheet. What matters is that every member can see every card. Use these columns: Backlog, Doing, Stuck, In Review, Done. The “Stuck” column is the most important one; it makes asking for help normal.

Two checkpoints instead of a “weekly meeting”

A 14-day internship has two weeks, so run two checkpoints: end of Day 7 and end of Day 14. At each, count cards in Done per member, list what is still in Stuck, and decide what to cut. Cutting scope on Day 7 is a sign of good judgement, not failure.

A pull request review template your group can reuse

Pull requests are how professional backend teams discuss code. Even if your group is small, practising the habit is valuable. Keep pull requests small: one feature, under about 150 changed lines where possible.

The author’s description template

## What this PR does
(One or two sentences)

## How to run it
(Commands, e.g. install, start server, sample request)

## What I tested
(Manual steps or pytest names)

## Where I want feedback
(One or two specific questions)

## Checklist
- [ ] No passwords or keys committed
- [ ] README updated if setup changed
- [ ] Tests pass locally

The reviewer’s comment template

Summary: (one sentence on what I understood)
Must fix: (bugs, security, broken behaviour)
Should consider: (naming, structure, readability)
Question: (things I do not understand)
Nice work: (one specific thing done well)

Reviewer checklist for Python backend code

Review etiquette

• Comment on the code, never the person.
• Give a reason with each request: “Please validate age, because a negative number will be saved otherwise.”
• Respond to reviews within 24 hours, even if only to say “will fix tomorrow”.
• The author decides how to fix; the reviewer does not rewrite their code.

Worked illustration: one pull request moving through the group

This example is illustrative. The names and code are invented to show the process; nothing here was run or tested.

Suppose Member A builds a small notes API and opens a pull request titled “Add create-note endpoint”. Her description follows the template. The relevant snippet looks like this:

@app.post("/notes")
def create_note(data: dict):
    notes.append({"id": len(notes) + 1, "text": data["text"]})
    return {"status": "ok"}

Member B, the reviewer-on-duty, writes:

Summary: Adds a POST route that stores a note in a list.
Must fix: If "text" is missing, data["text"] will raise an error and the client sees a server crash. Please return a 400 with a message.
Should consider: Using len(notes)+1 for ids can repeat an id after a delete. A counter or database id is safer.
Question: Should an empty string count as a valid note?
Nice work: The route name and the PR description made this very easy to follow.

Member A fixes the missing-field case, adds a test for it, and replies on the thread. On the board, the card moves from “In Review” to “Done” only after Member B ticks the checklist. The whole exchange takes perhaps twenty minutes and teaches both members something about error handling.

Assam Women’s University: using the placement page and your own structure to support a backend internship

Most of what a student needs from the university for an internship is a clear rule: can it count toward anything, who must approve it, and what proof is needed. That information is not something this guide could confirm, so treat the points below as things to check rather than assumptions.

What is verifiable: the AWU Placement Cell page says the university has a Placement Cell that offers career assistance, training programmes and internship arrangements for students. The same page says the Department of Business Management has its own Placement Cell and names Dr. Kaushik Handique, Assistant Professor, as Placement Coordinator. The page describes the university as NAAC accredited but gives no grade or year. It shows a recruiters logo section and a Facebook group link, yet names no recruiters in text and gives no placement statistics, so do not treat it as evidence of any particular hiring outcome.

What this means for a study group: the Placement Cell is the natural first contact if you want your 14-day internship noted by the university, or if you want guidance on how to present a finished backend project. The Business Management department’s separate cell suggests that departments may handle some arrangements themselves, so a student from another department should ask which office applies to her. Rules on internship duration, credit, evaluation and online internships were not available to confirm, so do not assume this internship counts for anything academically. Your certificate from the free CareerSwami internship is proof of completion of that programme, nothing more.

A practical benefit of the group is shared effort in asking. One message drafted together and sent from several students is easier to answer than four separate vague queries.

Verification steps for AWU students

1. Visit the Placement Cell page linked above and note the listed contact routes; email or visit the cell and ask whether an online internship taken independently can be recorded or acknowledged.
2. Ask your own department office, in writing, whether your programme has an internship or project regulation, and request the document name or notice number.
3. Ask your Head of Department or class coordinator whether any approval or permission letter is needed before starting an external internship.
4. Ask whether a completion certificate from an online internship is accepted as proof for any departmental record, and in what format.
5. Check your semester timetable or the academic notice board for exam and holiday dates, and choose your 14 days so they avoid exam weeks.
6. Keep every reply as an email or screenshot in a shared folder in case anyone asks later.

Handling common group problems in a short internship

Day 14 close-out: retrospective and portfolio

End with a 30-minute retrospective. Each person answers: what did I learn, what slowed me down, what will I do next week? Then do a portfolio pass:

• Give each repository a clear name and a README with setup steps and example requests.
• Remove secrets and check the commit history for accidentally committed keys.
• Pin dependencies in a requirements file.
• Write two or three honest lines about what the project does and what you would improve.
• Keep the group going: choose a next small project and meet twice a week.

Frequently Asked Questions

How many people should be in a backend study group?

Three or four is ideal. It allows rotating pairs, keeps meetings short and still works if one person is absent.

Can we run the group if we are on different internship tracks?

Yes. The standup, pairing and review routines do not depend on a shared project. Review is still useful when the reviewer is less familiar with the exact task, because unclear code becomes obvious.

How much Python should we know before starting?

Basic syntax, functions, lists and dictionaries are enough. The Day 2 session is meant to close small gaps, and the group can slow down for anyone who needs it.

Do we need GitHub for pull requests?

A hosted Git service is the easiest way to practise real pull requests. If access is a problem, you can share branches or patch files and still use the same review template in a document.

Will this internship count for credit or placement at AWU?

That cannot be assumed. The CareerSwami internship offers a free offer letter and completion certificate, not credit or jobs. Ask your department and the Placement Cell in writing whether any record or recognition is possible.

What if we only have 60 minutes a day?

Shorten the pair block to 30 minutes, keep a 10-minute standup and move reviews to asynchronous comments. Reduce project scope rather than skipping testing and review.

How do we stop one person from dominating?

Rotate the facilitator role, keep the driver and navigator swap every 15 minutes and have each member present their own code at standup.

What should we do if we cannot fix a bug in 30 minutes?

Move the card to Stuck, paste the full error message and what you tried, and ask the group. Writing it clearly often exposes the cause before anyone replies.

Related Python & Backend Engineering guides

• Noble University Students: Background Tasks and Queues Explained for Backend Interns
• Sushant University Students: Writing the Final Backend Internship Report Without Padding
• The Glocal University Students: Handling Feedback and Rework in a Backend Internship
• All Python & Backend Engineering internship guides