skip to Main Content
In Technische Interviews Verder Gaan Dan Programmeervaardigheden

In technische interviews verder gaan dan programmeervaardigheden

Het inhuren van ontwikkelaars is voor veel bedrijven een uitdagend proces. Er wordt veel nagedacht over het ontwerpen van goede interviewvragen en programmeeruitdagingen om de vaardigheden van kandidaten op een praktische manier te beoordelen, hetzij als een thuisoefening of in een whiteboard interview. Ik weet dit door zelf programmeeruitdagingen te hebben ontworpen en geëvalueerd, met betrekking tot codekwaliteit, structuur en optimalisatie van de oplossing.

Deze evaluatie is tot op zekere hoogte nuttig. Waar het proces echt op neerkomt, is de kandidaat vragen om een algoritme uit het niets te creëren, het in korte tijd af te ronden (meestal ergens tussen de 30 minuten en een paar uur), en dan hopen dat het goed uitvoeren van deze taak zich vertaalt in een goede fit voor het team.

De waarheid is dat er veel vaardigheden zijn die deze praktijk niet kan behandelen. Dit komt omdat werk van een ontwikkelaar meestal bestaat uit het werken met bestaande code, niet scratch, en binnen een team, niet alleen.

Daarom moet een ontwikkelaar beschikken over solide communicatieve vaardigheden en een effectieve aanpak voor het oplossen problemen in de echte, onvolmaakte wereld. Het beoordelen van deze vaardigheden, die soms ook wel ‘soft skills’ worden genoemd, als dit überhaupt gedaan wordt, gebeurt meestal door de kandidaat vragen te stellen over scenario’s uit het verleden of hypothetische scenario’s, bijvoorbeeld door hem of haar te vragen: “noem een situatie waarin je om hulp moest vragen”. Hoewel dit nuttig is in de zin dat gedrag uit het verleden toekomstig gedrag kan voorspellen, geeft het de kandidaat ook de mogelijkheid om te raden wat het antwoord zou moeten zijn. Bovendien hebben kandidaten de neiging om ook een hekel te hebben aan deze vragen.

Bedrijven testen kandidaten niet op bijvoorbeeld Python-vaardigheden door ze te vragen een situatie uit het verleden te beschrijven waarin ze een Python-programma hebben geschreven. Ze vragen hen om een Python programma te schrijven. Wat als er een manier was om vaardigheden te beoordelen die verder gaan dan algoritmes, op een vergelijkbare, praktische manier? Niet door middel van een apart HR interview, niet door middel van gedragsvragen, maar geintegreerd in hetzelfde proces dat programmeervaardigheden beoordeelt.

Dit is wat ik in dit artikel ga behandelen. We gaan kijken hoe we de verschillende interviewfasen kunnen aanpassen, met name de fase van de telefonische screening, de thuisoefening en het interview ter plaatse, om meer inzicht te krijgen in het vermogen van de kandidaat om te communiceren, hoe ze werken met een bestaande codebase en met anderen, en de vindingrijkheid die ze hebben in het oplossen van problemen.

Telefonische screening

Meestal worden telefonische screenings gebruikt om meer informatie te krijgen over de ervaring van de kandidaat. Het is echter mogelijk om te beoordelen of de kandidaat zich bewust is van wat hij/zij wel en niet weet, en hoe precies hij/zij kan communiceren.

Zelfbewustzijn

Zich bewust zijn van wat men wel en niet weet, en deze kennis ook delen is een echt geschenk als men in een team werkt. Als een medewerker zich ervan bewust is en eerlijk is dat hij/zij niet over de kennis beschikt die nodig is om een taak af te ronden, dan wordt er tijd vrijgemaakt vanuit het team om naar alternatieven te zoeken, zoals het toewijzen van tijd om de kennis te verwerven, het volgen van trainingen en het inhuren van externe medewerkers. Het team is in staat om de alternatieven af te wegen tegen de voordelen van het voltooien van de taak.

Een manier om dit te beoordelen tijdens de telefonische screening is een uitgebreide lijst met vragen over een grote verscheidenheid aan onderwerpen om de kandidaat te stellen, bijvoorbeeld het stellen van typische full-stack vragen, van CSS tot de interne werking van databases. Het is goed om dit vooraf aan de kandidaat te vertellen:

We zijn niet op zoek naar gissingen of antwoorden op alle vragen, we zijn gewoon op zoek naar de gebieden waar je sterk in bent.

We kunnen vervolgens doorgaan en aan hen voor een bepaalde tijd, meestal 5 tot 10 minuten, vragen stellen. Tijdens het proces kunnen we niet alleen observeren en registreren wat de kandidaat weet, maar ook hoe hij of zij handelt als hij of zij iets niet weet. Naast de juiste antwoorden zijn er enkele positieve signalen om op te zoeken: hoe snel geeft de kandidaat toe dat hij of zij niet met een bepaalde technologie heeft gewerkt, en verklaringen die effectief en eerlijk omgaan met onzekerheid, zoals “Ik ben er niet zeker van of dit specifieke databasesysteem bitmap-indexen implementeert. Als dat het geval is, kunnen we ze gebruiken, anders zouden we voor B-trees moeten gaan”.

Nauwkeurigheid

Ontwikkelaars die nauwkeurig kunnen communiceren maken het op vele fronten gemakkelijker. Ze zijn in staat om relevante informatie te geven bij beschrijvingen (zoals van een bug die moet worden opgelost, de voor- en nadelen van een architectonische beslissing, hoe een systeem werkt, etc.), en om iets uit te leggen wanneer erom gevraagd.

Tijdens de telefonische screening willen we kijken of de kandidaat een nauwkeurig verslag kan geven van zijn of haar ervaringen uit het verleden. Een manier om deze uitwisseling te vergemakkelijken is het stellen van zogenaamde Clean Language vragen. De basisfilosofie hierachter is het minimaliseren van onze aannames als interviewers, en het verkennen van het model van de kandidaat van zijn eigen werk. Clean Language vragen in de context van een technisch interview zijn vragen als deze:

  • Wat voor soort [technologie/database/etc] heb je gebruikt?
  • Hoe ziet [complex systeem] eruit voor [een soort gebruiker]?
  • En als [de gegevens worden verwerkt], wat gebeurt er dan achteraf?
  • Wat gebeurt er voordat [de logs op S3 worden opgeslagen]?
  • Is er nog iets anders [waar je lambdas voor nodig hebt]?

We kunnen tijdens dit deel van het interview beginnen met de kandidaat te vragen “een complex project te beschrijven waaraan ze hebben gewerkt” en verder te gaan met vragen die vergelijkbaar zijn met de vorige voorbeelden. We moeten een vriendelijke manier gebruiken om de kandidaat het gevoel te geven dat hij of zij gehoord wordt, niet dat hij of zij wordt ondervraagd.

Clean Language vragen dienen een tweeledig doel. Ten eerste geven ze diepere informatie over het werk van de kandidaat in het verleden, wat op zich waardevol is, en bieden ze de interviewers ook de mogelijkheid om uit te zoeken hoe goed de kandidaat kan uitleggen als er vragen gesteld worden over zeer specifieke aspecten van zijn of haar werk. Een ander positief signaal waar je naar kunt zoeken is wanneer de kandidaat vragen stelt om te verduidelijken wat er van hem of haar gevraagd wordt, zoals “Wat bedoel je met een ‘complex’ project?”.

Thuisoefening: Uitbreiding van een bestaande codebase

De thuisoefening wordt meestal gebruikt om de algoritmische vaardigheden van een kandidaat te evalueren, door te kijken hoe ze een probleem oplossen. Met enkele wijzigingen in het proces kunnen we nog meer leren over de kandidaat.

De meeste ontwikkelaars doen dat dagelijks, maar dat is geen greenfield project. Een groot deel bestaat uit het lezen en bouwen bovenop bestaande code, wat extra probleemoplossende vaardigheden vereist. In plaats van de kandidaat ta vragen om een script vanaf scratch te maken, kunnen we hem of haar een bestaande codebase geven die hij of zij kan forken. Deze codebase zou idealiter, moeten worden gedockerised zodat het opzetten van de afhankelijkheden eenvoudig is, en geproduceerd door het bedrijf kan worden. Het zou nog steeds deelbaar moeten zijn, bijvoorbeeld als een klein open-source project. We kunnen ook een privé Slack-kanaal opzetten waarin de kandidaat tijdens het ontwikkelingsproces vragen kan stellen aan ontwikkelaars.

We kunnen de kandidaat vragen om extra functionaliteit toe te voegen aan de codebase om een nieuw probleem op te lossen door commits in hun eigen fork aan te maken en vervolgens een pull-verzoek te doen aan de master repository. Hun vermogen om deze taken uit te voeren toont niet alleen hun algoritmische vaardigheden, maar ook hun vermogen om te lezen, te begrijpen en uit te zoeken waar ze wijzigingen kunnen aanbrengen op code die niet door hen geschreven is. We kunnen er ook voor zorgen dat we een testsuite toevoegen, waarbij we erop letten of de kandidaat de testsuite uitbreidt met de code. De thuisoefening kan worden hergebruikt als de kandidaat ter plaatse komt, wat we in de volgende sectie zullen bekijken.

Door de thuisoefening krijgt de kandidaat een stukje te zien van hoe de typische codebase van het bedrijf eruit ziet en een idee hoe het is om te werken met het team.

Interview ter plaatse

Het gesprek op locatie biedt de mogelijkheid om te testen hoe het bedrijf en de kandidaat samen kunnen werken. Het is zinvol om gebruik te maken van de tijd die beide partijen hebben geïnvesteerd om daar dieper op in te gaan. Als we verder willen gaan dan whiteboard interviews, volgen hier een paar ideeën voor taken om specifieke vaardigheden te beoordelen:

Omgaan met verandering en vragen om ondersteuning

Een taak die zowel de kandidaat als het bedrijf een dieper begrip van elkaar kan geven, is de kandidaat te vragen het programma te koppelen met een lid (of leden) van het bestaande team. We kunnen de kandidaat vertellen dat de eisen van zijn of haar thuisoefening zijn veranderd en dat hij of zij moet samenwerken met een andere ontwikkelaar en eventueel een business analist om deze verandering in de code weer te geven. Vervolgens kunnen we de kandidaat vragen om met de teamgenoten en hun laptops in een vergaderruimte te gaan zitten om samen te werken aan het maken van de veranderingen. Alle betrokkenen kunnen gebruik maken van het taakbeheersysteem dat het bedrijf gebruikt, bijvoorbeeld JIRA, Trello of een fysiek Kanban-bord.

We observeren of de kandidaat gebruik maakt van de beschikbare middelen (d.w.z. de andere mensen en de informatie die in het taakbeheersysteem is vastgelegd) om uit te zoeken wat er precies moet worden gedaan, wat de meest consistente manier is om dit te doen, en hoe ze mogelijke manieren om het werk te splitsen aan de orde stellen. We kunnen zien waar ze liggen in het spectrum van het aanpakken van veranderende eisen: van weerstand bieden aan de eisen, tot het andere uiterste van het volledig opnieuw beginnen met programmeren.

Deze taak zal de kandidaat symmetrische informatie verschaffen: hoe taken worden verdeeld en toegewezen in het bedrijf, hoe goed projectmanagers kunnen communiceren en hoe potentiële toekomstige medewerkers kennis kunnen delen en samenwerken.

Constructieve feedback

Een andere vaardigheid om te testen is hoe de kandidaat feedback geeft. Dit kan direct worden beoordeeld door een relatief op zichzelf staand deel van de echte codebase te isoleren, af te drukken, en de kandidaat te laten lezen en aantekeningen te laten maken met de bedoeling om een code review te doen door de vraag te stellen “wat vind je van de code en hoe zou je deze verbeteren”.

Het is belangrijk om erop te letten of de kandidaat positieve en negatieve commentaren met elkaar verbindt, of hij/zij in staat is om beknopte stappen te schetsen voor een iteratieve verbetering van wat opvalt, en of hij/zij vragen stelt om te weten te komen of deze verbeteringen de moeite waard zijn of andere delen van het systeem beïnvloeden. Mensen die alleen fouten zien in het werk van anderen zonder oplossingen te bieden, kunnen enorm demoraliserend werken voor het hele team, hoe scherp hun observaties ook zijn. Mensen die goed bedoeld zijn, maar te veel veranderingen tegelijk willen uitrollen, hebben waarschijnlijk niet veel productie-ervaring.

Sprekend vanuit persoonlijke ervaring, worden mensen die eerlijke en positieve feedback in hun recensies opnemen bedankt bij het beoordelen van pull requests. Degenen die begrijpen dat er weliswaar ruimte voor verbetering is, maar dat het soms het beste is om af te zien van het verbeteren van wat al goed genoeg is, zijn degenen die invloedrijke veranderingen kunnen stimuleren.

Deze taak heeft als bijkomend effect dat de kandidaat een kijkje kan nemen in de echte bedrijfscode. Bovendien, als de kandidaat aan de interviewer een alternatieve manier communiceert om dingen te doen die ze niet wisten, hoe positief deze suggestie wordt ontvangen kan zeer veelzeggend zijn voor het vermogen van het bedrijf om iteratieve verbeteringen te ondersteunen. Deze kwaliteit kan iets zijn waar de kandidaat naar op zoek is bij zijn nieuwe werkgever.

Conclusie

Door verder te gaan dan het whiteboard interview kunnen we beoordelen of de kandidaat meer kan dan alleen programmeren. Dit kan zo eenvoudig zijn als het bestaande sollicitatieproces door te nemen en het aan te passen met de bedoeling om meer over de kandidaat te leren. Uiteraard zal er tijd moeten worden geïnvesteerd in het vinden en verpakken van specifieke delen van de code die met de kandidaat kunnen worden gedeeld, en in het trainen van interviewers om kritische vragen te stellen. Deze aanpassing zal het symmetrische effect hebben dat de kandidaat ook een duidelijker beeld krijgt van hoe het is om met het team te werken.

Als afscheidsgedachte: denk eraan om altijd een positieve instelling te behouden. Als interviewers zijn we hier om de echte sterke punten van mensen te ontdekken, en het is aan ons om een proces te ontwerpen dat ze blootlegt.

Heeft u op de afdeling softwareontwikkeling een uitdaging met personeel en zoekt u tijdelijke, gekwalificeerde junior developers die direct operationeel zijn? Team X is een detacheringsbureau dat u kan helpen. Neem vrijblijvend contact op met Anthony Carter voor onze tarieven. Of lees meer over onze dienstverlening op de site.

Telefoon : 023-2052070

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Back To Top