Copilot-sollicitatievragen voor developers: wat teams echt vragen

De meeste developers vrezen dat toegeven dat ze Copilot dagelijks gebruiken als zwakte overkomt. Dat is niet zo; teams gaan ervan uit dat je met een assistent werkt en willen horen hoe je die aanstuurt. De vragen vallen in vijf soorten.

• Werkwijze: waar de assistent in je cyclus zit en welke taken je eraan geeft.
• Review: hoe je gegenereerde code verifieert voordat die in een pull request belandt.
• Beveiliging en licenties: secrets in prompts en code van onduidelijke herkomst.
• Debuggen: verantwoordelijkheid nemen voor een storing in code die je hebt overgenomen in plaats van geschreven.
• Oordeelsvermogen: de taken waarbij je de assistent uitzet.

Geen van deze beloont gereedschapskennis. Ze belonen een developer die een gewoonte kan beschrijven en verdedigen. Meer vragensets per rol en per ronde staan op de hub met sollicitatievragen.

Geef een concrete cyclus, geen oordeel over het gereedschap. Sterke antwoorden benoemen de taak, de controle en de uitkomst.

Een backend engineer die solliciteerde op een seniorrol bij een betaalbedrijf antwoordde zo: ze gebruikt Copilot om table-driven tests en standaard handlers op te zetten, leest elke gegenereerde tak tegen de specificatie voordat die naar staging gaat, en schrijft de concurrency-gevoelige paden zelf omdat de assistent steeds een lock-volgorde voorstelde die ze niet kon verantwoorden. De interviewer besteedde de volgende vijf minuten aan de lock-volgorde, niet aan Copilot.

Dat is het patroon om te kopiëren. Kies één taak die je uitbesteedt, één controle die je uitvoert en één ding dat je nog steeds met de hand schrijft. Vage claims over snelheid lokken een vervolgvraag uit die je niet kunt dragen, want elk getal dat je noemt wordt uitgediept.

Dit is de soort waarin senior kandidaten zich onderscheiden, en tegelijk de soort die het minst wordt voorbereid.

• Plak je bedrijfseigen code of secrets in een prompt? Het verwachte antwoord is nee, met een reden: de inhoud van de prompt verlaat je machine.
• Hoe ga je om met gegenereerde code van onduidelijke herkomst? Vertel wat het teambeleid is, of zeg dat je erom zou vragen.
• Heeft een suggestie ooit een kwetsbaarheid geïntroduceerd die je ving? Een concreet bijna-incident is sterker dan de bewering dat het nooit gebeurt.
• Zou je gegenereerde code laten mergen zonder menselijke reviewer? Nee, en wees klaar om te zeggen waarom review vangt wat tests missen.

Aaron Cao, oprichter van SubcueAI, ontwierp de assistent zo dat er geen bot aan het gesprek deelneemt en er niets in de meetingpagina wordt geïnjecteerd, precies om de reden waarom deze vragen worden gesteld: teams vertrouwen gereedschap waarvan iemand het datapad hardop kan beschrijven. Dat pad staat beschreven op de beveiligingspagina.

De voorbereiding is hier verbaal, niet technisch. Je eigen werkwijze ken je al; wat ontbreekt is die in negentig seconden beschrijven terwijl iemand wacht. De vragen hardop oefenen dicht dat gat, en oefenen met een proefgesprek stelt vervolgvragen in plaats van je een lijst te geven om voor te lezen.

Wees ook duidelijk over de grenzen in het echte gesprek. SubcueAI draait als native macOS- en Windows-app met een lokale overlay, en als zijpaneel van een browserextensie die alleen de audio van het meetingtabblad opvangt. Geen van beide neemt als deelnemer aan het gesprek deel. Geen van beide hoort thuis bij een bewaakte assessment, op een door het bedrijf beheerd apparaat of terwijl je je scherm deelt, en in die situaties is geen enkele assistent veilig.