The Job Market & Roles

The data job landscape

Back in Course 1, Chapter 01, you met the data team as a set of overlapping responsibilities rather than tidy boxes. The job market reflects exactly that messiness: the same work shows up under five different titles, and two companies can mean opposite things by the same word. Here's the spectrum, laid out from "closer to the raw infrastructure" on the left to "closer to the business question" on the right:

The boundaries are blurry on purpose — most real jobs straddle two of these. A "Data Engineer" at a small startup may do everything from spinning up infrastructure to writing the analytics models. The same title at a big tech company may be a narrow, well-defined slice. Don't take the label at face value; read the actual responsibilities (we'll do exactly that below).

Titles & seniority

On top of the role, every posting carries a seniority level. The ladder is roughly the same everywhere, even when the words differ:

Let's be honest and encouraging at the same time. A realistic first role from this curriculum is a junior-to-mid Data Engineer or Analytics Engineer. That's not a consolation prize — it's the front door of a field where mid-level engineers are in real demand and senior compensation climbs steeply. You're not trying to land "Staff Data Engineer" out of the gate; you're trying to get in, do good work, and let the ladder do the rest.

Who hires data engineers

"A data job" can mean wildly different day-to-day experiences depending on the kind of company. For a first role, the type of employer matters as much as the title, because it shapes how much you'll learn, how much support you'll get, and how forgiving the environment is while you find your feet.

How to read a job description

Most beginners read a job description as a pass/fail checklist and disqualify themselves on sight. That's a mistake. A JD is a wish-list written by a committee, not a contract. Your job is to separate the genuine must-haves from the aspirational padding — and to recognise the postings that are red flags in disguise.

The classic trap is the inflated JD: "5–8 years experience, expert in Spark, Kafka, Airflow, dbt, Snowflake, BigQuery, Kubernetes, Terraform, and 12 other tools." Almost nobody on Earth matches that. It's a wish-list, and the team would happily hire someone who's strong on the fundamentals and knows a few of those tools well. Here's how to decode the language:

Mapping a JD to your skills. Print (or paste) the posting and mark each requirement: ✓ I can demonstrate this, ~ I've touched it, ✗ never seen it. If you hit most of the ✓ on the genuine must-haves and the ✗ items are all in the "nice to have" pile, you're a fit — apply. Your capstone gives you a concrete answer for most of the core items, which is exactly why it's your biggest asset.

How compensation works

Pay in this field has three components, and understanding the structure matters more than chasing any single number:

Here's the honest part: compensation ranges vary enormously by country, city, cost of living, company size, industry, and seniority — by multiples, not percentages. Any specific number you read online is a snapshot of one context and can mislead you badly in another. So this chapter deliberately won't quote dollar figures as fact. Instead, learn to research comp for your own situation:

• Level-comparison sites (levels.fyi-style aggregators): strongest for big/public tech companies, where employees self-report base, bonus, and equity by level. Treat the data as indicative, not gospel — samples skew toward higher-paying firms.
• Glassdoor / Indeed / LinkedIn Salary: broader coverage including smaller and non-tech employers, but noisier and often self-selected. Use the range and median, not a single point.
• Public salary data: some regions and many job boards now require posted salary ranges — read them directly off the postings in your market.
• Ask real people: the most accurate source. Communities, alumni, and contacts in similar roles and locations will often share ranges privately. A polite "what does a junior DE in [city] typically make?" goes a long way.

Where the jobs are

Not all channels are equal. The single biggest mistake job-seekers make is pouring all their energy into the lowest-yield channel — blasting applications into job boards — while ignoring the one that actually converts. Here's the realistic picture:

✓ Check yourself

Answer from memory before opening each one.

1. Two postings both say "Data Engineer". One is a 15-person startup with no data team; the other is a large tech company. Why can't you infer the day-to-day work from the title, and what do you read instead?

   Show answer

   The roles are overlapping responsibilities, not tidy boxes: at the startup the title may cover everything from infrastructure to analytics models, while at the big company it is a narrow, well-defined slice. Read the listed responsibilities and place them on the spectrum from infrastructure to business question — that tells you whether the job is really platform, pipeline or analytics-engineering work. See The data job landscape.

2. A posting lists SQL, Python and a cloud warehouse as "required", asks for "5–8 years", and names Spark, Kafka, Kubernetes and Terraform under "experience with". You can demonstrate the three required items from your capstone and have never touched Kafka or Kubernetes. Apply or skip, and how do you treat the years and the tool list?

   Show answer

   Apply. A JD is a wish-list written by a committee: the "required" core is the real filter and you hit all of it, the long tool list is the team's stack (matching 50–60% is enough), and the years are an anchor rather than a gate. The tempting move is to treat every line as pass/fail and disqualify yourself on sight. See How to read a job description.

3. One posting wants a single hire to cover data engineering, data science, ML engineering and BI, and never mentions testing or data quality. Another is long and demanding but specific, and asks for "familiarity with data modelling and testing". What does each tell you about the team?

   Show answer

   The first is the do-everything unicorn — usually an understaffed, chaotic team — and the silence on quality suggests a firefighting culture; both are red flags. The second is healthy: demanding-but-specific is fine, and a line about modelling and testing signals a team that cares about doing it right, which is exactly where this curriculum is strongest. See How to read a job description.

4. You spend most of your search hours applying through LinkedIn and Indeed and hear almost nothing back. What does the chapter say those boards are actually good for, and where should the hours go instead?

   Show answer

   Job boards are the lowest-yield channel; use them as a discovery tool to find companies, then route the application through something warmer. Referrals have the highest yield — a referred application is far more likely to get a real human look — so a meaningful share of the time goes to relationships and communities, built before you need them. See Where the jobs are.

5. An article says data engineers earn a headline figure that is double what any posting in your city offers. Why does the chapter tell you not to anchor on it, and how do you build a number you can trust?

   Show answer

   Pay varies by multiples across country, city, company size and seniority, and the eye-popping numbers are mostly senior engineers at a few elite firms in expensive cities — real, but not your baseline. Combine several sources filtered to your role, level and location: level-comparison sites (strong for big tech, skewed high), Glassdoor-style ranges and medians, salary ranges posted in your own market, and people in similar roles. See How compensation works.

6. You hold two junior offers: sole data hire at an early startup, touching everything, and a junior seat on a six-person data team at a regional insurer with an older stack. Which is the better first role, and what decides it?

   Show answer

   It turns on how much guidance you need. The startup gives the broadest scope and ownership but thin mentorship, a lower base and less stability — great if you are scrappy and can teach yourself, risky if you need someone reviewing your work. The insurer is the underrated entry point: steady base, high stability, often well mentored, and the skills transfer even if the stack is less trendy; for most people finding their feet it wins, and the startup wins when you have already worked independently and value breadth over support. See Who hires data engineers.

POSTING: Data Engineer · Scaleup · 3–5 yrs experience

REQUIREMENTS (✓ can show / ~ touched / ✗ never):
  ✓  Strong SQL                         -> capstone models + drills
  ✓  Python for data pipelines          -> capstone ingestion code
  ✓  A cloud data warehouse             -> built on one in capstone
  ~  Airflow / orchestration            -> used it; not expert
  ✓  Data modelling & testing           -> dbt + tests in capstone  (GREEN FLAG: they care about quality)
  ✗  Kafka / streaming                  -> listed under "nice to have"
  ✗  Kubernetes                         -> listed under "bonus"
  "3–5 yrs"                             -> anchor, not a gate

MUST-HAVES (real):   SQL, Python, a warehouse, data modelling/testing  -> I hit all 4
NICE-TO-HAVES:       Kafka, Kubernetes, Airflow depth                  -> partial / optional
RED FLAGS:           none — specific, quality-aware, defined scope

FIT VERDICT:  STRETCH-but-apply.
  I match every genuine must-have. The ✗ items are all optional.
  Plan: apply, and in the cover note connect my capstone's testing
  work to their "data modelling & testing" line. Try to find a referral.

Takeaway

• The same work appears under five titles and one title means different things at different companies, so read what a role does, not what it is called.
• This curriculum maps most directly onto Data Engineer and Analytics Engineer roles, and a realistic first job is junior to mid level in one of them.
• A job description is a wish-list written by a committee: separate the real must-haves such as SQL, Python and a warehouse from the tool list, and apply when you match about half of it.
• The type of employer shapes a first role as much as the title; scaleups are often the sweet spot, and banks, hospitals and retailers are underrated entry points with less competition.
• Pay has three parts, base, bonus and equity, and for a first job you weight the guaranteed base most and treat the rest as upside.
• Build your salary picture from several sources filtered to your role, level and location, because any single number is a snapshot of one context.
• Referrals convert best, so use job boards to discover companies and then route the application through a warmer channel.

You know which roles to target and how to read them, so the next chapter makes you findable and credible to the people who hire for them. → Your Portfolio & Online Presence

Further reading

• 15-1243.01 Data Warehousing Specialists — O*NET OnLine, US Department of Labor. Tasks, skills and technologies for a core data engineering occupation, useful for checking a job description against.
• Database Administrators and Architects — US Bureau of Labor Statistics, Occupational Outlook Handbook. Duties, pay and outlook for the closest federal occupation category.
• Occupational Employment and Wage Statistics — US Bureau of Labor Statistics. Public wage data by occupation and region, the neutral check on aggregator numbers.