Crack Data Analyst Interviews 2026

SELECT r.restaurant_id, r.restaurant_name, r.city
FROM swiggy_restaurants r
LEFT JOIN swiggy_orders o
  ON o.restaurant_id = r.restaurant_id
 AND o.delivery_status = 'delivered'
WHERE o.order_id IS NULL
ORDER BY r.restaurant_id;

Output (from running the query)

Key insight

In an anti-join, every condition that defines "a matching row" goes in the ON clause, and WHERE only checks that no match was found (a right-hand key IS NULL).

Common mistake

Moving the status filter into WHERE: WHERE o.delivery_status = 'delivered' AND o.order_id IS NULL can never be true, so the query returns nothing. Dropping the status filter altogether is the other wrong version: it finds Chai Point (no orders) but misses Paranthe Wali Gali, whose single cancelled order counts as a match.

=VLOOKUP(1006,A2:B7,2)

Result (calculated by a formula engine on this table)

9,900

It returns ₹9,900, the amount of invoice 1005. When you leave out the last argument, VLOOKUP uses TRUE, an approximate match, and takes the nearest smaller invoice number. Type FALSE as the fourth argument and the same lookup returns #N/A.

Common mistake

Checking only that the formula returns a number. A wrong amount looks as normal as a right one, so test with a code you know is not in the list.

Likely follow-up

When does the default TRUE give a correct answer on an ID column? Only when the ID exists and the column is sorted ascending. Then it lands on the right row, but you have gained nothing over FALSE. On an unsorted column it can return a wrong row even for an ID that exists, so the default is never a safe choice for IDs.

Total Sales = SUM ( Sales[Amount] )

South Sales =
CALCULATE ( [Total Sales], Customer[Region] = "South" )

Result on the sample model (checked by recomputing it in pandas; the DAX was not run)

₹5,61,530.20

₹5,61,530.20, South's total, and the same on every row. The measure works as written: a CALCULATE filter on a column replaces any filter already on that column, so the North row's Region = North is overwritten by Region = South.

Common mistake

Calling the measure broken: a filter argument in CALCULATE replaces the row's filter on the same column, so South's figure on every row is what CALCULATE is defined to do.

Likely follow-up

How would you write sales for South and West together in one measure? CALCULATE([Total Sales], Customer[Region] IN {"South", "West"}), or Customer[Region] = "South" || Customer[Region] = "West" as a single argument. Two separate arguments, Customer[Region] = "South", Customer[Region] = "West", are combined with AND, and no customer is in both regions, so that version returns blank.

import pandas as pd

orders = pd.read_csv("data/orders.csv").drop_duplicates()
customers = pd.read_csv("data/customers.csv")
customers = pd.concat([customers, customers[customers["customer_id"] == "C015"]])
print(len(orders), customers["customer_id"].duplicated().sum())

m = orders.merge(customers, on="customer_id", how="left")
print(len(m))
print((orders["customer_id"] == "C015").sum(), (m["customer_id"] == "C015").sum())
try:
    orders.merge(customers, on="customer_id", validate="many_to_one")
except pd.errors.MergeError:
    print("MergeError")
fixed = orders.merge(customers.drop_duplicates("customer_id"), on="customer_id",
                     how="left", validate="many_to_one")
print(len(fixed))

Output (from running the code)

120 1
124
4 8
MergeError
120

A merge repeats a left row once for every match on the right. Customer C015 appears twice in customers, so each of C015's 4 orders comes out twice and 120 orders become 124 rows. validate="many_to_one" raises a MergeError straight away, and drop_duplicates("customer_id") on the customers table brings the count back to 120.

Common mistake

Fixing it with drop_duplicates() on the merged result: the rows are not exact copies once the customer columns differ, and the damage should be fixed before the merge, not after.

Likely follow-up

The two C015 rows differ: one says Delhi, one says Jaipur. What do you do? Don't drop either blindly. Check which row is newer or which one the source system treats as current, for example by signup date or a last-updated column, keep that one and tell the data owner. Dropping the first row is a guess.