1. Write a query to find the second highest salary from an Employees table.
Use a subquery with MAX where salary < (SELECT MAX(salary)), or DENSE_RANK() = 2.
Data Analyst interviews lean on SQL, spreadsheet fluency, and reasoning about metrics, can you pull the number and explain what it means. Below are real questions across the rounds you'll face, with worked answers.
A Data Analyst loop is checking one thing from three angles: can you get the right number, and then say what it means to someone who cannot read SQL. The SQL round tests the first half. The case and the take-home test the second, and most candidates who fail do so on the second.
Expect the SQL to be practical rather than clever: joins across three or four tables, a window function for a running total or a rank, a date bucket, and one question designed to see whether you notice duplicates or NULLs before they distort the answer. Recursive CTEs are usually less important than getting grain, joins, and edge cases right.
A recruiter screen, then usually a SQL screen in a shared editor with a small schema on screen. Then an onsite of three or four sessions: a longer SQL or spreadsheet round, a metrics case (define a metric, diagnose a drop, design a simple A/B test), a stakeholder or behavioral round, and at many companies a take-home analysis presented back to the panel.
The take-home is where the most time goes and the least is explained. It is judged on whether the analysis answers a business question, states its assumptions, and ends in a recommendation, far more than on the code.
Correctness first, then the narration. In the SQL round the score is whether the query returns the right rows and whether you said out loud what could go wrong (fan-out on the join, NULLs in the aggregate, the grain of the table). In the case round it is structure: clarify the question, pick a metric and defend it, list the causes you would check in the order you would check them, and know when you would stop.
The behavioral round scores concrete stories with a number in them. A story about a dashboard that changed a decision beats one about building a dashboard.
If you have two weeks: spend the first three days on SQL under time pressure, timed, out loud, until joins, window functions and date logic are automatic. Then spend the middle of the time on cases, the round candidates rehearse least. Practice explaining a metric drop in ninety seconds. Finish with two or three behavioral stories rewritten so each has a decision and an outcome.
Run a scored mock for each round rather than reading answers. Reading tells you what a good answer looks like. A score tells you whether yours was one.
Silence while writing SQL, a query that runs but double-counts because of a join fan-out, a case answer that lists twenty possible causes with no order, and a take-home with beautiful charts and no recommendation. The fix for all four is the same: say what you are doing, and say what the number means.
Use a subquery with MAX where salary < (SELECT MAX(salary)), or DENSE_RANK() = 2.
Aggregate orders to one row per day, then use SUM(daily_revenue) over a six-day date interval plus the current day. Use a date spine when the SQL engine cannot frame by interval.
INNER keeps only matches, LEFT keeps all left rows plus matched right rows, FULL keeps all rows from both sides.
Use PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY amount) where supported.
RANK()/ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC) <= 3.
fillna (mean/median/mode/forward-fill), dropna, or model-based imputation depending on context.
pd.merge(left, right, on='key', how='left').
A t-test compares means of a continuous variable, a chi-square test checks association between categorical variables.
A trend within groups reverses when groups are combined due to a confounder.
Market sizing: population times adoption times trips per day, with every assumption stated.
Use STAR: Situation, Task, Action, Result with a quantified impact.
Show prioritization, scoping, and communication under pressure.