Thiagarajar College of Engineering (TCE) students can showcase AI internship work by publishing one page per project. Each page should state the problem, the data, the metrics, an honest error analysis and a way to rerun the code. A reviewer should be able to judge your work in about five minutes without messaging you.
This guide gives you a page template, a self-scoring table, a worked illustrative example, and a list of things to confirm with your department before you publish anything under the college’s name.
Why the portfolio page matters more than the certificate
A certificate says you took part. A portfolio page shows what you can do. Recruiters, faculty guides and postgraduate admission panels rarely read a whole repository. They skim the top of a page, open one notebook, and look for signs of care: a clear question, a baseline, numbers that make sense, and an admission of what failed.
Short internships produce small projects, and that is fine. A tight, well-documented classifier on a modest dataset beats a sprawling project with no explanation. Reviewers cannot tell if a large project is yours or how it works. They can tell if a small one is rigorous.
Treat each project as a short technical report with runnable code attached. The sections below show how to build it.
TCE’s internship credit rules and what they mean for your AI portfolio page
TCE’s B.E./B.Tech. Regulations (CBCS 2022-23) were approved by the college’s own 63rd Academic Council on 25.06.2022. The same document says every student must do an internship in an industry or at the institution, and that two weeks equal 1 credit. It is a 2022 document, so check the version that applies to your batch.
For a portfolio, the useful point is that an internship is evaluated as well as completed. The regulations state that a faculty team nominated by the Head of Department evaluates the internship report and awards a grade and credit. The Controller of Examinations shows this in the mark sheet. The page you build for public viewing is therefore a separate piece of writing from the report. Keep the report’s content (problem, data, approach, metrics, your role) consistent with the portfolio page, and do not publish material the report treats as confidential.
The same regulations require 3 credits (6 weeks) of internship for the degree, and these credits are not counted in GPA/CGPA. A student who completes 3 further credits (6 weeks in one organisation) beyond that minimum may drop one Programme Elective course. If your AI project came from a longer placement, record the weeks and the organisation accurately on the page, since credit depends on that.
The regulations allow NPTEL and institution-run online courses for credit (4 weeks = 1, 8 weeks = 2, 12 weeks = 3 credits). The text reviewed has no clause on online internships, so do not assume a virtual AI internship counts towards the internship requirement. Ask first.
TCE also publishes B.E. CSE curriculum and syllabus PDFs, and the 2024-25 one includes an internship component. Use the syllabus to tie each project to the course it supports. The Career Development Centre contact page lists placement@tce.edu and phone +91 452 2482240-2 for placement queries.
None of these pages sets a portfolio format or rules for posting project work publicly. They do not mention CareerSwami, which is an independent guide.
Questions to settle before your AI project goes public
- Ask your internship coordinator or Head of Department’s office whether your batch follows the 2022 regulations, and how many weeks and credits apply to you.
- Ask whether an online or remote AI internship is accepted for the internship requirement, and get the answer in writing.
- Find out which documents the evaluating faculty team expects with the internship report, such as an offer letter or completion certificate.
- Get written permission from the host organisation, and from any supervising faculty member, before naming them, the college or any dataset.
- Check your department’s syllabus PDF to see where the internship sits and which course your project can be linked to.
- Write to the Career Development Centre if you want to know how placement staff view portfolio links.
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
The anatomy of a strong AI portfolio page
Use the same structure for every project. Consistency helps reviewers compare projects quickly, and it stops you from skipping the parts that are uncomfortable to write, especially error analysis.
1. Title and one-line outcome
Give the task and the result in one line. Example: “Classifying support tickets into five categories; macro-F1 0.81 against a 0.62 keyword baseline.” If you do not have a number yet, you are not ready to publish.
2. Problem statement
Write three to five sentences covering who needs the output, what decision it supports, and what a wrong prediction costs. Say what counts as success before you show results. A problem statement that reads like a tutorial title (“Using BERT for text”) shows that the project started from the tool and not from a problem.
3. Data
Give the source, licence, size, class balance, how you split it, and any cleaning. State whether personal or confidential data was involved and how you handled it. Never publish data you do not have the right to share. Link to the public source instead.
4. Approach
Describe the baseline first, then the model you chose and why. Include a small diagram or a numbered list of the pipeline steps. Mention the main hyperparameters and anything you tried that did not work.
5. Metrics
Pick metrics that match the problem. Accuracy alone misleads on imbalanced data. Report the metric on a held-out test set that you did not use for tuning, and say how many runs or seeds you averaged.
6. Error analysis
This section separates a working student from a tutorial follower. Look at wrong predictions, group them into categories, count them, and say what you would do about each.
7. Reproducibility
Provide pinned dependencies, a fixed random seed, a single command to train and a single command to evaluate. Say how long it takes and on what hardware.
8. Limitations and next steps
List what the project does not show, what could break it in use, and what you would do with another two weeks.
9. Your role and attribution
State what you built yourself, what came from a template or library, and who guided you. Be exact. Do not present supervised or templated work as fully independent.
The portfolio page template (copy and fill in)
Paste this into the README of the repository, or into a page on your portfolio site. The brackets are placeholders.
# [Project title]: [task] with [headline metric]
## Summary
One sentence on the task, one on the result, one on the main limitation.
## Problem statement
- Who needs this output: [user]
- Decision it supports: [decision]
- Cost of a wrong prediction: [false positive cost / false negative cost]
- Success criterion set before experiments: [e.g., macro-F1 >= 0.75]
## Data
- Source and licence: [link]
- Size: [rows / images / documents]
- Class balance: [counts]
- Split: [train/validation/test, how, seed]
- Cleaning steps: [list]
- Sensitive data: [none / handled by ...]
## Approach
- Baseline: [model, score]
- Main model: [model, why]
- Key settings: [learning rate, epochs, features]
- Things tried that did not help: [list]
## Results
| Model | Metric 1 | Metric 2 | Notes |
|---|---|---|---|
| Baseline | | | |
| Main model | | | |
## Error analysis
- Confusion matrix or per-class table
- Top 3 error categories with counts and 2 examples each
- Planned fix for each category
## Reproduce
- Environment: [python version, requirements file]
- Train: [one command]
- Evaluate: [one command]
- Expected runtime and hardware: [details]
- Expected output: [metric values within a small tolerance]
## Limitations and next steps
- [list]
## My role and acknowledgements
- Built by me: [list]
- Used from others: [libraries, templates, datasets]
- Guidance: [name, with permission]
The portfolio scorecard
Score each project before you publish it. Give 0 for absent, 1 for partial and 2 for complete. A total of 16 or more out of 20 is a strong page. Below 12 means the page needs work before you share it.
| Criterion | 0 points | 1 point | 2 points |
|---|---|---|---|
| Problem statement | Names a tool only | Names a task | Names user, decision, cost of errors and success criterion |
| Data description | Dataset name only | Source and size | Source, licence, balance, split method and cleaning |
| Baseline | None | Mentioned, no score | Simple baseline with a score in the results table |
| Metric choice | Accuracy only on imbalanced data | Suitable metric, one run | Suitable metrics, held-out test set, several seeds or a spread reported |
| Error analysis | Absent | Confusion matrix without comment | Categorised, counted errors with proposed fixes |
| Reproducibility | Notebook only, no environment | Requirements file | Pinned environment, seed, one-command train and evaluate |
| Honesty about limits | Not mentioned | Generic limitations | Specific limits tied to evidence |
| Attribution | Unclear what is yours | Credits listed | Clear split of your work, borrowed work and guidance |
| Readability | Long, unstructured | Structured but dense | Summary at top, tables for results, five-minute read |
| Confidentiality and permissions | Not checked | Checked informally | Data licence checked; supervisor and college naming confirmed in writing |
Worked illustrative example
Illustrative only: the project, numbers and findings below are invented to show how a page reads. Nothing here was run, and none of it describes a real student’s work.
Project: classifying short customer messages into five intents
One-line outcome. “Intent classification for 5 categories; macro-F1 0.78 compared with 0.60 for a keyword-rule baseline.”
Problem statement. A small support team sorts incoming messages by hand into billing, delivery, refund, technical issue and other. A wrong “refund” label delays a customer who is owed money, so missing a refund message costs more than mislabelling a billing one. Success was set in advance as macro-F1 of at least 0.75, with refund recall of at least 0.80.
Data. A public labelled dataset of short messages, with its licence linked on the page. The split was 70/15/15 with a fixed seed. The refund class was the smallest at about 8 percent of rows, so accuracy alone would have hidden weak performance there.
Results table (illustrative).
| Model | Macro-F1 | Refund recall | Notes |
|---|---|---|---|
| Keyword rules (baseline) | 0.60 | 0.55 | Fails on paraphrases |
| TF-IDF + logistic regression | 0.72 | 0.70 | Fast, easy to explain |
| Fine-tuned small transformer | 0.78 | 0.81 | Mean of 3 seeds, spread about 0.01 |
Error analysis (illustrative). The author reads 60 wrong predictions from the test set and sorts them into groups:
- Mixed-intent messages (about 40 percent of errors). A message asks about a delayed parcel and a refund together. The label allows only one intent. Proposed fix: move to multi-label annotation.
- Very short messages (about 30 percent). Texts such as “not working” carry too little signal. Proposed fix: add a “needs clarification” output rather than forcing a guess.
- Annotation noise (about 20 percent). Some gold labels look wrong on reading. Proposed fix: re-annotate a sample and measure agreement.
- Spelling and code-mixed text (about 10 percent). Proposed fix: add augmentation and test on a separate code-mixed slice.
Note what this does. It shows the model’s weakest area honestly, ties each error group to an action, and shows that the author checked the labels as well as the model.
Reproduce (illustrative commands).
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python train.py --seed 42 --config configs/transformer.yaml
python evaluate.py --split test --checkpoint outputs/best.pt
The page would also state the expected runtime, the hardware used, and the metric values a rerun should produce within a small tolerance.
Metrics by AI sub-area
Choose metrics that fit your project type, and state why. The table gives common starting points. Adjust them to your task.
| Project type | Common metrics | Error analysis idea |
|---|---|---|
| Text classification | Macro-F1, per-class precision and recall | Group errors by message length, language mix and ambiguity |
| Image classification | Top-1 accuracy, per-class recall, confusion matrix | View misclassified images; check lighting, background and class confusion pairs |
| Object detection | mAP at stated IoU thresholds | Split misses by object size and occlusion |
| Regression or forecasting | MAE, RMSE, comparison with a naive forecast | Plot residuals over time and by segment |
| Recommendation | Precision@k, recall@k, coverage | Check cold-start users and popular-item bias |
| Text generation or summarisation | ROUGE or similar, plus a small human rating rubric | Tag errors: factual slip, omission, repetition |
| Anomaly detection | Precision at a fixed alert budget, PR-AUC | Review false alarms by cause |
Reproducibility checklist
- A requirements or environment file with pinned versions.
- A fixed random seed for splitting and training, noted on the page.
- Data either linked with its licence or described by a download script. No manual steps.
- One command to train, one to evaluate.
- A saved results file (for example, a small JSON of metrics) so a reader can compare their rerun.
- A note on runtime and hardware, including whether a GPU is needed.
- No secrets, API keys, personal data or confidential files in the repository history. Check the history, not only the latest commit.
- A licence file for your own code.
Presenting internship work honestly
Internship projects are often guided, templated or built on provided data. Say so. A line such as “Dataset and starter notebook provided by the programme; I wrote the feature pipeline, ran the experiments and did the error analysis” is credible and specific. Reviewers trust it far more than a page that claims everything.
Separate three things on the page: what the task brief gave you, what you chose, and what you found. Keep dates and duration accurate. A two-week project should read as a two-week project with a clear scope, not as months of work.
If you completed the free two-week online internship at CareerSwami, mention it as exactly that: a free, 14-day online internship with an offer letter and a completion certificate after successful completion. Link the certificate if you wish, and put the substance, meaning the repository and page, ahead of the paper.
A two-week plan to build the page
A short internship leaves little time. Spread the portfolio work across the period so it does not become a last-day scramble.
- Days 1-2: Write the problem statement and success criterion before touching a model. Pick and describe the data.
- Days 3-4: Build the baseline and record its score. Set up the repository and environment file.
- Days 5-8: Train the main model. Keep a log of every experiment, including failures.
- Days 9-10: Evaluate on the held-out test set once. Run the error analysis on real mistakes.
- Days 11-12: Clean the code. Write the one-command scripts. Test them in a fresh environment.
- Days 13-14: Fill in the template, score yourself on the scorecard, and ask a friend to follow your reproduce steps.
Common portfolio mistakes
- Tuning on the test set. The reported score then overstates performance. Keep the test set untouched until the end.
- No baseline. Without one, a score of 0.85 means nothing.
- Accuracy on imbalanced data. A model that always predicts the majority class can score high.
- Screenshots instead of text. Results in images cannot be searched or copied. Use tables.
- Notebook with hidden state. Restart the kernel and run all cells top to bottom before publishing.
- Vague claims. Words like “high accuracy” or “state of the art” without a number and a comparison invite doubt.
- Leaked data. Duplicates across train and test inflate scores. Check for them.
Check TCE’s internship rules before publishing your AI portfolio
The official TCE pages reviewed do not publish institution-wide portfolio rules. Settle these points with the people who can answer them, and keep the replies in writing.
- Naming the college. Ask your department head or project guide whether you may name TCE or the department on a public page. Send an email and keep the reply. The AI department page lists a head of department contact.
- Naming a faculty guide. Ask for the guide’s permission in writing before listing their name.
- Internship recognition. If you want the internship to count for any academic requirement, ask your department’s internship or project coordinator what documents are needed and whether an online programme is accepted. Do not assume it counts.
- Final-year project work. Ask whether the project work you submit for evaluation can also be published, and when. Some projects have embargo or ownership terms.
- Data and confidentiality. If any data or problem came from a company or a lab, ask the faculty guide for the terms before sharing code or results.
- Official documentation formats. Ask whether your regulations or project handbook prescribe a report format. If so, your public page should be a separate, shorter summary and should not replace it.
- Training and placement cell. Ask what portfolio or project evidence they look for in recruitment preparation, and whether they run review sessions.
Frequently Asked Questions
How many projects should an AI portfolio have?
Two or three strong ones are enough. Cover different problem types, for example one text project and one vision or tabular project. Each should meet most of the scorecard criteria. Extra weak projects dilute the strong ones.
Should I host the portfolio on GitHub or a personal website?
Use GitHub for code and a README that follows the template. A personal page is optional. If you build one, link each project back to its repository and keep the structure identical across projects.
Is a Jupyter notebook enough?
A notebook can hold the narrative, but it is not enough alone. Add a requirements file, a seed and scripts that run training and evaluation from the command line. Restart and run the notebook fully before publishing.
What if my model performed poorly?
Publish it with a strong error analysis. A well-explained modest result shows more skill than a suspiciously perfect one. State what the poor result tells you about the data or the approach, and what you would try next.
Can I include a project done during the internship in my college project report?
That depends on your department’s rules, which these public pages do not settle. Ask your project coordinator in writing, and ask how to credit work that overlaps.
Do I need a deployed demo?
No. A demo helps when it is simple and stable, but a reproducible repository with honest evaluation matters more. If you add one, say what it does not handle.
How should I describe the internship on my résumé and portfolio?
State its type, duration and your outputs. For example: “Two-week online AI internship; built and evaluated an intent classifier; repository linked.” Do not add claims about stipend, academic credit or placement unless you hold documents that state them.
Can I use large language models or pretrained models in a portfolio project?
Yes, if you say so. Name the model and version, state what you changed, and add a baseline. Show your own contribution in the evaluation and error analysis, and disclose any use of AI tools to write code or text.
Related Artificial Intelligence guides
- Preparing for AI Internship Interviews: A Guide for Kumaraguru College of Technology Students
- Choosing an AI Internship Track: NLP, Vision or GenAI for Vishwakarma Institute of Technology, Pune Students
- AI Internship Demo Ideas for Pune Institute of Computer Technology Students
- All Artificial Intelligence internship guides
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Artificial Intelligence. The internship, the offer letter and the completion certificate are free.