Lovely Professional University Students: Data Science Internship Portfolio and Project Guide

A strong data science internship portfolio for an LPU student is one project, documented so that a stranger can rerun it and understand it. It needs four parts: a reproducible notebook, a data-cleaning log, a fair model comparison and a results summary written for a non-technical reader. This guide gives a template for each part, a worked illustrative example and a checklist you can score yourself against.

Why the documentation matters more than the model

Most students submit the same project: a Titanic, house-price or churn dataset, a random forest and an accuracy number. A reviewer who has seen fifty of these cannot tell your work from the rest. What separates them is evidence of judgement. Did you notice that the target leaked into a feature? Did you record why you dropped 12% of the rows? Did you compare the model against a trivial baseline? Did you say what the result means in plain words?

The four-part structure below is built to show that judgement. Each part answers a question a reviewer is likely to ask:

• Reproducible notebook: can I run this and get the same numbers?
• Data-cleaning log: what did you change in the data, and why?
• Model comparison: did you test the choice fairly, or just pick one?
• Plain-language summary: can a manager or faculty member who does not code understand the finding and its limits?

LPU and a data science internship portfolio: what to check first

Lovely Professional University describes itself, on its official about page, as a private university in Chaheru, Phagwara, Punjab. The same page lists UGC among its approving bodies and gives a timeline with establishment in 2005 and UGC recognition in 2006. For a data science portfolio this matters mainly as background. The documents you produce (notebook, cleaning log, model comparison, results summary) will be read by an LPU faculty member or an outside recruiter who wants to see exactly what you did, so dated and reproducible records are your strongest asset.

The site navigation under Academics, visible on the same about page, lists Industry Immersion, Live Projects, Academic Calendar and Holiday List pages. The navigation also links to a university placements page. These are links only; what they say about duration, eligibility, credits, documents or evaluation should be read directly on those pages, and nothing about them should be assumed. If your project is meant to count as a Live Project or Industry Immersion activity, find out early whether it has to be approved before you begin, since an unapproved project may not be accepted afterwards.

Rules for internships, training and project submissions can differ by programme, school and batch. Treat anything heard from seniors as a lead until it is confirmed in writing. Keep the project folder adaptable so the same work can become a college report, a GitHub repository and a one-page résumé entry, and keep a dated daily record in case a log or diary is requested.

Questions to settle in writing before you start the portfolio

• Open the Live Projects and Industry Immersion pages on lpu.in and note any stated eligibility, duration and submission steps for your programme.
• Ask your faculty coordinator or school office whether a self-built data science portfolio can count toward any project or training requirement, and request the answer by email.
• Check the Academic Calendar and Holiday List pages for your batch to plan the 14-day build around term breaks and exams.
• Ask which report format, if any, is required: file type, mentor sign-off, plagiarism or dataset-source declarations.
• Confirm whether datasets must be public or whether company data needs a permission letter, and keep that letter with your documentation.
• Visit the placements page and ask the relevant office what they expect from a student portfolio before you use it in applications.

The portfolio template at a glance

Use this folder structure for your repository. It is a suggested layout, not a university requirement.

project-name/
  README.md              # one-page overview and how to run
  environment.yml        # or requirements.txt with pinned versions
  data/
    raw/                 # untouched original files (never edit)
    processed/           # outputs of your cleaning code
  notebooks/
    01_exploration.ipynb
    02_cleaning.ipynb
    03_modelling.ipynb
  reports/
    cleaning_log.md
    model_comparison.md
    results_summary.md
  src/                   # reusable functions, if any

Keep raw data read-only. If the dataset is too large or has licence limits, store a download script and a checksum or row count instead of the file itself, and state the source and licence in the README.

Part 1: The reproducible notebook

Reproducible means another person can clone the repository, install the environment and reach the same tables and charts. A notebook that only works on your laptop, in the order you happened to run the cells, is not reproducible.

Reproducibility checklist

1. Pin library versions in environment.yml or requirements.txt, and record the Python version.
2. Set a random seed once at the top and pass it to every splitter and model that accepts one.
3. Load data with relative paths only. No C:\Users\... paths.
4. Split train and test data before any fitting step, including scaling, imputation and encoding.
5. Restart the kernel and run all cells top to bottom before every commit. If it fails, fix it.
6. Put a short markdown cell before each code block stating its purpose in one sentence.
7. End the notebook with a conclusion cell that matches the numbers actually printed above it.
8. Add a README section titled “How to run” with exact commands.

Notebook header template

# Project title
Author: your name | Date: DD-MM-YYYY
Question: one sentence, e.g. "Which customers are likely to cancel next month?"
Data: source, licence, rows x columns, date downloaded
Target: column name and definition
Metric: the number you will judge success by, and why
Seed: 42

Choose the metric before modelling. If cancellations are rare, accuracy is a poor choice because a model that predicts “no cancellation” every time scores high. Precision, recall, F1 or PR-AUC will say more.

Part 2: The data-cleaning log

A cleaning log is a table of every change you made to the raw data. It is the most underused part of student portfolios and one of the most persuasive. Each row records what you found, what you did, how many rows or values it affected, and the reason.

Cleaning log template

Fill the “rows affected” column from your code output, not from memory. A good habit is to print the row count after each step and paste it into the log.

Rules for a defensible log

• Never overwrite raw files. All changes happen in code that reads raw and writes processed.
• Log decisions you rejected as well. “Considered dropping rows with missing income; rejected because it would remove a large share of one region” shows reasoning.
• Separate cleaning that is safe before splitting (fixing typos, removing exact duplicates) from cleaning that learns from data (imputation, scaling), which belongs inside a pipeline fitted on training data only.

Part 3: The model comparison

A comparison is fair when every model sees the same split, the same features and the same metric, and when a simple baseline is included. Three to five candidates are enough.

Model comparison scorecard

Comparison rules

1. Use cross-validation on the training set to choose models and settings. Touch the test set once, at the end.
2. Report the spread (standard deviation) across folds. A 1-point gain smaller than the spread is noise.
3. Use stratified splits for imbalanced classes, and time-based splits for data that has a time order.
4. Look beyond one number: a confusion matrix, a calibration plot or error analysis by subgroup tells you where the model fails.
5. State the winner and the trade-off. A slightly weaker model that a manager can understand is sometimes the better choice, and saying so is a mark of maturity.

Part 4: The plain-language results summary

This is one page, written for someone who does not code. Avoid terms such as “hyperparameter” or “F1” unless you explain them in the same sentence.

Summary template

1. The question: one sentence in everyday language.
2. The data: where it came from, how many records, and the period it covers.
3. What was found: two or three findings, each with one number and one sentence of meaning.
4. How good the predictions are: compare against the baseline in words, for example “correct in X of every 10 cases, against Y of 10 for guessing the most common answer.”
5. Where it fails: the groups or situations where the model is weaker.
6. Limits: data age, missing groups, possible bias, and what was not tested.
7. Suggested next step: one realistic action or experiment.

Avoid claims about real-world impact that your data cannot support. A student project can show a method working on a dataset. It cannot show that a business would save money.

Worked example: data science internship portfolio (illustrative)

The following is an invented walk-through to show how the parts connect. The dataset, figures and findings are made up for teaching, and no code or tests were run for this article.

Project: predicting whether a subscription customer cancels within 30 days, using a public-style customer table with about 7,000 rows.

1. Question and metric. Roughly one customer in four cancels in this imagined dataset, so accuracy would mislead. The chosen metric is recall at a fixed precision, with PR-AUC as the headline number.
2. Cleaning log entries. The log records that a “total charges” column was stored as text because some blanks were spaces; the blanks were converted to missing and imputed inside the pipeline. It also records that a “cancellation reason” column existed only for customers who had already left, so it was removed as leakage.
3. Split. An 80/20 stratified split with seed 42. Cross-validation runs on the 80% only.
4. Comparison. A majority-class baseline, logistic regression, and gradient boosting are compared. In this imagined outcome, boosting beats logistic regression by a margin smaller than the fold-to-fold spread. The write-up therefore recommends logistic regression, because its coefficients can be explained and the performance difference is not reliable.
5. Plain-language summary. “Customers on month-to-month plans with short tenure were the most likely to leave in this data. The model finds most of them but also flags many who stay, so it suits a low-cost reminder, not an expensive discount. The data covers a single period and may not hold for other seasons.”

Notice what makes this example credible: a reasoned metric, a leakage catch, a spread-aware comparison and a limit stated openly.

Self-scoring rubric for your portfolio

Score each row from 0 to 2 (0 = missing, 1 = partial, 2 = complete). A total of 16 or more suggests the project is ready to share.

A 14-day schedule for building it

If you are working within a short internship window, a compact plan keeps the scope realistic. A free two-week online internship such as the CareerSwami free two-week internship, which offers an offer letter and a completion certificate after successful completion across 26 tracks, is one place to practise this workflow. Whatever programme you use, the schedule below fits a 14-day span.

• Days 1-2: pick the dataset, write the question and metric, create the repository and environment.
• Days 3-4: exploration notebook; start the cleaning log with every anomaly you spot.
• Days 5-6: cleaning code, pipeline, leakage review, train-test split.
• Days 7-9: baseline and candidate models with cross-validation.
• Days 10-11: tuning, final test evaluation, error analysis.
• Days 12-13: results summary, README, restart-and-run-all check.
• Day 14: ask a friend to follow your README cold, fix what breaks, then publish.

Presenting the project on a résumé and in interviews

Write the résumé entry as a method and a result, with no inflated claims. For example: “Built a customer-cancellation classifier on a public dataset; documented cleaning decisions, compared three models with cross-validation, and wrote a non-technical summary. Repository linked.” Link the repository, not a screenshot.

Prepare for these interview questions about your own project:

• Why did you pick that metric?
• What would you do if the test score was much lower than the cross-validation score?
• Which cleaning decision changed the results most?
• What does your model get wrong, and for whom?
• How would you deploy or monitor it, even in outline?

Data science portfolio mistakes that weaken an LPU student’s project

• Scaling or imputing before splitting. This lets test information leak into training.
• Reporting only the best run. Report the procedure, including the runs that did not work.
• Copying a tutorial wholesale. If you adapt one, say so, and change the question, features or evaluation so the work is yours.
• Hiding uncertainty. A confidence range or a plain limits paragraph increases trust.
• Committing sensitive data. Do not publish personal data or any dataset whose licence forbids redistribution.
• Overloading the repository. One finished project beats five half-done ones.

Questions to settle in writing before you start the portfolio

These items depend on your programme and batch. Ask in writing (an email to the relevant coordinator or a note on the department’s official portal) and keep the reply.

• Does an external online internship count towards any requirement in my programme, or is it purely extra-curricular? Ask for the relevant rule document or circular.
• If a project or training report is required, what format, template, word limit and submission deadline apply, and who evaluates it?
• Is a faculty mentor or an industry mentor needed, and does a certificate need to come from a particular type of organisation?
• Are there rules on using public datasets, publishing code online, or naming the university in a repository?
• Does the training or placement cell run any related sessions or verification of internship documents, and how should certificates be submitted to it?
• Which course in my curriculum covers data science tools, so I can align my portfolio with what I am assessed on?

Frequently Asked Questions

How many projects should a student portfolio contain?

One thoroughly documented project is better than several thin ones. If time allows, add a second project that uses a different data type, such as text or time series, so that your range is visible.

Can I use a Kaggle or other public dataset?

Yes, as long as you check the licence, cite the source and make the question your own. Reviewers see the same famous datasets often, so a clear question and strong documentation matter more than novelty.

Should I use Jupyter notebooks or Python scripts?

Both work. Notebooks suit exploration and narrative; scripts or a src folder suit reusable cleaning and training code. A common pattern is notebooks for the story and functions imported from src for the logic.

Do I need deep learning to impress?

No. For tabular data, a well-evaluated linear model or gradient-boosted trees, with honest comparison and clear explanation, is usually more convincing than an unexplained neural network.

How do I make the notebook reproducible if the data is too big for GitHub?

Keep a download script, record the source URL, date and row count, and add a checksum if the file does not change. Provide a small sample in the repository so reviewers can run the pipeline quickly.

What should I write when my model barely beats the baseline?

Report it as a finding. Explain what you tried, which features seemed weak, and what extra data might help. An honest weak result with clear analysis shows more skill than an inflated strong one.

Does an online internship certificate replace a project in my college submission?

That depends on your programme’s rules, which this guide cannot state for you. Ask your coordinator in writing, and use the verification list above to frame the question.

How long should the plain-language summary be?

One page, roughly 250 to 400 words, with one or two charts at most. If a non-technical reader cannot state the main finding after reading it, shorten it and cut the jargon.

Related Data Science guides

• RV College of Engineering Students: Data Science Internship Prerequisites in Math, Python and Statistics
• BMS College of Engineering Students: Preparing for Data Science Internship Interviews
• Ramaiah Institute of Technology Students: Choosing a Data Science Internship Project
• All Data Science internship guides