Switching Into Data? Your Old Job Is the Unfair Advantage

If you’re moving into data from another career, you’ve probably had this thought, usually late at night. Everyone else applying for analyst jobs seems to have a computer science degree, or three years of Python, or both. You have years in a billing office, a warehouse or a classroom. So you’re starting from zero, aren’t you?

We’d rather test that than argue about it. With a table, and two learners we’ve made up for the purpose.

One of them has his SQL down cold; we’ll call him the fast learner. The other, Ama, spent nine years in a hospital billing office. She can tell you, without looking anything up, what a denied claim is worth, why a coverage code matters and which insurer never rings back on a Friday. What she couldn’t tell you a year ago was the difference between WHERE and HAVING.

Same table, two first queries

Here’s the setup. Both get the same practice table: insurance claims from HealSync, a fictional hospital network whose data we built to be messy on purpose, 102 rows of claims. The question is one every finance team gets round to eventually: what’s our reimbursement rate?

The fast learner goes first. One query, thirty seconds:

SELECT ROUND(100 * SUM(Reimbursement_Amount)
                 / SUM(Claim_Amount), 1) AS reimbursement_rate
FROM insurance_claims;

74.3%. A clean number, ready for a slide. And to be fair to him, the query is right: it’s exactly the SQL for the question as written.

Ama is slower. Her SQL is still new enough that she checks the syntax twice. But her first query isn’t a total at all. In billing, a claim’s status decides everything that happens to it, so before she adds anything up, she wants to see the statuses.

SELECT Claim_Status,
       COUNT(*) AS claims,
       COUNT(*) FILTER (
         WHERE Reimbursement_Amount > 0
       ) AS with_a_payout,
       ROUND(SUM(Reimbursement_Amount), 2) AS total_paid
FROM insurance_claims
GROUP BY Claim_Status
ORDER BY Claim_Status;

The fast learner reads that table as a breakdown: three statuses, roughly even, fine. Ama reads it the way she’d have read a remittance landing on her desk in the old job, and stops on the middle row. Then she reads it again, slowly, in case it says something else the second time.

Denied. And paid.

Every one of the 34 rows marked Denied carries a reimbursement. Between them they were paid 79,154.29, against 63,578.54 for the approved claims, and the gap survives taking out the two claims that were recorded twice. In a billing office, a denied claim pays nothing. That isn’t an insight. It’s what you learn in your first week.

And once she’s seen one impossible thing, she goes looking for the rest. Her old rules turn straight into SQL, each one a check that ought to come back empty:

Thirty-nine rows paid more than was claimed. All 40 rows with no coverage paid out anyway. So the 74.3% isn’t really a rate. It’s an average over payments that, by the rules of the business, shouldn’t all exist. The fast learner’s query was correct; the number it produced wasn’t one anybody should act on yet.

Why it’s an unfair advantage

So what was the fast learner missing? Not SQL: his was better. Not care: he did exactly what was asked. He was missing a list of things that can’t happen, and no SQL course teaches that list, because it’s different in every industry.

That list is what domain knowledge actually is. Less “I know healthcare”, more a few hundred small rules about what’s normal, what’s impossible and what’s suspicious, built up over years and mostly never written down. A credit controller knows an invoice can’t be overdue before it’s due. A sustainability officer checks the units before the trend. A buyer knows which supplier’s delivery dates are always a week optimistic.

Here’s why it’s unfair, in your favour: it can’t be crammed. The SQL can be learned on evenings and weekends. Nine years in a billing office can only be spent.

How to spend it

So if your old job is the advantage, the trick is making sure the people hiring can see it. Four moves, in this order:

1. Practise on data from your old world. The Community’s datasets page filters by domain, from finance and accounting to health, environment and agriculture. A project in a field you know lets your rules do the work.
2. Write your rules down before you analyse. Each one becomes a WHERE clause that should return nothing. When it doesn’t, you’ve found your story.
3. Lead with what only you would have noticed. “Denied claims were paid more than approved ones” is a first line nobody forgets, and it belongs at the top of the project, not halfway down the notebook.
4. Translate the old job into data verbs. Not “processed claims”, but what you checked, with which tool, and what changed because of it.

And if you want a course on the same kind of data as your old job, each Academy course is built on one field’s tables:

One honest caveat, though, ahead of any CV rewrites. None of this lets you skip the SQL. Ama still had to write the GROUP BY, and the fast learner will pick up billing rules if he spends a year near a claims desk. The advantage is real. It just isn’t permanent.

An advantage with a sell-by date

There’s a catch, though, and we haven’t solved it. Your rules are an advantage because they’re fresh, and every year you spend in data makes them a little older. The billing codes change, the insurers change, and the office you remember stops being the office that exists.

So how long can you live off the job you left, and what will you know as well as Ama knows a denied claim by the time it runs out?