Why SQL is the most-screened analyst skill
Almost every company stores its operational data — orders, customers, transactions, tickets — in relational databases, and SQL is the language for asking those databases questions. That is why SQL appears in more Indian data analyst job descriptions than any other single skill, and why the technical screen for analyst roles is so often a timed SQL test: write a working query, live, against tables you have never seen.
The good news is that analyst SQL is a small, learnable subset of the full language. You are not administering databases or tuning servers — you are reading data, filtering it, summarising it and joining it. Roughly 20% of SQL delivers 80% of analyst work, and that 20% is what this guide covers. Combined with Excel and a BI tool, it forms the standard entry stack we teach in the Cokonet Data Analytics course.
There is a second reason recruiters lean on SQL screens: they are hard to fake. A polished CV can claim anything, but a live query against unfamiliar tables shows within ten minutes whether someone has genuinely practised. That works in your favour once you have put the hours in — a strong SQL round is the fastest way for a fresher without experience to look credible.
SELECT, WHERE and ORDER BY: asking your first questions
Every query starts by choosing columns from a table and, usually, filtering rows. Suppose an orders table holds every order a retailer has taken:
SELECT order_id, customer_city, order_value FROM orders WHERE order_value > 5000 ORDER BY order_value DESC;
Read aloud, that is a plain business question: show me the big orders, largest first. WHERE handles the conditions — combine them with AND and OR, match text with LIKE, ranges with BETWEEN, and lists with IN:
SELECT order_id, order_date FROM orders WHERE customer_city IN ('Trivandrum', 'Kochi') AND order_date BETWEEN '2026-01-01' AND '2026-06-30';
Two small companions round out the basics: DISTINCT removes duplicate values (SELECT DISTINCT customer_city FROM orders; lists each city once), and LIMIT caps the output while you explore a new table. Add IS NULL and IS NOT NULL for missing data — real tables always have gaps, and interviewers like to hide them in test data to see whether you check.
These patterns alone replace a surprising amount of manual spreadsheet filtering, and they are where week one of any sensible learning plan lives.
GROUP BY and aggregations: from rows to answers
Raw rows rarely answer business questions — summaries do. Aggregate functions (SUM, COUNT, AVG, MIN, MAX) paired with GROUP BY turn thousands of rows into a readable answer:
SELECT customer_city, COUNT(*) AS orders, SUM(order_value) AS revenue FROM orders GROUP BY customer_city ORDER BY revenue DESC;
That is revenue by city — the SQL equivalent of a pivot table. To filter after aggregation, use HAVING instead of WHERE:
SELECT customer_city, SUM(order_value) AS revenue FROM orders GROUP BY customer_city HAVING SUM(order_value) > 100000;
The WHERE-versus-HAVING distinction — filter rows before grouping, filter groups after — is one of the most common interview checkpoints, precisely because it separates people who understand the logic from people who memorised syntax.
Pair aggregation with CASE and you can bucket data on the fly — for example, labelling orders as high, medium or low value inside the query itself: SELECT CASE WHEN order_value > 10000 THEN 'High' WHEN order_value > 3000 THEN 'Medium' ELSE 'Low' END AS band, COUNT(*) FROM orders GROUP BY band;. That single pattern powers a large share of real reporting work.
JOINs, and a first look at window functions
Real databases split data across tables: orders in one, customer details in another. JOIN stitches them together on a shared key:
SELECT c.customer_name, SUM(o.order_value) AS total_spent FROM customers c JOIN orders o ON c.customer_id = o.customer_id GROUP BY c.customer_name;
An INNER JOIN keeps only matching rows; a LEFT JOIN keeps every row from the first table even without a match — which is exactly how you find customers who have never ordered, another interview favourite.
Window functions are the step beyond: they calculate across a set of rows without collapsing them. The pattern to recognise is OVER with PARTITION BY:
SELECT customer_id, order_value, RANK() OVER (PARTITION BY customer_city ORDER BY order_value DESC) AS city_rank FROM orders;
That ranks every order within its own city. ROW_NUMBER, RANK and running totals cover most practical uses — enough to answer "top 3 products per category" questions, which plain GROUP BY cannot do cleanly.
A practical tip for joins: before writing one, run a quick SELECT COUNT(*) on each table and after the join. If the joined count balloons unexpectedly, your key is not unique and you are double-counting — the single most common silent error in analyst SQL, and one that trainers catch in seconds but solo learners can miss for weeks.
A realistic 4-week learning plan, with practice datasets
Four weeks of one focused hour a day beats four months of occasional bingeing. A plan that works:
- Week 1 — foundations. Install MySQL or PostgreSQL (either is fine; the analyst subset is nearly identical). SELECT, WHERE, ORDER BY, LIMIT, handling NULLs. Write 10–15 small queries daily.
- Week 2 — aggregation. COUNT, SUM, AVG, GROUP BY, HAVING, CASE expressions for bucketing. Rebuild pivot-table summaries you would normally make in Excel.
- Week 3 — joins. INNER and LEFT JOIN, joining three or more tables, finding unmatched rows, basic subqueries. This is the week most learners wobble — slow down and draw the tables.
- Week 4 — window functions and speed. ROW_NUMBER, RANK, running totals, then timed practice: interview-style problems in 10–15 minutes each.
For datasets, use the classic Sakila and Northwind sample databases, Kaggle e-commerce and retail sales datasets, and Indian open-data portals — anything with multiple related tables. The rule that matters most: type every query yourself. Reading SQL teaches recognition; writing it teaches recall, and interviews test recall.
Two habits multiply the plan. First, narrate each query in business language before writing it — "average order value per city for the last quarter" — because interviews are exactly that translation exercise. Second, keep a personal error log: every wrong result and why. By week four that log becomes your best revision document, and the mistakes stop repeating.
Interview questions — and how SQL fits with Excel and Power BI
Across the screening tests our placement candidates face, the same question families repeat: second-highest salary or order value (classic ranking), duplicate detection with GROUP BY and HAVING, department-wise or category-wise top-N with window functions, customers with no orders via LEFT JOIN, month-on-month revenue comparison, and explaining WHERE versus HAVING or INNER versus LEFT JOIN in plain words. Practise these families until they are boring.
SQL does not replace your other tools — it feeds them. The everyday workflow in most Indian teams is: SQL pulls and shapes the data from the database, Excel handles quick ad-hoc analysis and business-side sharing, and Power BI turns the queried data into live dashboards for managers. Recruiters test SQL hardest because it sits at the start of that chain: an analyst who cannot get the data cannot do anything downstream. Learn the three together and each one reinforces the others. In interviews, expect at least one question that crosses the boundary — "you have this query result, how would you present it to the sales head?" — because the job itself always does.
Learn with Cokonet Academy, Trivandrum
At Cokonet Academy — training careers since 2010, with 15,000+ alumni, 400+ corporate partners, NSDC partnership and a 4.7 Google rating from 405 reviews — SQL is taught live inside the Data Analytics course, not left to videos. Practitioner trainers have every learner writing queries in class on business-style datasets, clear doubts in the same session, and run timed query challenges that mirror real screening tests before mock interviews begin. More guides live on our blog.
Meet us at the Trivandrum head office or the Kochi centre, or call +91 80754 00500 / learn@cokonet.com. We share free sessions and hiring updates on LinkedIn, YouTube, Instagram and Facebook.
