Power BI and Tableau Interview Questions for Freshers (2026) — with Answers
Updated August 2026
Power BI and Tableau sit on top of the two skills that actually get an analyst hired — SQL and Excel — and they are what turns an answer into something a business person will look at. That is why they come up in almost every data analyst, reporting analyst and business analyst interview, and why a candidate who can only make charts is distinguishable in about two questions from one who understands what is underneath them.
The distinction matters because these tools are easy to demo and hard to do well. Dragging a field onto a canvas produces a chart immediately, which is why so many candidates arrive with a certificate and a screenshot and no answer to why the numbers are wrong when a filter is applied. Interviewers know this, so the questions cluster in three places: the data model beneath the visuals, the difference between a calculation that runs per row and one that runs per context, and the judgement calls about what to show and how.
This set covers both tools, because most roles name one and interview on the concepts common to both — and because the concepts do transfer, even though the vocabulary does not. Where they differ meaningfully, the answers say so. If you are still building the layer underneath, our SQL and Excel sets come first: a BI tool cannot rescue an analyst who cannot query or clean data, and interviewers ask about that in the same conversation.
Frequently asked questions
What is a BI tool actually for — why not just use Excel?
Excel is excellent for exploration, one-off analysis and small datasets, and every analyst uses it daily. What it does not do well is the repeating case: a report that must refresh on a schedule from a live source, be seen by fifty people with each seeing only their own region, hold millions of rows without becoming unusable, and stay consistent when four people open it. That is what a BI tool is built for — connect once, model the data properly, define the measures in one place, and publish something that updates itself. Say it in those terms rather than "Power BI makes better charts", because the visual layer is the least interesting part of the answer. The honest addition, which interviewers respect: plenty of reporting problems genuinely are Excel problems, and reaching for a BI tool for a one-off analysis is over-engineering.
What is the difference between import and DirectQuery in Power BI, or extract and live connection in Tableau?
Import and extract mean the data is copied into the tool's own storage engine, so queries run against that copy: fast, works offline, supports the full range of calculations, but the data is only as fresh as the last refresh and there are size limits. DirectQuery and live connection mean queries go to the source system every time: the data is always current and nothing is duplicated, but performance depends on that source, some calculations are restricted, and every interaction puts load on a database somebody else may care about. The rule of thumb worth stating: default to import or extract for reporting on data that changes daily, and use direct or live when genuine near-real-time is required or when the dataset is too large to copy. If you can add that a mixed or composite approach exists, you are answering above fresher level.
What is a data model, and why not just use one big flat table?
A data model is a set of tables related to each other rather than a single wide sheet. The usual shape is a star schema: one or more fact tables holding the events you measure — sales, transactions, tickets, each row a thing that happened — surrounded by dimension tables holding the descriptive attributes you slice by, such as date, product, customer or region. A single flat table works until it does not, and then it fails in specific ways: every attribute is repeated on every row so the file bloats, a product name changes and you have to update it in a million places, filters behave inconsistently, and performance degrades badly. Modelling separates what you measure from what you describe it by, which is exactly what makes filtering and aggregation behave predictably. This is the question that most reliably distinguishes candidates who have built something real.
Explain relationships and cardinality.
A relationship connects two tables on a shared key so that filtering one filters the other. The common case is one-to-many: one row in a dimension table, such as a single product, relates to many rows in the fact table. Cardinality describes that — one-to-many, many-to-one, one-to-one, and many-to-many, which should be treated as a warning sign rather than a design choice at fresher level, since it usually means a dimension table is missing. Filter direction matters too: by default filtering flows from the one side to the many side, which is what you want, and turning on bidirectional filtering can produce ambiguity and unexpected results. The practical symptom to mention: if a slicer does not filter a visual the way you expect, the relationship or its direction is the first place to look, not the measure.
What is the difference between a calculated column and a measure?
This is the single most-asked Power BI question and the answer is about when the calculation happens. A calculated column is computed row by row when the data is loaded or refreshed, and it is stored — it becomes part of the table, consumes memory, and can be used as a slicer or an axis. A measure is computed at query time, in response to whatever filters and groupings the user has applied, and stores nothing. So a calculated column is right when you need a per-row attribute you will filter or group by, such as classifying each order into a size band. A measure is right for anything aggregated — totals, averages, ratios, year-on-year change — because the same measure must give a different answer at row level and at total level. The classic mistake to name: computing a profit margin as a calculated column and averaging it, which gives a wrong total, when a measure dividing total profit by total revenue gives the right one.
What is DAX, and what do row context and filter context mean?
DAX is the formula language for Power BI, and the two contexts are what make it different from an Excel formula. Row context means the calculation is evaluated for a specific row, which is what happens inside a calculated column or inside an iterator function. Filter context is the set of filters in effect when a value is calculated — the slicers, the row and column headers of a matrix, anything on the page — and it is why one measure gives different numbers in every cell of a table. Nearly every confusing DAX result comes from misunderstanding which context applies. At fresher depth you are not expected to handle context transition fluently, but you are expected to know the two exist and to say that a measure is evaluated within whatever filters surround it. That answer alone puts you ahead of candidates who describe DAX as "like Excel formulas".
What does CALCULATE do?
It evaluates an expression under a modified filter context — which is the reason it exists and the reason it is the most important function in DAX. The common fresher-level use is a measure that ignores or overrides a filter on the page: total sales for a fixed region regardless of what the slicer says, or last year's figure by shifting the date filter. The mental model to give is that the first argument is what to calculate and everything after it changes the filters under which it is calculated. You are not expected to explain context transition in depth, but if you can say that CALCULATE also turns row context into filter context when used inside an iterator, that is a genuinely strong fresher answer. Do not overclaim here — a clear account of the simple case beats a confused one of the advanced case.
SUM versus SUMX?
SUM aggregates a single column directly. SUMX iterates over a table, evaluates an expression for each row, and then sums the results — so it is what you need when the thing you are summing does not exist as a column. The standard example: revenue where the table holds quantity and unit price but no line total. SUM cannot multiply them; SUMX iterates row by row, multiplies within each row, and totals the results. Getting this wrong produces the classic error of multiplying total quantity by total price, which is meaningless. The general lesson worth stating is that the X functions are the iterators — SUMX, AVERAGEX, MAXX and so on — and you reach for them whenever the calculation must happen per row before aggregation.
In Tableau, what is the difference between dimensions and measures, and between discrete and continuous?
Dimensions are qualitative fields that categorise data — product, region, date, customer — and by default Tableau uses them to partition a view. Measures are quantitative fields that get aggregated, such as sales or quantity. Separately, and this is what confuses people, fields are either discrete or continuous, shown as blue and green: discrete fields create distinct headers and separate panes, continuous fields create a continuous axis. The two distinctions are independent, which is the point of the question — a date can be used discretely to give one column per month, or continuously to give a proper time axis. If someone asks why their chart shows separate bars instead of a line, this is nearly always the answer, and knowing it signals you have actually used the tool.
What are calculated fields, table calculations and LOD expressions in Tableau?
They differ in when and at what level they are computed. A calculated field is evaluated in the underlying query, row by row before aggregation, so it behaves like adding a column to the data. A table calculation is computed after aggregation, on the results already in the view — running totals, percent of total, rank, moving averages — which is why its result depends on the layout of the view and why "compute using" matters so much. A level-of-detail expression lets you compute at a granularity different from the view: a FIXED expression, for example, computes per customer regardless of what the view shows, which is how you answer questions like average order value per customer while displaying totals by region. At fresher level you are expected to know the three exist and roughly when each applies; being able to give one concrete example of a table calculation and one of an LOD is a strong answer.
How do you decide which chart to use?
By starting from the question rather than the chart menu, and the framing interviewers like is to name the comparison you are making. Comparing values across categories is a bar chart, and horizontal bars when the labels are long. Showing change over time is a line chart. Showing relationship between two numeric variables is a scatter plot. Showing composition is a stacked bar or a treemap, and only rarely a pie. Showing distribution is a histogram or box plot. Showing geography is a map, and only when location genuinely matters rather than because it looks impressive. Two habits worth mentioning because they signal judgement: a single number displayed large is often the right answer when there is only one number worth knowing, and a well-formatted table beats a bad chart when people need to read exact values. The wrong instinct is choosing a chart because it is visually interesting.
When is a pie chart the wrong choice?
Almost always, and being able to say why is a good test of whether you think about visual encoding. Humans compare angles and areas poorly and lengths well, so a bar chart communicates the same data more accurately. Pie charts get worse as slices multiply, they cannot show change over time, they cannot handle negative values, and comparing across two pies is close to impossible. They are defensible in one narrow case: a small number of parts of a whole, typically two or three, where the point is roughly what fraction rather than a precise comparison. The way to answer this in an interview is not to declare pie charts forbidden — a candidate who says "the business asked for one, so I made it, but I would show the bar version alongside" sounds like someone who has worked with actual stakeholders.
What makes a dashboard good?
That it answers a specific question for a specific person quickly. The failure mode is a dashboard built to display everything available, which forces the reader to work out what matters — and a dashboard that needs explaining has already failed, because the person opening it at eight in the morning will not have you next to them. Concretely: decide who the audience is and what decision they take, put the most important number where the eye lands first, limit the visuals rather than filling the canvas, keep filters obvious and consistent, label things in business language rather than column names, and make units and time periods unmistakable. Add the two things freshers usually omit — the last-refreshed timestamp, so nobody argues with stale data, and a definition of any ambiguous metric, because half of all dashboard disputes are two people meaning different things by the same word.
What is the difference between a filter and a slicer, and what should the user be able to change?
Mechanically, a slicer in Power BI is an on-canvas control the user interacts with, while filters can be applied at visual, page or report level and may not be visible to the user at all; Tableau makes the same distinction between filters shown as controls and those applied behind the scenes. The design question underneath is more interesting, and it is what a good interviewer is really asking: which choices should the reader have. Expose the filters that correspond to real questions people ask — time period, region, product line — and apply invisibly the ones that define the report's scope, such as excluding cancelled orders or internal test accounts. Too many controls make a dashboard feel like a database query tool, and readers stop trusting it because two people can produce two different numbers from the same page.
How does refresh work when a report is published?
Once published to a service, the report needs its data updated on a schedule rather than by you reopening it. In Power BI that means configuring a scheduled refresh in the service, and where the source is an on-premises database or a file on an internal network, traffic passes through a data gateway installed inside that network — the service cannot reach a private source directly. Tableau uses the same pattern with extract refresh schedules on its server or cloud. Two practical points that show you have thought past the happy path: refreshes fail, most often because a credential expired, a source file moved or the gateway is offline, so somebody should be alerted rather than discovering it from a confused stakeholder; and refresh frequency should follow how often the data actually changes, because refreshing hourly a table updated nightly loads the source for nothing.
How is a report shared, and what is row-level security?
Sharing means publishing to a workspace or site and giving people access, rather than emailing a file — which is the whole point, since an emailed copy is stale the moment it is sent and forks into a dozen versions. Row-level security is the mechanism that lets one report serve many audiences: rules defined on the model restrict which rows each user can see, so a regional manager opening the same dashboard as a colleague sees only their own region. At fresher level you are expected to know it exists, that it is defined on the data rather than by hiding visuals, and why that matters — hiding a chart is not security, because the data is still in the model and reachable. If you have implemented it, say so, since very few freshers have.
A dashboard is slow. How would you approach it?
Work from the data upwards, because performance problems are far more often modelling problems than visual ones. Check the size and shape of the model first: unnecessary columns, especially high-cardinality ones such as transaction IDs and free text, cost disproportionate memory, and removing them is the cheapest win available. Check whether you are importing rows nobody looks at, such as ten years of history for a report that shows the current quarter. Then look at the calculations: complex measures that iterate over large tables, and calculated columns doing work that belongs upstream in the source query or the database. Then the page itself: too many visuals on one page means many simultaneous queries, and a table with thousands of rows is a query nobody reads. And if the connection is direct or live, the bottleneck may be the source system rather than the report at all. Naming that order — model, then calculations, then visuals, then source — is the answer; a list of unordered tips is not.
I hand you a messy spreadsheet and ask for a dashboard. What do you do first?
Ask what decision it is for and who will use it, before touching the data. That is the answer interviewers are listening for, and most candidates skip it and start describing cleaning steps. Then profile the data before trusting it: how many rows, what each column actually means, which columns have blanks, whether dates parsed correctly or silently became text, whether categories are consistent — "Hyderabad", "hyderabad" and "HYD" being three values is the standard example — whether there are duplicates, and whether the numbers reconcile to any total the business already believes. Then shape it: clean in the query layer rather than in visuals, split what should be separate columns, set data types explicitly, and build a proper date table if there is any time analysis. Only then design the dashboard. And say out loud that you would go back to whoever gave you the file with the anomalies you found — an analyst who silently guesses at ambiguous data is the one who produces the confidently wrong report.
Your numbers do not match the source system. How do you debug that?
Systematically, and the willingness to do this at all is what employers are actually buying. Narrow the scope first: does the discrepancy appear in the grand total or only under certain filters, for one region, one month, one product. That immediately separates a data problem from a calculation problem. Then check the obvious causes in order — is the report simply stale relative to the source; is the filter context different from what you assume, for instance a report-level filter excluding rows you forgot about; is a join or relationship duplicating rows, which shows up as totals that are too high by a suspiciously round multiple; are you comparing different date fields, such as order date against invoice date; are cancelled, test or internal records included in one and excluded in the other. Then reproduce a single number end to end: take one small slice, query it directly in SQL, and compare. Finding one row that is wrong is worth more than a day of staring at totals.
What is a date table and why does every model need one?
A date table is a dedicated dimension with one row per date and columns for year, quarter, month, week, day name, fiscal period and any flags you need. You need it because time intelligence depends on a continuous, complete calendar: the dates present in your fact table have gaps — no rows on days with no sales — and any month-on-month or year-to-date calculation built on those gaps is wrong. It also gives consistent sorting, since month names sort alphabetically unless a sort column exists, and lets several fact tables share one calendar so a single slicer filters everything. Mentioning the sorting problem is a nice detail, because everyone has hit it and few name it. Marking the table as the model's official date table is the last step, and forgetting it is a common cause of time functions behaving oddly.
Where do you do your data cleaning — in the source, the query layer, or the visual?
As far upstream as you reasonably can, and this is a question about judgement rather than tooling. If a fix belongs to everyone who uses the data — a wrong category, a missing join, a business rule about what counts as an active customer — it belongs in the source system or the database view, so every report inherits it and nobody re-implements it slightly differently. If it is specific to this report, do it in the query layer, Power Query or Tableau Prep, where it is repeatable, visible to the next person and applied before the model. Do it in a visual only for genuine display concerns such as formatting and labels. The reason interviewers care is maintenance: cleaning buried inside individual visuals is invisible, gets duplicated inconsistently and is the reason two dashboards on the same data disagree.
Power BI or Tableau — which should I learn?
Learn one properly rather than both superficially, because the concepts transfer and the vocabulary does not take long to convert. Practical considerations rather than partisanship: Power BI is very widely used in organisations already on the Microsoft stack, and it has a free desktop version that makes practice easy, so for most Indian fresher roles it is the more common ask. Tableau has a strong reputation for exploratory analysis and visual design and appears frequently in analytics-led teams and some multinationals. Check the job postings you are actually targeting and follow those. In an interview, the honest and effective answer is that you know one to real depth and understand that the other solves the same problems with different names — and that you would expect a short ramp-up rather than a retraining. Candidates who claim fluency in both usually have neither, and one follow-up question exposes it.
What should a fresher have in a portfolio for a BI role?
One or two dashboards built on real public data, with an account of the thinking rather than a screenshot. What makes a portfolio piece work: a stated question and audience, a note on what you found wrong in the data and how you handled it, a visible data model rather than one flat imported sheet, two or three measures that are genuinely calculated rather than dragged-in sums, and a short honest paragraph on what you would improve. A dashboard on a clean, pre-prepared sample dataset demonstrates that you can follow a tutorial, which is not the claim you want to make. Pick a dataset with real problems — government open data, sports statistics, public transport figures — because the mess is the part employers care about. And be ready to have the whole thing questioned, since a portfolio you cannot defend is worse than none.
How much does SQL matter if I know a BI tool? (2027 batch)
Enormously, and this is the ordering mistake students make most. A BI tool consumes data that somebody has already got into a usable shape, and for most analyst roles that somebody is you — so SQL is the load-bearing skill and the visual layer is what you put on top. Interviews reflect that: expect to be asked to write joins, aggregations and window functions in the same conversation as the dashboard questions, and expect the SQL to carry more weight. If you are in the 2027 batch planning towards an analyst role, do it in this order — SQL first to real competence, then Excel beyond what coursework taught you, then one BI tool properly, then statistics well enough to describe a distribution and not misuse an average — and build one project that goes end to end from raw data to a dashboard you can defend. That sequence takes months rather than years, and very few candidates arrive having done it deliberately.
I am in the 2026 batch applying for analyst roles now. What is enough?
Enough is: SQL you can write under observation including joins, group-by and a window function; Excel including lookups, pivots and conditional logic; one BI tool where you can build a small model with relationships, write measures rather than only dropping fields, and explain the difference between a calculated column and a measure; and one dashboard project you built yourself and can defend end to end. Add the ability to answer the messy-dataset question with a method rather than a list, since it is asked constantly. That is weeks of focused work rather than months for someone with reasonable fundamentals. What will not get you there is another certificate: the market for entry-level analysts is competitive precisely because the entry bar looks low, and what distinguishes candidates is being able to discuss work they actually did, including what went wrong in it.
Don't just read Power BI & Tableau questions — get asked them
Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.
Start a free AI mock interviewHow to prepare
- Learn the model, not just the canvas. The questions that decide these interviews are about relationships, cardinality and where a calculation is evaluated — a candidate who can only produce charts is identified in about two questions.
- Rehearse calculated column versus measure until it is automatic, with the profit-margin example. It is the most-asked question in Power BI interviews and the wrong answer is a wrong total, which is exactly the kind of error employers are hiring you to prevent.
- Build one dashboard on genuinely messy public data rather than a clean sample. The mess is the part employers care about, and a tutorial dataset demonstrates only that you can follow a tutorial.
- Answer the "here is a messy file" question with a method that starts before the data: who is this for and what decision does it support, then profile, then clean upstream, then design. Most candidates start at cleaning and lose the point of the question.
- Do not neglect SQL for the tool. SQL carries more weight in analyst interviews than the BI layer does, and the two get tested in the same conversation — our SQL set is the higher-priority preparation if your time is limited.
- Know one tool properly and say so plainly. Claiming fluency in both Power BI and Tableau usually collapses under one follow-up; saying you know one deeply and expect a short ramp-up on the other reads as honest and capable.
- Have an opinion about chart choice and dashboard design, and be able to justify it. Judgement questions — why not a pie chart, what makes a dashboard good, which filters should users control — are where freshers with genuine experience separate themselves from certificate holders.
Where these questions get asked
- TCS NQT guide and Infosys hiring guide — the two biggest exams these questions appear in.
- All company placement guides — pattern, syllabus and rounds for every mass recruiter.