GitHub Profile Setup for Job Seekers

GitHub lets you create a special repository with the same name as your username. The README.md in that repo displays directly on your profile page. This is the first thing people see when they visit your GitHub.

How to create it:

1. Create a new repository with exactly your GitHub username as the name. If your username is "juma-dev", create a repo called "juma-dev".
2. Initialize it with a README.md file.
3. Edit the README.md with your content.

What to include in your profile README:

# Hi, I'm [Your Name]

Full-stack developer based in Nairobi, Kenya.
I build web applications with React, Node.js, and PostgreSQL.
Currently focused on payment integrations for East African businesses.

## What I'm working on
- Building an M-Pesa payment dashboard for small businesses
- Learning TypeScript and system design
- Contributing to [open-source project name]

## Tech I use
- **Languages:** TypeScript, JavaScript, Python
- **Frontend:** React, Next.js, Tailwind CSS
- **Backend:** Node.js, Express, PostgreSQL
- **Tools:** Git, Docker, Vercel, Railway

## Get in touch
- Portfolio: [your-site.com]
- LinkedIn: [linkedin.com/in/your-name]
- Email: [your-email]

Keep it concise. Three to four sections. No walls of auto-generated stats, no flashy GIF banners that take 10 seconds to load. Simple, honest, and informative.

Avoid generic phrases like "passionate about technology" or "lifelong learner." Be specific. "I build payment integrations for Kenyan businesses" is specific. "I am passionate about coding" is not.

GitHub lets you pin up to 6 repositories on your profile. These are the first repos people see. Choose carefully.

Which repos to pin:

• Your 2 to 4 best projects. These should be the same projects featured on your portfolio site.
• Prioritise projects that are deployed and working. A live project is always more impressive than one that only runs on localhost.
• Show variety. If you pin 4 React to-do apps, you demonstrate one skill. If you pin a React front-end, a Node.js API, a Python data tool, and a full-stack app, you demonstrate range.
• Do NOT pin forked repos that you have not significantly modified. Pinning a fork of a popular project you have not contributed to looks misleading.

How to pin repos:

1. Go to your GitHub profile page.
2. Click "Customize your pins" (appears near the top of the repos section).
3. Select the repos you want to highlight.
4. Save.

Each pinned repo should have a short description (the one-line summary that appears under the repo name). Write a clear, specific description. "M-Pesa payment dashboard with STK Push integration and transaction tracking" is better than "My project".

A repository without a README is like a shop without a sign. Nobody knows what is inside or whether they should bother looking.

What every project README should include:

# Project Name

One-paragraph description of what the project does and why it exists.

## Live Demo
[Link to deployed app]

## Screenshot
![Screenshot of the app](./screenshot.png)

## Tech Stack
- React 18 + TypeScript
- Node.js + Express
- PostgreSQL
- M-Pesa Daraja API
- Deployed on Railway

## Features
- User authentication with email/password
- M-Pesa STK Push payment flow
- Transaction history dashboard
- Responsive design (works on mobile)

## Getting Started

### Prerequisites
- Node.js 18+
- PostgreSQL 14+
- Daraja sandbox credentials

### Installation
```bash
git clone https://github.com/your-username/project-name.git
cd project-name
npm install
cp .env.example .env
# Fill in your environment variables
npm run dev
```

## What I Learned
Brief description of technical challenges and what you learned.

## License
MIT

Key details:

• Include a screenshot or GIF of the app in action. A visual preview dramatically increases the chance that someone explores the repo further.
• Include a .env.example file in the repo so someone cloning it knows what environment variables are needed. Never commit actual .env files.
• The "Getting Started" section should be accurate. Clone the repo yourself and follow your own instructions. If they do not work, fix them.
• The "What I Learned" section is optional but valuable. It shows reflection and self-awareness, qualities that hiring managers notice.

Hiring managers who click into your repos will scan your code. They are not reading every line. They are looking for patterns that indicate whether you write clean, professional code or messy, tutorial-copy-paste code.

What they notice:

• File organisation: Are files in logical folders (components/, pages/, utils/, api/) or is everything dumped in the root directory? Organised file structure signals that you think about maintainability.
• Naming conventions: Are variables and functions named descriptively? calculateTotal(items) is professional. doStuff(x) is not. Consistent naming (camelCase for JS/TS, snake_case for Python) shows attention to convention.
• No console.log spam: Remove debugging statements before pushing. A file full of console.log("here") and console.log("test123") screams unfinished work.
• Error handling: Do your API calls handle errors? Does the UI show meaningful error messages or just crash? Even basic try/catch blocks and user-facing error states show that you think about what happens when things go wrong.
• Comments where needed: You do not need to comment every line. But a comment explaining why you made a non-obvious decision ("Using polling here because webhooks are not reliable in the sandbox") shows thoughtfulness.

A quick cleanup checklist before applying for jobs:

1. Remove all console.log and debugging statements.
2. Delete commented-out code blocks. If you are not using it, remove it. Git history keeps everything.
3. Make sure there are no hardcoded secrets, API keys, or passwords in the code. Search for them: grep -r "password\|secret\|api_key" .
4. Add a .gitignore file that excludes node_modules, .env, and build artifacts.
5. Run your linter (ESLint for JS/TS, Flake8 or Ruff for Python) and fix any warnings.
6. Make sure the app builds and runs without errors.

Your commit history tells a story about how you work. Good commit messages show that you work methodically. Bad ones suggest chaos.

Good commit messages:

feat: add M-Pesa STK Push payment flow
fix: handle timeout on callback response
refactor: extract payment logic into separate service
docs: add setup instructions to README
style: fix responsive layout on mobile screens

Bad commit messages:

fix stuff
updated
asdfgh
final version
final final version
please work
WIP
.

You do not need to follow the Conventional Commits format perfectly, but your messages should be clear enough that someone reading the log understands what changed and why.

Tips for better commit history:

• Commit frequently in small, logical chunks. One commit per feature or fix, not one giant commit with everything.
• Write the message in present tense, imperative mood: "add feature" not "added feature" or "adding feature".
• If you have messy commits in an existing project, it is fine. Do not rewrite history just for appearances. Focus on writing better commits going forward.

About the green squares (contribution graph):

The contribution graph on your profile shows your activity over the past year. A completely empty graph can raise questions. But a graph full of green squares from meaningless commits ("update readme", "fix typo", repeated daily) is worse than a moderate amount of genuine activity. Hiring managers who are experienced developers can tell the difference. Focus on building real things, and the activity graph will fill itself naturally.

Use this as a final review before you start applying for jobs.

Profile basics:

• Profile photo: a clear, professional-looking photo. Not a cartoon avatar (unless you have strong reasons). Not a blank silhouette.
• Bio: one line describing what you do. "Full-stack developer | React, Node.js, PostgreSQL | Nairobi, Kenya"
• Location: set to your city. It helps recruiters find you when searching by region.
• Website: link to your portfolio site.
• Profile README: created and populated with relevant information.

Pinned repositories (2 to 4):

• Each has a clear, specific description.
• Each has a comprehensive README with setup instructions.
• Each has a live demo link (either in the repo description or the README).
• Code is clean, organised, and free of debugging artifacts.
• No hardcoded secrets or API keys.

Activity:

• Recent commits visible in the last 30 days. If you have not pushed anything in months, push something this week.
• Commit messages are descriptive and meaningful.

Things to remove or hide:

• Archive or make private any repos that are embarrassing, broken, or just tutorial follow-alongs. You can archive repos without deleting them.
• Unpin any forked repos you have not meaningfully contributed to.
• Remove any repos with names like "test", "asdf", or "delete-me".

Your GitHub profile is your technical resume. Treat it with the same care you would give your CV. A clean, well-maintained profile tells a hiring manager: "This person takes their craft seriously."