Qlik Sense Interview Questions: Synthetic Keys, Set Analysis, and Incorrect Totals

A Qlik Sense chart can show a plausible number and still answer the wrong question. In interviews, the difficult part is not reciting a set-analysis expression; it is tracing the associative model, the current selection state, and the chart's own dimensions until the total has a clear grain. This guide uses a small original fixture and exact expected numbers. The product behavior is grounded in Qlik's synthetic-key documentation and aggregation-scope documentation. The fixture is an instructional example, not a claim about any employer's interview format.

The core thesis: debug a wrong total from fields and associations outward, then from selection and expression inward. Do not assume a synthetic key is the sole cause. Do not assume {1} means a single scalar.

Interview prompt: a sales dashboard has the wrong total

Imagine these three logical tables in a Qlik app:

Table	Fields	Intended grain
Sales	OrderID, CustomerID, Region, Year, SalesAmount	One order
Customers	CustomerID, Region, Segment	One customer snapshot
Budget	Region, Year, BudgetAmount	One region-year

The simplified sales rows are East/2025/120, West/2025/80, East/2026/60, and West/2026/40; each is a distinct order. The all-year sales total is therefore 300, and the selected 2026 total is 100. A recruiter asks: Why did loading these tables produce synthetic keys? Why might the dashboard's totals change after a customer-region update or an ill-judged join? How would you compare selected-year sales with all-year sales by region?

In Qlik, tables with two or more fields in common can create a synthetic key. Here Sales and Customers share CustomerID and Region; Sales and Budget share Region and Year. Qlik's official guidance says synthetic keys may be valid, but chained or unexpected keys often indicate a script/model problem. The decisive interview answer is to name each unintended shared field and the business relationship it falsely implies. Blindly renaming all fields to suppress the warning can disconnect the model and merely hide the defect.

The intended customer association may be CustomerID only. If a customer's region changes in the snapshot, treating both CustomerID and Region as a composite match can exclude historical orders under some selections. The intended budget association is different: Region plus Year may genuinely identify a budget row, but BudgetAmount lives at region-year grain while sales lives at order grain. A direct physical join that repeats the budget on every order can make Sum(BudgetAmount) wrong. Qlik associations do not automatically perform that join; distinguish an associative synthetic key from a separately introduced join-induced duplication.

Question 1: How do you inspect and repair a synthetic key?

Start with the data model viewer and load script, not with a chart formula. List the common fields between each pair of tables and ask whether every shared name denotes the same business key. If Region in Customers is a current attribute while Region in Sales is the order-time region, the names look alike but do not represent the same relationship. That is a semantic problem, not a cosmetic one. Check the number of rows in each source, distinct key counts, and whether one customer has multiple region values over time.

For the invented fixture, a deliberate repair could keep CustomerID as the Sales–Customers association and rename the customer snapshot field to CurrentCustomerRegion. If the sales region is an order-time fact, keep it on Sales. For budget, a composite RegionYearKey built consistently from normalized region and year may express the intended grain; alternatively build an explicit link table when several facts share dimensions. The choice depends on the rest of the model. Document how nulls, date formats, and changes to region membership are handled. A string concatenation without a separator or with inconsistent formats can create new collisions, so use a well-defined key construction rather than a hasty patch.

Do not promise that every synthetic key hurts performance or that removing one proves correctness. A composite association could be exactly what the data requires. The test is whether selections propagate as intended and measures reconcile to independent source totals at their own grain. After a change, reload, inspect the model again, and test a customer whose region changed, a region-year with no budget, and a budget row with no sale. If the model now drops one of those populations, the fix is incomplete.

An interviewer may ask whether QUALIFY or field renaming is enough. It can prevent automatic associations by changing field names, which is useful when the fields are unrelated. It does not create the right association by itself. State the desired relation first, then choose rename, explicit composite key, link table, or a controlled join. Treat a generated synthetic table as evidence to investigate, not a universal failure signal.

Question 2: Why can a chart total differ from its visible rows?

There are at least four different failure families. First, the underlying data may have duplicate orders. Second, the model may associate records through an unintended composite field or disconnect them through an overzealous rename. Third, the measure may have a different grain from the dimensions, such as budget per region-year displayed by order. Fourth, the expression may use a selection set or TOTAL qualifier that changes scope. Debug them in that order. Rewriting the expression before inspecting the data can make a wrong total seem right in one filter state while failing elsewhere.

For the sales-only fixture, there are four rows and Sum(SalesAmount)=300 with no selection. Selecting Year=2026 leaves two rows totaling 100. On a chart with Region rows, the selected values are East=60, West=40. A useful reconciliation table compares source row counts, selected row counts, and per-region sums. If the displayed values are East=180, West=120 after selecting 2026, the expression may be ignoring the Year selection. If both regions display 300, the expression may also be ignoring the Region chart dimension.

Those examples are expected values of this invented fixture, not statements about every Qlik app. Qlik's aggregation-scope reference explicitly distinguishes selection scope from dimensional scope. The display may also have presentation-level totals or non-additive measures; a distinct customer count, ratio, or average should not automatically equal the sum of row values. Ask what “total” is meant to mean before calling it incorrect.

Question 3: What do $, 1, and TOTAL actually change?

Use a Region dimension and the four sales rows above. Suppose the user selects Year=2026. These expression patterns answer different questions:

Expression	East row	West row	Meaning in this fixture
Sum(SalesAmount)	60	40	Current selection and current chart dimension.
Sum({1} SalesAmount)	180	120	All records, still split by Region.
Sum({1} TOTAL SalesAmount)	300	300	All records and no Region split.
Sum({$<Year=>} SalesAmount)	180	120	Current selections except clear Year; assumes no other selections.

Qlik's set-modifier reference documents the syntax, and its scope reference gives the crucial distinction: set analysis changes the record set, while TOTAL changes how chart dimensions restrict aggregation. {1} does not mean “one overall number.” In a chart it can still yield one all-records value per region.

The fourth row deserves care. Clearing Year from the current set does not necessarily recover all rows if other selections, such as Segment or CustomerID, remain active. In the toy fixture there are no other selections, so it matches {1}. In a real app, state what is selected before predicting a number. Likewise, an explicit <Year={2025}> modifies the year value in the set; it is not synonymous with clearing Year. Avoid treating set syntax as a bag of incantations.

For a share-of-total metric, define numerator and denominator in words first. If a selected-region numerator is divided by an all-region denominator, the denominator may require TOTAL or another scoped expression. The correct syntax depends on whether the denominator should respect Year, Segment, and alternate states. Write a small matrix of filter states and expected results, then test the expression in each. A single screenshot with no selections cannot validate a selection-sensitive measure.

Question 4: How do you distinguish a modeling error from an expression error?

Build a diagnostic sheet with simple counts and sums before touching the production measure. Put Count(OrderID), Count(DISTINCT OrderID), and Sum(SalesAmount) next to the questioned measure. Compare them with a source-level export at the same filter state. If order counts are inflated, investigate duplicate loads or joins. If order counts are stable but a customer selection loses historical orders, inspect associations. If base sums are correct but only one KPI is wrong, inspect its set identifier, modifiers, TOTAL, and chart dimension behavior.

Then make two controlled selections. Select one year; note which rows should remain. Select one region as well; note whether budget and customer rows should follow. Clear each selection separately. This tests the graph of associations. A synthetic key can be visible while the actual wrong total comes from multiplying a budget in a preceding SQL join. Conversely, a perfect-looking expression cannot rescue an unintended association. Make the causal claim only after a before/after test isolates it.

For a budget comparison, preserve two grains explicitly. Sales is one order, budget is one region-year. If you present sales and budget by region-year, aggregate each at that grain before comparing. If you drill down to orders, repeating a region-year budget on each order changes the meaning of Sum(BudgetAmount). You may display a single budget value per group or allocate it by a documented rule, but those are business decisions. “Use DISTINCT” is not a general cure; distinct numerical values can collapse legitimate equal budgets.

Finally, test an absent association. If West/2026 has sales but no budget, should a sales chart retain it? What if a budget exists for a region-year with no sale? The expected answer depends on chart dimensions and business intent. A strong candidate makes the expected population explicit and verifies it, rather than declaring the model correct because the grand total happens to match once.

Sources and Further Reading

• Qlik Help: Synthetic keys — official association behavior and cautions.
• Qlik Help: Set modifiers — official set-analysis syntax.
• Qlik Help: Defining the aggregation scope — selection versus dimensional scope.
• Qlik Help: Set expressions — set identifiers and expression structure.