SQL og Python interviewspørgsmål til adtech: en komplet guide

Informatic Digital » Recursos » SQL og Python interviewspørgsmål til adtech: en komplet guide

Hvis du forbereder dig til en jobsamtale inden for adtech , digital analyse eller dataanalyse , vil du før eller siden stå over for den frygtede tekniske test. Det er her, virksomheder tjekker, om du virkelig mestrer det, du skriver på dit CV: SQL til at udtrække data, Python til at bearbejde og analysere dem, og nogle analytiske tænkeevner for at undgå at fare vild blandt alle tabellerne og scriptsene.

Den gode nyhed er, at tekniske interviews ikke er magiske: de drejer sig normalt om de samme blokke af SQL, Python og modelevaluering . Hvis du forstår det grundlæggende grundigt, øver dig med øvelser fra den virkelige verden og lærer at forklare dine argumenter, vil du have en betydelig fordel i forhold til andre kandidater.

Hvorfor tekniske interviews er skræmmende (og hvordan man tager toppen af ​​dem)

I stillinger som dataanalytiker eller produktmedarbejder inden for adtech kombinerer tekniske interviews typisk konceptuelle spørgsmål med praktiske øvelser . Du kan blive bedt om at forklare funktionen af ​​en SQL-klausul eller løse en business case, der involverer data fra programmatiske reklamekampagner.

Du vil typisk blive vurderet på tre fronter: SQL på mellemniveau (JOIN, GROUP BY, underforespørgsler, vinduesfunktioner), dataorienteret Python (pandaer, oprydning, aggregeringer, merger) og din evne til at fortolke resultater og kommunikere fund . De leder ikke efter en erfaren dataforsker, men snarere en person, der kan arbejde med data på en robust og pålidelig måde.

Den typiske fejl, mange kandidater begår, er at fokusere på at huske syntaks og glemme at øve sig på komplette øvelser , der ligner dem, du vil støde på på platforme som HackerRank, StrataScratch eller virksomhedernes egne interne tests. Dit mål bør være at ankomme til interviewet og allerede have løst snesevis af meget lignende forespørgsler og scripts.

SQL-niveau, der typisk kræves i jobsamtaler til adtech- og dataanalytikere

For en analytikerrolle i adtech- eller digitale marketingmiljøer forventer virksomheder, at du er dygtig til klassisk relationel SQL : udtrækning af data fra flere tabeller, kombinering, gruppering, filtrering og oprettelse af nyttige metrikker. De kræver ikke databaseadministrationsfærdigheder, men du bør være fortrolig med moderat komplekse forespørgsler.

Typisk vil testen omfatte forespørgsler, der kombinerer INNER JOIN, LEFT JOIN, filtre med WHERE-klausuler, aggregeringer med GROUP BY og nogle betingelser for aggregater ved hjælp af HAVING-klausuler. Derfra, i lidt mere avancerede positioner, er det meget almindeligt at se underforespørgsler og vinduesfunktioner til rangeringer, kumulative totaler og rækkesammenligninger.

Inden for adtech vil du sandsynligvis besvare forretningsmæssige spørgsmål som "Hvilke kampagner har en bedre CTR end gennemsnittet for deres branche?" eller "Hvilke udgivere mister visninger sammenlignet med sidste måned?". At løse disse effektivt kræver normalt en grundlæggende forståelse af korrelerede underforespørgsler og vinduesfunktioner.

Grundlæggende SQL-spørgsmål, der ofte opstår (og hvordan man besvarer dem)

Næsten alle dataorienterede tekniske interviews indeholder et sæt grundlæggende SQL-teorispørgsmål . De forsøger ikke at fange dig, men snarere at sikre, at du har et solidt fundament.

Et af de oftest stillede spørgsmål er forskellen mellem WHERE og HAVING . Den klareste måde at forklare det på er, at WHERE filtrerer individuelle rækker før gruppering , mens HAVING filtrerer grupper, der allerede er aggregeret . Du kan også nævne, at betingelser, der involverer aggregeringsfunktioner (COUNT, SUM, AVG osv.), skal placeres i HAVING, ikke WHERE.

Et andet klassisk spørgsmål er, hvilke typer JOIN der findes, og hvornår man skal bruge hver enkelt: INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN og i nogle tilfælde CROSS JOIN eller self-join. I dataanalyse bruges LEFT JOIN i vid udstrækning, når man vil beholde hele det primære datasæt (f.eks. alle brugere), selvom der ikke er tilknyttede poster i den sekundære tabel (f.eks. køb).

Eksempler på grundlæggende SQL-forespørgsler og deres logik

For at give dig en idé om det "minimum rimelige" niveau, skal du være i stand til at skrive forespørgsler fra hukommelsen, såsom at vælge specifikke kolonner, filtrere rækker og sortere resultater . På et meget grundlæggende niveau omfatter typiske spørgsmål: hvordan man udtrækker alle kolonner fra en tabel, hvordan man kun vælger nogle kolonner, eller hvordan man anvender læsbare aliasser med AS.

Det er også almindeligt at blive spurgt om WHERE-klausulen med flere betingelser, der kombinerer AND, OR og NOT, eller hvordan man bruger sammenligningsoperatorer (<, <=, >, >=, =) til både numeriske værdier og datoer. Mange virksomheder lægger vægt på NULL- filtre , hvor det ikke er nok blot at bruge lighedstegnet; man skal bruge IS NULL eller IS NOT NULL.

En anden klassiker er tekstbaseret filtrering med LIKE og mønstre ved hjælp af jokertegnene % og _. For eksempel kan du finde kampagner, hvis navne indeholder et specifikt ord, eller brugere, hvis e-mailadresser ender på et bestemt domæne. Det er vigtigt at forklare, at LIKE '%text%' søger efter mønsteret hvor som helst i strengen.

Endelig dækker dette grundlæggende afsnit normalt, hvordan man opdaterer poster med UPDATE og filtrerer, hvilke rækker der ændres med WHERE, samt hvordan man sletter rækker med DELETE FROM ved hjælp af klare betingelser. Det er afgørende, at du altid understreger vigtigheden af ​​at bruge en specifik WHERE-klausul for at undgå at slette halvdelen af ​​tabellen ved et uheld.

Mellemforespørgsler: GROUP BY, HAVING, underforespørgsler og UNION

Når du bevæger dig ud over juniorniveauet, begynder næsten alle virksomheder at værdsætte din beherskelse af kombinationen af ​​GROUP BY, aggregeringsfunktioner og filtre på aggregeringer med HAVING . Det er dette, du vil bruge dagligt til at generere performancerapporter for kampagner, målgrupper og kreative medarbejdere.

Det fungerer sådan her: GROUP BY grupperer rækker efter en eller flere kolonner, og du kan anvende SUM, COUNT, AVG, MIN og MAX på disse grupper for at beregne metrikker. HAVING kommer derefter for kun at beholde de grupper, der opfylder en betingelse, for eksempel kunder med salg over en bestemt tærskel.

Et andet tilbagevendende tema er underforespørgsler : en forespørgsel inden for en anden forespørgsel. De bruges ofte til at filtrere efter værdier beregnet i et tidligere trin, f.eks. ved at vælge kunder med et salg over det globale gennemsnit eller kampagner med visninger over den 90. percentil.

Du bliver også ofte spurgt om forskellen mellem UNION og UNION ALL . UNION kombinerer to resultatsæt med det samme skema og fjerner dubletter; UNION ALL gør det samme, men beholder alle rækker, selvom de gentages. I dataanalyse vil du ofte foretrække UNION ALL af ydeevneårsager og fordi du vil bevare alle de originale poster.

Window-funktioner: det næste spring i SQL

Vinduefunktioner er blevet en standard inden for teknisk testning på et vist niveau, især for adtech-relaterede roller , hvor tendenser over tid, kampagnerangeringer eller totale investeringer skal analyseres.

Hovedideen er, at en vinduesfunktion beregner en værdi over et sæt rækker relateret til den aktuelle række , men uden at skjule resultatet, som GROUP BY gør. Med andre ord ser du stadig hver enkelt række, men ledsaget af et aggregat beregnet over et "vindue" af data.

Den typiske syntaks er at bruge funktionen (SUM, AVG, RANK osv.) efterfulgt af OVER, og inden for OVER definere partitionen (PARTITION BY) og rækkefølgen (ORDER BY). For eksempel beregne salgsrangeringen efter sælger eller det akkumulerede antal visninger pr. dag.

Hvis du vil demonstrere din færdighed, bør du gøre dig bekendt med funktioner som RANK, DENSE_RANK, ROW_NUMBER, LAG og LEAD . De er meget nyttige til at rangere kampagner baseret på deres præstation, sammenligne hver periode med den foregående eller identificere variationer i nøgleparametre fra år til år.

CTE, kumulative totaler og glidende gennemsnit

I moderne jobsamtaler værdsættes læsbarheden af ​​din SQL-kode højt. Derfor bliver du ofte spurgt om Common Table Expressions (CTE'er) . En CTE er i bund og grund en type navngiven midlertidig tabel, defineret med WITH-klausuler, der kun eksisterer under udførelsen af ​​forespørgslen.

CTE'er bruges til at opdele komplekse forespørgsler i logiske blokke og genbruge mellemresultater. For eksempel beregner du først daglige metrics pr. kampagne i en CTE, og derefter udfører du i hovedforespørgslen yderligere aggregeringer eller filtrering på det resultat.

En anden meget almindelig øvelse er at beregne en løbende total ved hjælp af SUM som en vinduesfunktion. I adtech-miljøer er det normalt at blive bedt om akkumulerede visninger, klik eller forbrug for at se, hvordan en kampagne klarer sig over tid.

Relateret til dette er glidende gennemsnit , hvor AVG anvendes som en vinduesfunktion over en forskudt rækkeramme (f.eks. de to foregående datoer og den aktuelle). Dette er en simpel måde at udjævne tidsserier og registrere tendenser uden at være så afhængig af daglige toppe.

Python-niveau typisk påkrævet for dataanalytiker

I de fleste dataanalytikerroller (inklusive adtech) forventer virksomheder ikke, at du er en maskinlæringsguru, men de forventer, at du har praktiske kendskaber til Python med pandas . Typisk vil du blive bedt om at indlæse datasæt, rense dem, transformere dem og indhente simple metrics eller visualiseringer.

Python-tests fokuserer typisk på operationer som at læse data fra CSV-filer , inspicere null-værdier og kolonnetyper, filtrere rækker, oprette nye kolonner, aggregeringer ved hjælp af groupby og joins mellem DataFrames. I mange tilfælde er ordlyden næsten identisk med SQL-delen, men i Pandas-format.

Det er ikke almindeligt at skulle bygge komplekse modeller fra bunden i en analytikertest, selvom de måske værdsætter din evne til at bruge scikit-learn til at træne en grundlæggende model og frem for alt din viden om de grundlæggende metrikker til at måle dens ydeevne.

Grundlæggende pandaoperationer, du bør mestre

For at gennemføre enhver Python-dataøvelse skal du være dygtig til grundlæggende DataFrames-operationer. Det første trin er normalt at indlæse en fil ved hjælp af `read_csv` og udforske dens struktur med metoder som `head()`, `info()` eller `describe()`.

Delen om at rydde op i null-værdier dukker normalt også op: at tælle hvor mange null-værdier der er pr. kolonne med isnull().sum(), at beslutte om man skal slette hele rækker eller kolonner med dropna() eller udfylde manglende med fillna(), for eksempel ved at bruge middelværdien eller medianen af ​​kolonnen.

Hvad angår filtre, vil du blive bedt om at opbygge betingelser på numeriske eller kategoriske kolonner, f.eks. at vælge salg over et bestemt beløb eller rækker, der opfylder flere betingelser kombineret med & og |. Nøglen er at vide, hvordan man skriver df uden tøven.

Forklaringen af ​​`groupby` i pandas er næsten altid inkluderet, da det er den direkte ækvivalent til SQL's `GROUP BY`. Du grupperer efter en eller flere kolonner og anvender derefter aggregeringer som `sum`, `mean`, `count` osv. Syntaksen `groupby('column').agg()` er essentiel.

Sammenfletter og fusionerer mellem DataFrames

Ligesom det er essentielt at mestre JOINs i SQL, er det obligatorisk at mestre pd.merge i pandas . Virksomheder vil gerne se, om du ved, hvordan man joiner datasæt, der deler en nøgle, for eksempel en tabel over brugere, med en anden tabel over hændelser eller køb.

Merge-funktionen tager de to DataFrames, der skal joinees, nøglekolonnen (on) og join-typen (how), som kan være 'left', 'right', 'inner' eller 'outer', ligesom i SQL. I dataanalyse bruges left join primært til at bevare hoveddatasættet og tilføje attributter eller metrikker fra sekundære tabeller.

I et interview er det en god idé at nævne detaljer som, hvad der sker, når der er dublerede nøgler på begge sider, eller hvordan man håndterer konflikter mellem kolonnenavne og parametersuffikser. Dette formidler et højere niveau af modenhed.

Typiske, mere teoretiske Python-spørgsmål

Ud over pandaer inkluderer mange interviews en kort blok af generelle Python-spørgsmål for at teste din forståelse af sproget. Disse er normalt korte spørgsmål om funktioner, hukommelse, datatyper eller små stykker syntaks.

Blandt de emner, der dukker op gentagne gange, er automatisk hukommelsesstyring i Python, baseret på en privat heap, som brugeren ikke har direkte adgang til, og en garbage collector, der er ansvarlig for at frigøre objekter, der ikke længere har referencer.

Det er også almindeligt at blive bedt om at sammenligne Python med Java , ikke for at kåre en vinder, men for at demonstrere, at man forstår forskellene: Python er mere dynamisk med en mere præcis syntaks, perfekt til prototyping og datalogi, mens Java har en tendens til at dominere i mere virksomhedsorienterede og højtydende økosystemer.

Andre typiske spørgsmål drejer sig om lambda-udtryk (anonyme funktioner til simple operationer), pickling/unpickling-processer til serialisering af objekter til bytes og hentning af dem, eller forskellen mellem lister og tupler, hvor førstnævnte er foranderlige og defineret med firkantede parenteser, og sidstnævnte er uforanderlige og defineret med parenteser.

Flere centrale Python-koncepter i interviews

Det er almindeligt at blive spurgt, hvordan man sletter eller kopierer et objekt i Python. Normalt er det nok at forklare, at man kan bruge `del`-sætningen til at fjerne en reference, og at overfladiske kopier udføres med `copy.copy()`, mens dybe kopier kræver `copy.deepcopy()`.

Et andet koncept, der kan optræde, især i mere backend-profiler, er den såkaldte dogpile-effekt , som beskriver det scenarie, hvor mange brugere eller processer angriber en ressource (f.eks. et websted eller en cache) på samme tid og mætter systemet.

I forbindelse med økosystemet kan du også støde på spørgsmål om databaser, der kan bruges med Python . Den mest fornuftige tilgang er at nævne nogle populære databaser som MySQL, PostgreSQL, SQLite, MongoDB og Oracle, og bemærke, at Python generelt integrerer godt med en bred vifte af relationelle og NoSQL-databasemotorer.

Endelig opstår der ofte enklere spørgsmål, såsom hvordan man sorterer en ordbog ved hjælp af sorterede elementer, hvad et navnerum er, og hvad det bruges til (at knytte navne til objekter i forskellige omfang), eller hvordan man starter en underproces ved hjælp af underprocesmodulet med funktioner som run() eller Popen().

Metrikker til evaluering af modeller i Python: det minimum du bør kende

Selvom mange analytikerstillinger ikke kræver, at du designer deep learning-arkitekturer, er det almindeligt at være bekendt med grundlæggende metrikker til evaluering af klassifikationsmodeller , især hvis rollen involverer dataprodukter, kampagneattribution eller svindeldetektion inden for adtech.

Udgangspunktet er forvirringsmatricen , som opsummerer succeserne og fiaskoerne for en binær eller multiklasseklassifikator. I det binære tilfælde er den opdelt i sande positiver (TP), sande negativer (TN), falske positiver (FP) og falske negativer (FN). En grundig forståelse af disse fire kategorier er nøglen.

Fra matricen udledes målinger som nøjagtighed , som måler procentdelen af ​​korrekte forudsigelser ud af det samlede antal; præcision (TP/positive forudsigelser); og genkendelse eller følsomhed (TP/faktiske positive). Disse to sidste er især vigtige, når klasserne er ubalancerede.

F1 -scoren kombinerer nøjagtighed og genkendelse ved hjælp af den harmoniske middelværdi, hvilket straffer særligt lave scorer for begge dele. Det er en almindelig måleenhed i scenarier, hvor både falsk positive og falsk negative resultater er dyre, såsom svindelopdagelse, leadscoring eller sygdomsopdagelse.

Andre avancerede målinger: ROC-AUC, logloss, Jaccard og mere

For stillinger med en stærkere data science- eller marketinganalysekomponent ser virksomheder på, om du mestrer mere avancerede metrikker som ROC-AUC , som måler arealet under ROC-kurven og afspejler en models evne til at adskille klasser.

ROC-kurven repræsenterer forholdet mellem den sande positive rate (recall) og den falsk positive rate (1 – specificitet) for forskellige beslutningstærskler. En tilfældig model ville ligge på en diagonal linje, mens en god model ville være tættere på det øverste venstre hjørne. Jo større arealet under kurven er, desto bedre er diskriminationsevnen.

En anden almindelig måleenhed er logaritmisk tab (logloss) , som vurderer kvaliteten af ​​forudsagte sandsynligheder og i høj grad straffer overdreven selvtillid og fejl. En perfekt model ville have et logaritmisk tab på 0, og generelt gælder det, at jo lavere logaritmisk tab er, desto bedre.

De kan også spørge dig om Jaccard-indekset , som måler ligheden mellem to sæt som størrelsen af ​​skæringspunktet divideret med størrelsen af ​​foreningen. Det bruges blandt andet til at evaluere klassifikatorer, segmentering og anbefalingssystemer.

I nogle sammenhænge nævnes gevinst- og stigningsdiagrammer , som viser, hvor stor en procentdel af mål du opnår ved kun at bruge en del af populationen (for eksempel de 20% bedste brugere, der er bedømt af din model). Dette bruges i vid udstrækning i marketing til at beslutte, hvem man skal målrette først.

Kolmogorov-Smirnov, Gini-koefficient og dybdegående evaluering

Hvis virksomheden er stærkt fokuseret på scoring- eller risikomodeller, kan der forekomme metrikker som Kolmogorov-Smirnov (KS)-statistikken , som måler graden af ​​adskillelse mellem fordelingen af ​​positive og negative scorer.

En KS-værdi tæt på 100 (som en procentdel) indikerer, at modellen adskiller de to populationer næsten perfekt; en værdi tæt på 0 antyder, at modellen ikke skelner bedre end tilfældigheder. I praksis falder modeller fra den virkelige verden inden for mellemliggende værdier og sammenlignes med hinanden for at vælge den bedste.

Gini -koefficienten er en anden måleenhed udledt af ROC-AUC ved hjælp af formlen Gini = 2 × AUC – 1. Den er meget populær inden for kredit og forsikring og fortolkes også som et mål for ulighed: jo højere Gini er, desto større er modellens evne til at koncentrere sande positive faktorer ved højere scorer.

I mere avancerede interviews kan du blive bedt om at forklare, hvordan disse metrikker implementeres i Python ved hjælp af scikit-learn (f.eks. confusion_matrix, accuracy_score, roc_auc_score, f1_score…), og om at kommentere, hvornår du ville bruge hver enkelt, afhængigt af problemets art og ubalancen i klassen.

Sådan strukturerer du dine svar under det tekniske interview

Ud over den kode, du skriver, er interviewere meget opmærksomme på, hvordan du tænker, og hvordan du forklarer dig selv . Et dårligt struktureret svar kan få dig til at virke lavere rangeret, end du rent faktisk er, selvom du kender den rigtige løsning.

En meget nyttig tilgang til at besvare tekniske spørgsmål er som følger: Forklar først konceptet i én sætning , giv derefter et konkret eksempel (ideelt set relateret til et af dine egne projekter), og nævn, hvis det er relevant, alternativer eller nuancer . Dette fungerer lige så godt for SQL, Python eller modelmålinger.

Hvis du for eksempel bliver spurgt, hvad en CTE er til, kan du sige, at det er en navngiven midlertidig underforespørgsel, der forbedrer læsbarheden af ​​komplekse forespørgsler, tilføje, at du bruger den, når du har brug for at genbruge et mellemresultat flere gange, og nævne, at den i nogle tilfælde kan erstattes af indlejrede underforespørgsler, selvom det er mindre tydeligt.

Det er også vigtigt at tænke højt . Hvis du går i stå, så lad være med at tie stille: forklar, hvad du prøver at gøre, hvilke oplysninger du overser, og hvilke antagelser du gør dig. Dette hjælper intervieweren med at se din tankeproces og giver dig nogle gange endda spor eller afklaringer, der gør det lettere at komme videre.

De mest almindelige fejl i interviews med tekniske data

Mange kandidater bliver ikke udelukket, fordi de mangler tilstrækkelige SQL- eller Python-færdigheder, men på grund af en kombination af dårlig forberedelse og kommunikationsfejl . Det er afgørende at være fuldt ud opmærksom på almindelige faldgruber for at undgå dem.

Den første er at huske uden at forstå . Det er ikke særlig nyttigt at kende syntaksen for RANK eller en lambda-funktion, hvis du ikke derefter kan forklare, i hvilke tilfælde du ville bruge disse værktøjer, eller hvorfor de er at foretrække frem for andre alternativer.

En anden meget almindelig fejl er ikke at vurdere datakvaliteten i øvelserne. Hvis du får udleveret et datasæt, er det tilrådeligt at kontrollere for nuller, dubletter eller outliers, der kan skævvride analysen, inden du begynder at aggregere. Dette demonstrerer sund dømmekraft og praktisk erfaring.

Det er også meget skadeligt at undgå at stille afklarende spørgsmål . I en business case om reklamekampagner giver det for eksempel god mening at spørge om sæsonudsving, måltidsrammen, om der søges efter metrikker pr. bruger eller pr. visning osv. At tie stille og lave antagelser fører ofte til løsninger, der er dårligt afstemt med, hvad intervieweren havde i tankerne.

Undgå endelig "overkodning"-tilgangen: at skabe unødvendigt komplekse løsninger, når forespørgslen eller scriptet kunne være enklere. I virkelige arbejdsmiljøer værdsættes klarhed, vedligeholdelse og effektivitet , ikke gådelignende løsninger.

Intensiv forberedelsesplan på to uger

Hvis du har begrænset tid før interviewet, kan du følge en komprimeret plan, der dækker de tre nøgleområder: SQL, Python med pandas og praktisk anvendelse. Du vil ikke udføre mirakler på 14 dage, men du kan ankomme med et solidt niveau af færdigheder og rimelig selvtillid.

I løbet af de første par dage er det en god idé at fokusere på SQL for begyndere til øvede : gennemgå grundlæggende syntaks, JOIN'er, GROUP BY, underforespørgsler og de mest almindelige vinduesfunktioner. Sæt tid af til både at læse eksempler og skrive dine egne forespørgsler.

I en anden fase fokuseres der på pandaer : dataindlæsning, rensning, filtrering, groupby, merges og hurtig visualisering med matplotlib eller seaborn. Du behøver ikke at bygge komplekse dashboards, men du skal være i stand til at replikere de samme transformationer i Python, som du ville udføre i SQL.

Sæt derefter flere dage af til at lave praktiske øvelser på platforme som HackerRank eller tekniske interviewdatabaser. Målet er at vænne sig til formatet, tidsbegrænsningerne og presset ved at skrive kode i et kontrolleret miljø.

Afslutningsvis kan du prøve en eller to fulde interviewsimuleringer : Tag et offentligt datasæt, stil rimelige forretningsmæssige spørgsmål, løs dem med SQL eller Python, og forklar hele din argumentation højt, fra den indledende udforskning til de endelige konklusioner.

Med en god kombination af teoretisk gennemgang, guidet øvelse og realistiske øvelser, vil du ankomme til jobsamtalen med et solidt fundament i SQL på et mellemniveau, Python til dataanalyse og modelmålinger – hvilket er præcis, hvad de fleste virksomheder inden for adtech og dataanalyse forventer at se.