Understand tech roles and career ladders, pick a realistic learning route, build portfolio evidence, and navigate postings, interviews and your first 90 days.

Foundations for Software, Data, Design & Tech Education Careers

Write your target role at the top of a page or document.

Collect five real job postings for that role (any job site) and list the skills or tools that appear in at least three of them.

For piece 1, choose a problem that uses the most common skill from your list. Write one sentence for the problem, one for who it helps, and one for the data or design input you will use.

For piece 2, choose a project that shows a different skill from your list (for example, testing, accessibility, a dashboard, a security write-up or a lesson plan).

For piece 3, choose something that shows depth: improve piece 1 or 2, or take on a slightly harder version.

For each piece, write the evidence you will publish: a live link, a repository with a README, a case study or a recorded demo.

Check each idea against the list: is it original or personalised (not a copy of a tutorial)? Rewrite any that are not.

Set a finish date for piece 1 no more than four weeks away and put it in your calendar.

## Why it matters

For most tech roles, a portfolio is the strongest evidence you have before your first job. A hiring manager reading 200 applications looks for one thing: proof that you can do the work they need. A CV says "proficient in SQL"; a portfolio piece shows a real question answered with SQL, with the query, the chart and the conclusion. That is often the difference between being skipped and being interviewed.

## The core idea: evidence for a specific role

A good portfolio is **small, targeted and finished**. Three strong pieces aimed at one role beat ten tutorial clones.

Each piece should answer four questions in its README or case study:

1. **Problem:** what were you trying to solve, and for whom?
2. **Approach:** what did you do, and why did you choose that approach?
3. **Result:** what does it do, with a link, screenshot or numbers?
4. **Reflection:** what would you improve, and what did you learn?

## What a good piece looks like, by role

| Role | Strong piece | Weak piece |
|---|---|---|
| Software / UI / mobile developer | a deployed app solving a real problem, with tests and a clear README | an unchanged to-do list from a tutorial |
| Data analyst / scientist | an analysis of a public dataset answering a real question, with code, charts and a written conclusion | a notebook that only loads a famous dataset |
| Machine learning engineer | a small model served behind an API with monitoring notes | a copied Kaggle notebook |
| Cybersecurity engineer | a home-lab write-up: hardening a virtual machine, or analysing logs from a safe practice environment | a list of tools you have installed |
| Cloud engineer / DBA | infrastructure as code that deploys a small app on a free tier, with a cost and cleanup note; or a database tuning write-up | screenshots of a console |
| Systems analyst / IT PM | a requirements document or project plan for a real (even volunteer) project | a template with no content |
| UI/UX designer / game designer | a case study with research, iterations and testing; a playable prototype with a design doc | final screens with no process |
| Technical trainer / CS teacher | a short lesson or workshop with objectives, materials and learner feedback | a slide deck with no learning goals |

## Worked example: improving a weak idea

**Weak:** "A weather app." Thousands of applicants have built one from the same tutorial.

**Stronger:** "A frost alert for my community garden. It checks the overnight forecast and emails the volunteers when the temperature will drop below 2 °C. It has run for a month and sent three correct alerts."

What changed:

- a **real user** (the garden volunteers)
- a **specific problem** (protecting plants from frost)
- **evidence it works** (a month of real use)
- the same technical skills (an API, scheduling, email), now with a story an interviewer will ask about

For a data analyst, "Titanic survival analysis" becomes "Which bus routes in my city are most often late, and at what times?", using the city's open data.

## Presenting it

- **Pin** your best three pieces at the top of your GitHub, Behance or personal site.
- Put the **live link and a screenshot** at the top of each README.
- Write for a reader with **two minutes**: the problem and result first, details after.
- Remove or archive old half-finished work from the front page.
- Keep **secrets out**: no API keys or passwords in public repositories.

## Common mistakes

- **Tutorial clones.** If it looks identical to a popular tutorial, it shows you can follow instructions, not solve problems.
- **No README.** Reviewers will not dig through code to guess what it does.
- **Unfinished work on display.** Finish fewer things.
- **Ignoring the target role.** A game prototype does little for a database administrator application.
- **Using private or employer data.** Use public, synthetic or your own data.

## Quick recap

- Three finished, targeted pieces beat many unfinished ones.
- Each piece explains problem, approach, result and reflection.
- Real users and specific problems make ordinary skills stand out.
- Lead with the result and a link; keep secrets out.

## Try it

Open the **Do** tab to plan three portfolio pieces for your target role.


Plan three portfolio pieces that show the skills your target role's postings ask for.

Portfolios that get interviews

Web Developer Portfolio Review and Tips - Nisar

How to create your first UX case study (2026 beginner tutorial)

Practise the workflow first on a sandbox repository made for beginners, such as github.com/firstcontributions/first-contributions: fork it, make the change it describes and open a pull request.

List two or three tools, libraries or apps you already use (for example a Python library, a VS Code extension or a documentation site).

On GitHub, open one of those projects' Issues tab and filter by the label "good first issue" (or use goodfirstissue.dev). Note two candidate issues.

Read the project's README, CONTRIBUTING file and code of conduct. Write down how they want contributions made (for example: comment first, sign a CLA, run tests).

For your chosen issue, check it is not already assigned or being worked on by someone else in the comments.

Write a short plan: what you think the fix is, which files are involved, and how you will test it locally.

Post a polite comment on the issue saying you would like to work on it and briefly describe your approach, following the project's rules. Then follow your plan.

## Why it matters

Open source contributions are public proof that you can work in someone else's codebase, follow a team's conventions and respond to review. That is exactly what you do in a tech job, and it is hard to show any other way before your first role. Contributions also help you learn from experienced maintainers and meet people in your field.

Open source is not only code. Documentation fixes, translations, tests, bug reports with clear reproduction steps, design work and accessibility reviews are all valuable, which makes open source useful for designers, analysts and trainers as well as developers.

## The core idea: the contribution workflow

Most projects on GitHub use the same steps:

1. **Find an issue.** Look for labels like `good first issue`, `help wanted` or `documentation`.
2. **Read the rules.** The `CONTRIBUTING.md` file says how the project wants contributions; the `CODE_OF_CONDUCT.md` says how people treat each other.
3. **Say you are working on it**, if the project asks for that.
4. **Fork** the repository (your own copy on GitHub), then **clone** it to your computer.
5. **Create a branch**, make the change, and **run the tests**.
6. **Commit** with a clear message and **push** to your fork.
7. **Open a pull request (PR)** explaining what you changed and why, and link the issue.
8. **Respond to review.** Maintainers may ask for changes; that is normal and useful.

In commands, the middle of that looks like:

```bash
git clone https://github.com/<you>/<project>.git
cd <project>
git checkout -b fix-typo-in-install-docs
# edit the file, then
git add docs/install.md
git commit -m "docs: fix broken link in install guide"
git push origin fix-typo-in-install-docs
```

Then open the pull request from your fork on GitHub.

## Worked example: a documentation fix

You use a Python library and notice the install guide links to a page that no longer exists.

- You search the issues and find "Broken link in install docs", labelled `good first issue` and `documentation`, unassigned.
- `CONTRIBUTING.md` says: "Comment on the issue before starting; docs changes do not need tests; use conventional commit messages."
- You comment: "Hi, I'd like to fix this. I think the link should point to the new `getting-started` page. Is that right?"
- A maintainer replies "Yes, thanks!" You fork, branch, fix the link, commit with `docs: fix broken link in install guide`, push and open a PR that says "Fixes #1234".
- The reviewer asks you to fix the same link in the French translation too. You push a second commit. The PR is merged.

That single small PR shows a future employer that you can read a project's rules, communicate clearly, use Git and respond to review.

## Choosing a project

- Start with something **you already use**: you understand what it does and will notice problems.
- Prefer **active projects**: recent commits, maintainers replying to issues within days or weeks.
- Check the **licence and code of conduct**: a project with neither may not welcome contributors.
- Smaller, friendly projects are often easier to start with than huge ones.

Useful starting points (Checked on 2026-10-23.): the GitHub guide https://opensource.guide/how-to-contribute/, the practice repository https://github.com/firstcontributions/first-contributions and the issue finder https://goodfirstissue.dev.

## Etiquette

- **Be patient.** Most maintainers are volunteers.
- **Do not claim many issues at once**, and say so if you have to stop.
- **Keep PRs small** and focused on one issue.
- **Never open low-effort PRs** (like whitespace changes) just to get a contribution count. Maintainers notice, and it can harm your reputation.
- **Do not paste AI-generated changes you do not understand.** Be ready to explain every line.

## Common mistakes

- **Starting work without reading CONTRIBUTING.md**, then having the PR rejected.
- **Working on an issue someone else has claimed.**
- **One giant PR** that changes many unrelated things.
- **Taking review comments personally.** Review is how projects keep quality high.
- **Giving up after the first PR.** Repeated contributions to one project show much more than single drive-by fixes.

## Quick recap

- Open source shows you can work in a real codebase with real collaborators.
- Contributions include docs, tests, design and bug reports, not only code.
- Workflow: find issue, read rules, fork, branch, change, test, commit, push, PR, respond to review.
- Start with projects you use, keep PRs small, and follow the project's etiquette.

## Try it

Open the **Do** tab to practise the workflow and plan your first real contribution.


Find a beginner-friendly open source issue, understand the contribution workflow and make a plan to contribute.

Contributing to open source

Getting started with open source contributions for beginners

How to find your first open source project

Open your profile in a private browser window so you see it as a stranger would. Note your first impression in one sentence.

Set a clear display name and a professional photo or neutral avatar. Add a one-line bio that names your target role, for example "Aspiring data analyst | SQL, Python, dashboards".

Remove personal details you do not want public, such as a home address or personal phone number.

On GitHub, create a repository with exactly your username to make a profile README. Write three short sections: who you are and your target role, what you are working on, and links to your best work and how to contact you. On Behance, write the About section with the same content.

Pin your three best projects (or feature your three best case studies on Behance). Make sure each has a clear title, description and a live link or cover image.

Open each pinned project and check its README or case study starts with the problem and the result. Fix the weakest one.

Check one repository for secrets (API keys, passwords, .env files) and remove any you find; rotate any key that was ever committed.

Ask a friend or classmate to look at the profile for 60 seconds and tell you what role they think you want. Adjust if they guess wrong.

## Why it matters

Recruiters and hiring managers often look you up before or after reading your application. For developers, data people, cloud and security engineers and teachers, that usually means **GitHub**. For designers, it is often **Behance**, Dribbble or a personal site. Your profile is a first impression you control: in under a minute, a stranger should know what role you want and see your best work.

## The core idea: a profile is a landing page

Treat your profile like the front page of a small website with one goal: get the right person to click your best project. It needs:

1. **A clear identity:** name, photo or avatar, and a one-line bio naming your target role.
2. **A short introduction:** who you are, what you are working on, how to contact you.
3. **Your best work, up front:** three pinned projects or case studies.
4. **Nothing that undermines you:** no secrets, no embarrassing or abandoned work at the top.

## GitHub: the profile README

GitHub shows a special README at the top of your profile when you create a **public repository with exactly your username** (for example, `github.com/ada-lee/ada-lee`) containing a `README.md`. GitHub's guide: https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme (Checked on 2026-10-23.)

A simple, effective example:

```markdown
## Hi, I'm Ada

Aspiring **data analyst**. I turn public data into clear answers with SQL, Python and dashboards.

**Currently:** analysing late buses in my city with open transit data.

### Selected work
- [Late buses](https://github.com/ada-lee/late-buses): which routes run late, and when (SQL, pandas)
- [Garden frost alert](https://github.com/ada-lee/frost-alert): emails volunteers before a frost
- [Library dashboard](https://github.com/ada-lee/library-dashboard): weekly loans by branch

**Contact:** ada.lee@example.com · LinkedIn: /in/ada-lee
```

It is short, names the role, shows current work and links to evidence. Animated banners, long badge walls and visitor counters add little; a reviewer cares about the projects.

## Pinned repositories

On GitHub you can **pin up to six** repositories. Pin your **best three to six** projects for your target role. For each pinned project:

- give it a clear name (`late-buses`, not `project2-final-v3`)
- write a one-line description
- add the live link in the "About" box
- make sure its README starts with the problem, the result and a screenshot

The green contribution graph shows activity, but do not game it with empty commits. Steady real work is more convincing than a perfect grid.

## Behance and design portfolios

For UI/UX and game designers, the case study is the unit of work. On Behance (or a personal site), feature three projects. Each cover image should show the final design; each case study should walk through the **problem, research, iterations, testing and outcome**. Keep the About section to a few lines naming your target role and contact details. If your work was for an employer or client, ask before publishing and remove confidential details.

## Worked example: before and after

**Before:** username `xX_coder99_Xx`, no photo, no bio, 23 repositories (mostly forks and tutorial folders), nothing pinned, the most recent repo called `test`.

**After:** display name "Sam Ortiz", neutral avatar, bio "Cloud engineer in training | Linux, AWS free tier, Terraform", a profile README with current work, three pinned projects (a Terraform deployment with a cleanup script, a Linux hardening write-up, a monitoring dashboard), tutorial forks archived or made private.

Same skills, far clearer story.

## Privacy and safety

- **Never commit secrets.** If a key was ever pushed, assume it is compromised: revoke and replace it, then remove it from the repository.
- Use a public contact email you are happy to share; GitHub can hide your personal email in commits.
- Do not post your home address or personal phone number.

## Common mistakes

- **No bio or a vague one** ("I love tech").
- **Pinning tutorial forks** instead of your own work.
- **Badge walls and widgets** that bury the projects.
- **Abandoned repositories at the top.** Archive or make private what you no longer stand behind.
- **Mismatched story.** Your profile, CV and LinkedIn should name the same target role.

## Quick recap

- Your profile is a landing page: identity, short intro, best work, nothing harmful.
- A GitHub profile README lives in a repository named exactly like your username.
- Pin three to six projects with clear names, descriptions and live links.
- Designers lead with three strong case studies on Behance or a personal site.
- Keep secrets and personal details out.

## Try it

Open the **Do** tab to polish your profile step by step.


Turn a GitHub or Behance profile into a clear, professional page that shows your target role and best work.

Your public profile

How to Create a Standout GitHub Profile README (Step by Step Guide 2026)

Turn what you learn into proof: portfolio pieces aimed at your target role, a first open source contribution, and a clear public profile.