Every placement season, interviewers see the same AI projects: a chatbot wrapper, a sentiment classifier on a famous dataset, a "resume analyser" that is one prompt. They do not stand out, because they do not show anything the interviewer needs to know.
What an interviewer wants to know is simple. Can you build something that works, on real input, and explain why you built it that way? The ten projects below are picked to show exactly that. They go from beginner to advanced, and each one practises a skill that comes up in AI engineering interviews.
What makes an AI project impressive
Before the list, the criteria. A strong project has five things:
- A real user. You, your classmates, a local shop, your college office. Not "anyone".
- Messy input. Real data breaks naive solutions. Handling it shows engineering.
- A check. Tests for the code, and a small evaluation set for the AI part: inputs with known good answers.
- Numbers you measured. Accuracy on your eval set, cost per request, response time. Measured, never invented.
- A live link and a clean repo. Deployed, with a README and a Git history that shows how you worked.
One deployed project with an eval set beats five notebooks on your resume.
Beginner projects
1. Receipt and bill extractor
Upload a photo or PDF of a bill. The app extracts merchant, date, items and total as structured JSON, validates it (do the items add up to the total?) and saves it to a database.
What it shows: calling a model API, structured output, validation, handling bad scans. Measure: extraction accuracy on 30 real bills you collected.
2. Lecture notes to flashcards
Paste lecture notes or a transcript. The app generates question-and-answer flashcards, lets you edit them, and quizzes you with spaced repetition.
What it shows: prompt design, a usable UI, storing user data. Measure: what share of generated cards your classmates kept without editing.
3. Resume to job match explainer
Given a resume and a job description, it highlights which requirements are met, which are missing, and suggests honest improvements. No made-up experience.
What it shows: structured comparison, guardrails against fabrication. Measure: agreement with a senior's manual review on 20 pairs.
Intermediate projects
4. College regulations assistant
An assistant that answers questions from your college's handbook, exam rules and circulars, cites the exact section and says "I don't know" when the answer is not in the documents.
What it shows: retrieval (RAG), chunking, citations, refusing to guess. Measure: correct-answer rate and correct-refusal rate on 50 real student questions.
5. Code review bot for your own repos
A GitHub Action that reviews pull requests on your projects: flags secrets, missing tests, risky changes and unclear names, and comments on the PR.
What it shows: Git workflows, CI, tool integration, writing a focused review prompt. Measure: how many of its comments you acted on across 20 PRs.
6. Local language support helper
A small business gets customer questions in Tamil, English and a mix of both. The tool drafts replies in the customer's language from the shop's own FAQ, for a person to approve before sending.
What it shows: multilingual handling, retrieval, human-in-the-loop design. Measure: share of drafts the owner sent without edits over two weeks.
7. Meeting or class summariser with action items
Transcribe a recording, summarise it, and extract action items with owners and dates as structured data you can export.
What it shows: a multi-step pipeline (speech to text, summary, extraction), handling long input. Measure: action items caught versus a manual list on 10 recordings.
Advanced projects
8. An agent with approval steps
An agent that does a real repetitive job, such as reading new internship postings from a few sites, filtering them against your criteria and drafting applications, but asks for your approval before anything is sent.
What it shows: the agent loop, tool use, approval for irreversible actions, logging every step. Measure: precision of its filtering, and time saved per week.
9. Evaluation harness for an LLM feature
Take project 4 or 6 and build the testing system around it: an eval set, an automated scorer, a report comparing two prompts or two models on quality, cost and speed.
What it shows: a skill most student portfolios lack, and the one that tells you whether a change made things better. Measure: the comparison itself is the result. Publish the table.
10. A cost-aware model router
A small service that sends easy requests to a cheap, fast model and hard ones to a stronger model, with a fallback if a provider fails, and a dashboard of cost per request.
What it shows: production thinking: cost, reliability, observability. Measure: cost and quality versus sending everything to the strongest model.
How to build them with AI tools, the right way
Use AI coding agents. Learning to direct them is part of the skill. But use them like an engineer:
- Plan before you prompt. Write a one-page spec: users, inputs, outputs, what done looks like.
- Keep a context file (
CLAUDE.mdorAGENTS.md) with your commands and rules. See context engineering. - Review every diff. If you cannot explain a change, ask the AI to explain it before you accept it.
- Write tests and an eval set early, not the night before the demo.
- Commit small and often. Your Git history is part of the portfolio.
If you are new to this, start with what vibe coding is and how to do it without a mess, then how to use Claude Code.
Mistakes that sink student projects
The same few mistakes turn a good idea into a weak interview story.
- No real data. Testing only on three examples you typed yourself. Collect real inputs, even 30 of them, before you call it done.
- API keys in the repo. Interviewers do look. Use environment variables and a
.env.example, and rotate any key you have ever pushed. - One giant commit. It hides how you worked and makes the project look copied, even when it is not.
- No failure handling. What happens when the model returns bad JSON, the API times out, or the user uploads a blank file? Handle it, and mention it.
- Invented numbers. "95% accuracy" with no eval set behind it is worse than no number at all. If you did not measure it, do not claim it.
- Scope creep. Ten features half-working loses to three features that work every time.
How to present your project
In an interview, tell the story in this order:
- The problem and the user. One sentence.
- The demo. Live link, 60 seconds.
- The design. Why this model, why retrieval, why this approval step.
- What broke. The bug or bad output that taught you the most.
- What you measured. Your eval set and your numbers.
- What you would do next.
Put the same structure in your README. Interviewers often read the README before they meet you.
Which one should you pick?
- First-year or new to coding: projects 1 to 3. Finish one fully before starting another.
- Pre-final or final year: one from 4 to 7 as your main project, plus project 9 built around it.
- Already comfortable building apps: 8 and 10, which show production judgement.
Three finished projects at different levels make a stronger story than ten half-built ones. If you want a full learning path around them, see our AI engineer roadmap.
If you want help choosing and scoping your first project, come to our free Saturday workshop. We plan and build a small project live with an AI coding agent, and you leave with a working repo and a plan for your next one. Book a seat for Saturday.