Making group projects work in an online cohort

Write a one-page working agreement in the first meeting

Spend 30 minutes of the first call on this, write it in the repository's README or a shared document, and have everyone reply "agreed". It feels formal. It is what you will point to in week three.

Project:        Support-ticket triage service (cohort project, synthetic data)
Deadline:       Demo on <date>; code freeze two days before
Check-in:       Written update in the group channel by 10 pm, Mon/Wed/Fri
Sync call:      Sunday 8:00-8:45 pm, video optional, agenda in the channel first
Response time:  Reply to direct questions within 24 hours, or say when you can
Code:           No direct pushes to main; every change through a pull request
Reviews:        Every PR reviewed by one other person within 48 hours
Unavailable?:   Tell the group as soon as you know, with the dates
If silent:      After 2 missed check-ins, the task can be reassigned (see ladder)

Keep it to one page. A longer document is one nobody reads.

Split roles by component, not by activity

The common mistake is splitting by activity — "you do the research, you do the coding, you do the slides." That leaves the coder carrying the project and the others unable to explain it in an interview. Split by component instead, so each person builds and can defend one part end to end.

For a four-person FDE-style project, such as a small service that classifies support tickets and routes them:

Each person writes the part of the README for their component. Everyone reviews at least one other component's pull requests, which is how each member learns the whole system well enough to answer questions about it.

A Git routine that avoids merge chaos

Remote teams lose days to overwritten work. A simple branch-and-pull-request routine prevents most of it:

git switch main
git pull                             # start from the latest main
git switch -c ingest-validate-dates  # one branch per small task
# ... make changes, run tests ...
git add src/ingest.py tests/test_ingest.py
git commit -m "Reject tickets with unparseable created_at dates"
git push -u origin ingest-validate-dates
# open a pull request; a teammate reviews and merges

Three rules make this work:

1. 1Small branches. A pull request that changes 40 lines gets reviewed the same day; one that changes 800 sits for a week.
2. 2Pull main before starting each task, so you build on your teammates' latest work.
3. 3Commit messages say what changed and why, not "update" or "fixed". These messages become your evidence of contribution later.

If Git is new to you, the free Pro Git book covers branching in its early chapters.

Written check-ins beat long calls

With members on different shifts and commitments, a 90-minute weekly call is hard to schedule and easy to miss. Short written updates three times a week keep everyone informed without requiring the same free hour:

Done: date validation merged (PR #12). Next: handle empty ticket bodies. Blocked: need B's label list to finish the test fixture.

Three lines: done, next, blocked. The "blocked" line is where most of the value is, because it tells a teammate precisely what to unblock.

Keep one short sync call a week for decisions that need discussion, and post the agenda beforehand so it stays short.

The escalation ladder for a silent teammate

Agree on this in the first meeting, before anyone is upset, so applying it later is not personal.

The tone throughout is about the task, not the person. People go quiet for reasons that are often serious — a family emergency, a job crisis — and a factual message makes it easy for them to return.

Getting individual credit from shared work

When you talk about a group project in an interview, the interviewer is trying to find out what you did. Prepare by listing:

• The component you owned and the two or three decisions you made in it.
• One problem you hit and how you fixed it.
• One thing you reviewed in a teammate's work and what you caught.

Your commit history and pull requests support this. On the repository, git log --author="Your Name" --oneline shows your commits. Describe the team honestly as a team: "four of us built it; I owned the ingestion and validation layer."

Group work is part of forward deployed engineering practice, because client delivery rarely happens alone. The FDE for Freshers programme includes client-simulation work — a mock discovery session and demo with a mentor playing the client — taught live online with optional in-person labs at our Noida centre. For how a finished project should hold up to questioning, see what an FDE capstone should prove.