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

Find one real, current entry-level or junior posting for your target role (any job board or company careers page). Save a copy, since postings disappear.

Copy every requirement into a two-column table and label each one "must have" or "nice to have", using the posting's wording ("required", "preferred", "bonus") and how often it is repeated.

Next to each requirement, write your evidence: a project, course, job, volunteer role or certificate. Leave it blank if you have none.

Count the must-haves you can evidence. If you can show most of them (roughly 60 to 70 percent or more), mark the job "apply".

Pick the two most important gaps and write one concrete action for each (for example, "add tests to my late-buses project" or "finish the SQL Fundamentals course").

Write three CV bullet points for this posting, each using the posting's language and pointing to a specific piece of evidence with a result.

Note any red flags (unpaid "trial work", a huge list of unrelated skills, requests for payment or bank details) and decide whether to proceed.

## Why it matters

A job posting is a wish list written by several people, sometimes copied from an older posting. Read literally, many entry-level postings seem to want years of experience and a dozen tools. Learners often either apply to nothing (because they do not meet every line) or apply to everything with the same CV (and hear nothing back). Reading postings well lets you apply to the right jobs with the right evidence.

## The core idea: decode, then map

Read every posting in two passes:

1. **Decode** it: what does this team actually need someone to do in the first six months?
2. **Map** it: for each requirement, what evidence do you have?

## Anatomy of a posting

| Section | What it tells you |
|---|---|
| **Title and level** | "Junior", "Associate", "I" or "Entry-level" are good signs. "Senior" or "Lead" usually means several years. |
| **About the team** | the product, users and team size; useful for your cover letter and interview |
| **Responsibilities** | the real daily work; the best clue to what they will test you on |
| **Requirements / qualifications** | the must-haves (often called "required" or "minimum") |
| **Preferred / nice to have / bonus** | not required; strengths that set candidates apart |
| **Benefits, salary range, location** | many places now require salary ranges in postings; check remote, hybrid or on-site |

## Worked example

> **Junior Data Analyst.** You will build weekly sales dashboards, answer ad-hoc questions from the sales team and help clean our CRM data.
> **Requirements:** strong SQL; experience with Excel or Google Sheets; clear written communication; bachelor's degree or equivalent experience.
> **Nice to have:** Python, Tableau or Power BI, experience in retail.

Decode:

- Daily work: dashboards, quick SQL questions, data cleaning.
- Must-haves: SQL, spreadsheets, writing, a degree **or equivalent experience** (so not strictly required).
- Nice-to-haves: Python, a BI tool, retail.

Map (a learner's table):

| Requirement | Evidence | Status |
|---|---|---|
| Strong SQL | late-buses project (joins, window functions); SQL Fundamentals course | yes |
| Excel/Sheets | library dashboard in Google Sheets | yes |
| Written communication | project READMEs; blog post on the bus analysis | yes |
| Degree or equivalent | no degree; 2 years in retail operations + portfolio | partial |
| Python (nice) | pandas in the bus project | yes |
| BI tool (nice) | none | gap |
| Retail (nice) | 2 years as a store supervisor | yes |

The learner meets most must-haves and has a retail background the posting values. **Apply**, and spend a weekend building one small Power BI or Tableau Public dashboard to close the gap for future applications.

## Reading between the lines

- **"Or equivalent experience"** means the credential is flexible.
- **"Familiarity with"** is weaker than **"strong" or "expert in"**.
- **Years of experience** on entry-level roles are often soft, but "5+ years" on a junior posting is a sign of a confused or unrealistic posting.
- **A long list of unrelated technologies** often means the posting was assembled by committee; focus on the responsibilities.
- **Hard requirements are real**: a teaching licence, a security clearance, the legal right to work in the country, or a certification required by a government contract cannot be argued around.

## Red flags

- Requests to **pay** for training, equipment or a background check before hiring.
- **Unpaid "trial projects"** that look like real client work.
- Interviews only by chat app, offers without interviews, or requests for bank details early. These are common job scams.
- No company name or a company you cannot find any information about.

## Tailoring your application

Use the posting's **language** in your CV when it is true for you. If it says "build dashboards", write "Built a weekly dashboard tracking..." rather than "Created visualisations". Many companies use applicant tracking systems that search for these terms, and human reviewers scan for them too. Lead each bullet with a result: "Cut a monthly report's run time from 40 s to 3 s by adding an index".

## Common mistakes

- **Not applying unless you meet 100%.** Many hires meet most, not all, requirements.
- **Ignoring hard requirements** such as licences, clearances or right to work.
- **Sending the same CV everywhere.**
- **Skipping the responsibilities section**, which predicts the interview.

## Quick recap

- Decode what the team needs, then map each requirement to your evidence.
- Separate must-haves from nice-to-haves; "or equivalent" means flexible.
- Apply when you can evidence most must-haves; close the biggest gaps over time.
- Watch for scams and respect true hard requirements.

## Try it

Open the **Do** tab to map a real posting to your evidence.


Separate must-haves from nice-to-haves in a job posting and map each requirement to your evidence.

Reading job postings

How to Read & Understand Job Postings (Tips to Know When to Apply!) | Indeed Career Tips

Choose a take-home task that fits your role and takes no more than 2 hours, for example: developers build a small feature from the course projects; analysts answer three questions about a public dataset; designers redesign one screen of an app you use; trainers outline a 20-minute lesson; PMs and analysts write a one-page plan or requirements for a small change.

Before starting, write down your assumptions and what "done" means. Set a timer for the limit.

Do the task. When the timer ends, stop and write a README or cover note: what you did, how to run or view it, the trade-offs you made and what you would do with more time.

Choose a live exercise: a beginner coding problem (on a free site such as the practice problems in this platform's courses), a SQL question, a design critique or a five-minute teaching demo.

Record yourself (or ask a friend to watch) doing it in 30 minutes while thinking aloud: restate the problem, ask clarifying questions, describe your plan, then work through it.

Test your answer with at least two examples, including an edge case such as empty input or a missing value.

Watch or review the recording and note two things you did well and two to improve (for example, silence while stuck, or skipping clarification).

Prepare two STAR stories (Situation, Task, Action, Result) for common behavioural questions: a time you solved a hard problem, and a time you handled feedback or disagreement.

## Why it matters

Most tech hiring processes include a test of the actual work: a coding problem, a SQL exercise, a design challenge, a case study or a teaching demo. Interviewers are not only checking for a correct answer. They are watching how you think, communicate and handle being stuck, because that is what working with you would be like. Preparing for the format removes a lot of avoidable stress.

## The core idea: a typical process

Processes vary, but a common sequence is:

1. **Recruiter screen** (20–30 minutes): background, interest, logistics, salary range.
2. **Hiring manager call:** your experience and motivation.
3. **Technical assessment:** a take-home task, a live exercise, or both.
4. **Final round:** several interviews covering technical depth, collaboration and behavioural questions.
5. **Offer** and references.

What the technical part looks like by role:

| Role | Common technical exercises |
|---|---|
| Software / UI / mobile developer | live coding (arrays, strings, maps), a small take-home app, code review of a sample |
| Data analyst / scientist | SQL questions, a take-home analysis, a statistics or experiment question |
| ML engineer | coding, ML concepts, a system design for serving a model |
| Cybersecurity / cloud / DBA | scenario questions ("a server is slow; what do you check?"), troubleshooting, design of a secure setup |
| Systems analyst / IT PM | case study: gather requirements or plan a project; stakeholder scenarios |
| UI/UX / game designer | portfolio walkthrough, a design challenge, critique of an existing product |
| Technical trainer / CS teacher | a short teaching demo, a lesson plan, how you would handle a struggling learner |

## Live exercises: think aloud

Interviewers want to follow your reasoning. A reliable routine:

1. **Restate** the problem in your own words.
2. **Ask clarifying questions:** input size, edge cases, what to return when something is missing.
3. **Work an example by hand.**
4. **Describe a plan** before writing code or designs. Start with a simple working approach; improve later.
5. **Build it**, talking as you go.
6. **Test** with your example and an edge case.
7. **Discuss improvements:** speed, readability, what you would change with more time.

**Worked example.** "Write a function that returns the most common word in a sentence."

- Restate and clarify: "Should it ignore case and punctuation? What if two words tie?" The interviewer says: ignore case, ignore punctuation, return either on a tie.
- Example: "The cat and the hat" gives "the".
- Plan: lowercase, remove punctuation, split on spaces, count with a dictionary, return the word with the highest count.

```python
from collections import Counter
import re

def most_common_word(sentence):
    words = re.findall(r"[a-z']+", sentence.lower())
    if not words:
        return None
    return Counter(words).most_common(1)[0][0]

print(most_common_word("The cat and the hat."))   # the
print(most_common_word(""))                       # None
```

- Test: the example, an empty string, a sentence with punctuation.
- Improve: "If performance mattered on huge text, I would stream the words rather than load them all at once."

Even if you do not finish, this routine shows clear thinking.

## Take-home tasks

- **Respect the time limit.** If they say 3 hours, do not spend 20. Note what you would add with more time.
- **Read the brief twice** and do exactly what it asks first; extras come after.
- **Include a README**: how to run it, your assumptions, trade-offs and next steps.
- **Make it easy to review**: clean structure, sensible names, a few tests or checks.
- Be cautious about take-homes that look like **real unpaid client work** or take days.

## Behavioural questions and STAR

Questions like "Tell me about a time you disagreed with a teammate" are scored seriously. Use **STAR**:

- **Situation:** the context, in one or two sentences.
- **Task:** what you were responsible for.
- **Action:** what **you** did (say "I", not only "we").
- **Result:** the outcome, with a number if you can, and what you learned.

Prepare four or five stories from projects, jobs, volunteering or study that you can adapt to different questions.

## Common mistakes

- **Coding in silence.** The interviewer cannot credit thinking they cannot hear.
- **Jumping in without clarifying.**
- **Not testing your own solution.**
- **Overbuilding take-homes** and blowing the time limit.
- **Memorising answers** instead of understanding them. Follow-up questions expose it.
- **Being afraid to say "I don't know".** Say what you would do to find out.

## Quick recap

- Expect a test of real work; formats vary by role.
- Live: restate, clarify, example, plan, build, test, improve, all while thinking aloud.
- Take-home: follow the brief, respect the time limit, include a clear README.
- Behavioural: tell STAR stories with your own actions and results.

## Try it

Open the **Do** tab to practise a take-home and a live exercise.


Prepare for take-home and live technical exercises by thinking aloud, testing your work and telling clear STAR stories.

Technical interviews

Prepare for Your Google Interview: Coding

How to ace the whiteboard coding interview

Write the role, team and company (real or a posting you mapped in lesson 7). List what you know about its goals and what you still need to learn.

Days 1–30 (learn): write three goals, such as setting up your environment, meeting key people, learning the product and shipping one small change or deliverable.

List five people you will meet in the first month (for example: your manager, a buddy, a teammate in each related role, a key user or stakeholder) and one question for each.

Days 31–60 (contribute): write three goals that involve owning a small piece of work end to end and improving one thing you noticed in month 1.

Days 61–90 (own): write two or three goals that show growing independence, such as owning a feature, a report, a course module or a process.

Add one measurable outcome to each phase (for example, "three PRs merged", "first dashboard used weekly by sales", "first workshop delivered with feedback above 4/5").

Add a line for how you will check in: a weekly one-to-one with your manager and a review of this plan at day 30, 60 and 90.

Start a "brag document" with today's date and leave space to log what you do and its impact each week.

## Why it matters

Getting the job is the start, not the finish. The first three months shape how your team sees you and how fast you grow. Many new hires struggle not from lack of skill but from unclear expectations, hesitation to ask questions, or trying to prove themselves with big changes too early. A **30-60-90 day plan** gives you structure, and some employers ask candidates to present one in the final interview.

## The core idea: learn, contribute, own

A simple plan has three phases:

| Phase | Focus | Typical goals |
|---|---|---|
| **Days 1–30: learn** | people, product, tools, how work gets done | set up your environment; meet key people; understand the product and users; deliver one small change |
| **Days 31–60: contribute** | take on real work with support | own a small task end to end; contribute in meetings; improve one small thing you noticed |
| **Days 61–90: own** | growing independence | own a feature, report, project or course module; help a newer colleague; propose an improvement with evidence |

Each phase should include at least one **measurable outcome** so you and your manager can see progress.

## Worked example: a junior software developer

**Days 1–30**
- Get the app running locally and ship one small bug fix (goal: first PR merged in week 2).
- Meet my manager, my onboarding buddy, the product manager, the designer and someone from support. Ask each: "What do you wish new people understood sooner?"
- Read the team's architecture notes and fix one thing that was out of date.

**Days 31–60**
- Own a small feature end to end with reviews (goal: shipped by day 60).
- Pair with a teammate on an incident or on-call shift to learn how production problems are handled.
- Write down three questions about the codebase and get them answered.

**Days 61–90**
- Lead a medium-size task, including the plan and the review with stakeholders.
- Review two teammates' pull requests per week.
- Present one small improvement (such as speeding up the test suite) with numbers.

**Check-ins:** a weekly one-to-one with my manager; review this plan at days 30, 60 and 90.

## The same idea in other roles

- **Data analyst:** by day 30, know the main tables and definitions (what counts as an "active customer"?); by day 60, own a weekly report; by day 90, deliver an analysis that changes a decision.
- **Cybersecurity or cloud engineer:** shadow on-call and incident reviews, learn the runbooks, then own a hardening or automation task.
- **UI/UX designer:** learn the design system and research history, run a small usability test, then own a feature's design.
- **IT project manager or systems analyst:** map stakeholders, learn the delivery process, then run a small project or requirements effort.
- **Technical trainer or CS teacher:** observe sessions or classes, learn the curriculum and learners, then deliver and improve a module using feedback. New K-12 teachers usually also have induction or mentoring requirements set by their school or state.

## Habits that help

- **Ask good questions.** Try first for a set time, then ask with what you tried. Keep a running list to batch questions for your one-to-one.
- **Write things down.** Notes on setup, decisions and terminology help you and the next new hire.
- **Clarify expectations early.** Ask your manager: "What would a great first 90 days look like for you?"
- **Deliver small things reliably** before proposing big changes. Trust comes from follow-through.
- **Keep a brag document.** Log what you did each week and its impact. You will need it for reviews.
- **Look after yourself.** Feeling overwhelmed in the first months is normal; it is not a sign you were the wrong hire.

## Common mistakes

- **Waiting to be told everything.** Onboarding is often incomplete; take ownership of your learning.
- **Suggesting a rewrite in week two** before understanding why things are the way they are.
- **Hiding mistakes.** Report them early with what you know and what you are doing about it.
- **Only talking to your own team.** Relationships with neighbouring teams make work easier later.
- **Ignoring the plan after writing it.** Review it with your manager at each milestone.

## Quick recap

- First 90 days: learn (1–30), contribute (31–60), own (61–90).
- Give each phase measurable outcomes and review them with your manager.
- Meet key people early, deliver small things reliably and write things down.
- Keep a brag document from day one.

## Try it

Open the **Do** tab to write your own 30-60-90 day plan.


Write a 30-60-90 day plan that helps you learn, contribute and take ownership in a new tech role.

Your first 90 days

Starting a New Job? Here's a 90-Day Plan from Harvard

Preparing for your first day at a new tech job (emotionally, mentally, and professionally)

Read job postings critically, practise technical interviews, and plan your first 90 days in a new role.