Interview & Resume

Data Analyst Interview Questions: The Guide for Career Changers in Australia

Anudithi Saxena · Career Consultant · August 20, 2026 · 32 min read

You have been doing analysis for years. You just did not have the job title.

Maybe you ran the roster for a contact centre and worked out which shifts were bleeding money. Maybe you taught for a decade and rebuilt your assessment tracking because the spreadsheet the school gave you was useless. Maybe you sat in accounts payable and found the duplicate supplier that had been paid twice a month since before you started. That is analysis. You did it without being asked and nobody called it a career.

So you decided to make it official. You did a course, or a bootcamp, or you worked through SQL exercises at night after the kids went down. You rewrote your CV, you set up alerts on Seek, and you started applying. And then one of two things happened. Either nothing came back at all, or you got to a technical round, somebody shared a screen with two tables on it, and your mind emptied out.

I sit with people in exactly that position most weeks. The frustrating part is how rarely it is a capability problem. Career changers moving into analytics are usually better at the part that is hard to teach, which is asking the right question of a business, and they lose on the part that is easy to teach, which is writing a join without hesitating.

This guide is the whole loop for an entry level data analyst role in Australia. The rounds, the real questions, the queries written out with the reasoning underneath them, and the answers that work when you are switching fields rather than climbing a ladder you are already on.

Two notes before we start.

On wording. Australian advertisements use both common words for the same document interchangeably, and you should read nothing into which one an advert picks. This article says CV throughout.

On the numbers. The figures inside the model answers below exist to show the shape of a strong answer and nothing else. They are not market data and they are not benchmarks to copy. Anything you say in a real interview has to be yours, and it has to survive the follow up question, which is nearly always some version of how do you know that.

What questions are asked in a data analyst interview?

Five layers. SQL, which carries the most weight. Spreadsheet and data cleaning questions. A visualisation layer covering Power BI or Tableau. Statistics at a working level. Then a business case where you are handed a metric that moved and asked how you would investigate. Behavioural questions sit around all of it. The SQL test and the case round decide most entry level outcomes.

Nearly everyone prepares the SQL. Almost nobody rehearses the case round out loud, and that is the round where career changers should be winning, because it rewards the years you already spent inside a business.

Why capable career changers interview badly

The market is crowded at the front door and thin just behind it, so one junior analyst advertisement in Melbourne opens a very full inbox of near identical applications. Same certificates, same tutorial projects, same sentence about turning data into insights.

The person reading them is usually an analytics lead carrying a queue they cannot service. They are not hunting for brilliance. They want somebody who will not create work, and their private fear is a hire who produces a wrong number that nobody catches until it is in a board pack. The senior analyst beside them is asking something narrower: will I have to check this person’s output forever, or only for three months. Neither of them cares that you finished a certificate. Both care whether you check your own work.

Which is why four things sink capable people, all of them fixable in a fortnight.

You apologise for your background instead of using it. Twelve years in operations is domain knowledge a graduate does not have, and domain knowledge is why analysts get promoted.

Your SQL is recognition, not recall. You can follow a query on a screen. You have never written one from blank while a stranger watches, and only one of those gets tested.

Your portfolio answers no question. A notebook that loads a tidy dataset, plots four charts and stops shows only that you can follow instructions, which is precisely what the panel is already worried about.

You have never said any of it out loud. A window function you can explain inside your own head is not one you can explain while somebody holds eye contact and waits. Say it to a wall first.

The interview loop for an entry level data analyst role in Australia

Stage	Who runs it	Length	What passes	What fails
CV screen	Recruiter or hiring manager	A scan, not a read	Tools named plainly, one project with an outcome, location and working rights visible	A skills wall with no evidence, duties with no results, no portfolio link
Recruiter call	Internal talent or agency consultant	15 to 25 min	A clear reason for the switch, honest tool levels, salary and notice ready	Vagueness about what you can actually do, no questions asked back
Technical test	Automated platform or take home	45 min to 3 hrs	Working SQL, sensible assumptions written down, clean presentation	Unstated assumptions, a query that runs but answers the wrong question
Technical interview	Senior analyst	45 to 60 min	Thinking out loud, checking your own output, saying what you would verify	Silence, guessing, claiming a tool you half know
Case or stakeholder round	Analytics lead plus a business person	45 min	Clarifying questions first, a structure, a recommendation with limits named	Jumping to a cause in the first thirty seconds
Hiring manager and culture fit	The manager, sometimes with HR	30 to 45 min	A clear reason for wanting this specific team, questions about the data itself	Generic answers, no curiosity about the business

The order moves around. Smaller employers merge the technical test and the technical interview into one live session. Banks, insurers and large retailers in Sydney and Melbourne often keep them separate, and an online assessment sometimes sits in front of both, though that is most common in graduate and early careers programmes rather than in lateral hiring for a single junior seat. Federal and state government roles usually replace the culture round with a panel scoring against published selection criteria, and you should answer those using the words the criteria use, because a panel cannot award points for something they cannot map.

Round 1: the recruiter call

Fifteen to twenty five minutes with somebody who cannot assess your SQL and will never open your dashboard. It is tempting to treat it as a formality. It is the round that decides whether you are described to the hiring manager as a career changer with real operational depth or as another bootcamp graduate.

So hand them specifics rather than a summary. A recruiter who cannot repeat what you actually do falls back on the category you arrived from, and the category is always duller than the person.

The opening, done well

Do not start at the beginning. An answer that walks forward through your working life spends its best thirty seconds on the job furthest from the one you want, and the listener has stopped writing by the time you reach the analysis.

“I am moving into analytics from operations. Nine years in a health insurer, the last four running the claims processing team, so about eighteen people and a monthly volume I reported on every cycle. The analysis part of that job grew until it was most of my week: I built the reporting the team ran on, and I was the person who worked out why a number looked wrong. I have spent the past year making that formal, so SQL to a working level with joins, aggregations and window functions, Power BI for the reporting side, and enough Python to clean a file. I am in Brisbane, full working rights, four weeks notice, and I am looking for a junior or associate analyst role where the domain is complicated.”

That is about forty five seconds. Count what it carries. A reason for the switch that is a continuation rather than an escape. Scope in numbers. An honest tool inventory with a stated ceiling. Location, rights, notice. And a preference at the end that quietly tells them you are not applying to everything.

The last line matters more than it looks. Saying you want somewhere the domain is complicated is a career changer’s strongest card, because it is exactly what a graduate cannot offer.

What the screening questions are really for

Question	What it is checking	How to answer
Why are you moving into data?	Whether this is considered or a reaction	Give the moment the analysis part of your old job took over, not a passion statement
What is your SQL like?	Whether they can submit you without embarrassment	Name what you can do and name where it stops
Have you used Power BI or Tableau?	Which tool stack fits	Say which one, at what depth, and whether you have published anything
Do you have full working rights?	Whether you can be submitted at all	Answer at once, and say what your visa allows rather than leaving them to infer it
What salary are you after?	Budget fit	Ask for the band first, then answer inside it
When could you start?	Fit with the client date	Real notice period, and what would move it
Do you have a portfolio?	Whether there is anything to show	Have one link ready, not five

One clarification on the working rights row, since government analyst advertisements come up often in this search. Most Australian Government roles require Australian citizenship, which is a separate question from working rights, and a security clearance is sponsored by an employer through the government vetting process rather than something you can obtain and carry in, so there is nothing to arrange in advance.

The salary question, for a first analytics role

You are negotiating from the weakest position you will ever hold, so the goal here is not to win. It is to avoid pricing yourself out of the round or anchoring yourself into a number you will resent in six months.

You: “Happy to talk about it. What has been budgeted for the role? I have a range in mind but yours is the one that matters, and if it works I will tell you straight away rather than string it out.”

If they insist you go first: “For a first analyst role I am looking at the entry band rather than trying to price in my operations experience, because I know the title is a step across. What I care more about is whether there is a senior analyst I would learn from. Give me the approved range and I will give you a straight answer on it.”

That only works if you have done the reading first, and an afternoon covers it. Start with live advertisements rather than aggregate data, because a band printed in an advertisement is one somebody has already approved. Read every junior and associate analyst posting for your city and note which ones publish a figure. Then widen it with the annual salary guides the large recruitment firms put out for technology and analytics hiring in Australia, and the ranges Seek, Glassdoor and LinkedIn carry for the same title in the same city. Treat all of it as a spread rather than a target, and adjust for yourself honestly, because a first analytics title sits below the headline, the two largest capitals sit above the smaller ones, and permanent and contract are not comparable numbers at all. What you want out of it is not a figure to demand. It is the ability to hear their band and know at once whether it is normal.

One Australian specific. If the role is a contract quoted at a daily rate, ask whether the rate includes superannuation or sits on top of it, and confirm the current superannuation guarantee rate on the Australian Taxation Office site rather than trusting a figure somebody quoted you two years ago. Most entry level analyst roles here are permanent, so this comes up less than it does further up the ladder, but it is worth one question when it does.

If you want the longer version of what happens to your application after you agree to be submitted, there is a walkthrough of the submission process that covers it end to end.

Do you need SQL for an entry level data analyst job in Australia?

Yes, and it is the single most tested skill. You need joins, filtering, aggregation with GROUP BY and HAVING, subqueries or common table expressions, and at least ROW_NUMBER and LAG from the window functions. You are not expected to tune a query plan. Being unable to write a working join under mild pressure ends most entry level processes on the spot.

What follows is the actual question set, with the answers written out. Under each one is the part that matters more than the syntax, which is what the interviewer is grading.

One note before the first query. These are written in Postgres style SQL and function names shift by dialect, so DATE_TRUNC works in Postgres and Snowflake but is not available in most SQL Server versions or in MySQL, where the same bucketing is done with DATEADD or DATE_FORMAT. If the advertisement names the database, practise in that dialect and say which one you are writing in before you start typing.

Joins

Question: “What is the difference between an inner join and a left join, and when would you use each?”

An inner join returns only the rows that match on both sides. A left join keeps every row from the left table and fills the right side with nulls where nothing matches.

The answer that gets you past it is the business consequence.

“The reason I care about the difference is that choosing the wrong one does not throw an error. It just changes the answer while looking fine. If I join customers to orders with an inner join and then count customers, I have silently excluded everybody who has never ordered, which is usually the group the question was about. So my habit is to check the row count before and after any join. If it went up, I have a fan out from a one to many relationship and my sums are now double counting. If it went down more than I expected, I have lost rows to a key mismatch, usually whitespace or case in a text key.”

That paragraph is the whole answer. Row counts before and after is the single most useful sentence a junior analyst can say in a technical round.

GROUP BY, and the HAVING question

Question: “Give me every customer with more than three orders in the last ninety days, with their total spend, highest spend first.”

SELECT c.customer_id,
       c.customer_name,
       COUNT(o.order_id)  AS orders_90d,
       SUM(o.order_total) AS spend_90d
FROM   customers c
JOIN   orders    o ON o.customer_id = c.customer_id
WHERE  o.order_date >= CURRENT_DATE - INTERVAL '90' DAY
  AND  o.status <> 'CANCELLED'
GROUP  BY c.customer_id, c.customer_name
HAVING COUNT(o.order_id) > 3
ORDER  BY spend_90d DESC;

What they are grading: whether you know that WHERE filters rows before grouping and HAVING filters groups after. Candidates who put the count in the WHERE clause have not understood the order of operations, and it is a fast signal.

Now the sentence that separates you from somebody who memorised the pattern.

“One thing I would check before I trusted this. That status filter excludes cancelled orders, but if status is nullable then rows where status is null get dropped too, because a comparison with null is not true. If cancelled is the exception and null means normal, I have just thrown away most of the data. I would run a count grouped by status first to see what values actually live in that column, because a status field that has been through a migration or two tends to accumulate variants nobody ever went back and cleaned up.”

Null handling is the most common real world bug in junior SQL and almost nobody raises it unprompted.

The second highest value question

It is a cliche and it still gets asked, because the follow up is where the information is.

Question: “Find the second highest salary in the employees table.”

The version without window functions:

SELECT MAX(salary) AS second_highest
FROM   employees
WHERE  salary < (SELECT MAX(salary) FROM employees);

The version with them:

SELECT DISTINCT salary AS second_highest
FROM  (SELECT salary,
              DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
       FROM   employees) ranked
WHERE rnk = 2;

What they are grading is the edge cases, so raise them yourself.

“Two things worth saying. If everybody earns the same amount, the first query returns null rather than an error, which is usually the behaviour you want, and the second returns no rows at all, which is a different thing and worth knowing. And DENSE_RANK is deliberate. If two people tie for the top salary, RANK skips straight from one to three and rank two is empty, so the query silently returns nothing. Which one is right depends on whether the business means the second highest amount or the second highest person, and that is a question I would ask rather than assume.”

Window functions

Three of them cover most entry level tests: ROW_NUMBER, RANK or DENSE_RANK, and LAG.

Question: “Give me the top three products by revenue within each category.”

SELECT category, product_name, revenue
FROM (
  SELECT p.category,
         p.product_name,
         SUM(s.line_total) AS revenue,
         ROW_NUMBER() OVER (
           PARTITION BY p.category
           ORDER BY SUM(s.line_total) DESC
         ) AS rn
  FROM   sales    s
  JOIN   products p ON p.product_id = s.product_id
  GROUP  BY p.category, p.product_name
) ranked
WHERE  rn <= 3
ORDER  BY category, revenue DESC;

The two details being watched: that you know PARTITION BY restarts the numbering per group, and that you know you cannot filter on a window function in the same WHERE clause, which is why it sits inside a subquery or a common table expression.

Question: “Show monthly revenue with the change from the previous month.”

SELECT month_start,
       revenue,
       LAG(revenue) OVER (ORDER BY month_start) AS prev_month_revenue,
       revenue - LAG(revenue) OVER (ORDER BY month_start) AS change
FROM   monthly_revenue
ORDER  BY month_start;

Then say the thing about the partial month.

“The trap in month over month reporting is the current month, because it is incomplete and it will always look like a collapse. I would either exclude it or label it clearly, and I would rather do that in the query than rely on the person reading the dashboard to remember.”

The self join

Question: “Here is an employees table with a manager_id that points back at employee_id. List everybody with their manager’s name.”

SELECT e.employee_name,
       m.employee_name AS manager_name
FROM   employees e
LEFT  JOIN employees m ON m.employee_id = e.manager_id;

The grading point is the LEFT. The chief executive has no manager, so an inner join quietly drops the most senior person in the company, which is a memorable way to be wrong.

Date bucketing

Question: “Orders per month for the last financial year, with distinct customers.”

SELECT DATE_TRUNC('month', order_date) AS month_start,
       COUNT(*)                        AS orders,
       COUNT(DISTINCT customer_id)     AS customers
FROM   orders
WHERE  order_date >= DATE '2025-07-01'
  AND  order_date <  DATE '2026-07-01'
GROUP  BY DATE_TRUNC('month', order_date)
ORDER  BY month_start;

Three Australian details here that will make you sound like somebody who has done this before.

The financial year runs July to June, so a request for last year is ambiguous and you should ask which one they mean before writing anything. Months with no orders vanish from this result rather than showing zero, and if the chart needs them you join against a calendar or date dimension table. And if your timestamps are stored in UTC while the business reports in Australian local time, your daily and monthly boundaries are wrong by up to eleven hours, which quietly moves transactions between months. Say that out loud. It is the kind of thing seniors have been burned by.

Deduplication

Question: “This staging table has duplicate contacts. Keep the most recent record per email address.”

WITH ranked AS (
  SELECT s.*,
         ROW_NUMBER() OVER (
           PARTITION BY LOWER(TRIM(email))
           ORDER BY updated_at DESC, source_id DESC
         ) AS rn
  FROM   staging_contacts s
)
SELECT *
FROM   ranked
WHERE  rn = 1;

What is being graded is whether you thought about two things: what defines a duplicate, and what breaks a tie. The LOWER and TRIM matter because in a real staging table the same person arrives as an address with a capital letter and a trailing space. The second sort key matters because without a tiebreaker the result is not deterministic, so the same query returns different rows on different runs, which is the sort of bug that takes a week to find.

The funnel drop off question

This is the one that most often decides the technical round, because it is half SQL and half thinking.

Question: “We have an events table with session_id, step, and event_time. Where are people dropping out of the checkout funnel?”

SELECT COUNT(DISTINCT CASE WHEN step = 'view_product' THEN session_id END) AS viewed,
       COUNT(DISTINCT CASE WHEN step = 'add_to_cart'  THEN session_id END) AS added,
       COUNT(DISTINCT CASE WHEN step = 'checkout'     THEN session_id END) AS reached_checkout,
       COUNT(DISTINCT CASE WHEN step = 'purchase'     THEN session_id END) AS purchased
FROM   events
WHERE  event_time >= CURRENT_DATE - INTERVAL '28' DAY;

Write it, then immediately criticise it, because that is the actual test.

“That gives me the four counts but it is not really a funnel, because it does not enforce order. A session that lands straight on checkout from a saved link gets counted at checkout without ever appearing at view_product, so my conversion between steps can exceed one hundred and look absurd. The stricter version takes the earliest timestamp per session per step and only counts a session at step three if it has a step two that happened before it. I would also cut this by device, by browser and by day before drawing any conclusion, because in my experience a funnel that looks broken overall is usually broken on one platform.”

Then the query that shows you can build the ordered version:

WITH first_step AS (
  SELECT session_id,
         step,
         MIN(event_time) AS first_seen
  FROM   events
  WHERE  event_time >= CURRENT_DATE - INTERVAL '28' DAY
  GROUP  BY session_id, step
)
SELECT COUNT(DISTINCT v.session_id) AS viewed,
       COUNT(DISTINCT a.session_id) AS added_after_view,
       COUNT(DISTINCT p.session_id) AS purchased_after_add
FROM       first_step v
LEFT JOIN  first_step a ON a.session_id = v.session_id
                       AND a.step = 'add_to_cart'
                       AND a.first_seen > v.first_seen
LEFT JOIN  first_step p ON p.session_id = v.session_id
                       AND p.step = 'purchase'
                       AND p.first_seen > a.first_seen
WHERE      v.step = 'view_product';

If you can write the first query and then say why it is not good enough, you have already outperformed most of the field.

The Excel and spreadsheet questions that still get asked

Do not skip this preparation because it feels beneath the job. A very large share of Australian analyst work still lands in a spreadsheet, and finance, operations and government teams test it deliberately.

XLOOKUP against VLOOKUP

Question: “Why would you use XLOOKUP instead of VLOOKUP?”

VLOOKUP only searches to the right of the key, takes a column index number that silently breaks the moment somebody inserts a column, and defaults to an approximate match, which is the source of an enormous amount of quietly wrong data.

=XLOOKUP(A2, Staff[EmployeeID], Staff[Department], "Not found", 0)
=INDEX(Staff[Department], MATCH(A2, Staff[EmployeeID], 0))

XLOOKUP looks in any direction, matches exactly by default, and takes a value to return when nothing is found, so the sheet says Not found rather than showing an error a manager will screenshot. INDEX and MATCH does the same job and is the answer to give if the employer is on an older version, because XLOOKUP is not available everywhere. Mentioning that yourself reads as practical rather than pedantic.

Pivot tables

Question: “Talk me through building a pivot table to show monthly sales by region.”

Region into rows, the date field into columns grouped by month, the sales value into values set to Sum. Then say the two things that go wrong.

“The first thing I check is whether the value field defaulted to Count instead of Sum, because that means there are blanks or text sitting in a numeric column, and I would rather fix the column than override the setting. The second is Show Values As, because most of the questions people actually ask are proportional. Per cent of column total answers which region is growing its share, and the raw number does not.”

Cleaning a messy export

Question: “You have been handed a CSV export from a legacy system. Walk me through cleaning it.”

“First I do not touch the original file, I work on a copy, because the one thing worse than dirty data is a cleaning step nobody can reproduce. Then I look at the column types before anything else. Dates are the usual problem, because a system exporting from an American default writes months and days the wrong way round for us, and the rows where the day is twelve or less convert silently while the rest stay as text. That is the failure mode that gets a report retracted. After that: TRIM and CLEAN on the text keys, check for duplicates on whatever the real key is, look at the blank counts per column, and check anything that looks like a code. Postcodes are the classic here, because Excel eats the leading zero and the Northern Territory postcodes all begin with a zero. If it is a repeating job I do the whole thing in Power Query instead so the steps are recorded and the next month takes one refresh.”

That answer names two specific Australian traps and one working habit. It is worth more than any formula.

Do I need Python to get a data analyst job?

For a large share of Australian entry level analyst roles, no. Those roles run on SQL, spreadsheets and Power BI. Python starts to matter when the advertisement says analytics engineer, product analyst or sits inside a data science team. If you have it, keep it honest and shallow: reading a file, cleaning, grouping, joining and plotting is enough.

The level actually asked of an entry candidate looks like this.

import pandas as pd

orders = pd.read_csv("orders.csv", parse_dates=["order_date"])

orders = orders.drop_duplicates(subset="order_id")
orders["order_total"] = orders["order_total"].fillna(0)

monthly = (
    orders
    .groupby(orders["order_date"].dt.to_period("M"))
    .agg(order_count=("order_id", "count"),
         revenue=("order_total", "sum"),
         customers=("customer_id", "nunique"))
    .reset_index()
)

And the join, which is where the interesting question lives.

merged = orders.merge(customers, on="customer_id", how="left", indicator=True)
print(merged["_merge"].value_counts())

“The indicator flag is the habit I would bring across from SQL. It tells me how many rows found no match on the right, which is the same row count check I would do after any join. If two thousand orders have no customer record, I want to know that before I report revenue by segment, not after.”

Never claim more Python than you have. A panel will ask one gentle follow up, and being caught costs you the whole interview rather than the question.

Power BI and Tableau questions

The visualisation round is short and it is mostly about whether you understand a data model, not whether you can make something look nice.

Measures against calculated columns

Question: “What is the difference between a measure and a calculated column in Power BI?”

A calculated column is worked out row by row when the model refreshes and stored in the model, so it uses memory and it cannot react to what the user has filtered. A measure is worked out at query time inside whatever filter context the user has created by clicking a slicer.

“My rule of thumb is that if I need the thing on an axis, in a slicer or as a category, it has to be a column, because a measure cannot sit there. If it is a number I want aggregated and sliced, it should be a measure. New Power BI users create calculated columns for everything, and then the model is slow and the totals do not respond to filters the way people expect.”

Revenue = SUM(Sales[LineTotal])

Revenue LY = CALCULATE([Revenue], SAMEPERIODLASTYEAR('Date'[Date]))

Mention that time intelligence functions need a proper date table marked as a date table in the model, and that a date table which does not cover every day of the period gives wrong answers rather than errors.

Star schema

Question: “Why not just load one big flat table?”

A star schema is a fact table holding the events at a defined grain, surrounded by dimension tables holding descriptive attributes, joined one to many.

“Three reasons. Filters flow one way from the dimension to the fact, so the behaviour is predictable and DAX does what you expect. The model is much smaller, because the text repeats once per dimension row instead of once per transaction. And when the business asks for a new slice, you add a column to a dimension rather than rebuilding the whole extract. The grain question is the one I would ask first though. One row per order or one row per order line changes every number in the report.”

For Tableau the equivalent questions are dimensions against measures, what a level of detail expression such as FIXED is for, and when to use an extract rather than a live connection. If the advertisement names Tableau, prepare Tableau. Do not turn up with Power BI answers and hope the concepts carry.

Why did you choose that chart?

Expect to be asked to defend a chart, especially if you brought a portfolio.

Choice	The defensible reason
Bar rather than pie	People compare lengths accurately and angles badly, and a pie with more than four slices is unreadable
Line for time	It shows the direction between points, which is what a time question is about
Sorted bars	Sorting by value answers the ranking question the reader had; alphabetical answers a question nobody asked
Axis starting at zero on a bar	The length is the message, so truncating the axis exaggerates the difference
One number, large	If the answer is a single figure, a chart is decoration
A dual axis only with a reason	Two scales on one chart lets the reader see whatever correlation they were hoping for, so my default is two charts stacked on a shared time axis; it is defensible now and then for an audience that already reads both scales every week, and then I would say why

The statistics questions, at the depth actually asked

Nobody is going to make you derive anything. They are checking that you will not mislead a stakeholder by accident.

Mean or median? The mean is pulled by extreme values and the median is not. For anything with a long tail, so income, property prices, session length or basket size, the median describes the typical case and the mean describes the total divided up. Say which question you are answering. If a handful of enterprise customers dominate revenue, the mean order value is the right number for forecasting and the wrong number for describing a normal customer.

What does a p value actually tell you? It is the probability of seeing a result at least as extreme as this one if the null hypothesis were true. That is all. It is not the probability that your hypothesis is correct, it is not the probability the result was luck, and it says nothing about how big the effect is. A tiny difference becomes statistically significant with a large enough sample, and a significant result that moves revenue by nothing is not worth shipping. Report the effect size next to it.

Sampling bias. The survey is answered by the customers who are still engaged enough to open your email. The app telemetry only covers people who accepted tracking. The store data stops at five in the afternoon because that is when the extract runs. Every one of those produces a clean, confident, wrong answer. The question to keep asking is who is missing from this table.

Correlation and causation. Everyone can recite the difference and few can catch it live. The interview version is usually a plausible trap: users who use feature X retain better, so we should push everybody to feature X. The likely truth is that people who were already going to stay are the ones who find feature X. Say the phrase confounding variable, then say how you would separate them, which is a controlled experiment or at minimum a comparison of similar users.

A/B test basics. Randomise at the right unit, usually the user and not the session. Decide the one primary metric before you start. Work out the sample size and the run time in advance and then leave it alone, because checking daily and stopping when it looks good manufactures a result out of noise. Run whole weeks, since behaviour on a Sunday is not behaviour on a Tuesday. And watch a guardrail metric, so you notice if your conversion win came with a support ticket surge.

Simpson’s paradox is worth one sentence of preparation. A trend that appears in every subgroup can reverse when the groups are combined, usually because the groups are different sizes. Mentioning it in a case round makes a senior analyst sit up.

The case round, worked through properly

The case: “Our weekly active users dropped twelve per cent last week. How would you investigate?”

The failure is answering immediately. Every candidate who names a cause in the first thirty seconds has failed the round regardless of whether they happen to be right.

Start with questions.

“Before I guess at causes, three questions. Is the drop against the previous week or against the same week last year? Has anything changed in how we define or collect weekly active users recently? And is anybody already looking at it, so I am not duplicating work?”

Then give the structure out loud, in order.

Check the measurement before the business. Is this real or is it a broken pipeline? I would check whether the job ran, whether the row counts for the underlying events look normal, and whether a tracking change or an app release altered what gets logged. A surprising share of dramatic drops are an event that stopped firing.
Pin down the definition. Weekly active on what action? If somebody changed active from opened the app to completed a session, the drop is a definition change and the investigation stops here.
Establish the shape. Is it a step change on one day or a gradual slide? A cliff points at a release, an outage or a tracking break. A slope points at retention or acquisition.
Cut it by dimension, one at a time. Platform and app version first, then region, then new against returning, then acquisition channel, then device. The goal is to find the smallest group that explains the largest part of the drop. If it is confined to one app version on one platform, you have your answer in twenty minutes.
Split the numerator from the denominator. Fewer new users arriving is a marketing problem. The same arrivals staying less is a product problem. They look identical in a single headline number and they go to different teams.
Look outside the product. School holidays, a public holiday, a heatwave, a major sporting event, a competitor launch, a change in advertising spend. Australian data has real seasonality and state by state public holidays that do not line up, which catches people out.
Ask two humans. What shipped last week, and what did support see. Five minutes with a release log and a support lead often replaces two days of querying.
Report with the confidence you actually have. Say what you know, what you suspect, what you have ruled out, and what you would need to be sure.

Finish on the sentence you want them repeating to each other after you have left the room.

“My starting bias on a drop that size and that sudden is that it is measurement rather than behaviour, because real user behaviour does not usually move twelve per cent in a week without an obvious external cause. So I would spend the first hour trying to prove the number is wrong, and I would want the data to defeat that theory rather than confirm it.”

Notice that none of it required you to know the product. It required an order of operations, an instinct to check your own instruments before blaming the world, and enough honesty to state a theory as a theory rather than a finding. Those three things are close to the whole of what a case round is scoring.

Behavioural answers when you are changing fields

Two questions decide this round for career changers, and both have an obvious weak answer that most people give.

Why are you leaving what you were doing?

Weak: “I was not really enjoying it anymore. There was not much progression and I have always been more of a numbers person, so I wanted to do something more analytical.”

That is three complaints and a preference. It tells the panel you are running away from something, which raises the question of what you will do when this job gets hard.

Strong: “I am not leaving it so much as following the part of it I was already doing. In the claims team I ended up owning the reporting, and the bit I looked forward to every month was working out why a number had moved. That grew from a side task to about half my week, and at some point it was obvious that the half I liked was somebody else’s whole job. What I am bringing across is nine years of knowing how claims data actually gets created, including the fields people fudge when they are in a hurry, which is the part you cannot learn from a schema.”

Sixty seconds. Continuity rather than escape, evidence in the middle, and a closing line that turns the old job into an asset.

How do I answer you have no commercial data experience?

Agree with the fact, then reframe the gap as tooling rather than thinking. Name one decision you changed with data in your previous job, say what you measured and what happened, then say what you have deliberately built since. Never argue with the observation and never apologise for two minutes. Sixty seconds, evidence in the middle, no defensiveness.

Weak: “That is true, but I have done a lot of projects and I learn really fast. I have done the certificate and I have been practising SQL every day, so I am confident I could pick it up quickly.”

Everything there is a claim about the future. There is nothing the panel can check.

Strong: “That is fair, I have not held the title. What I have done is the work under a different name. In the roster planning for the contact centre I pulled two years of call volume by half hour, found we were staffing to a daily average when the load was really two peaks, and rebuilt the roster around it. Abandoned calls fell over the following quarter and we did that without adding headcount. That is a question, a data set, an analysis and a decision, and the only part of it I could not do at the time was SQL, because I was doing it in a spreadsheet. That is the part I have spent the last year fixing, and I would rather you tested it than took my word for it.”

The last clause is the strongest thing in the answer. Inviting the test is what confidence sounds like.

Two more you should have ready

“Tell me about a time the data disagreed with what somebody senior believed.” They are testing whether you will fold. The good answer shows you checked your own work first, then presented the finding without making it a confrontation, and were specific about the limits of what you found.

“Tell me about a mistake you made with data.” Never say none. A finance or operations background gives you a real one, and volunteering it buys more credibility than anything else in the interview. Say what happened, how it was caught, and what you changed permanently so it cannot happen again. The permanent change is the whole point of the answer.

Your CV: turning your old job into analytics evidence

The panel is downstream of the CV, and most career changer CVs fail in the same way. They describe duties from the old career at the top and pile a list of tools at the bottom, so a screener sees an operations person who has done a course.

Rewrite the old work as analysis. The work already was analysis. Here is the conversion.

Before	After
Managed rostering for a contact centre team of 18	Analysed 2 years of call volume at half hour granularity to replace average based rostering with peak based rostering, cutting abandoned calls across the following quarter with no added headcount
Responsible for monthly reporting to the operations manager	Rebuilt the monthly operations pack in Power BI, replacing 4 manual spreadsheets with one refreshable model and reducing preparation from 2 days to under an hour
Taught Year 11 and 12 mathematics	Built a tracking model across 120 students that flagged those falling behind on assessment trends 6 weeks earlier than the reporting cycle did, which changed how intervention time was allocated
Handled customer support tickets	Categorised 6 months of support tickets to identify the 3 issue types driving 40 of every 100 contacts, and presented the analysis that led to two of them being fixed in the product
Processed supplier invoices	Reconciled supplier data across 2 systems, identified duplicate vendor records causing repeat payments, and designed the matching rule used to prevent recurrence

Two rules for those numbers. Only use figures you could defend if the panel asked how you know. And when there genuinely is no figure, give the size of the thing instead: how many people, how many systems, how many months of data, how many rows in the file. That is not a weaker bullet. It is a truthful one, and a screener can still picture the job from it.

The tools go in a short, honest block near the top with a level attached, not a wall of logos. SQL at a working level, Power BI for published reports, Excel including Power Query, Python for cleaning. In our experience a screener scans that block rather than reads it, and a claim with a level attached reads as more credible than a claim without one.

If your applications are going out and nothing is coming back, the problem is nearly always the description rather than the capability, and that is what standalone job support for experienced candidates is for. Plenty of people switching into analytics do not need another course. They need the last decade of their working life described in a language the screener recognises.

The portfolio project a hiring manager will actually open

What should a data analyst portfolio contain?

Two or three projects, not eight, each starting from a question a business would actually ask. Use messy public data, show the cleaning decisions, end on a recommendation with its limitations named. A short readable summary matters more than the notebook. A hiring manager opens the summary first and usually stops there if it does not say anything.

Here is what we see happen when somebody clicks your link. It gets a look, not a study. They read the first paragraph. If it says what question you asked and what you found, they scroll. If it opens with a list of imports, they close the tab.

What makes a project look like coursework:

The famous teaching datasets. Titanic survival, the iris flowers, the movie catalogue everybody uses. A hiring manager has seen these hundreds of times and they carry no signal at all.
Data that arrived clean, so no cleaning judgement was ever needed or shown.
Cleaning that consists of dropping every row with a missing value, without a sentence about what that removed.
Four charts and no conclusion.
No question at the top and no decision at the bottom.

What makes a project look like work:

A real question with a stakeholder implied by it. Which suburbs should this service expand into first, and what would that cost.
Messy public data you had to wrestle. Australia has genuinely good open data: data.gov.au aggregates federal and state datasets, the Australian Bureau of Statistics publishes census and economic data, the Bureau of Meteorology publishes historical weather, and the state transport agencies publish open transport data. Any of those beats a tidy competition file.
Visible cleaning decisions, with the reasoning. I dropped these 400 rows because the date was unparseable, which is under one per cent and they were spread evenly across the period, so I do not think it biases the result.
A conclusion in plain English with the limitations stated. What this does not tell you is worth more than one more chart.
One dashboard, published and public, if the role names Power BI or Tableau.

The summary that goes on top

What I wanted to know: whether the weekday and weekend patterns for [service] differ enough to justify separate staffing.

Data: three years of [source], about 1.4 million rows, joined to the public holiday calendar for the relevant states.

What I had to fix: timestamps stored in UTC while the service runs on local time, which shifted roughly 4 per cent of records into the wrong day until I converted. Duplicate records where the source system logged a retry. Two months missing in 2024, which I have excluded and flagged rather than interpolated.

What I found: two sentences. The finding, and the size of it.

What I would do with it: one recommendation, and what it would cost or change.

What this does not tell you: the honest limitations, in two or three lines.

How to run it: one command, and where the data comes from.

Write that in the first screen of the page. If the reader stops there, they have still learned that you think like an analyst.

Questions to ask the panel, and what each one signals

Never say you have no questions. Two good ones is enough.

Ask this	What it signals
What does the data stack look like day to day, and where does most of the querying happen?	You are thinking about the work, not the title
Who are the main stakeholders for this role, and what do they usually ask for?	You understand the job is service, not just querying
Is there a senior analyst who reviews work, and how does that review happen?	You want to be checked, which is exactly what they want to hear from a junior
What is the most common data quality problem the team lives with?	You know real data is broken and you are not squeamish about it
What happened with the last person in this seat?	The answer tells you what the manager is worried about, and you can address it directly next round
How would you know in six months that this hire went well?	You are asking to be measured, which almost nobody does

Common mistakes, and what to do instead

Silence during a live SQL question. The panel cannot grade thinking they cannot hear. Say what you are about to write, what you are unsure of, and what you would check once it runs.

Answering the question asked rather than the one meant. In a take home especially, write your assumptions at the top. An analyst who states assumptions is safe to give work to.

Apologising for your background for more than one sentence. Acknowledge it, evidence it, then put it to work. A domain sentence about your nine years in claims is the one thing nobody else in the queue can say.

Practising SQL by reading solutions. Blank screen, timer, no scrolling down to the answer. Recognition and recall are different skills and only recall gets tested.

Turning up with no number and nothing to show. One figure about the old job, rows or headcount or tickets, makes everything after it sound measured, and one artefact you can put on a screen puts you in a very small group.

Treating the recruiter call as a formality. It writes the paragraph the hiring manager reads before anything else.

A follow up email that says thank you and nothing more. Ask the panel what their biggest data quality headache is, then use the email to say how you would start on it. That is the one that gets forwarded.

A 14 day preparation plan

Days	What to do	Time
1 to 2	Write and rehearse your 45 second opening, including the reason for the switch	1 hr
3 to 5	SQL from blank: joins, GROUP BY with HAVING, second highest, ROW_NUMBER, LAG, self join, dedup	4 hrs
6	The funnel question, written and then criticised out loud	1 hr
7	Excel: XLOOKUP, INDEX and MATCH, pivot with per cent of total, one messy file cleaned in Power Query	2 hrs
8	Power BI or Tableau: build one small star schema model and two measures	2 hrs
9	Statistics: mean against median, p values, sampling bias, A/B test design, said aloud	1 hr
10	The case round, rehearsed aloud against two different metrics	1 hr
11	Rewrite five CV bullets from duty to analysis, with a defensible number in each	2 hrs
12	Tidy one portfolio project and write the summary that sits above it	3 hrs
13	Mock interview with somebody who will interrupt and push back	1 hr
14	Employer research, your questions for them, referees briefed, follow up email drafted	1 hr

Your checklist before the interview

FAQs

What questions are asked in a data analyst interview?

Do you need SQL for an entry level data analyst job in Australia?

Do I need Python to get a data analyst job?

How do I answer you have no commercial data experience?

What should a data analyst portfolio contain?

How long does the data analyst hiring process take in Australia?

Permanent entry level roles usually run three to six weeks from application to offer. That covers a CV screen, a recruiter call, a technical test or take home, a hiring manager interview and often a final panel. Contract roles compress to one to three weeks. Government and university roles run longer because of panel scheduling and selection criteria.

Do I need a degree or a certificate to become a data analyst in Australia?

No specific degree is required and no certificate hires you on its own. Employers ask for evidence that you can query data, clean it and explain it to somebody who is not technical. A certificate helps a CV get read when you are switching fields, but the portfolio project and the SQL test carry far more weight in the decision.

Can experienced candidates get job support without enrolling in training?

Yes. Plenty of people moving into analytics already have the thinking and do not need another course. What they need is positioning, submissions handled properly and rehearsal for the SQL and case rounds. Campus4tech offers standalone job support with no training attached, and we continue working with candidates until they are successfully placed.

Summary

A data analyst interview is not really a knowledge test, and for a career changer it is definitely not a test of whether you deserve the title. It is a test of whether you can be trusted with a number that somebody else will act on.

That trust shows up in four places, and all four are things you can rehearse. Whether you can write SQL from a blank screen rather than recognise it. Whether you check your own output and say so. Whether you ask questions before you diagnose. And whether you can describe your previous career as a source of judgement rather than as a gap to apologise for.

None of the four is knowledge you either have or do not have. All four are rehearsal, and the fortnight above is enough of it.

The people who make this switch successfully are almost never the ones who studied hardest. They are the ones who stopped presenting themselves as beginners.

The pattern we see with career changers is nearly always the same. The thinking is there, the SQL is nearly there, and the story is being told backwards. Campus4tech job support fixes the story, gets your CV describing analysis rather than duties, puts your submissions in front of the right people, and rehearses the technical and case rounds with you until they stop being frightening. There is no training course attached to any of that, and we continue working with candidates until they are successfully placed. If you want to see what we are currently recruiting for first, the live roles we are hiring into are a reasonable place to start, or book a free consultation and we will tell you honestly where your search is going wrong.

Written by

Anudithi Saxena

Career Consultant

Advises candidates on positioning, interview preparation and career transitions.