LinkedIn - lesson 4 | HackIndia Skills

Key point

Proof beats tech lists

A project is not strong because it says React, Node, MongoDB. It is strong when a reader can see what problem you solved, what you built, and where they can check it.

Recruiters and builders are scanning fast. Give them enough proof to decide if your project is real and relevant.

What to include

For every good project entry, include five parts: problem, your role, tech stack, outcome, and links.

Keep it specific. If it was a college or hackathon team project, say what you personally handled.

Your to-do

Build one entry

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Name the project in plain words, not only the app name.
Write the user problem in one short line.
State your role and the main parts you built.
List the core tech stack, not every package.
Add one outcome, such as working demo, users tested with, or feature completed.
Add links to GitHub, live demo, video demo, or HackIndia submission.

0 of 6 done

Common mistake

Avoid empty claims

Do not write “Built a full-stack app using MERN” and stop there. That tells the reader almost nothing.

Also avoid adding private repo links that nobody can open. If your repo must stay private, add a public demo video or a short public README instead.

Example

Before and after

Here is a weak project entry turned into a useful one. You can adapt this structure for LinkedIn’s Projects section or your Featured post text.

Before:
Expense Tracker
Made using React, Node.js, Express, MongoDB.

After:
Expense Tracker for hostel students
Problem: Students lose track of small UPI and cash spends during the month.
Role: Built the React UI, expense form, category filters, and monthly summary view.
Tech stack: React, Node.js, Express, MongoDB.
Outcome: Tested with 6 classmates and fixed the category flow based on feedback.
Links: GitHub repo, live demo, HackIndia submission.

Tip

Use link labels

When you add links, label them clearly. “GitHub”, “Live demo”, and “HackIndia submission” are easier to scan than a long raw URL.

If your demo needs setup, put screenshots and run steps in your README. A project with a clean README feels more complete.

Pick your best proof

You do not need ten projects. Two or three clear projects with proof are better than a long list of half-finished work.

Choose projects that match your goal from lesson 1. If you want frontend roles, show UI decisions, responsiveness, and user flows. If you want backend roles, show APIs, data models, auth, or deployment.