Resume, GitHub and LinkedIn
Before you start
You need: a finished, deployed project (Article 09).
Time: about 40 minutes to read, then a focused afternoon to do it properly.
Learning objective
Present your work so that a recruiter spending twenty seconds sees the evidence, and the interview opens on your strongest ground.
Topics
- Twenty seconds
- The one-page resume
- Writing the project so it means something
- Words that cost you nothing and words that cost you
- Your GitHub profile
- Applying, and what actually works
Twenty seconds
A recruiter scanning fifty fresher resumes gives yours about twenty seconds on the first pass. In that time they are looking for four things:
1. What can this person build?
2. With what?
3. Is there evidence?
4. Are they nearby and available?
Everything else is decoration. Your objective statement, your hobbies, your school percentages — none of it is being read on the first pass.
So put the project first, above education, above skills. It is the only thing on the page that distinguishes you from the other forty-nine.
The one-page resume
One page. A fresher with two pages is padding, and it reads that way.
RAVI KUMAR
Hyderabad · +91 99515 10727 · ravi.kumar@email.com
github.com/ravikumar · linkedin.com/in/ravikumar · school-portal.example.com
──────────────────────────────────────────────────────────────────────
PROJECT
School Management System — Full-stack web application
ASP.NET Core 9 · Dapper · SQL Server · React 18 · JWT
Live: school-portal.example.com · Code: github.com/ravikumar/school-portal
Multi-tenant school portal handling students, fees, exam results and
attendance across three schools with strict data isolation.
· 14 REST endpoints with JWT authentication and role-based access;
tenant isolation enforced from the token, verified from Postman
· SQL Server schema, 12 tables, with constraints preventing invalid
data at the database level; parameterised Dapper data access
· React frontend with search, paging and full error-state handling
· LLM-drafted report-card comments, reviewed by a teacher before saving
· 40 unit tests covering grading logic, fee calculation and isolation
· Cut student lookup from several minutes of scrolling to under 2 seconds
──────────────────────────────────────────────────────────────────────
SKILLS
Languages C#, SQL, JavaScript, TypeScript, HTML, CSS
Backend ASP.NET Core, Dapper, REST APIs, JWT
Database SQL Server, T-SQL, stored procedures, indexing
Frontend React, responsive CSS
Tools Visual Studio, Git, GitHub, Postman, SSMS
Practices Unit testing, code review, AI-assisted development
──────────────────────────────────────────────────────────────────────
EDUCATION
B.Tech Computer Science · [University] · 2026 · [CGPA]
──────────────────────────────────────────────────────────────────────
Note what is not there: an objective statement, hobbies, a photograph, "references available on request", declaration lines, or a skills bar chart showing C# at 80%. None of it earns its space, and the percentage bars actively invite a question you cannot win.
Writing the project so it means something
This is where most fresher resumes fail. The difference is entirely in specificity.
| Weak | Strong |
|---|---|
| Developed a school management system using .NET | Built a multi-tenant school portal — ASP.NET Core, Dapper, SQL Server, React — with 14 endpoints and JWT auth |
| Worked with databases | Designed a 12-table schema with constraints preventing invalid data at the database level |
| Implemented security | Enforced tenant isolation from the JWT claim; verified from Postman that School 1 cannot read School 2's records |
| Used AI tools | Drafted report-card comments via an LLM API, reviewed by a teacher before saving |
| Wrote tests | 40 unit tests covering grading logic, fee calculation and tenant isolation |
Numbers are what make it credible. 14 endpoints, 12 tables, 40 tests, 3 schools, under 2 seconds. They are checkable, they suggest you know your own project, and vague claims suggest the opposite.
Every line should be something you can be asked about. If a line invites a question you cannot answer, remove it.
The line about cutting lookup time is the one that reads as engineering rather than coursework. It states a problem and an outcome, which is what the job is.
Words that cost you nothing and words that cost you
| Avoid | Because |
|---|---|
| "Passionate about coding" | Everyone writes it; it signals nothing |
| "Quick learner", "hard worker" | Unverifiable, so ignored |
| "Expert in C#" | You are six months in. It invites a demolition |
| "Familiar with" | Reads as "I watched a video" |
| Skill percentage bars | "Why is C# 80% and not 75%?" is a question with no good answer |
| "Team player" | Show it with a pull request instead |
| Use | Because |
|---|---|
| "Built", "designed", "implemented" | Concrete verbs |
| Specific numbers | Checkable |
| The actual technology names | Recruiters and filters match on them |
| A live link | Someone can look in five seconds |
On listing technologies you barely know: do not. A line saying "Docker, Kubernetes, Azure" that you cannot discuss turns a good interview bad in one question. List what you can defend and no more.
Your GitHub profile
For a fresher, GitHub is more persuasive than the resume, because it cannot be written in an afternoon.
Fix these five things:
1. Pin the project. Pin two or three at most, and unpin the tutorial repositories. A profile showing twelve half-finished experiments reads worse than one showing three deliberate ones.
2. The README must be complete. Article 09 has the shape. This is what gets read.
3. The commit history should look like work. Small commits, real messages, spread across months. One commit called "final project" tells them you archived a folder rather than used version control.
4. Use branches and pull requests, even alone. Visible evidence of how you work.
5. Fill in the profile. Name, a one-line bio, location, a link to the deployed project. It takes two minutes and most candidates skip it.
One thing to check before applying anywhere:
git log -p | grep -i "password\|connectionstring\|apikey"
If that returns anything, rotate the credential and deal with it. A reviewer who finds a connection string in your history will mention it, and it undoes the good impression the rest made.
LinkedIn
Less important than GitHub for the work itself, more important for being found.
Headline — not "Student":
Weak: B.Tech Student at [College]
Strong: .NET Developer · ASP.NET Core, SQL Server, React · Open to junior roles
About — four sentences:
I build full-stack web applications with ASP.NET Core, SQL Server and React.
Most recently I built a multi-tenant school management system — 14 REST
endpoints with JWT auth, a 12-table SQL Server schema, a React frontend,
and an LLM-drafted report-card feature reviewed by a teacher before saving.
I care about getting the awkward cases right: absent students excluded from
averages rather than counted as zero, and tenant isolation enforced from the
token rather than the request.
Looking for a junior developer role in Hyderabad.
That third sentence is doing real work. It shows judgement in a way "detail-oriented" never could.
Also: a clear photograph, your city, "Open to work" switched on, and the project in the Projects section with the live link.
Connect with people who actually work in your target companies, with a short note. A generic connection request to strangers achieves nothing; a specific one occasionally gets you a referral, and referrals fill a large share of fresher roles.
Applying, and what actually works
Roughly in order of how well they work for freshers:
| Route | Reality |
|---|---|
| Referral | By far the best. Ask seniors, alumni, anyone you know |
| Direct on the company site | Better than a job board — fewer applicants, and it shows intent |
| Campus placement | Take it seriously; the volume is real |
| Recruiters on LinkedIn | Reply promptly and politely, even to a poor fit |
| Job boards | Highest volume, lowest conversion. Still worth doing |
| Cold email to a hiring manager | Occasionally works, if specific and short |
Ask for referrals directly. Most people are willing and are simply never asked:
"Hi [name], I graduated from [college] in [year] and have been building a full-stack .NET project — here is the code and a live demo. I saw [company] has a junior developer opening. Would you be open to referring me, or telling me who to speak to? Happy to send anything useful."
Track your applications. A spreadsheet: company, role, date, route, status. Fifty applications is a normal number, and without a list you will lose track by twenty.
Expect a low response rate. Fifty applications producing five conversations is ordinary and is not a verdict on you. Keep applying while you interview.
Common mistakes
- Two pages
- An objective statement at the top
- Education above the project
- Vague project descriptions with no numbers
- Skill percentage bars
- Listing technologies you cannot discuss
- No live link
- A GitHub profile with a dozen unpinned tutorial repositories
- A secret in the commit history
- "Student" as a LinkedIn headline
- Applying to five roles and concluding it is hopeless
- Never asking anyone for a referral
Practice
- Write your resume on one page with the project first.
- Rewrite every project line to include a number.
- Read each line and ask: can I be questioned on this? Remove anything you cannot defend.
- Delete the objective, the hobbies and any percentage bars.
- Pin your project on GitHub, unpin the tutorials, complete the profile.
- Run the secret-scan command. Deal with anything it finds.
- Rewrite your LinkedIn headline and About section.
- Add the project with the live link to LinkedIn.
- Write your referral request message and send it to three people this week.
- Start the application tracker. Add your first ten.
- Give your resume to someone else and ask what they think you built. If they cannot say, rewrite it.
Exercise 11 is the honest test. Twenty seconds, another person, and see what survives.
You can now
- Write a one-page resume with the project first
- Describe your work with specific, checkable numbers
- Remove everything that invites a question you cannot answer
- Present a GitHub profile that reads as evidence
- Write a LinkedIn headline and About that show judgement
- Ask for a referral in a way people respond to
- Track applications and keep applying through the rejections
Where this leaves you
Six months ago you had no code. You now have an application you built and can explain, a commit history showing how you work, a live link, answers to the questions you will be asked, and an honest account of how you use AI.
That is a credible junior candidate. Whether it converts depends on the market where you are, how you interview on the day, and some luck — none of which anyone can promise you.
What you can control, you have done. Keep applying, keep the project alive, and write down every question you cannot answer.
Return to the Playbook overview, or start the work at Track 02 — Software Industry Foundation.
Next: Glossary — the reference to keep open while you work.