N017-H2 Tier 2 · Core SQL · hard hr · Helix Systems

Return one row per salary record, showing the employee's name alongside the salary amount and end date for that record

Part of INNER JOIN in SQL

The problem

Helix Systems' HR team wants to review every salary record on file.

Write a query to return one row per salary record, showing the employee's name alongside the salary amount and end date for that record.

Assumptions:

  • The salaries table contains every salary record ever held by an employee — current and historical. An employee with three salary changes over their tenure has three rows here.
  • The employees table contains every active and former employee at Helix Systems, identified by employees.id.
  • The result row count exceeds the employee headcount because of the one-to-many relationship between employees and salary records.

Output:

  • One row per salary record, with columns employee_name, amount, and end_date.
Schema · hr 4 tables
departments
id integer
name text
location text
budget numeric
salaries
id integer
employee_id integer
amount numeric
effective_date date
end_date? date
employees
id integer
name text
email text
department_id integer
manager_id? integer
hire_date date
title text
is_active boolean
job_history
id integer
employee_id integer
title text
department_id integer
start_date date
end_date? date

Run previews · Check grades

Write a query, then run it to see results here.

Worked solution Try it yourself first
Solution query
SELECT
  e.name AS employee_name,
  s.amount,
  s.end_date
FROM
  salaries s
  JOIN employees e ON s.employee_id = e.id

The shape

One employee can hold many salary records, so the result has one row per salary record, not one row per employee. Sarah Chen appears twice (her 380000 and her 420000), Marcus Reid appears twice, and so on. The join multiplies the employee's row across however many salary records they have, with the employee's name duplicated on each.

Clause by clause

  • FROM salaries s reads from the salaries table, the many side of the relationship. Each row is one salary record, with an employee_id linking back to the person who held it.
  • JOIN employees e ON s.employee_id = e.id pairs each salary row with its employee. For every row in salaries, PostgreSQL finds the matching row in employees and attaches the employee's columns. An employee with three salary records gets paired three times — one pairing per salary row — and the employee's name appears three times in the result.
  • SELECT e.name AS employee_name, s.amount, s.end_date returns the employee's name from the employees side and the salary record's amount and end date from the salaries side. The row count of the result matches the row count of salaries, not the headcount of employees.

Why this and not the other direction

The choice of which table to put in FROM versus JOIN doesn't change the result for an inner join. The conventional pattern is to put the many side first when the report is about "every salary record," because the FROM table's row count is the report's row count. Reading the query top-down, FROM salaries immediately signals that the answer is one row per salary record.

The trap

The trap is reading the result row count as if it were the employee count. A row count of 137 doesn't mean Helix has 137 employees. It means there are 137 salary records on file, spread across however many distinct employees. An employee with several historical raises contributes multiple rows, and their name repeats on each.

The rule: when a join multiplies, the result row count is the count of the many side, not the count of the one side. Mistaking the row count for a headcount is the standard one-to-many error, and it's silent. The query runs cleanly and the number looks plausible until you check it against the known employee total.

You practiced an INNER JOIN where the multiplying side is the fact table (salaries) and the parent (employee) appears repeated across multiple rows. The recurring shape: a one-to-many join always produces one output row per fact-table row, with the parent's columns duplicated as needed.

How you actually get good at SQL

Reading explains SQL. Writing it, over and over with instant feedback, is what makes you fluent.

That's the whole SQLMaxx loop: 600+ real problems, instant AI feedback, mastery you can actually see, and spaced review that won't let you forget.

A stack of SQL practice problem cards, the top card showing an employees table.
615 problems · 66 concepts

Real problems. Not toy examples.

615 hand-built problems spanning all 66 concepts, from basic SELECTs to window functions, built on real schemas and real business questions, the kind you'll actually get asked on the job. Enough reps to make SQL automatic.

A retro computer showing a SQL query marked correct with a green checkmark.
Instant AI feedback

Write a query. Know if it's right in one second.

No copying an answer and hoping it clicked. The AI grader checks your real query against real data, catches exactly what's wrong, and explains the fix in plain English, like a senior analyst reading over your shoulder on every problem.

A circular mastery progress dial filling from blue to green, the SQLMaxx diamond at its center.
Mastery tracking

Stop guessing whether you actually know it.

SQLMaxx tracks every concept and shows you what you've mastered and what's still shaky. Your skills fill in one concept at a time, so 'I think I get joins' becomes something you can prove.

A SQL query editor circled by a blue return arrow with a clock, scheduled to come back for review.
Spaced review

Learn it once. Keep it for good.

Most of what you learn this week fades by next week. So when a concept comes due for review, SQLMaxx hands you a fresh problem to solve from a blank editor, not a flashcard to re-read. A research-backed spaced-repetition algorithm (FSRS) times each return for right before you'd forget, so your SQL is still there months later, when the interview or the job actually needs it.

Practice, feedback, mastery, review. That's the loop that turns reading into real skill.

Start free

No account, no credit card. Start solving in under a minute.