Zephyrnet-logo

Interviewvragen over Data Science Codering beantwoorden

Datum:

Interviewvragen over Data Science Codering beantwoorden


 

Er is geen recept voor hoe u interviewvragen over het coderen van datawetenschap moet beantwoorden. Er is niet één aanpak die altijd zal werken. Er zijn echter enkele leidende principes die u in de meeste gevallen zullen helpen de codeervragen beter te beantwoorden.

Deze richtlijnen zijn gevormd op basis van de ervaring van het gaan naar de interviews en het beantwoorden van de coderingsvragen. We hebben deze richtlijnen opgedeeld in vier secties. U kunt deze richtlijnen als checklist gebruiken, vooral als u niet zo ervaren bent met interviewvragen over data science codering. Later zul je natuurlijk in staat zijn om je eigen aanpak te vinden, misschien sommige punten te negeren of zelfs iets toe te voegen dat voor jou beter werkt.

Maar wat je ervaring ook is, als je deze checklist volgt, vergroot je je kansen om een ​​goed antwoord te geven op een codeervraag.

De vierdelige checklist

 
De vier onderdelen van deze checklist zijn:

  1. Vraaganalyse
  2. Benadering van oplossing
  3. Een code schrijven
  4. Uw code controleren

Nu u het overzicht van de checklist hebt, zullen we elke sectie bekijken en de punten van de checklist uitleggen.

1. Vraaganalyse

 
Het gedeelte Vraaganalyse van de checklist gaat over het nemen van een paar minuten en het grondig nadenken over de vraag die je zojuist hebt gekregen. Zoals je zult zien bij echte zakelijke problemen, is het altijd beter om eerst over het probleem na te denken en wat tijd te verliezen om het vanuit alle perspectieven te bekijken. Onthoud dat nadenken nooit tijdverspilling is!

Deze paar minuten zullen later hun vruchten afwerpen. Als je meteen aan de slag gaat met het schrijven van de oplossing, is de kans groot dat je helemaal opnieuw moet beginnen zodra je je realiseert dat je aanpak niet tot de gewenste oplossing leidt. Of dat je constant je code moet veranderen en herschrijven.

De punten die u zullen helpen om na te denken over het probleem zijn:

  1. Begrijp de vraag
  2. Analyseer de tabellen en gegevens waarmee u werkt
  3. Denk aan het coderesultaat

I. Begrijp de vraag

Om er zeker van te zijn dat je de vraag begrijpt, moet je de vraag heel aandachtig lezen. Lees het langzaam. En lees het 2-3 keer om er zeker van te zijn dat je niets hebt gemist. Dit geldt voor iedereen interviewvragen over datawetenschap, hoe gemakkelijk of moeilijk ze ook zijn. Het punt is dat je niet weet of de vraag die je hebt moeilijk of gemakkelijk is. Sommige vragen kunnen bedrieglijk eenvoudig lijken, maar ze hebben een addertje onder het gras dat er precies is om die kandidaten te elimineren die niet grondig genoeg zijn en de neiging hebben om oppervlakkig te zijn.

Als de vraag niet is geschreven, kun je de interviewer ook vragen om hem te herhalen als je iets niet hebt opgevangen. In dit geval is het ook raadzaam om, zodra u de vraag begrijpt, deze aan de interviewer te herhalen. Op die manier zorg je ervoor dat je het goed hebt gedaan en laat je de interviewer zichzelf corrigeren voor het geval ze je niet alle benodigde informatie hebben gegeven.

ii. Analyseer de tabellen en gegevens waarmee u werkt

Zodra u de vraag begrijpt, is de volgende logische stap het analyseren van de tabellen die u krijgt. Dit betekent dat je moet analyseren hoeveel tabellen er zijn en hoe ze met elkaar verbonden zijn (foreign key en primary key).

U wilt ook zien welke gegevens in deze tabellen staan. Dit betekent welke kolommen er in elke tabel staan. Welk type gegevens staat in elke kolom. Dit is belangrijk omdat uw code afhangt van of u tekenreeksgegevens, integer, geld of een ander type gegevens verwerkt. Misschien moet u zelfs het ene gegevenstype naar het andere converteren om het gewenste resultaat te krijgen.

Naast het gegevenstype is het ook belangrijk om te begrijpen hoe gegevens zijn georganiseerd, geordend en gegranuleerd. Betekent dit, zijn er dubbele waarden in de tabel? Worden data gepresenteerd op bijvoorbeeld klantniveau, transactieniveau, etc.?

iii. Denk na over het resultaat van de code

Voordat u begint met coderen, moet u weten hoe u wilt dat uw resultaat eruitziet. Dit hangt natuurlijk ook af van de vraag die je wilt beantwoorden.

Maar als je nadenkt over het resultaat dat literair betekent, zal het slechts één waarde in één regel zijn of een tabel met meerdere kolommen. Als het een tabel is, moet u opnieuw nadenken over hoe uw gegevens worden geaggregeerd en geordend, hoeveel kolommen u moet weergeven, enz.

 
Vraaganalyse - Voorbeeld

Om je te laten zien hoe dit eerste deel van de checklist moet worden toegepast, gebruiken we de Dropbox-coderingsvraag. De vraag gaat als volgt:

Interviewvragen over Data Science Codering beantwoorden


 

“Schrijf een query die het verschil berekent tussen de hoogste salarissen op de marketing- en engineeringafdelingen. Produceer net het verschil in salarissen.”

Link naar de vraag: https://platform.stratascratch.com/coding/10308-salaries-differences

Als je de vraag goed leest, realiseer je je dat je het hoogste salaris moet zoeken. OK, maar niet het hoogste salaris in elke afdeling, maar alleen in twee afdelingen: marketing en engineering. Zodra u het hoogste salaris in deze twee afdelingen heeft gevonden, moet u het verschil tussen beide berekenen.

Nu u de vraag begrijpt, kunt u de tabellen en gegevens erin analyseren. De tabellen waarmee u gaat werken zijn db_employee en db_dept. De tabel db_employee bevat gegevens over medewerkers van het bedrijf. Het heeft vijf kolommen:

id int
Voornaam Varchar
achternaam Varchar
salaris int
afdeling_id int

U ziet, de naamkolommen zijn van het varchar-gegevenstype, terwijl het salaris een geheel getal is. Het kan belangrijk zijn om te weten dat er geen decimalen in de salariswaarden staan. Als u de voorbeeldoptie gebruikt die u hier beschikbaar heeft, ziet u dat deze gegevens uniek zijn: elke werknemer krijgt slechts één salariswaarde toegewezen. Ook een belangrijk ding om te weten; het kunnen ook historische gegevens zijn waarin u voor elke werknemer alle eerdere salarissen door de jaren heen hebt. Er is een kolom department_id, een refererende sleutel die deze tabel koppelt aan de tabel db_dept:

id int
afdeling Varchar

Slechts twee kolommen in deze tabel. Het is slechts een lijst met afdelingen, geen duplicaten, met zes afdelingen in de tabel.

Goed, je hebt de gegevens geanalyseerd. Ga nu terug naar de vraag en lees de tweede zin. Ja, dit is een instructie over wat uw oplossing moet zijn. U hoeft niet het hoogste salaris van de ene afdeling in de ene kolom te tonen, dan het hoogste salaris van de andere afdeling in de tweede kolom en dan het verschil daartussen in de derde kolom. Nee, de output is alleen het verschil:

Interviewvragen over Data Science Codering beantwoorden


 

Er was geen instructie over de naam van deze uitvoerkolom. Dus het zal geen vergissing zijn, hoe je het ook noemt of helemaal niet. Het belangrijkste is dat u dit resultaat krijgt en niets anders.

Daarmee heb je de basis om een ​​kwaliteitscode te schrijven. Nu is het tijd tot tijd over de strategie: hoe ga je een code schrijven?
 

2. Aanpak van oplossing

 
Voordat je begint met het schrijven van een code, is het ook belangrijk dat je een duidelijk beeld hebt van hoe je code eruit komt te zien. Coderen zou alleen uw (duidelijke!) idee van de oplossing moeten vertalen naar de programmeertaal.

Wanneer u nadenkt over hoe u uw oplossing moet benaderen (of een code moet schrijven), overweeg dan het volgende:

Interviewvragen over Data Science Codering beantwoorden


 

  1. Zijn er verschillende manieren om een ​​code te schrijven?
  2. Geef je aannames aan
  3. Deel uw oplossing op in stappen
  4. Begin met coderen

I. Zijn er verschillende manieren om een ​​code te schrijven?

Bij het nadenken over de oplossing, denk je soms als eerste aan de beste oplossing. En soms is dat niet zo. Hoe kon jij het weten? Als je eenmaal het eerste idee hebt, is het de kunst om na te denken over de vraag of er een andere manier is om het probleem op te lossen. In programmeertalen, vaker wel dan niet, zijn er verschillende mogelijke oplossingen.

Houd dit in gedachten. Er zijn verschillende redenen waarom dit belangrijk is. Ten eerste kan er een simpele truc of functie zijn die gemakkelijk iets oplost dat je denkt op te lossen met een lange code, bijvoorbeeld door vensterfuncties of CTE's in plaats van een code te schrijven met eindeloze subquery's.

Ga altijd voor wat gemakkelijker te schrijven is, met zo min mogelijk regels code. Als je bij het interview bent, moet je ook tijd tot je beschikking hebben. Dit is een van de manieren.
Als er meerdere min of meer even complexe oplossingen zijn, bedenk dan natuurlijk hoe de code zal presteren. Bij grote hoeveelheden gegevens kunnen verschillende codes veel meer tijd en geheugen in beslag nemen dan andere.

Kortom, u moet op twee manieren nadenken over code-efficiëntie. Een daarvan is persoonlijke efficiëntie, of hoe snel je een code kunt schrijven. De tweede is de code-efficiëntie of hoe snel de code zal presteren wat u wilt.

ii. Geef uw veronderstellingen weer

Het vermelden van uw aannames is om verschillende redenen belangrijk. De eerste is om ze hardop te zeggen en op te schrijven, zodat je mogelijke problemen met je aanpak kunt zien.

De tweede belangrijke reden is dat het je gesprekspartner uitnodigt om met je te communiceren en zelfs wat hulp te bieden, wat ze meestal doen. Als ze niet weten wat je wilt doen en waarom, kunnen ze je ook niet helpen. Zoals we al vermeldden, zijn er meestal meerdere oplossingen die hetzelfde resultaat opleveren. Door uw aannames te communiceren, kan de interviewer u in de juiste richting sturen op basis van de door u gekozen aanpak. Of je zelfs afleiden van de volledig verkeerde veronderstellingen die je oplossing in de war zullen brengen.

De derde reden is dat de vraag soms opzettelijk vaag is gesteld. Deze vragen gaan niet zozeer over de juiste oplossing, maar over hoe u denkt. Dus als je je veronderstellingen vermeldt, zal het de interviewer laten zien hoe je denkt, waar ze meestal erg in geïnteresseerd zijn.

De vierde en laatste reden om je aannames te vermelden, is dat zelfs als je het antwoord helemaal fout hebt, maar correct hebt binnen de aannames die je hebt opgegeven, de kans groot is dat je daar nog wat punten voor krijgt. Het denken gaat in dit geval rond deze lijnen: OK, misschien heeft de kandidaat volledig verkeerd begrepen wat er werd gevraagd, maar de oplossing is eigenlijk correct binnen de context van wat ze begrepen.

Dit alles leidt tot ervoor zorgen dat u het juiste antwoord geeft op een interviewvraag.

iii. Deel uw oplossing op in stappen

Dit is ook een handig punt dat het voor u gemakkelijker maakt om een ​​duidelijk oplossingsidee te hebben en later een schone code te schrijven.

Afbreken betekent in dit geval opschrijven. Ja, noteer alle belangrijke stappen en functies van uw oplossing. Bedenk of je tabellen moet joinen, hoeveel tabellen en welke join je gaat gebruiken. Moet u een subquery of een CTE schrijven? Schrijf je keuze op. Bedenk welke verzamelfuncties u moet gebruiken, of u gegevenstypen moet converteren, of gegevens op een specifieke manier moeten worden geordend, of ze moeten worden gefilterd en gegroepeerd, enz.

Dit zijn allemaal afzonderlijke stappen, dus schrijf ze op, evenals de belangrijkste trefwoorden die u bij elke stap zult gebruiken.

iv. Begin met coderen

Dit is in zekere zin een noodpunt. Als je wel hebt nagedacht over je benadering van de oplossing, maar je kunt de volledige oplossing gewoon niet voor je ogen zien, dan moet je gewoon beginnen met het schrijven van een code.

De gedachte hierachter is dat zelfs als je een onvolledige oplossing geeft, het zeker meer waard is dan het niet schrijven van een enkele regel code. Sommige vragen kunnen ook heel moeilijk zijn, en het is zelfs voor de meest ervaren moeilijk om de hele oplossing meteen te zien. Begin met coderen en er is een kans dat je onderweg op een idee komt. En zo niet, dan heb je tenminste iets om voor te laten zien.

Nog een reden om in gedachten te houden: sommige vragen zijn niet eens bedoeld om te worden beantwoord. Sommige zijn gewoon (en opzettelijk!) te moeilijk om op te lossen in de tijd die je krijgt tijdens het interview. Niemand lost ze volledig op. De gedeeltelijke oplossing is de beste die iemand zal krijgen. U wordt dus aangegeven hoe ver u bent gekomen in vergelijking met de andere onvolledige oplossingen.

 
Aanpak van oplossing - Voorbeeld

Nu u weet hoe u moet denken over uw oplossingsaanpak, laten we één interviewvraag gebruiken om te laten zien hoe het in de praktijk werkt. We gebruiken de Amazon-coderingsinterviewvraag:

Interviewvragen over Data Science Codering beantwoorden


 

“Zoek de totale kosten van de bestellingen van elke klant. Voer de klant-ID, voornaam en de totale bestelkosten uit. Bestel records alfabetisch op voornaam van de klant.”

Link naar de vraag: https://platform.stratascratch.com/coding/10183-total-cost-of-orders

Bij deze vraag moeten we gegevens van twee tafels, tafelklanten en tafelbestellingen gebruiken. We kunnen een code schrijven met subquery's om dit probleem op te lossen. U weet echter waarschijnlijk dat als de query en subquery gegevens uit meerdere tabellen gebruiken, de oplossing ook kan worden geschreven met de JOIN. Met het advies in gedachten om zo min mogelijk regels code te schrijven, is het beter om JOIN te gebruiken.

Wat zijn de aannames bij deze oplossing? Een aanname zou kunnen zijn dat er klanten kunnen zijn die nul bestellingen hebben. Dit betekent dat er klanten aan tafel kunnen zijn die niet verschijnen in de tafelbestellingen. De tweede veronderstelling is dat we de klanten met nulbestellingen niet zullen laten zien, omdat de vraag het niet expliciet zei.

Dit leidt ons al naar een oplossingsanalyse. We moeten twee reeds bestaande kolommen uitvoeren, dus we zullen zeker SELECT gebruiken. We moeten het totaal van de bestellingen van elke klant vinden. We zullen het moeten optellen met behulp van de aggregatiefunctie SUM(). OK, tabellen moeten worden samengevoegd. We doen dat met het JOIN-sleutelwoord. Waarom sluit niet een ander zich aan? Omdat onze veronderstelling zegt, willen we alleen klanten die ten minste één bestelling hebben. Het gebruik van JOIN geeft ons precies dat: het zal twee tabellen samenvoegen en alleen waarden (klanten) vinden die in beide tabellen staan. Wat nu? Ik heb de aggregatiefunctie gebruikt, dus ik moet de GROUP BY gebruiken. En het resultaat moet alfabetisch worden gerangschikt, dus ik gebruik ORDER BY en ASC.

De resulterende uitsplitsing van de oplossing kan er dan als volgt uitzien:

  • SELECT
  • SUM (totale_order_kosten)
  • AANMELDEN
  • GROEP DOOR
  • BESTELLEN PER ASC

In jouw geval is dit geen noodgeval omdat je alles hebt begrepen, dus je kunt doorgaan naar het volgende gedeelte met de checklist. Of u kunt ook de meest voorkomende vinden SQL JOIN interviewvragen hier.

3. Een code schrijven

 
Nadat je de vraag hebt beoordeeld en de strategie voor je code hebt uitgestippeld, is het tijd om deze te schrijven.

Interviewvragen over Data Science Codering beantwoorden


 

  1. Blijf bij een gekozen dialect
  2. Ga regel voor regel bij het coderen
  3. Praat terwijl je codeert
  4. Maak het leesbaar
  5. Wees consistent met de gekozen conventies

I. Blijf bij een gekozen dialect

Dit is vooral belangrijk als je in het SQL-coderingsinterview zit. Zoals je al weet, is er een ANSI/ISO SQL-standaard en zijn er veel SQL-dialecten. Vrijwel elk RDBMS gebruikt zijn eigen SQL-dialect. Je kunt ze natuurlijk niet allemaal kennen. En het bedrijf waarvoor je solliciteert, gebruikt waarschijnlijk een van die dialecten.

Als het de interviewer niet uitmaakt welk dialect je gebruikt, kies dan het dialect waarmee je je het prettigst voelt. Probeer de interviewer niet aan te spreken door het SQL-dialect te kiezen dat ze gebruiken als je niet erg sterk bent in het coderen in dat dialect. Het is beter om het dialect te kiezen dat je het beste kent en het probleem op te lossen dan een ander dialect te gebruiken waar je niet zo zeker van bent. Als je voor het laatste kiest, is de kans groot dat je nerveuzer bent dan nodig is. Ook als u niet zo bekend bent met het specifieke SQL-dialect, kunt u de oplossing verknoeien.

Als je eenmaal het SQL-dialect hebt gekozen, houd je eraan. Als u er bijvoorbeeld voor kiest om in PostgreSQL te schrijven, verwar dit dan niet met T-SQL.

ii. Ga lijn voor lijn

Met een duidelijke uitsplitsing van de oplossing kunt u dit punt bijna onopgemerkt controleren. Omdat je de functies en secties van je code al hebt geschetst, hoef je alleen maar kalm te blijven en een code systematisch te schrijven volgens de oplossingsbeschrijving. Code is niets meer dan een programmeertaalversie van je gedachten. Als uw gedachten en uw oplossingsoverzicht duidelijk zijn, is uw code dat ook.

Als je van de ene regel naar de andere springt, raak je jezelf en de interviewer in de war. Wat waarschijnlijk zal leiden tot het niet schrijven van de juiste code.

iii. Praat terwijl u codeert

Terwijl u uw code regel voor regel schrijft, moet u ook praten over wat u aan het doen bent. Dit is belangrijk, want als je hardop zegt wat je doet, kun je gemakkelijker zien of je iets verkeerd doet. Alles kan geweldig klinken in je hoofd. Maar als je het uitspreekt, vallen de niet zo geweldige ideeën echt op! Dit geeft u de mogelijkheid om de code gaandeweg te corrigeren. Anders zou je je code kunnen afmaken, niet eens beseffend dat je iets verkeerd hebt gedaan.

Een van de redenen waarom het belangrijk is om elke regel uit te leggen terwijl u deze schrijft, is dat het de interviewer opnieuw uitnodigt om deel te nemen aan uw oplossing. Het maakt het voor hen mogelijk om te begrijpen wat u doet en u enkele hints te geven. Als je gewoon een code schrijft en voor jezelf houdt wat je doet, zal de interviewer waarschijnlijk ook afsluiten en gewoon wachten tot je de code hebt voltooid om je te laten weten hoe je het hebt gedaan.

iv. Maak het leesbaar

Het hebben van een goed gestructureerde code is een genot om simpelweg vanuit esthetisch oogpunt te zien. Niet alleen dat, het maakt het voor jou en de interviewer ook gemakkelijker om je code te lezen.

Het belangrijkste dat je code leesbaar maakt, staat in een van de bovenstaande punten: schrijf het zo eenvoudig mogelijk. Sommige oplossingen kunnen echter niet eenvoudig zijn. En zelfs een paar regels code kunnen een nachtmerrie zijn om te lezen als je geen moeite doet om het leesbaar te maken.

Een van de tips om in gedachten te houden is om spatie, tab en enter te gebruiken. En maak er veel gebruik van! Deze sleutels zijn er om uw code in secties te scheiden, waardoor het gemakkelijker wordt om te begrijpen wat de code doet. Zie het als alles wat je zegt of schrijft. Spatie, tab en enter zorgen ervoor dat uw code komma's, zinnen en alinea's bevat.

Gebruik indien mogelijk aliassen voor tabellen. Maar probeer ze zelfverklarend te maken. Vermijd het gebruik van aliassen van één letter, maar maak aliassen ook niet te uitgebreid en beschrijvend. Hetzelfde geldt voor de namen van de variabelen.

Hoewel SQL niet hoofdlettergevoelig is, is het altijd beter om de SQL-sleutelwoorden in hoofdletters te schrijven. Hierdoor vallen ze ook op in de code, vooral als alle kolom- en tabelnamen in kleine letters zijn geschreven.

Bekijk ons ​​bericht “Best practices om SQL-query's te schrijven: hoe u uw code kunt structureren” dat zich richt op hoe uw SQL-query's kunnen worden verbeterd, met name als het gaat om prestaties en leesbaarheid.

v. Wees consistent met de gekozen conventies

Er zijn geen regels die ervoor zorgen dat u in hoofdletters of kleine letters schrijft; er is geen voorgeschreven naamgevingsconventie, dus het is aan jou en hoe je het leuk vindt. Maar wat je ook doet, wees er consequent in.

Als u alle nieuwe kolomnamen in kleine letters wilt schrijven en woorden wilt scheiden met onderstrepingstekens, doe dit dan en houd het zo. Het benoemen van een kolom salaris_per_employee ziet er redelijk goed uit. Maar probeer de ene kolom salaris_per_employee, de andere kolom SalarisPerDepartment, de derde 'Totaal Salaris' en de vierde MAX_sALAryPerdeparment te noemen. Je zult jezelf pijn doen als je de code probeert te lezen, vooral bij de laatste.

Hetzelfde geldt voor het schrijven van tabelnamen, het gebruik van aliassen, enz. Het behouden van consistentie zal ook bijdragen aan de leesbaarheid van uw code.

Over consistentie gesproken, we laten u zien hoe deze checklist-sectie in de praktijk werkt.

 
Een code schrijven - Voorbeeld

Hier is een codeervraag van Facebook:

Interviewvragen over Data Science Codering beantwoorden


 

“Facebook verstuurt sms-berichten wanneer gebruikers 2FA (2-factor authenticatie) proberen op het platform om in te loggen. Om met succes 2FA te kunnen gebruiken, moeten ze bevestigen dat ze het sms-bericht hebben ontvangen. Bevestigingsteksten zijn alleen geldig op de datum van verzending. Helaas was er een ETL-probleem met de database waarbij vriendschapsverzoeken en ongeldige bevestigingsrecords werden ingevoegd in de logboeken, die zijn opgeslagen in de tabel 'fb_sms_sends'. Deze berichttypen mogen niet in de tabel voorkomen. Gelukkig bevat de tabel 'fb_confirmers' geldige bevestigingsrecords, zodat u deze tabel kunt gebruiken om SMS-berichten te identificeren die door de gebruiker zijn bevestigd.

Bereken het percentage bevestigde sms-berichten voor 4 augustus 2020.”

Link naar de vraag: https://platform.stratascratch.com/coding/10291-sms-confirmations-from-users

Als u een code als deze schrijft, dekt deze alles wat we in deze checklistsectie hebben genoemd:

SELECT cust_id, SUM(total_order_cost) AS revenue
FROM orders
WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019
GROUP BY cust_id
ORDER BY revenue DESC

Laten we ons voorstellen dat Facebook SQL Server gebruikt, maar dat het aan u overlaat in welk SQL-dialect u uw code schrijft. U bent niet bekend met T-SQL, dus u besluit in PostgreSQL te schrijven.

EXTRACT() en dubbele dubbele punt (::) zijn bijvoorbeeld functies die typisch zijn voor PostgreSQL. De eerste extraheert het deel van de datum uit het datatype datetime. Het bestaat niet in T-SQL! Dus als je tegen de interviewer zou zeggen dat je in T-SQL schrijft en dan deze functie gebruikt, zou je een fout maken. In T-SQL moet u de functie DATEPART() gebruiken. En u moet weten dat deze functie in PostgreSQL DATE_PART() wordt genoemd. Eén onderstrepingsteken kan een verschil betekenen tussen uw code die werkt en niet werkt.

Evenzo wordt dubbele dubbele punt (::) in PostgreSQL gebruikt voor conversie van gegevenstypes. In T-SQL werkt het niet; je moet CAST() of CONVERT() gebruiken.

Als u een uitsplitsing van de oplossing voor deze code heeft, kunt u deze gemakkelijk regel voor regel schrijven. Het is makkelijk, eigenlijk. Eerst moet u enkele gegevens uit een tabel selecteren, filteren, groeperen en ten slotte bestellen. Schrijf niet eerst de WHERE-component, ga dan naar de SELECT-instructie en vervolgens naar het converteren van gegevenstypes of een andere bizarre manier om uw code te benaderen.

Terwijl je codeert, kun je als volgt met de interviewer praten: Ik selecteer de kolom cust_id met behulp van de SUM()-functie om de inkomsten uit tafelbestellingen te berekenen. Vervolgens gebruik ik de WHERE-clausule om gegevens te filteren op basis van de maand en het jaar uit de kolom order_date. Daarna groepeer ik gegevens op klantniveau en rangschik ik het resultaat in aflopende volgorde.

Je ziet dat deze code inspringt, er is een nieuwe regel voor elk belangrijk onderdeel van de code en de naamgevingsconventies zijn consistent. Wil je zien hoe de code eruit zou kunnen zien als we dit niet zouden volgen? Hier is het:

SELECT cust_id,SUM(total_order_cost) AS INKOMSTEN UIT BESTELLINGEN WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019 GROEPEREN OP klant_id volgorde OP omzet DESC

Veel succes met het lezen ervan!

4. Uw code bekijken

 
Nadat je de code hebt geschreven, is het tijd om deze te herzien voordat het je definitieve antwoord wordt. Als u tot nu toe alle items op een checklist heeft gevolgd, kunt u deze gemakkelijk bekijken.

Het beoordelen van uw code is in zekere zin het controleren van een aantal punten op uw checklist:

  1. Check hoeveel tijd je nog hebt
  2. Controleer het tegen de vereiste output
  3. Vergelijk het met de vermelde aannames
  4. Controleer de leesbaarheid
  5. Leid de interviewer door de oplossing
  6. Optimaliseer uw code

I. Controleer hoeveel tijd je nog hebt

Alle andere punten in dit deel van de checklist zijn hiervan afhankelijk. Als je geen tijd meer hebt, kun je niets doen. Je deed wat je deed, en je code is het antwoord dat je hebt, leuk vinden of niet.

Tijdbeheer is belangrijk, dus u moet bewust wat tijd overhouden voor het beoordelen van een code. In het ideale geval heeft u de tijd om de volgende drie controles uit te voeren.

ii. Controleer de code tegen de vereiste uitvoer

Je moet teruggaan naar je vraag en kijken of je code echt teruggeeft wat nodig is. Bent u vergeten enkele verplichte kolommen op te nemen? Heb je het resultaat echt besteld zoals gevraagd? Die en andere soortgelijke vragen moet je jezelf stellen.

Als je tijd hebt, corrigeer dan de fouten die je hebt gemaakt. Als er geen tijd is, laat de code dan zoals hij is, maar schrijf op wat je fout hebt gedaan.

iii. Controleer de code aan de hand van de vermelde veronderstellingen

Je hebt je code geschreven op basis van enkele aannames. Ga terug naar je lijst met aannames en controleer of je ze hebt gevolgd.

Het zou perfect zijn als je dat deed. Maar bij het schrijven van complexere code is het mogelijk dat u enkele aannames hebt weggegooid of nieuwe hebt geïntroduceerd. Schrijf dat ook op. Als je niet alle aannames hebt gevolgd, maar je denkt dat je dat wel zou moeten doen en je hebt tijd om de code te wijzigen, doe het dan. Zo niet, laat het dan zoals het is.

iv. Controleer de leesbaarheid van de code

Hier moet u controleren of u begrijpt wat u zojuist hebt geschreven. Ga terug naar je code, controleer elke regel opnieuw op zijn syntaxis en logica. Ga regel voor regel na of de leesbaarheid van de code kan worden verbeterd. Was u consequent in de naamgevingsconventies? Zijn uw aliassen duidelijk te begrijpen? Is er onduidelijkheid? Is de code op een logische manier opgebouwd en in logische delen?

Nogmaals, als je tijd hebt, verbeter dan de leesbaarheid van de code. Als er geen tijd is, probeer dan op te schrijven of gewoon te onthouden wat je beter had kunnen doen.

v. Leid de interviewer door de oplossing

Als je alle bovenstaande stappen hebt uitgevoerd, zou deze vanzelf voor je moeten komen. Het belangrijkste is dat je eerlijk bent als je je code uitlegt.

Welke fouten je ook hebt gevonden in je code bij het beoordelen, vermeld ze expliciet. Reken er niet op dat uw interviewer ze niet opmerkt. Probeer ze niet te verbergen. Geef je fouten toe en laat zien dat je weet wat je verkeerd hebt gedaan. Iedereen maakt fouten, maar niet iedereen kan beseffen dat ze die hebben gemaakt en ze toegeven. Het laat zien dat je weet wat je doet, ook al heb je een fout gemaakt. Over fouten gesproken, dit zijn de meest voorkomende die mensen maken in interviews over datawetenschap.

Als je een onnodige kolom in je output hebt opgenomen, zeg dat dan en ga verder met het uitleggen van de output die je hebt. U dwaalde af van uw aanvankelijke veronderstellingen of voegde nieuwe toe? Zeg het en leg uit waarom. Als je het per ongeluk hebt gedaan, zeg dan dat het niet de bedoeling was, maar je ziet dat je oplossing een aantal aanvullende aannames moet bevatten. Geef aan wat ze moeten zijn om uw code te laten werken. Hetzelfde geldt voor leesbaarheid: als je ziet dat je je code beter kunt maken, leg dan uit hoe.

Door dit alles te doen, laat je niet alleen je codeervaardigheid zien, maar ook hoe snel je denkt, dat je verantwoordelijk en eerlijk bent. Dit zijn allemaal zeer hoog aangeschreven kenmerken door alle bedrijven.

vi. Optimaliseer uw code

De laatste vraag in het coderingsinterview is meestal degene die u vraagt ​​om uw code te optimaliseren. Op die manier zal de interviewer uw kennis van SQL-theorie testen. Als u bijvoorbeeld weet dat JOIN's rekenkundig tijdrovend kunnen zijn? U wordt gevraagd om uit te zoeken of er een manier is om JOIN of een subquery te elimineren. U kunt bijvoorbeeld meestal een subquery in de WHERE-component verwijderen met een functie, zoals de rangschikkingsfunctie, als u probeert de maximale waarde te vinden.

Of als u weet hoe snel bewerkingen worden uitgevoerd op bepaalde gegevenstypen. Stringvergelijking is bijvoorbeeld traag dan vergelijking met gehele getallen, dus misschien is er een manier om dit op stringgegevens te doen?

Conclusie

 
Dit komt er allemaal op neer: het schrijven van een code zou bijna een technische kwestie moeten zijn als je je aanpak goed structureert. Het accent ligt meer op denken en minder op coderen. En het schrijven van een code moet op een zeer georganiseerde manier gebeuren.

Je moet nadenken over de vraag, de gegevens die je voor je hebt, de mogelijke oplossing(en), je aannames en de functies die je nodig hebt. Pas daarna moet je beginnen met coderen. Als je eenmaal begint met coderen, zou je de interviewer moeten kunnen betrekken bij wat je doet en hem elke stap die je maakt, laten weten. Net als in het echte leven, moet u uw code controleren en optimaliseren voordat u deze in productie gaat gebruiken. Dit interview is jouw productie; beheer uw tijd zodat u uw oplossing kunt bekijken.

Dit zijn de dingen die je moet doen. Er zijn ook meer voorbereidingstips in onze post: 5 tips om je voor te bereiden op een datawetenschappelijk interview.

Dit alles is niet gemakkelijk. Het vereist ervaring en oefening; niemand kan dit faken. Maar het volgen van deze checklist zal zeker een solide structuur toevoegen aan uw denk- en interviewprestaties, ongeacht uw ervaring. Het kan je alleen maar beter laten presteren.

 
 
Nate Rosidi is een datawetenschapper en in productstrategie. Hij is ook een adjunct-professor onderwijsanalyse en is de oprichter van StrataScratch, een platform dat datawetenschappers helpt bij het voorbereiden van hun interviews met echte interviewvragen van topbedrijven. Maak contact met hem op Twitter: StrataScratch or LinkedIn.

ORIGINELE. Met toestemming opnieuw gepost.

Bron: https://www.kdnuggets.com/2022/01/answer-data-science-coding-interview-questions.html

spot_img

Laatste intelligentie

spot_img