Intervjuspørsmål for SQL og Python innen annonseteknologi: en komplett guide

Informatec Digital » Ressurser » Intervjuspørsmål for SQL og Python innen annonseteknologi: en komplett guide

Hvis du forbereder deg til et intervju innen adtech , digital analyse eller dataanalyse , må du før eller siden ta den fryktede tekniske testen. Det er der bedrifter sjekker om du virkelig mestrer det du har på CV-en din: SQL for å trekke ut data, Python for å behandle og analysere dem, og noen analytiske tenkeevner for å unngå å gå deg vill blant alle tabellene og skriptene.

Den gode nyheten er at tekniske intervjuer ikke er magiske: de dreier seg vanligvis om de samme blokkene med SQL, Python og modellering . Hvis du forstår det grunnleggende grundig, øver med praktiske øvelser og lærer å forklare resonnementet ditt, vil du ha en betydelig fordel over andre kandidater.

Hvorfor tekniske intervjuer er skumle (og hvordan du kan ta brodden av dem)

I dataanalytiker- eller produktroller innen adtech kombinerer tekniske intervjuer vanligvis konseptuelle spørsmål med praktiske øvelser i praksis . Du kan bli bedt om å forklare funksjonen til en SQL-klausul eller løse en forretningssak som involverer data fra programmatiske reklamekampanjer.

Du vil vanligvis bli vurdert på tre fronter: SQL på mellomnivå (JOIN, GROUP BY, delspørringer, vindusfunksjoner), dataorientert Python (pandaer, rensing, aggregeringer, sammenslåinger) og din evne til å tolke resultater og kommunisere funn . De ser ikke etter en senior dataforsker, men snarere noen som kan jobbe med data på en robust og pålitelig måte.

Den typiske feilen mange kandidater gjør er å fokusere på å memorere syntaks og glemme å øve på komplette øvelser , lik de du vil støte på på plattformer som HackerRank, StrataScratch eller selskapenes egne interne tester. Målet ditt bør være å komme til intervjuet etter å ha løst dusinvis av svært like spørsmål og skript.

SQL-nivå som vanligvis kreves i intervjuer med annonseteknikere og dataanalytikere

For en analytikerrolle i adtech- eller digitale markedsføringsmiljøer forventer selskaper at du er dyktig i klassisk relasjonell SQL : utvinning av data fra flere tabeller, kombinering, gruppering og filtrering, og oppretting av nyttige målinger. De krever ikke databaseadministrasjonsferdigheter, men du bør være komfortabel med moderat komplekse spørringer.

Vanligvis vil testen inkludere spørringer som kombinerer INNER JOIN, LEFT JOIN, filtre med WHERE-klausuler, aggregeringer med GROUP BY og noen betingelser på aggregater som bruker HAVING-klausuler. Derfra, i litt mer avanserte posisjoner, er det veldig vanlig å se underspørringer og vindusfunksjoner for rangeringer, kumulative totaler og radsammenligninger.

Innen adtech vil du sannsynligvis svare på forretningsspørsmål som «Hvilke kampanjer har en bedre klikkfrekvens enn gjennomsnittet for bransjen sin?» eller «Hvilke utgivere mister visninger sammenlignet med forrige måned?» Å løse disse spørsmålene effektivt krever vanligvis en grunnleggende forståelse av korrelerte underspørringer og vindusfunksjoner.

Grunnleggende SQL-spørsmål som ofte dukker opp (og hvordan du svarer på dem)

Nesten alle dataorienterte tekniske intervjuer inneholder et sett med grunnleggende SQL-teorispørsmål . De prøver ikke å lure deg, men heller å sikre at du har et solid grunnlag.

Et av de vanligste spørsmålene er forskjellen mellom WHERE og HAVING . Den klareste måten å forklare det på er at WHERE filtrerer individuelle rader før gruppering , mens HAVING filtrerer grupper som allerede er aggregert . Du kan også nevne at betingelser som involverer aggregeringsfunksjoner (COUNT, SUM, AVG, osv.) bør plasseres i HAVING, ikke WHERE.

Et annet klassisk spørsmål er hvilke typer JOIN som finnes og når man skal bruke hver enkelt: INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN, og i noen tilfeller CROSS JOIN eller self-join. I dataanalyse brukes LEFT JOIN mye når man vil beholde hele det primære datasettet (for eksempel alle brukere) selv om det ikke finnes tilknyttede poster i den sekundære tabellen (for eksempel kjøp).

Eksempler på grunnleggende SQL-spørringer og deres logikk

For å gi deg en idé om det «minimum rimelige» nivået, bør du kunne skrive spørringer fra minnet, for eksempel å velge bestemte kolonner, filtrere rader og sortere resultater . På et veldig grunnleggende nivå inkluderer typiske spørsmål: hvordan trekke ut alle kolonner fra en tabell, hvordan bare velge noen kolonner, eller hvordan bruke lesbare aliaser med AS.

Det er også vanlig å bli spurt om WHERE-klausulen med flere betingelser som kombinerer AND, OR og NOT, eller hvordan man bruker sammenligningsoperatorer (<, <=, >, >=, =) for både numeriske verdier og datoer. Mange selskaper legger vekt på NULL -filtre , der det ikke er nok å bare bruke likhetstegnet; man må bruke IS NULL eller IS NOT NULL.

En annen klassiker er tekstbasert filtrering med LIKE og mønstre ved bruk av jokertegnet % og _. Du kan for eksempel finne kampanjer der navnene inneholder et bestemt ord, eller brukere der e-postadressene slutter på et bestemt domene. Det er viktig å forklare at LIKE «%text%» søker etter mønsteret hvor som helst i strengen.

Til slutt dekker denne grunnleggende delen vanligvis hvordan man oppdaterer poster med UPDATE og filtrerer hvilke rader som endres med WHERE, samt hvordan man sletter rader med DELETE FROM ved hjelp av klare betingelser. Det er avgjørende at du alltid understreker viktigheten av å bruke en spesifikk WHERE-klausul for å unngå å slette halve tabellen ved et uhell.

Mellomliggende spørringer: GROUP BY, HAVING, delspørringer og UNION

Når du går forbi juniornivået, begynner nesten alle selskaper å verdsette din mestring av kombinasjonen av GROUP BY, aggregeringsfunksjoner og filtre på aggregeringer med HAVING . Dette er hva du vil bruke daglig for å generere resultatrapporter for kampanjer, målgrupper og reklamer.

Det fungerer slik: GROUP BY grupperer rader etter én eller flere kolonner, og du kan bruke SUM, COUNT, AVG, MIN og MAX på disse gruppene for å beregne målinger. HAVING kommer deretter, for å bare beholde gruppene som oppfyller en betingelse, for eksempel kunder med salg over en viss terskel.

Et annet tilbakevendende tema er delspørringer : en spørring i en annen spørring. De brukes ofte til å filtrere etter verdier beregnet i et tidligere trinn, for eksempel å velge kunder med salg over det globale gjennomsnittet eller kampanjer med visninger over 90. persentil.

Du blir også ofte spurt om forskjellen mellom UNION og UNION ALL . UNION kombinerer to resultatsett med samme skjema og fjerner duplikater; UNION ALL gjør det samme, men beholder alle rader, selv om de gjentas. I dataanalyse vil du ofte foretrekke UNION ALL av ytelseshensyn og fordi du vil bevare alle de originale postene.

Vindusfunksjoner: det neste spranget innen SQL

Vindusfunksjoner har blitt en standard innen teknisk testing på et visst nivå, spesielt for annonseteknologirelaterte roller der trender over tid, kampanjerangeringer eller totale investeringer må analyseres.

Hovedideen er at en vindusfunksjon beregner en verdi over et sett med rader relatert til gjeldende rad , men uten å skjule resultatet slik GROUP BY gjør. Med andre ord ser du fortsatt hver enkelt rad, men ledsaget av et aggregat beregnet over et "vindu" med data.

Den typiske syntaksen er å bruke funksjonen (SUM, AVG, RANK, osv.) etterfulgt av OVER, og innenfor OVER definere partisjonen (PARTITION BY) og rekkefølgen (ORDER BY). For eksempel å beregne salgsrangeringen per selger eller det kumulative antallet visninger per dag.

Hvis du vil demonstrere ferdigheter, bør du gjøre deg kjent med funksjoner som RANK, DENSE_RANK, ROW_NUMBER, LAG og LEAD . De er svært nyttige for å rangere kampanjer basert på ytelse, sammenligne hver periode med den forrige, eller identifisere variasjoner i viktige målinger fra år til år.

CTE, kumulative totaler og glidende gjennomsnitt

I moderne jobbintervjuer verdsettes lesbarheten til SQL-koden din høyt. Derfor blir du ofte spurt om Common Table Expressions (CTE-er) . En CTE er i hovedsak en type navngitt midlertidig tabell, definert med WITH-klausuler, som bare eksisterer under utførelsen av spørringen.

CTE-er brukes til å dele opp komplekse spørringer i logiske blokker og gjenbruke mellomresultater. For eksempel beregner du først daglige beregninger per kampanje i en CTE, og deretter utfører du ytterligere aggregeringer eller filtrering på det resultatet i hovedspørringen.

En annen veldig vanlig øvelse er å beregne en løpende totalsum ved å bruke SUM som en vindusfunksjon. I annonseteknologimiljøer er det normalt å bli spurt om kumulative visninger, klikk eller forbruk for å se hvordan en kampanje presterer over tid.

Relatert til dette er glidende gjennomsnitt , der AVG brukes som en vindusfunksjon over en forskjøvet radramme (for eksempel de to foregående datoene og den nåværende). Dette er en enkel måte å jevne ut tidsserier og oppdage trender uten å stole så mye på daglige topper.

Python-nivå kreves vanligvis for dataanalytikere

I de fleste dataanalytikerroller (inkludert adtech) forventer ikke selskaper at du er en maskinlæringsguru, men de forventer at du har praktiske ferdigheter i Python med pandas . Vanligvis vil du bli bedt om å laste inn datasett, rense dem, transformere dem og innhente enkle målinger eller visualiseringer.

Python-tester fokuserer vanligvis på operasjoner som å lese data fra CSV-filer , inspisere null-verdier og kolonnetyper, filtrere rader, opprette nye kolonner, aggregeringer ved hjelp av groupby og koblinger mellom DataFrames. I mange tilfeller er ordlyden nesten identisk med SQL-delen, men i pandas-format.

Det er ikke vanlig å bli bedt om å bygge komplekse modeller fra bunnen av i en analytikertest, selv om de kan verdsette din evne til å koble deg til scikit-learn for å trene en grunnleggende modell, og fremfor alt din kunnskap om de grunnleggende beregningene for å måle ytelsen.

Grunnleggende pandaoperasjoner du bør mestre

For å fullføre en Python-dataøvelse må du være dyktig i grunnleggende DataFrames-operasjoner. Det første trinnet er vanligvis å laste inn en fil ved hjelp av `read_csv` og utforske strukturen med metoder som `head()`, `info()` eller `describe()`.

Delen om å rydde opp i nullverdier dukker vanligvis også opp: å telle hvor mange nullverdier det er per kolonne med isnull().sum(), avgjøre om man skal slette hele rader eller kolonner med dropna() eller fylle manglende med fillna(), for eksempel ved å bruke gjennomsnittet eller medianen til kolonnen.

Når det gjelder filtre, vil du bli bedt om å bygge betingelser på numeriske eller kategoriske kolonner, noe som å velge salg over et visst beløp eller rader som oppfyller flere betingelser kombinert med & og |. Nøkkelen er å vite hvordan man skriver df uten å nøle.

Forklaringen av «groupby» i pandas er nesten alltid inkludert, ettersom det er den direkte ekvivalenten til SQLs «GROUP BY». Du grupperer etter én eller flere kolonner og bruker deretter aggregeringer som «sum», «mean», «count» osv. Syntaksen «groupby('column').agg()» er viktig.

Sammenføyer og slår sammen mellom DataFrames

Akkurat som det er viktig å mestre JOIN-er i SQL, er det obligatorisk å mestre pd.merge i pandas . Bedrifter vil ønske å se om du vet hvordan du kan koble sammen datasett som deler en nøkkel, for eksempel en tabell over brukere med en annen tabell over hendelser eller kjøp.

Merge-funksjonen tar de to DataFrames som skal kobles sammen, nøkkelkolonnen (on) og koblingstypen (how), som kan være 'venstre', 'høyre', 'indre' eller 'ytre', akkurat som i SQL. I dataanalyse brukes venstre kobling primært til å bevare hoveddatasettet og legge til attributter eller beregninger fra sekundære tabeller.

I et intervju er det lurt å nevne detaljer som hva som skjer når det er dupliserte nøkler på hver side, eller hvordan man håndterer konflikter mellom kolonnenavn og parametersuffikser. Dette formidler et høyere nivå av modenhet.

Typiske, mer teoretiske Python-spørsmål

Utover pandaer inkluderer mange intervjuer en kort blokk med generelle Python-spørsmål for å sjekke din forståelse av språket. Dette er vanligvis korte spørsmål om funksjoner, minne, datatyper eller små deler av syntaksen.

Blant temaene som dukker opp gjentatte ganger er automatisk minnehåndtering i Python, basert på en privat heap som brukeren ikke har direkte tilgang til, og en søppelinnsamler som er ansvarlig for å frigjøre objekter som ikke lenger har referanser.

Det er også vanlig å bli bedt om å sammenligne Python med Java , ikke for å kåre en vinner, men for å demonstrere at du forstår forskjellene: Python er mer dynamisk, med en mer konsis syntaks, perfekt for prototyping og datavitenskap, mens Java har en tendens til å dominere i mer bedrifts- og høytytende økosystemer.

Andre typiske spørsmål dreier seg om lambda-uttrykk (anonyme funksjoner for enkle operasjoner), pickling/unpickling-prosesser for å serialisere objekter til byte og hente dem, eller forskjellen mellom lister og tupler, hvor førstnevnte er muterbare og definert med hakeparenteser og sistnevnte er uforanderlige og definert med parenteser.

Flere viktige Python-konsepter i intervjuer

Det er vanlig å bli spurt om hvordan man sletter eller kopierer et objekt i Python. Vanligvis er det nok å forklare at man kan bruke `del`-setningen for å fjerne en referanse, og at overfladiske kopier gjøres med `copy.copy()`, mens dype kopier krever `copy.deepcopy()`.

Et annet konsept som kan dukke opp, spesielt i mer backend-profiler, er den såkalte dogpile-effekten , som beskriver scenarioet der mange brukere eller prosesser angriper en ressurs (for eksempel et nettsted eller en cache) samtidig, og dermed metter systemet.

Relatert til økosystemet, kan du også støte på spørsmål om databaser som kan brukes med Python . Den mest fornuftige tilnærmingen er å nevne noen populære databaser som MySQL, PostgreSQL, SQLite, MongoDB og Oracle, og merke seg at Python generelt integreres godt med et bredt utvalg av relasjonelle og NoSQL-databasemotorer.

Til slutt dukker det ofte opp enklere spørsmål, som hvordan man sorterer en ordbok ved hjelp av sorterte elementer, hva et navnerom er og hva det brukes til (knyttet navn til objekter i forskjellige omfang), eller hvordan man starter en delprosess ved hjelp av delprosessmodulen med funksjoner som run() eller Popen().

Målinger for evaluering av modeller i Python: minimumskravene du bør vite

Selv om mange analytikerstillinger ikke krever at du designer dyp læringsarkitekturer, er det vanlig å være kjent med grunnleggende målinger for evaluering av klassifiseringsmodeller , spesielt hvis rollen involverer dataprodukter, kampanjeattribusjon eller svindeldeteksjon innen annonseteknologi.

Utgangspunktet er forvirringsmatrisen , som oppsummerer suksessene og feilene til en binær eller flerklasseklassifikator. I det binære tilfellet er den delt inn i sanne positive (TP), sanne negative (TN), falske positive (FP) og falske negative (FN). En grundig forståelse av disse fire kategoriene er nøkkelen.

Fra matrisen utledes målinger som nøyaktighet , som måler prosentandelen av riktige prediksjoner av totalen; presisjon (TP / positive prediksjoner); og gjenkjennelse eller sensitivitet (TP / faktiske positive). Disse to siste er spesielt viktige når klassene er ubalanserte.

F1 -poengsummen kombinerer nøyaktighet og gjenkjenning ved hjelp av det harmoniske gjennomsnittet, og straffer spesielt lave poengsummer for begge deler. Det er en vanlig målestokk i scenarier der både falske positiver og falske negative resultater er kostbare, for eksempel svindeldeteksjon, leadscoring eller sykdomsdeteksjon.

Andre avanserte målinger: ROC-AUC, logloss, Jaccard og mer

For stillinger med en sterkere komponent innen datavitenskap eller markedsføringsanalyse, ser selskaper på om du behersker mer avanserte målinger som ROC-AUC , som måler arealet under ROC-kurven og gjenspeiler en modells evne til å skille klasser.

ROC-kurven representerer forholdet mellom den sanne positive raten (recall) og den falske positive raten (1 – spesifisitet) for ulike beslutningsterskler. En tilfeldig modell ville ligge på en diagonal linje, mens en god modell ville ligge nærmere øvre venstre hjørne. Jo større arealet under kurven er, desto bedre er diskrimineringsevnen.

En annen vanlig måleenhet er logaritmisk tap (logloss) , som vurderer kvaliteten på predikerte sannsynligheter, og straffer kraftig overdreven selvtillit og feil. En perfekt modell ville ha et logaritmisk tap på 0, og generelt sett, jo lavere logaritmisk tap, desto bedre.

De kan også spørre deg om Jaccard-indeksen , som måler likheten mellom to sett som størrelsen på skjæringspunktet delt på størrelsen på unionen. Den brukes blant annet til å evaluere klassifikatorer, segmentering og anbefalingssystemer.

I noen sammenhenger nevnes gevinst- og løftdiagrammer , som viser hvor stor prosentandel av målene du fanger opp ved å bruke bare en del av populasjonen (for eksempel de 20 % beste brukerne som er vurdert av modellen din). Dette brukes mye i markedsføring for å bestemme hvem man skal målrette seg mot først.

Kolmogorov-Smirnov, Gini-koeffisient og grundig evaluering

Hvis selskapet fokuserer sterkt på scoring eller risikomodeller, kan det dukke opp målinger som Kolmogorov-Smirnov (KS)-statistikken , som måler graden av forskjell mellom fordelingen av positive og negative poengsummer.

En KS-verdi nær 100 (i prosent) indikerer at modellen skiller de to populasjonene nesten perfekt; en verdi nær 0 innebærer at modellen ikke skiller bedre enn tilfeldigheter. I praksis faller virkelige modeller innenfor mellomverdier og sammenlignes med hverandre for å velge den beste.

Gini -koeffisienten er en annen måleenhet utledet fra ROC-AUC ved bruk av formelen Gini = 2 × AUC – 1. Den er svært populær innen kreditt og forsikring, og tolkes også som et mål på ulikhet: jo høyere Gini er, desto større er modellens evne til å konsentrere ekte positive faktorer ved høyere poengsummer.

I mer avanserte intervjuer kan du bli bedt om å forklare hvordan disse metrikkene implementeres i Python ved hjelp av scikit-learn (f.eks. confusion_matrix, accuracy_score, roc_auc_score, f1_score…) og kommentere når du ville brukt hver enkelt, avhengig av problemets art og ubalansen i klassen.

Hvordan strukturere svarene dine under det tekniske intervjuet

Utover koden du skriver, følger intervjuerne nøye med på hvordan du tenker og hvordan du forklarer deg selv . Et dårlig strukturert svar kan få deg til å virke lavere rangert enn du egentlig er, selv om du vet den riktige løsningen.

En veldig nyttig tilnærming for å svare på tekniske spørsmål er som følger: først, forklar konseptet i én setning , gi deretter et konkret eksempel (ideelt sett knyttet til et av dine egne prosjekter), og, hvis relevant, nevn alternativer eller nyanser . Dette fungerer like bra for SQL, Python eller modellmålinger.

Hvis du for eksempel blir spurt om hva en CTE er til for, kan du si at det er en navngitt midlertidig delspørring som forbedrer lesbarheten til komplekse spørringer, legge til at du bruker den når du trenger å bruke et mellomresultat flere ganger, og nevne at den i noen tilfeller kan erstattes av nestede delspørringer selv om det er mindre tydelig.

Å tenke høyt er også viktig . Hvis du står fast, ikke vær stille: verbaliser hva du prøver å gjøre, hvilken informasjon du går glipp av, hvilke antagelser du gjør. Dette hjelper intervjueren med å se tankeprosessen din og gir deg noen ganger til og med ledetråder eller avklaringer som gjør det lettere å gå videre.

De vanligste feilene i intervjuer med tekniske data

Mange kandidater blir ikke utelukket fordi de mangler tilstrekkelige SQL- eller Python-ferdigheter, men på grunn av en kombinasjon av dårlig forberedelse og kommunikasjonsfeil . Det er avgjørende å være fullt klar over vanlige fallgruver for å unngå dem.

Det første er å memorere uten å forstå . Å kjenne syntaksen til RANK eller en lambda-funksjon er ikke særlig nyttig hvis du ikke deretter kan forklare i hvilke tilfeller du ville brukt disse verktøyene eller hvorfor de er å foretrekke fremfor andre alternativer.

En annen veldig vanlig feil er å ikke vurdere datakvaliteten i øvelsene. Hvis du får et datasett, er det lurt å sjekke for nullverdier, duplikater eller avvikere som kan forvrenge analysen før du begynner å aggregere. Dette demonstrerer god dømmekraft og praktisk erfaring.

Det er også svært skadelig å unngå å stille oppklarende spørsmål . I en forretningsplan om reklamekampanjer er det for eksempel helt fornuftig å spørre om sesongvariasjoner, målrammen, om det søkes etter målinger per bruker eller per visning, og så videre. Å tie og gjøre antagelser fører ofte til løsninger som er dårlig i tråd med det intervjueren hadde i tankene.

Til slutt, unngå «overkoding»-tilnærmingen: å lage unødvendig komplekse løsninger når spørringen eller skriptet kunne vært enklere. I virkelige arbeidsmiljøer verdsettes klarhet, vedlikeholdbarhet og effektivitet , ikke gåtelignende løsninger.

Intensiv forberedelsesplan på to uker

Hvis du har begrenset tid før intervjuet, kan du følge en kortfattet plan som dekker de tre hovedområdene: SQL, Python med pandas og praktisk anvendelse. Du vil ikke utføre mirakler på 14 dager, men du kan komme frem med et solid ferdighetsnivå og rimelig selvtillit.

I løpet av de første dagene er det lurt å fokusere på SQL for nybegynnere til viderekomne : gjennomgå grunnleggende syntaks, JOIN-er, GROUP BY, underspørringer og de vanligste vindusfunksjonene. Sett av tid til både å lese eksempler og å skrive dine egne spørringer.

I en andre fase, fokuser på pandaer : datalasting, rensing, filtrering, groupby, sammenslåinger og litt rask visualisering med matplotlib eller seaborn. Du trenger ikke å bygge komplekse dashboards, men du må kunne replikere de samme transformasjonene i Python som du ville utført i SQL.

Sett deretter av noen dager til å gjøre praktiske øvelser på plattformer som HackerRank eller tekniske intervjuarkiv. Målet er å bli vant til formatet, tidsbegrensningene og presset ved å skrive kode i et kontrollert miljø.

Til slutt, prøv ut én eller to fullstendige intervjusimuleringer : ta et offentlig datasett, still rimelige forretningsspørsmål, løs dem med SQL eller Python, og forklar hele resonnementet ditt høyt, fra den innledende utforskningen til de endelige konklusjonene.

Med en god kombinasjon av teoretisk gjennomgang, veiledet praksis og realistiske øvelser, vil du komme til intervjudagen med et solid grunnlag i mellomliggende SQL, Python for dataanalyse og modellmålinger – noe som er akkurat det de fleste selskaper innen adtech og dataanalyse forventer å se.