SQL-sollicitatievragen: de vragen die je krijgt en hoe je ze beantwoordt

Hoe ziet een SQL-test bij een sollicitatie eruit?

Een SQL-test bij een sollicitatie is meestal kort en praktisch: je krijgt een paar tabellen, zoals klanten en bestellingen, en een handvol vragen die je met een query beantwoordt. Soms zit je achter een online editor, soms schrijf je op papier of loop je een query hardop door met je toekomstige collega. De vragen gaan zelden over obscure functies. Ze testen of je de basis foutloos beheerst, ook als de gegevens niet meewerken.

Dat werkgevers ernaar vragen, is niet vreemd. Bijna 17% van de Vlaamse bedrijven met minstens tien werknemers had in 2024 vacatures voor ICT-specialisten, en in heel België ging het om 14%, tegenover 10% in de EU (Statistiek Vlaanderen). Op de lijst van knelpuntberoepen 2026 van de VDAB staan onder meer de data engineer, de data scientist en de software-ontwikkelaar (VDAB).

Hoeveel SQL moet je kennen voor een job als data-analist?

Minder dan je vreest, maar dan wel grondig. Voor een job als data-analist, controller of marketeer volstaat meestal de kern: SELECT en WHERE, GROUP BY met COUNT en SUM, HAVING, INNER en LEFT JOIN, en vaak één window function zoals RANK. Wie die kern foutloos toepast, ook op gegevens met lege velden en dubbele rijen, staat sterker dan iemand die honderd functies vaag kent.

Alle voorbeelden hieronder draaien op de gegevens van Bonen & Co, de koffiebranderij uit de eerste module van onze cursus. Die heeft vier tabellen: klanten, producten, bestellingen en bestelregels. Elk resultaat dat je hier leest, komt uit die tabellen, en twee vragen los je meteen zelf op. Nog nooit een query geschreven? Lees dan eerst wat SQL is en hoe een query werkt.

SQL-vragen bij een sollicitatie: de basis

De eerste vragen van een test lijken eenvoudig, en dat is net de bedoeling: een werkgever wil zien of je weet wat een query precies doet, ook in de randgevallen waar een beginner over struikelt. Deze drie komen in een of andere vorm vaak terug.

In welke volgorde voert de database een query uit?

Niet in de volgorde waarin je ze schrijft. Je typt eerst SELECT, maar de database begint bij FROM: uit welke tabel? Daarna houdt WHERE de juiste rijen over, maakt GROUP BY groepen, filtert HAVING die groepen, en pas dan kiest SELECT de kolommen. ORDER BY en LIMIT komen als laatste. Wie die volgorde kent, snapt meteen waarom COUNT niet in WHERE mag staan.

FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

Wat is het verschil tussen = NULL en IS NULL?

NULL betekent dat er geen waarde is, en daarmee kan je niets vergelijken: zelfs NULL = NULL is niet waar, maar onbekend. Daarom geeft WHERE email = NULL nooit een rij terug, en je krijgt er ook geen foutmelding bij. Bij Bonen & Co hebben drie klanten geen e-mailadres. De eerste query hieronder vindt er nul, de tweede alle drie: Amira El Idrissi, Noah Janssens en Daan Smit.

-- 0 rijen, zonder foutmelding
SELECT naam FROM klanten WHERE email = NULL;

-- 3 rijen
SELECT naam FROM klanten WHERE email IS NULL;

Waarom geeft deze query te veel rijen?

Een klassieker: de interviewer vraagt de klanten uit Gent of Antwerpen die sinds 2024 lid zijn, en legt je deze query voor. Ze geeft drie namen terug en ziet er op het eerste gezicht in orde uit. Wat loopt er mis?

SELECT naam, stad, lid_sinds
FROM klanten
WHERE stad = 'Gent' OR stad = 'Antwerpen'
  AND lid_sinds >= '2024-01-01';

AND gaat voor OR, zoals vermenigvuldigen voor optellen gaat. De database leest dus: klanten uit Gent, óf klanten uit Antwerpen die sinds 2024 lid zijn. Zo glipt Lotte Peeters erdoor, lid sinds 2023, gewoon omdat het adres in Gent ligt. Met haakjes rond stad = 'Gent' OR stad = 'Antwerpen' blijven alleen Fien Maes en Lucas Mertens over, de twee die echt aan de vraag voldoen.

Welke vragen krijg je over GROUP BY, HAVING en COUNT?

Zodra er geteld wordt, verschuift de test van rijen naar groepen. Daar gaat het vaak mis, omdat de query wel loopt maar iets anders telt dan je denkt. Twee verschillen moet je dan vlot kunnen uitleggen, liefst met een voorbeeld erbij.

Wat is het verschil tussen WHERE en HAVING?

WHERE filtert rijen vóór het groeperen, HAVING filtert groepen erna. Dat is het korte antwoord, en meestal vraagt de interviewer dan een voorbeeld. Deze query telt per stad de klanten met een e-mailadres en toont alleen de steden met minstens twee zulke klanten.

SELECT stad, COUNT(*) AS klanten
FROM klanten
WHERE email IS NOT NULL
GROUP BY stad
HAVING COUNT(*) >= 2;

Het resultaat: Antwerpen met 2 en Gent met 3. Zonder de WHERE stond Brussel er ook bij, met twee klanten, maar Amira El Idrissi heeft geen e-mailadres. Zet je COUNT(*) >= 2 in WHERE, dan krijg je een foutmelding: de groepen bestaan op dat moment nog niet. Oefen het verschil in de les over HAVING.

Wat is het verschil tussen COUNT(*) en COUNT(kolom)?

COUNT(*) telt rijen, COUNT(email) telt alleen de rijen waar email niet NULL is, en COUNT(DISTINCT stad) telt de verschillende waarden. Op dezelfde tabel geeft dat drie verschillende antwoorden, en een interviewer wil horen dat je weet welk je nodig hebt.

SELECT COUNT(*), COUNT(email), COUNT(DISTINCT stad)
FROM klanten;

Twaalf klanten, negen met een e-mailadres, uit acht steden. Wie op "hoeveel klanten hebben een e-mailadres?" met COUNT(*) antwoordt, zit er dus drie naast. Het verschil wordt pas echt pijnlijk bij een LEFT JOIN, verderop: daar telt COUNT(*) een rij vol NULL'en gewoon mee.

Welke vragen over JOIN kan je verwachten?

Joins zijn het hart van bijna elke SQL-test, want echte gegevens staan zelden in één tabel. De vragen gaan over welk soort join je kiest, hoe je vindt wat ontbreekt, en waarom een totaal na een join plots niet meer klopt.

Wat is het verschil tussen INNER JOIN en LEFT JOIN?

Een INNER JOIN, of gewoon JOIN, houdt alleen de rijen die in beide tabellen een partner hebben. Een LEFT JOIN houdt elke rij van de linkertabel, ook zonder partner, en vult de kolommen van rechts dan met NULL. Koppel je de 12 producten van Bonen & Co aan hun 25 bestelregels, dan geeft JOIN 25 rijen en LEFT JOIN 26: de Reismok werd nooit besteld en komt er alleen met een LEFT JOIN bij.

Welke klanten hebben nog nooit besteld?

Dit is misschien de bekendste testvraag, en het antwoord is een patroon: een LEFT JOIN naar de bestellingen, en dan alleen de rijen houden waar rechts niets gevonden werd. Een gewone JOIN kan deze vraag nooit beantwoorden, want die laat de klanten zonder bestelling al vallen voor WHERE aan de beurt komt.

SELECT k.naam
FROM klanten k
LEFT JOIN bestellingen b ON b.klant_id = k.id
WHERE b.id IS NULL;

Bij Bonen & Co geeft die query nul rijen, want elke klant bestelde al minstens één keer. Ook dat is een juist antwoord, en zeg het gerust hardop in een gesprek: een leeg resultaat is geen fout zolang de query klopt. Hetzelfde patroon op de producten vindt wel iets. Probeer het zelf.

Wil de interviewer daarna het aantal bestelregels per product, ook als dat 0 is, tel dan COUNT(br.id) en niet COUNT(*). Met COUNT(*) krijgt de Reismok 1, want de rij met lege bestelkolommen telt mee. De les over LEFT JOIN bouwt beide patronen stap voor stap op.

Filter je na een LEFT JOIN in WHERE op een kolom van rechts, zoals b.status = 'geleverd', dan vallen de rijen zonder partner weer weg: hun NULL voldoet nooit. Zet zo'n voorwaarde in ON.

Waarom is mijn SUM te hoog na een JOIN?

Omdat één rij links bij meerdere rijen rechts hoort, en de join die rij dan herhaalt. Rosa wil per categorie de voorraad en het aantal verkochte stuks. Deze query ziet er logisch uit, loopt zonder fout en geeft voor elke categorie een getal. Alleen klopt de voorraad nergens.

SELECT p.categorie, SUM(p.voorraad) AS voorraad, SUM(br.aantal) AS verkocht
FROM producten p
JOIN bestelregels br ON br.product_id = p.id
GROUP BY p.categorie;

Voor de capsules geeft ze een voorraad van 530 stuks, terwijl er 120 Capsules Lungo en 85 Capsules Ristretto liggen: samen 205. Bij de bonen is het nog erger, met 343 in plaats van 90. Kijk naar de rijen vóór het optellen en je ziet waarom.

Capsules Lungo staat in drie bestelregels, dus telt SUM(p.voorraad) die 120 drie keer. Het aantal verkochte stuks klopt wel, want dat zit in de bestelregels zelf. De oplossing: tel de bestelregels eerst op per product, zodat elk product nog maar één rij heeft, en koppel pas daarna.

SELECT p.categorie, SUM(p.voorraad) AS voorraad, SUM(v.verkocht) AS verkocht
FROM producten p
LEFT JOIN (
  SELECT product_id, SUM(aantal) AS verkocht
  FROM bestelregels
  GROUP BY product_id
) v ON v.product_id = p.id
GROUP BY p.categorie;

Nu staat er 205 voor de capsules, met 20 verkocht. Door de LEFT JOIN telt ook de voorraad van de Reismok mee, die nooit verkocht werd. In een gesprek maak je hier indruk door eerst terug te vragen: op welk niveau staat elk getal, per product of per bestelregel?

Wat is het verschil tussen ROW_NUMBER, RANK en DENSE_RANK?

Alle drie nummeren rijen in een volgorde die je zelf kiest, en ze verschillen alleen bij een gelijke stand. Je hebt ze nodig voor ranglijsten, een top 3 per categorie of de beste klant per stad, en de vraag erachter is altijd dezelfde: wat doe je met gelijken?

Wat gebeurt er bij een gelijke stand?

ROW_NUMBER geeft altijd een ander nummer, ook bij gelijke waarden. RANK geeft gelijken hetzelfde nummer en slaat daarna plaatsen over. DENSE_RANK geeft gelijken ook hetzelfde nummer, maar telt daarna gewoon door. Rangschik de klanten van Bonen & Co op hun aantal bestellingen, en je ziet het verschil meteen.

SELECT k.naam, COUNT(b.id) AS bestellingen,
  ROW_NUMBER() OVER (ORDER BY COUNT(b.id) DESC) AS rij,
  RANK()       OVER (ORDER BY COUNT(b.id) DESC) AS rang,
  DENSE_RANK() OVER (ORDER BY COUNT(b.id) DESC) AS dicht
FROM klanten k
JOIN bestellingen b ON b.klant_id = k.id
GROUP BY k.id, k.naam;

Jonas en Sander hebben allebei twee bestellingen. ROW_NUMBER moet toch kiezen wie tweede wordt, en die keuze ligt niet vast. RANK geeft hen allebei 2 en springt dan naar 4, want er staan drie klanten voor. DENSE_RANK gaat verder met 3. Vraagt de interviewer een top 2, dan geeft rang <= 2 drie klanten en rij <= 2 er twee. Oefen het in de les over RANK en DENSE_RANK.

Hoe vind je de op één na hoogste waarde?

Een vaste klant in testvragen is het op één na hoogste salaris. Bij Bonen & Co nemen we de prijs: de Handmolen kost 39 euro, de Pour-over set 27,50 euro. Er zijn drie gangbare antwoorden, en ze zijn niet even goed:

1. ORDER BY prijs DESC LIMIT 1 OFFSET 1: kort, maar fout als twee producten samen de duurste zijn. Dan krijg je de hoogste prijs nog eens.
2. MAX met een subquery: de hoogste prijs die onder de hoogste prijs ligt. Dat werkt in elk dialect.
3. DENSE_RANK() OVER (ORDER BY prijs DESC) en dan plaats 2 houden. Met dezelfde query vraag je ook de derde of de tiende.

LIMIT, TOP of FETCH FIRST: welk SQL-dialect gebruikt de test?

Vraag het gewoon. De kern van SQL is overal dezelfde, maar het aantal rijen beperken schrijft elk systeem anders. SQLite, MySQL en PostgreSQL gebruiken LIMIT. PostgreSQL noemt dat zelf eigen syntax die ook MySQL gebruikt, en wijst erop dat de standaard sinds SQL:2008 OFFSET ... FETCH FIRST heeft voor hetzelfde (PostgreSQL). SQL Server schrijft TOP.

Microsoft raadt zelf aan om TOP altijd samen met ORDER BY te gebruiken: zonder sortering krijg je de eerste rijen in een volgorde die niet vastligt (Microsoft). Bij LIMIT is dat niet anders: wie "de drie duurste" vraagt, wil een sortering, geen toevallige drie. Dat zeg je in een gesprek best even.

Oefen je op SQLite, zoals hier, let dan op de versie van je eigen tool. Window functions zitten in SQLite sinds versie 3.25.0 uit 2018 (SQLite), RIGHT en FULL OUTER JOIN pas sinds 3.39.0 uit 2022 (SQLite). Lurndo draait een recente versie in je browser, dus alles uit dit artikel werkt er.

Welk systeem je op de werkvloer tegenkomt, verschilt per bedrijf. Bij professionele ontwikkelaars gebruikt 61,3% SQL, en bij de databases staat PostgreSQL bovenaan met 58,2%, voor MySQL, SQLite en SQL Server met 30,9% (Stack Overflow). Ken je de kern, dan pas je je snel aan elk van die dialecten aan.

Hoe bereid je je voor op een SQL-test?

Door queries te schrijven, niet door ze te lezen. Een lijst met antwoorden uit het hoofd leren helpt weinig zodra de tabellen er anders uitzien dan in je voorbeeld. Wat wel helpt, zijn vijf gewoontes die je bij elke oefening toepast, tot ze vanzelf gaan:

1. Oefen op echte tabellen. Schrijf elke query zelf en kijk naar het resultaat, niet alleen naar de code.
2. Zoek de randgevallen. Wat gebeurt er met NULL, met een gelijke stand, met een rij zonder partner?
3. Tel je rijen. Hoeveel verwacht je er? Zijn het er meer na een JOIN, dan herhaalt er iets.
4. Praat hardop. Zeg wat elke regel doet. Zo hoort je gesprekspartner hoe je denkt, ook als je een detail vergeet.
5. Vraag het dialect. LIMIT of TOP? Eén vraag, en je verliest geen tijd aan een syntaxfout.

Op SQL leren voor je sollicitatie lees je welke modules het vaakst in tests terugkomen, en bij de SQL-oefeningen vind je oefeningen per onderwerp, met hints en uitleg bij elk antwoord. Elke query die je schrijft, draait echt en wordt gecontroleerd op het resultaat, niet op de schrijfwijze. De eerste drie modules zijn gratis.