Ik ga niet naar je algoritmische test interview

Gepubliceerd: Laatst bijgewerkt:
Tomasz Nurkiewicz algoritmische test

Hoe werft de gemiddelde persoon een top-notch kleermaker? Ze vragen de kandidaten om te laten zien wat ze tot nu toe hebben genaaid, misschien vragen ze hen zelfs om snel iets te naaien. Dan observeren ze de resultaten, noteren hoe goed ze de naaimachine bedienen, de organisatie van de werkplek, en beoordelen de aandacht van de kleermaker voor details. Verspillen ze te veel stof of leveren ze gewoon niet goed werk?

Hoe huren software ontwikkelaars top-notch kleermakers in? Nou, het zou waarschijnlijk een beetje als volgt gaan: "Dit is een whiteboard. Teken alsjeblieft het verschil tussen een Ghiordes en Senneh knoop. Leid de lengte van de draad af als functie van de oppervlakte van de stof".

Eerlijk gezegd ben ik van mening dat een topkleermaker het verschil zou moeten kennen, maar wat controleren we hier eigenlijk? Wil je een elegant jasje of een elegante vergelijking op een whiteboard?

Mijn ervaring met een zoekbedrijf en een investeringsbank

Laat me een paar ervaringen delen die ik had toen ik een geïnterviewde was in twee grote bedrijven. De eerste verkocht advertenties die af en toe werden afgewisseld met echte organische zoekresultaten en de andere was een grote ondernemingsbank. In het eerste bedrijf bracht ik verschillende uren door met het bedenken van oplossingen voor niet-triviale algoritmische taken. Bij de tweede was het vergelijkbaar, maar ik beschreef mijn algoritmen telefonisch aan iemand die aan de andere kant van de Atlantische Oceaan zat... en het werd nog vreemder dan dat.

Algoritmische test tweet

Bij het zoekbedrijf zocht ik naar het langste achtervoegsel van een gekoppelde lijst die...iets deed. Eerlijk gezegd, herinner ik me niet veel. Net zoals ik me de laatste keer dat ik een gelinkte lijst gebruikte niet meer kan herinneren. Ja, ik begrijp dat het anders is dan een array - prestatie implicaties, verschillende gebruikssituaties, enz. Ik weet dat ook omdat deze vraag in elk sollicitatiegesprek wordt gesteld! Maar in het echte werk heb ik gewoon nooit de kans gehad om er gebruik van te maken. Er was ook een vraag die te maken had met het balanceren of doorkruisen van een boom op een bizarre manier. Eerlijk gezegd, niet echt een gedenkwaardige ervaring. Eigenlijk dacht ik dat het eerlijk van me zou zijn om te zeggen dat ik deze oefening van tevoren kende. Niet uit een boek over algoritmen, maar uit een gids over hoe je bij dit specifieke bedrijf kunt worden aangenomen. Daarover later meer.

Bij de investeringsbank werd mij eerst gevraagd om alle mogelijke permutaties van een lijst van elementen te genereren. Vergeet niet dat dit allemaal gebeurde tijdens een transcontinentaal telefoongesprek. OK, gewoon voor de lol, stel ik me voor dat ik mezelf dit soort vragen stel. Hier zijn de mogelijke antwoorden die ik verwachtte, van slecht naar best:

  • Zoek een oplossing op het internet, beweer dat het de jouwe is en denk dat ik het toetsenbord niet hoor tikken
  • Zeg een oplossing regel voor regel op uit je hoofd, omdat je je als een gek hebt voorbereid en je de oplossing gelukkig uit je hoofd kent. En niet veel meer dan dat.
  • Dwingend, ingewikkelde code die itereert over de invoer. Bij voorkeur met variabelen als i, j, k
  • Schone, recursieve oplossing, omdat de kandidaat zich realiseerde dat dit probleem ontleed kan worden.
  • Walg je van handgeschreven code, zoek dan wat langer en vind een bibliotheek die precies dat doet (bv. Verzamelingen2 van Guava)
Whiteboard algoritme tests

Serieus, je bent waarschijnlijk op zoek naar een nieuwe teamgenoot. Zie je liever een pull request met elegante, recursieve code of een enkele library call? Een bibliotheek, getest door miljoenen ontwikkelaars, gebaseerd op Donald Knuth's "De kunst van het computerprogrammeren"? Het kostte me ook wat tijd om een bibliotheek te vinden, terwijl handgemaakte, geneste lussen overal op het Internet te vinden zijn. Naar wat voor instelling ben je op zoek? Uit het hoofd leren en blindelings code van het internet kopiëren, of daadwerkelijk onderzoek doen om beproefde oplossingen te vinden?

Een andere oefening die ik kreeg was het willekeurig schudden van een matrix, waarbij ik alleen maar een muntstuk kon opgooien. Dit is op zich een interessant probleem, dat echter niets te maken heeft met de werkomstandigheden. Ik kwam op de een of andere manier met een algoritme (en het was best leuk), maar na een paar maanden was het enige wat ik deed een stuk XML van de ene kant van de bank naar de andere kant doorgeven. Honderden alledaagse transformaties per seconde en trouwens, elke grote taal heeft shuffle ondersteuning: [1], [2], [3], [4], of een pakket [5].

Algoritmische testvragen voor sollicitatiegesprekken: de vloek van het werven

Ik heb een graad in computerwetenschappen en ik vind algoritmische tests niet intimiderend of zinloos. Eigenlijk is het tegendeel waar, ze zijn geweldig om je hersenen te oefenen, net als het oplossen van sudoku's of het spelen van bridge. Ik heb aan meerdere algoritmische wedstrijden deelgenomen (bijv. De komst van de code) en vond ze altijd leuk. Maar dat is slechts mijn hobby, misschien studeer jij liever DDD of geavanceerde SQL. En ik ben er niet zeker van dat zuivere algoritmen en datastructuren bijzonder goed passen in de meeste rekruteringsprocessen. Ze verifiëren wel de abstracte analytische vaardigheden van een kandidaat, evenals een solide achtergrond in CS en wiskunde (wat allebei belangrijke eigenschappen zijn in software engineering), maar ze slagen er niet in andere belangrijke eigenschappen vast te leggen of zijn te ingewikkeld om overtuigend te zijn.

Tegenwoordig vereist het meeste werk in de IT het aan elkaar naaien van API's en frameworks. We zijn meer kleermakers dan stoffenproducenten. Algoritmische vaardigheid is nuttig bij het schalen van een enkele functie van je systeem, maar meer gerichte ervaring in gedistribueerde systemen zal je waarschijnlijk verder brengen. Kennis van grafentheorie of discrete functies is bijvoorbeeld waardevol. Maar praktijkervaring met een groot netwerk van gerepliceerde databases of begrijpen waarom sommige hashfuncties gecompromitteerd zijn, heeft een veel grotere impact op je dagelijkse werk.

Whiteboard algoritme tests

Inderdaad, begrijpen wat recursie is, is essentieel. Net als weten waarom HashMap zo snel is in Java. Maar begrijpen waarom Woordenboek nog sneller is in C# is het volgende niveau. Hint: geheugenindeling, iets dat niets te maken heeft met theoretische computationele complexiteit. Velen geloven echter dat het stellen van zuiver algoritmische vragen de eenvoudigste manier is om uitzonderlijke, goed opgeleide ontwikkelaars te vinden. Zo'n overtuiging is heel romantisch, maar vaak uiterst naïef. Kijk maar eens hoeveel boeken je helpen om specifiek te slagen in (het beroemde algoritmische) Google-interviews. Ze leren je niet de grondbeginselen van CS, ze leggen nauwelijks uit hoe je specifieke klassen van Google-achtige problemen moet oplossen.

Sorteren is een van de meest (ab)gebruikte algoritmische interviewvragen. Weten hoe Quicksort werkt is waardevol, ook al, bijvoorbeeld, Java heeft het niet gebruikt voor bijna een decennium. Begrijpen wat O(nlogn) is, kan ook van pas komen. Maar veel vaker was het niet de algoritmische complexiteit die mijn systeem tot stilstand bracht. In plaats daarvan was het een N+1 probleem - iets dat ik steeds weer op de harde manier tegenkwam, maar waar tijdens mijn CS opleiding nauwelijks aandacht aan was besteed. Als je de neiging niet kunt weerstaan om over sorteren te vragen, bespreek dan op zijn minst wat het betekent dat een algoritme stabiel is. Je zult hoogstwaarschijnlijk een kant-en-klaar, snel algoritme gebruiken. Stabiel vs. onstabiel is waarschijnlijk je enige zorg. Hint: sorteren in Java is stabiel, in C# is het dat niet.

Whiteboard algoritme tests

Houd in gedachten dat algoritmische vragen geweldig zijn als dat is wat je echt nodig hebt op een dagelijkse basis. Machine learning-experts moeten begrijpen wat gradiëntafdaling is, en dat vereist een aanzienlijke wiskundige achtergrond. Ook voor statistiek, onderzoek, computergrafiek en spelontwikkeling is een zekere CS-achtergrond vereist. Voor de rest moet je je rekruteringstijd verstandig gebruiken en de juiste vragen stellen.

Een betere benadering van een algoritmische testontwerp en werk samen

Tijdens mijn loopbaan heb ik heel wat mensen geïnterviewd, ik beschouw dit als een deel van mijn job, vooral in de hogere functies. Veel van de gesprekken waren vergeetachtig, maar soms waren kandidaten uiterst tevreden, ook al kregen ze de baan niet. Dit bouwt een geweldige relatie op en een merk voor je bedrijf. Hoe heb ik zo'n geweldige ervaring gecreëerd?

  • Geef de voorkeur aan het oplossen van problemen in het echte leven. Ontwerp Twitter-achtige architectuur of maak een Instagram-achtige website - dat soort oefeningen zijn veel leuker dan het kortste pad of het langste palindroom vinden.
  • Geef de voorkeur aan pair-programming boven whiteboard schetsen. Zien hoe een kandidaat werkt, hoe hij of zij door code navigeert, antwoorden zoekt, obstakels benadert - dit zou u veel moeten vertellen. Samenwerken vermindert ook de stress en maakt het proces menselijker.
  • Liever bestaande codebase dan een lege editor. Wij houden van greenfield projecten, maar een bestaande codebase aanpassen is veel dichter bij het echte werk.
  • Voorkeur voor testen boven pure productiecode. Coderen is geweldig, maar zoekt of ontwikkelt een kandidaat tests naast de implementatie? Dat aspect wordt bijna universeel over het hoofd gezien bij een algoritmische test.
Algoritme test

Vergeet niet dat samenwerken niet betekent dat je ter plaatse moet vergaderen. Scherm delen en real-time samenwerking zijn tegenwoordig heel eenvoudig, ook met DevSkiller.

Samenvatting

Er is niets mis met algoritmische vragen tijdens een sollicitatiegesprek. Dit is een belangrijk onderdeel van ons vakgebied. Maar als je bedenkt hoe weinig tijd je hebt om te werven, zijn er verstandigere manieren om je volgende beste ingenieur te kiezen. Door echte vaardigheden te oefenen, zorg je ervoor dat een kandidaat goed is in wat je echt nodig hebt. Bovendien vermindert dit de stress en verbetert het beeld dat een kandidaat van uw bedrijf heeft.

Post delen

Meer informatie over het inhuren van tech

Abonneer u op onze Learning Hub en ontvang nuttige inzichten rechtstreeks in uw inbox.

Verifieer en ontwikkel coderingsvaardigheden naadloos.

Zie DevSkiller producten in actie.

Beveiligingscertificeringen & naleving. Wij zorgen ervoor dat uw gegevens veilig en beveiligd zijn.

DevSkiller logo TalentBoost logo TalentScore logo