Make a college minor project interview-ready in two weekends

Day 1 (Saturday): can you still run it?

Most minor projects were last run the night before submission. Start there.

• Fresh clone test (1 hour). Clone your own repository into a new folder, create a fresh virtual environment, install requirements and run it. Note every error. Missing packages, hardcoded paths such as C:/Users/yourname/Desktop/data.csv, and notebooks that only work when cells run out of order are the usual failures.
• Fix paths and versions (2 hours). Use relative paths, write a requirements.txt with versions, and make the notebook run top to bottom with "Restart and run all".
• Record the real numbers (1 hour). Whatever your report says, the interview is about what the code produces today. Write them down.

If your numbers differ from the submitted report, do not hide it. Either find why (a random seed, a different data version) or state the new numbers and the reason.

Day 2 (Sunday): add the comparison you skipped

Interviewers ask "compared to what?" more than any other question. Add one baseline:

Then write one sentence: "The model's F1 is 0.71 against 0.00 for the majority-class baseline" or "error fell from ₹4,200 to ₹3,100 per prediction". If the model barely beats the baseline, say that plainly — it is a better interview answer than pretending it does not matter.

A script that keeps your numbers honest

Once you have final numbers, check that the code still produces them. This self-contained example trains nothing heavy; it uses a synthetic dataset, a fixed seed, a baseline and a simple threshold rule, then asserts that the numbers you wrote in your README still match what the code produces. Only the standard library is needed.

import random

random.seed(42)                      # fixed seed: same data every run

# Synthetic attendance (%) and pass/fail labels
students = []
for _ in range(200):
    attendance = random.randint(40, 100)
    p_pass = 0.2 + 0.7 * (attendance - 40) / 60
    students.append((attendance, 1 if random.random() < p_pass else 0))

train, test = students[:150], students[150:]

def accuracy(rule, rows):
    return sum(rule(a) == y for a, y in rows) / len(rows)

majority = 1 if sum(y for _, y in train) >= len(train) / 2 else 0
baseline = accuracy(lambda a: majority, test)

best_cut = max(range(40, 101), key=lambda c: accuracy(lambda a: int(a >= c), train))
model = accuracy(lambda a: int(a >= best_cut), test)

print(f"majority class = {majority}, baseline accuracy = {baseline:.2f}")
print(f"threshold = {best_cut}, model accuracy = {model:.2f}")

# The numbers written in the README after the final run; the check fails if code or data drift.
README_NUMBERS = {"baseline": 0.52, "model": 0.70}
assert round(baseline, 2) == README_NUMBERS["baseline"], "baseline changed"
assert round(model, 2) == README_NUMBERS["model"], "model result changed"
print("README numbers still match")

On this synthetic data the script prints a baseline accuracy of 0.52, a threshold of 54% attendance and a model accuracy of 0.70, then confirms the README numbers. In your own project, put your README's figures in README_NUMBERS. If a later change moves a result, the assertion fails and you find out before the interviewer does.

Day 3 (next Saturday): rewrite the README

A README that makes an interviewer's first two minutes easy earns you better questions. Use this order:

1. 1One-line problem: who would use this and for what decision.
2. 2Result: your main metric against the baseline, in one sentence.
3. 3Data: source, size, date range, whether any of it is synthetic, and any consent or licence note.
4. 4How to run: three to five commands, copied from your fresh-clone test.
5. 5What I would do next: two honest limitations and one improvement.
6. 6What I did myself: if it was a group project, say which parts were yours.

Point 6 matters. Interviewers ask about group projects specifically to find out which part you can explain. Claiming the whole project and then failing a question on the part you did not build is the most common way a good project hurts a candidate.

Day 4 (next Sunday): rehearse six questions

Say the answers aloud, timed, without notes.

Record yourself on your phone once. Listen for filler phrases and for any claim you could not back with a number.

What not to do in these two weekends

• Do not swap in a bigger model to look impressive. A change you cannot explain is a liability.
• Do not delete the original submission; tag it (for example git tag submitted-version) and work on a branch, so you can show both.
• Do not add a tool to the resume line that the project does not use.

For a final-year project still being planned, the full 100-point rubric is the longer version of this checklist. Once the project is ready, the free skill check shows how your resume reads against data job descriptions. Defending a project under questioning is practised in every review in the Data Science programme.