Cineva cu 4 ani de experiență ca BI Analyst se pregătește pentru un interviu la o companie de top — financial services, retail mare, sau tech. Are CV-ul lustruit, știe Power BI, scrie SQL bine. Întrebarea care îl preocupă nu e dacă va răspunde la întrebările tehnice, ci dacă va răspunde ca un senior sau ca un mid pasionat. Diferența între aceste două nivele se vede în detalii pe care recruiterii buni le ascultă deliberat. Acest material adună întrebări reale dintr-un interviu BI Specialist serios în 2027 și arată cum sună răspunsurile la fiecare nivel.

Articolul nu e despre formule clișeu („spune-mi o slăbiciune”). E despre întrebări tehnice și business unde diferența între candidați devine clară.

Cum arată un interviu BI Specialist în 2027

Structura standard la companii medii și mari include trei sau patru runde.

Prima e screening telefonic sau video, 30-45 de minute, cu recruiter sau hiring manager. Verifică experiența reală, motivația, fit-ul cultural inițial. Întrebările sunt despre proiecte trecute, nu despre sintaxă SQL.

A doua e tehnică, 60-90 de minute, cu un senior BI sau data engineer. Aici se testează SQL la nivel intermediar-avansat, Power BI sau Tableau, înțelegerea modelelor de date, eventual statistică. La companii mai mari, există o probă practică separată.

A treia e business case sau probă reală, 60-120 de minute. Candidatul primește un dataset sau un brief de business, construiește o soluție, prezintă. Asta separă clar oamenii care înțeleg analytics business de cei care doar cunosc tooluri.

A patra, dacă există, e cu management — discuții despre arhitectură, decizii anterioare, gestionarea stakeholder-ilor. Pentru roluri senior, e adesea cea mai grea rundă.

Întrebări de SQL care apar constant

„Explică-mi diferența dintre INNER JOIN și LEFT JOIN cu un exemplu concret.”

Răspuns mid: „INNER JOIN păstrează doar rândurile cu match în ambele tabele. LEFT JOIN păstrează toate rândurile din tabelul stâng plus match-urile din dreapta. Dacă vreau toți clienții și opțional comenzile lor, folosesc LEFT JOIN.”

Răspuns senior: „INNER JOIN pe clienți și comenzi îmi va da doar clienții cu comenzi. LEFT JOIN îmi va da toți clienții, cu NULL pe coloanele de comenzi pentru cei fără. În practică, asta contează enorm pentru rapoarte gen ‚câți clienți nu au comandat de 90 de zile’ — răspunsul greșit cu INNER JOIN ar exclude exact populația care interesează. O capcană subtilă apare când vrei să filtrezi și pe condiție din tabelul drept — punerea condiției în WHERE versus în clause ON schimbă semantic ce face query-ul. Pentru ‚clienți fără comenzi în ultimele 90 de zile’, condiția pe data comenzii trebuie să fie în ON, nu în WHERE, altfel LEFT JOIN se transformă efectiv în INNER JOIN.”

Diferența: senior-ul leagă tehnologia de business case și știe edge case-urile.

„Ai un tabel cu vânzări. Scrie un query care îmi dă top 3 produse pe fiecare categorie.”

Răspunsul corect implică window functions.

SELECT *
FROM (
    SELECT
        category,
        product_id,
        revenue,
        ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC) AS rn
    FROM products
) ranked
WHERE rn <= 3;

Răspunsul senior adaugă: „Folosesc ROW_NUMBER pentru că în caz de egalitate vreau exact 3 produse. Dacă business-ul vrea să includă egalitățile, folosesc DENSE_RANK. ROW_NUMBER alege arbitrar între egalități — pentru un raport critic, sortarea secundară explicită (ex: ORDER BY revenue DESC, product_id ASC) face rezultatul determinist.”

„Cum identifici rânduri duplicate într-un tabel?”

Răspunsul de bază — GROUP BY pe coloanele cheie cu HAVING COUNT(*) > 1. Răspunsul mai bun adaugă: „Depinde ce înseamnă duplicate. Duplicat exact pe toate coloanele e ușor — folosesc agregare pe toate coloanele sau ROW_NUMBER. Duplicat business (același client cu nume scrise diferit) e o problemă fundamental diferită — fuzzy matching, normalizare prealabilă, eventual probabilistic matching pentru volume mari.”

Întrebări despre modelare de date

„Cum modelezi un data warehouse pentru retail cu 50 de magazine?”

Răspunsul mid descrie tabele dimensionale și fact-uri. Senior-ul adaugă context.

„Star schema clasic — fact_sales în centru cu măsurări (quantity, revenue, cost), dimensiuni pe customer, product, store, date, employee. Snowflake schema doar dacă normalizarea ajută real performanța sau spațiul. Pentru retail cu 50 de magazine, star schema simplu e suficient. Atenție la grain-ul fact-ului — la nivel de linie de bon sau la nivel de bon agregat. Diferența contează enorm pentru posibilitatea de a face analize granulare ulterior. În 90% din cazuri, recomandarea e linie de bon, chiar dacă volumul crește. Costul stocării e neglijabil; rigiditatea unui fact agregat e majoră.”

Continuarea naturală e despre slowly changing dimensions. „Pentru atributele care se schimbă în timp — magazin schimbă manager, client schimbă regiune, produs schimbă categoria — trebuie decis SCD Type 1 (suprascris), Type 2 (istoric păstrat), sau Type 3 (parțial). Pentru rapoarte care compară perioade, Type 2 e adesea necesar. Implementarea adaugă complexitate semnificativă în ETL.”

„Când folosești OLAP cube vs query direct pe data warehouse?”

În 2027, întrebarea are valență istorică. Cube-uri MOLAP (SQL Server Analysis Services tradițional) au pierdut teren în favoarea modelelor tabulare in-memory (Power BI, SSAS Tabular).

Răspuns matur: „Modelele tabulare in-memory au înlocuit OLAP cube-urile clasice în majoritatea cazurilor pentru BI corporate. VertiPaq engine din Power BI / SSAS Tabular oferă performanță foarte bună pe modele de mărime medie-mare, cu cost de development semnificativ mai mic decât MOLAP. Cube-urile MOLAP rămân relevante doar pe scenarii foarte specifice — modele cu calcule complexe pe ierarhii adânci, integrare cu sisteme Microsoft tradiționale, sau cazuri în care o investiție majoră s-a făcut și nu se justifică migrarea. În 2027, recomandarea default pentru un departament BI nou e model tabular.”

Întrebări despre Power BI

„Explică diferența între măsurări și coloane calculate.”

Răspunsul de bază — coloanele se calculează la refresh, măsurările la query. Răspunsul senior leagă de impact pe model.

„Coloana calculată consumă memorie. Pe un fact cu 50M rânduri, o coloană nouă crește dimensiunea modelului proporțional. Măsurarea nu — se calculează on-demand în contextul de filtru. Regula practică — orice ai putea exprima ca măsurare, exprimă ca măsurare. Coloana calculată e justificată doar când ai nevoie de filtrare, grupare sau relație pe valoarea respectivă. Atenție și la coloanele calculate care depind de relații — în anumite scenarii, propagarea relațiilor în coloane calculate diferă de comportamentul în măsurări, ceea ce creează rezultate surprinzătoare.”

„Cum optimizezi un model Power BI care e lent?”

Aici răspunsul scurt nu există. Senior-ul listează un proces.

„Primul — identifici unde e problema. Refresh lent? Interactivitate lentă pe raport? Două probleme complet diferite. Pentru refresh, mă uit la query folding în Power Query — multe transformări nu se traduc în query SQL pe sursa de date și ajung să tragă toate datele și să le proceseze local. Folding-ul corect mută munca pe motorul bazei de date. Pentru interactivitate lentă, DAX Studio și Performance Analyzer arată exact ce măsurări sunt scumpe. Tipic, problemele sunt în CALCULATE-uri imbricate, FILTER-uri pe coloane mari în loc de tabele small dimension, sau CALCULATETABLE cu rezultate masive.”

„Pe modele mari, agregările (aggregations) — fie automate, fie definite explicit — sunt diferența între raport care răspunde în 2 secunde și raport care răspunde în 30. Documentația Power BI pentru aggregations explică pattern-urile.”

„Power BI Premium vs PPU vs capacități Fabric — când alegi ce?”

Întrebare care testează dacă candidatul a făcut alegeri reale, nu doar a citit despre features.

„Per User (PPU) face sens pentru echipe mici-medii care nu au nevoie de capacitate dedicată. Premium per capacity, cu cost fix de la $5000+/lună, devine economic peste un anumit număr de utilizatori — tipic 70-100 cu nevoi avansate. Fabric F-SKU-urile au unificat capacitățile BI cu data engineering, deci alegerea în 2027 nu mai e doar despre BI — e despre întreaga stivă analytics. Pentru o companie care construiește acum platforma, Fabric e direcția naturală dacă deja sunt în Microsoft. Pentru echipe care folosesc Power BI izolat, PPU rămâne adesea suficient.”

Întrebări de business sense

Aici diferența între un BI Specialist tehnic competent și unul senior real devine cea mai vizibilă.

„Un manager îți cere un raport săptămânal nou. Cum procedezi?”

Răspunsul mediu — întreb ce date sunt necesare, construiesc raportul, îl trimit.

Răspunsul senior — „Întâi întreb de ce. Ce decizie va lua pe baza acestui raport? Asta filtrează 30% din cereri care de fapt sunt rezolvabile cu un raport existent ușor modificat. Apoi întreb cine îl va primi și ce face cu el — un raport care merge la 5 directori e diferit de unul care merge la 50 de team lead-uri. Apoi clarific cadența reală — săptămânal e cerut, dar deseori se descoperă că lunar e suficient sau zilnic e necesar. La sfârșit construiesc, dar primele 30 de minute de conversație economisesc deseori zile de revizuiri ulterioare.”

„Cum convingi un stakeholder că datele lor sunt greșite?”

Întrebarea testează maturitatea politică. Răspunsurile slabe sună a tehnician care prezintă fapte. Răspunsurile bune arată că candidatul a învățat că oamenii nu acceptă mesaje despre datele lor doar pentru că faptele sunt corecte.

„Niciodată în public. Niciodată ca acuzație. Întâi documentez cu cifre clare diferența — nu ‚datele sunt greșite’ ci ‚aici e ce arată sistemul X, aici e ce arată sistemul Y, diferența e Z%, iată unde se rupe lanțul’. Apoi merg la stakeholder unu la unu, încadrez ca pe o problemă comună de rezolvat, nu ca pe greșeala lui. Apoi propun mecanismul concret de validare permanentă pentru viitor. Tonul e ‚ce să facem împreună’, nu ‚ai greșit’. Ce trebuie evitat e să trimiți un email cu screenshot care contrazice public raportul cuiva — fără excepție, asta închide ușa colaborării.”

„Ai construit un raport. După 3 luni nu mai e folosit. Ce fac?”

Răspunsul slab acceptă cu resemnare. Răspunsul senior investighează.

„70% din rapoartele BI generate într-o companie sunt deschise o singură dată. Asta spune mai multe despre cum sunt construite decât despre cititori. Întrebări reale — am construit ce a fost cerut sau ce era util? Stakeholder-ul original a plecat / și-a schimbat focusul / a găsit alt mod? Raportul e accesibil la momentul potrivit, sau ajunge într-un folder uitat? Tehnologia folosită s-a schimbat — un dashboard Power BI care nu mai e accesibil mobil în 2027 când management-ul e mobil-first e mort fără să apese cineva pe el. Concluzia practică — la următoarea livrare, am o conversație de 15 minute la 30 de zile după go-live. Verifică adopția, ajustează.”

Întrebări tehnice care apar mai rar dar diferențiază

„Explică statistica testului A/B la un nivel pe care îl poate înțelege un director comercial.”

Candidatul care răspunde rapid în jargon (p-value, confidence interval, sample size calculation) demonstrează că știe testul. Candidatul senior demonstrează că poate traduce.

„Un test A/B e o întrebare: dacă schimb X, se schimbă rezultatul măsurabil cu cifre? Dezvoltăm două variante, le rulăm pe utilizatori similari aleatori, măsurăm. Întrebarea cheie e cât de mult trebuie să vedem diferență pentru a fi siguri că nu e doar șansă. La 1% diferență pe 10.000 de utilizatori, da, e probabil real. La 1% diferență pe 200 de utilizatori, e probabil zgomot. Există o formulă care îți spune câți utilizatori îți trebuie ca să poți detecta o diferență de X% — calculul ăsta trebuie făcut înainte de test, nu după.”

Răspunsul demonstrează că candidatul a vorbit cu non-tehnici suficient cât să știe ce funcționează.

„Diferența practică între AI generativ și predictive modeling tradițional pentru BI?”

Întrebare relevantă în 2027 pe rolurile senior. „AI generativ rezolvă probleme de interfață și de generare de conținut — text-to-SQL, rezumate automate pe rapoarte, asistent conversațional. Predictive modeling clasic rezolvă probleme de predicție pe variabile cuantificabile — churn, demand forecasting, scoring. Pentru un departament BI, ambele au loc. Greșeala comună e să folosești GPT-style models pentru predicții cuantificabile — vor genera răspunsuri plauzibile dar nesigure. Pentru forecasting de cerere, folosești ARIMA, Prophet, sau modele gradient boosting cu features inginerite. Pentru asistent conversațional pe semantic layer, folosești LLM cu RAG.”

Proba practică: ce să te aștepți

La companii serioase, există proba practică. Tipic — un dataset (CSV cu 10-100k rânduri) și un brief simplu: „Construiește un dashboard care răspunde la întrebările Y și Z din punct de vedere business. Ai 90 de minute. Prezintă rezultatul.”

Recruiterii evaluează:

• Cât de rapid identifici structura datelor și problemele evidente (NULL-uri, duplicate, valori imposibile).
• Ce alegi să arăți și ce excluzi. Cei care arată totul demonstrează că nu au prioritizat.
• Cum prezinți. Storytelling-ul, nu doar graficele.
• Cât de bine răspunzi la întrebări follow-up care provoacă alegerile tale.

Recomandarea practică pentru pregătire — exersează cu dataset-uri publice (Kaggle, BigQuery public datasets). Pune-ți cronometru. Forțează-te să livrezi în 60 de minute, chiar dacă rezultatul e imperfect.

Întrebări care testează vector de creștere

La nivel senior, recruiterii caută și semnale despre potențial. Câteva întrebări comune.

„Cum ai învăța o tehnologie nouă pe care nu ai mai folosit-o niciodată?”

Răspunsuri generice („citesc documentația”) sunt slabe. Răspunsuri concrete cu pași și exemple personale sunt bune. „Aleg un proiect mic real, nu tutorial — un mini-proiect pe date personale sau publice. Citesc documentația oficială selectiv, nu cap-coadă. Mă uit la 2-3 implementări reale pe GitHub. Construiesc, eșuez, ajustez. În maxim 2 săptămâni am suficient să iau o decizie despre dacă tehnologia merită aprofundată.”

„Ce parte din ce faci zilnic ai automatiza dacă ai avea timp?”

Testează self-awareness și gândire de produs. Răspunsuri bune identifică patternuri repetitive specifice și au schiță de soluție. Răspunsuri slabe sunt vagi.

Întrebări pe care să le pui tu

Interviul e bidirecțional. Întrebările pe care le pui spun mult despre maturitatea ta.

„Cum arată stack-ul actual și ce e planificat să se schimbe în următoarele 12 luni?” Testezi dacă au strategie sau improvizează.

„Cine ia decizia finală pe priorități în roadmap-ul BI?” Indicator clar despre cum se iau decizii.

„Cum se măsoară succesul echipei BI?” Răspunsuri vagi („livrăm valoare”) sunt semnal negativ. Răspunsuri specifice (NPS de la stakeholders, time-to-insight, adopție dashboard-uri) arată maturitate.

„Care a fost cel mai mare eșec al echipei în ultimul an și ce s-a învățat?” Companiile sănătoase au răspuns. Companiile care evită întrebarea sunt semnal de alertă.

Greșeli comune în interviuri BI

După observarea multor interviuri din ambele părți, câteva pattern-uri.

Folosirea jargonului fără context. „Am implementat un star schema cu SCD Type 2 pe dimensiunile critice” — fără să explici de ce, fără să arăți că ai înțeles tradeoff-urile, sună a memorat.

Exagerarea contribuțiilor personale. „Am crescut adopția dashboard-ului cu 200%”. La follow-up: „pe ce bază măsurat? Cine altcineva a contribuit? Care a fost contextul mai larg?”. Răspunsurile evazive trag în jos.

Neacceptarea că nu știi ceva. „Nu am folosit Snowflake direct, dar am lucrat cu BigQuery și înțeleg conceptele de columnar warehouse. Aș învăța rapid”. E un răspuns infinit mai bun decât improvizație despre o tehnologie nefolosită.

Lipsa exemplelor concrete. „Am experiență cu rapoarte complexe” — nu spune nimic. „Am construit un dashboard de KPI executive cu 6 surse de date, refresh la fiecare 15 minute, folosit zilnic de board” — asta spune.

Ce caută companiile cu adevărat

Skill-urile tehnice sunt scor minim. Diferențiatorii reali la nivel senior:

• Capacitatea de a comunica cu non-tehnici fără să simplifici greșit.
• Judecata despre tradeoff-uri — știe să spună „depinde” și să explice de ce.
• Inițiativă cu rezultat — nu doar idei, ci execuție pe idei.
• Conștientizarea limitelor proprii și a tehnologiei. Cine pretinde că orice e posibil pierde credibilitate.
• Curiozitate continuă — peisajul BI s-a schimbat dramatic între 2024 și 2027. Cine nu mai învață rămâne în urmă rapid.

Asta e ce caută hiring manager-ul după ce a verificat că știi SQL și DAX la nivel corect. Restul candidaților se află în pool-ul mid; cei care arată aceste trăsături trec la senior.

Tema se leagă natural de discuția despre Data Analyst, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. Pentru actualizări și detalii suplimentare, LinkedIn Learning rămâne sursa principală pe acest subiect. În fond, interviu BI nu e doar un concept tehnic — este o decizie de business cu impact direct pe productivitatea echipei.

Pregătirea reală pentru interviu

Un singur sfat care contează mai mult decât celelalte. Pregătește-ți 3-4 povești concrete despre proiecte recente. Fiecare poveste cu: contextul de business, problema, ce ai făcut tu specific, rezultatul măsurabil, ce ai învățat. Aceste povești vor fi materia primă din care răspunzi la 60% din întrebările de interviu.

Companiile care fac interviuri serioase folosesc tehnici comportamentale — întreabă despre situații specifice din trecut. Răspunsurile teoretice („în general aș face X”) sunt slabe. Răspunsurile cu situații reale, cu cifre, cu rezultate, sunt convingătoare.

Restul — sintaxa SQL, sintaxa DAX, definițiile formale — sunt verificabile rapid. Diferențiatorul e cum integrezi tehnic și business într-o narațiune coerentă despre ce ai făcut și cum gândești.

Asta vine din experiență practică, nu din cărți. Dar și din reflecție conștientă asupra experienței — multe persoane fac proiecte bune și nu știu să le povestească. Pregătirea pentru interviu e și ocazia de a clarifica pentru tine ce ai învățat efectiv în ultimii ani.

Întrebări frecvente

Cum arată un interviu de BI Specialist?

Trei sau patru runde la companiile medii și mari: screening de 30-45 de minute cu recruiterul sau hiring managerul; tehnică de 60-90 de minute cu un senior BI sau data engineer; business case sau probă reală de 60-120 de minute; și, dacă există, o rundă cu managementul despre arhitectură, decizii anterioare și gestionarea stakeholderilor.

Cum răspund la întrebarea despre INNER JOIN și LEFT JOIN?

Diferența dintre un răspuns mid și unul senior nu e definiția, ci legătura cu businessul. Mid spune că INNER JOIN păstrează doar rândurile cu potrivire în ambele tabele. Senior traduce: un INNER JOIN pe clienți și comenzi îți dă doar clienții care au comenzi — și continuă cu edge case-urile care apar din asta în raportare.

Ce se cere la SQL în probă?

Interogări de tip top-N pe grupuri. Exemplu tipic: primele 3 produse din fiecare categorie, rezolvat cu ROW_NUMBER() OVER (PARTITION BY category ORDER BY revenue DESC) într-un subquery filtrat la rn ≤ 3. Alt clasic: identificarea rândurilor duplicate, cu GROUP BY pe coloanele cheie și HAVING COUNT(*) > 1.