Yes, particularly if you have fewer than 4 years of commercial experience or if the project demonstrates a skill your employment history does not. Include the project name, the tech stack, a brief description of what it does, and a link to the repository or live version. The projects most worth including are ones that solve a real problem, have clear documentation, and show evidence of thoughtful technical decisions. Avoid listing tutorial projects or clones of well-known apps without meaningful additions.
List only languages you can be confidently interviewed in. A skills section with 20 languages signals shallow knowledge across the board, and experienced interviewers notice this. Aim for 6 to 10 technologies grouped by category (languages, frameworks, infrastructure, practices). If you know a language at a basic level, consider leaving it off rather than listing it with a caveat. Depth is more valuable than breadth on almost every engineering CV.
At product companies and startups, often. In the Stack Overflow Developer Survey 2022, 96.65% of professional developers reported using Git, so version control fluency is a baseline expectation for technical roles. A visible, active GitHub profile can help. Clean repositories with descriptive READMEs and recent commit activity signal professional habits. At large enterprises hiring through ATS, GitHub is less critical at screening but may be reviewed before the offer stage. Include your URL in the CV header regardless of seniority.
Only if it is specific enough to be useful. A profile that reads "full-stack developer passionate about clean code and agile methodologies" tells a recruiter nothing they could not infer from the rest of the CV. A profile that reads "full-stack developer with 5 years building production React and Node.js applications. Strong focus on performance, testing, and open source. Contributed to Radix UI and maintained a library with 2,100 GitHub stars" immediately signals relevant experience. Write the profile last, after the rest of the CV is complete.
Translate every technical decision into a user or business outcome. "Reduced frontend bundle size by 43% through code-splitting and dependency audit, improving Time to Interactive from 4.2s to 1.8s" is far more compelling than "optimized frontend performance." Use this structure: what you changed, what system or user was affected, and what measurably improved. If you do not have a metric, describe the scale ("across a codebase used by 400,000 teams globally") or the risk removed ("eliminated a class of race conditions that caused 3 production incidents per month").