Skip to content

Projects and Resume

~6 min

In short

Your projects and resume are the evidence an interviewer reads before they talk to you. This section covers three things: which kinds of projects show real skill, how to write a one-page resume that describes them honestly, and how to present your code on GitHub and your profile on LinkedIn. Nothing here ensures a shortlist. It helps your materials say what you actually did, in a way someone can check.

Pages in this section

Page Read it when Output
01-projects-that-help.md You are choosing or improving a project One project at a level you can finish
02-resume.md You are drafting or revising your resume A one-page resume that passes the checklist
03-github-and-linkedin.md Your code or profile is public, or about to be A README checklist, pinned repos, a matching profile

Suggested order

  1. Choose or finish projects first, because resume bullets describe them.
  2. Write one resume bullet per project, using the pattern in the resume page.
  3. Tidy each GitHub README, then update LinkedIn so it matches the resume word for word on dates, names and titles.

What a reader looks for

A reader who opens your project folder usually asks four questions: does it run, does it do what the README says, is there evidence of testing, and can the author explain the choices. Each page in this section is built around one or more of those questions. The project page sets the acceptance checks, the resume page sets how each claim is worded, and the GitHub and LinkedIn page makes sure the public pages do not contradict either one.

Being able to answer those four questions is more useful than any single feature. If a project fails the first one, nothing else in the folder will save it.

Time to plan

A realistic first pass is one evening to pick a project and write its acceptance checks, a weekend to build a level 1 or 2 project, and one more evening to write the README and resume bullet. Level 3 takes longer, because the design note and measurement are the work. These are author's estimates for planning, not a standard. Adjust them to your own hours per week.

Common mistakes

  • Spending weeks on a project and never writing its README, so nobody can run it.
  • Listing every tool you have ever touched on the resume. Keep only what appears in a project you can explain.
  • Writing bullets that describe duties ("responsible for backend") instead of what you built and how you checked it.
  • Adding numbers you did not measure. Use placeholders you can fill later instead.
  • Updating the resume but not the GitHub README or LinkedIn, so the three contradict each other.

Fixing these takes less time than building a new project, and they are the first things a careful reader notices.

Go deeper

Honest limits

A good project and a clean resume make a conversation possible. They do not decide the outcome. Hiring processes vary by company, and no one can promise a result from any single document.

Try this

Open your current resume and your GitHub profile side by side. List every claim on the resume and mark the ones you can point to in a repo, a test or a certificate. Remove or rewrite every claim you cannot point to.

Sources