How to Choose a Final Year Project That Helps You Get Hired

For most computer science graduates in Pakistan, the final year project is the only substantial piece of software on their CV. It is what an interviewer asks about when there is no job history to discuss.

Yet most groups choose their FYP in a week, under deadline pressure, by picking whatever idea the group's strongest coder suggests or whatever the senior batch did.

This guide is about choosing deliberately: how to pick a problem, a scope, a team, a stack and a supervisor so that the project gets approved, gets finished and gets you an interview. It draws on what we see when we interview interns and fresh graduates at Softhat.

What employers look at in a fresh graduate's FYP

Employers care less about the project's title than about four pieces of evidence: it runs, the code is yours, it is documented, and someone other than you used it.

When a fresh graduate's CV lands on a hiring desk, the FYP line gets roughly one question: "Can I see it?" Here is what answers that well.

Evidence	What it proves	How to have it
A live demo link or APK	You can ship, not just code	Deploy early on a free tier and keep it running after the viva
A GitHub repo with real history	You wrote it, steadily, over months	Commit from week one, with clear messages, from every member's own account
A README and short docs	You can explain your work to others	Setup steps, architecture diagram, screenshots, known limits
Real users or a real client	The problem existed outside the classroom	Test with 10-50 actual users and record what changed
Your own decisions	You understand the trade-offs	Be ready to say why you chose this database, this model, this design

None of these depend on the idea being impressive. A clinic booking system that a real clinic used for a month is a stronger interview story than an unfinished "AI-powered smart city platform".

Start from a problem, not a technology

The safest way to choose is to start with a person who has a problem, then pick the technology that solves it.

"We want to do something with AI" produces vague proposals that supervisors send back. "Receptionists at a clinic spend two hours a day answering the same appointment questions on WhatsApp" produces a project with users, requirements and a way to measure success.

Good sources of real problems:

• Family and neighbourhood businesses. Shops, clinics, academies and workshops all have a repetitive task nobody likes.
• Your own university. Admissions queries, transport, timetables, lost-and-found, society events.
• Local industry. In Mardan, Khyber Pakhtunkhwa that includes marble, agriculture and trade; the problems are concrete and the people are reachable.
• Your future job. If you want to work in AI automation or web development, build what those companies build.

If you need a starting list, we published 32 final year project ideas for computer science students.

Pick a scope you can finish

Scope is the most common reason good FYPs fail. Two semesters sounds long; after exams, holidays, proposal defence and report writing, a team usually has five to six months of real build time.

The one-sentence test

Write the project in one sentence: "[User] can [do task] by [method], instead of [current way]." If you need "and" three times, the scope is too big. If the sentence describes a CRUD form, it is too small.

Core, then extras

Split features into must-have and nice-to-have before the proposal. The core should be finished and deployed by the middle of the final semester; extras only start after that.

Sign	Too big	About right	Too small
Users	"Everyone in Pakistan"	One clear group, e.g. clinic patients	Only you
Features	15+ modules	4-6 core features	Add, edit, delete, view
AI	Train a new model from scratch	Use or fine-tune an existing model for one task	None, or a chatbot with no purpose
Data	Data you hope to get	Data you already have or can collect	Dummy rows

Choose your team carefully

Choose teammates for reliability and complementary skills, not friendship alone. Every member will be questioned individually in the viva.

• Two or three is the sweet spot for most projects, if your department allows it. Four people need a project with four genuinely separate parts.
• Split by component, not by task type. "Ali owns the WhatsApp integration end to end" works better than "Ali does all the testing".
• Agree on rules early: weekly meeting, where tasks are tracked, what happens if someone stops contributing.
• Make contribution visible. Each member commits from their own GitHub account. It protects the people doing the work and gives everyone a portfolio.

Choose a stack you can finish and sell

Use a stack that is in demand in Pakistani job ads and that at least one member already knows. Learning one new major technology during the FYP is healthy; learning three is how projects stall.

If you want to work in	A sensible FYP stack	Learn it with
Web development	Next.js or Laravel, Postgres or MySQL, deployed on a free tier	Web development course
AI and automation	Python, FastAPI, an LLM API or local model, vector search, WhatsApp or web front end	AI automation course
Data science and ML	Python, pandas, scikit-learn or PyTorch, a simple dashboard	Python course
Mobile	Flutter or React Native with Supabase or Firebase	Official docs and a small practice app first

Whatever you pick, put the free resources to work: the GitHub Student Developer Pack gives verified students credits and tools (GitHub Education), and Google's Gemini API has a free tier for prototyping (Google AI for Developers).

Find the right supervisor fit

A supervisor whose interests match your project gives better feedback, better references and fewer surprises at the defence.

• Read their recent work. Faculty pages and Google Scholar show what they publish and supervise.
• Bring a one-page idea, not a blank page. Supervisors respond better to a draft they can shape.
• Ask how they work: how often they meet groups, whether they expect a research component, how they handle team disputes.
• Know your department's structure. Some universities run separate departments for computer science and software engineering; UET Mardan, for example, lists both (UET Mardan), and expectations for the report can differ between them.

Your supervisor and department have the final word on scope and format. Listen to them, even when an online guide (including this one) says otherwise.

Turn the FYP into a portfolio piece

A finished FYP should leave you with five things you can send to an employer the day after the viva.

1. A live link or installable build, kept running for at least a year.
2. A clean GitHub repo with a README covering what it does, how to run it, the architecture and screenshots (GitHub Docs).
3. A two-minute demo video showing one real user journey from start to finish.
4. A short case study: problem, your role, decisions, results, what you would change. Post it on LinkedIn or a personal site.
5. Numbers from your own project: users, response times, accuracy, hours saved. Only numbers you measured.

Use your FYP in internship and job interviews

Interviewers ask about your FYP because it is the one place you can show judgement. Prepare it like a story, not a feature list.

• The problem in one sentence, and who had it.
• Your part, specifically: "I built the booking API and the reminder scheduler."
• One hard decision and why you made it: a database choice, a model you rejected, a feature you cut.
• One thing that went wrong and how you fixed it.
• The result, with the numbers you measured.

Students who can talk through this clearly do well in internship interviews even with a modest project. Our internships page lists the tracks we hire for, including AI automation and Python and AI.

Common mistakes to avoid

• Copying the senior batch's project with a new name. Supervisors remember, and interviewers can tell.
• Choosing the trendiest technology nobody in the group knows.
• No users until the last month. Test early, even with five people.
• Leaving the report to the end. Write each chapter as you finish the matching part of the work.
• One member doing everything. It is unfair, and it shows in the viva.
• Buying or outsourcing the project. It is academic misconduct, it collapses under viva questions, and it leaves you with nothing to show in interviews. Get mentorship, not a ready-made project.

FYP selection FAQ

Should my FYP be research or development?

Development suits most students aiming for industry jobs. Choose research if you are planning an MS or PhD and your supervisor is active in that area; a good research FYP ends with a dataset or results you can write up.

Does the FYP really matter for getting a job?

For fresh graduates it is often the main technical discussion in the interview, because there is little else to ask about. A deployed, well-explained project makes that conversation much easier.

Can we change our project after the proposal is approved?

Sometimes, with your supervisor's agreement and through your department's process. Narrowing scope is usually easier to get approved than changing the idea.

Key takeaways

• Employers look for four things: it runs, the code is yours, it is documented, and real people used it.
• Start from a real user's problem, then choose the technology.
• Scope for five to six months of build time, with a finished core before any extras.
• Pick teammates for reliability, split work by component, and commit from your own accounts.
• Choose a stack in demand that someone in the group already knows, and a supervisor whose interests fit.
• Never buy or outsource an FYP; it fails in the viva and gives you nothing for interviews.

Get mentorship for your FYP

Softhat mentors final-year groups at our Mardan, Khyber Pakhtunkhwa office or remotely: choosing and scoping the idea, the proposal, architecture, weekly code reviews, AI integration, deployment, documentation structure and viva practice. Your group builds the project; we help you make the decisions that get it finished and noticed. See FYP mentorship, and when your proposal is due, read how to write an FYP proposal.

Ask about FYP mentorship