Joel on Software   Joel over Software

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

Het aannemen van de juiste mensen is zéér belangrijk voor Fog Creek Software. In ons vakgebied zijn er drie soorten mensen. Aan de ene kant van het spectrum zijn er degenen die nog nat achter de oren zijn, met nog niet eens een minimale hoeveelheid kennis in huis. Deze zijn er snel uit te halen, vaak door alleen maar naar het CV te kijken en twee of drie korte vragen te stellen. Het andere uiteinde bevat briljante uitblinkers die voor de lol Lisp compilers schrijven, in een weekeinde, in assembler voor de Palm Pilot. En daartussen heb je een groot aantal "misschien" die wellicht in staat zijn om iets toe te voegen. De truc zit hem er in het verschil tussen de uitblinkers en de misschien-en te zien, omdat we bij Fog Creek Software enkel de uitblinkers aannemen. Hier zijn een aantal technieken om dat voor elkaar te krijgen.

Ten eerste, de absolute nummer één criteria om bij Fog Creek aangenomen te worden zijn:

• Slim zijn
• Dingen Gedaan Krijgen

Slim is ietsje moeilijker te quantificeren, maar als we straks gaan kijken naar mogelijke sollicitatievragen zullen we zien hoe we daar achter kunnen komen. Dingen Gedaan Krijgen is cruciaal. Mensen die Slim zijn maar geen Dingen Gedaan Krijgen hebben vaak ingenieurstitels en werken voor grote firma's waar toch niet naar ze geluisterd wordt omdat ze volslagen nutteloos werk afleveren. Ze houden zich liever met een of ander theoretisch probleem bezig in plaats van op tijd hun product af te leveren. Dit soort mensen herken je omdat ze je graag wijzen op de theoretische overeenkomsten tussen twee compleet verschillende concepten. Zij zullen bijvoorbeeld zeggen dat "een spreadsheet niets anders dan een speciaal geval van een programmeertaal", om vervolgens een week te spenderen aan het schrijven van een briljante white paper over de theoretische rekenkundige taalkundige attributen van een spreadsheet als programmeertaal. Briljant, maar volslagen nutteloos.

Welnu, mensen die Dingen Gedaan Krijgen maar niet Slim zijn, doen domme dingen zonder er schijnbaar over na te denken, en iemand anders kan later de troep achter ze op gaan ruimen. Dit maakt ze tot kostenposten, omdat ze niet alleen niks toevoegen, maar ze verkwisten ook nog eens andermans tijd. Dit is het soort mensen dat grote stukken code kopieëert in plaats van een subroutine te schrijven omdat het zo ook wel werkt, maar niet bepaald op de slimste manier.

De belangrijkste regel bij sollicitatiegesprekken is:

• Beslis

Aan het einde van het gesprek moet je in staat zijn een duidelijke beslissing over de kandidaat te nemen. Er zijn slechts twee uitkomsten mogelijk: Doen of Niet Doen. Ga achter je PC zitten en stuur spoedig een antwoord naar de recruiter of kandidaat. Het onderwerp moet de naam van de kandidaat zijn. De eerste regel van het mailtje luidt: Aangenomen (Doen) of Niet Aangenomen (Niet Doen). Dan schrijf je nog een tweetal paragrafen ter ondersteuning van je beslissing.

Er is geen ander antwoord mogelijk. Zeg nooit: "Doen, maar niet in mijn groep." Dit is onbeschoft en impliceert dat de kandidaat niet slim genoeg is voor jouw groep, maar misschien wel voor dat stelletje imbecielen van de andere groep. Als je naar "Doen, maar niet in mijn groep" neigt, vertaal dat dan automatisch naar Niet Doen en dan is er geen probleem. Zelfs als je een kandidaat hebt die heel erg goed is in één specifiek ding, maar niet echt goed in een andere groep zou passen, ook dat is Niet Doen. Dingen veranderen zo vaak en zo snel dat we mensen nodig hebben die overal kunnen slagen. Als je op de een of andere manier een idiot savant vindt die erg, erg goed is met SQL maar niet in staat is ook maar iets anders te leren, Niet Doen. Zij hebben geen toekomst bij Fog Creek.

Zeg ook nooit: "Misschien, maar ik weet het niet.". Twijfelen betekent Niet Doen. Het is echt veel gemakkelijker dan je denkt. Twijfel? Zeg gewoon nee! Zelfs als je op het randje staat, betekent dat Niet Doen. Zeg nooit: "Wel, Doen, zou ik zeggen, ik weet alleen niet of ..." Ook dat is Niet Doen.

Een belangrijk iets om te onthouden bij gesprekken is dit: het is veel beter om een goede kandidaat af te wijzen dan om een slechte aan te nemen. Een slechte kandidaat kost veel geld en moeite en verspilt de kostbare tijd van anderen omdat zij de bugs mogen oplossen. Als je ook maar de geringste hoeveelheid bedenkingen hebt, Niet Doen.

Als je gesprekken voert, wees dan niet bang dat als je te veel mensen afwijst, Fog Creek niet in staat zal zijn iemand te vinden om aan te nemen. Dat is niet jouw probleem. Het is het probleem van de headhunters, personeelszaken, Joel's probleem, maar niet het jouwe. Vraag jezelf telkens af wat erger is - dat we uitgroeien tot een groot, slecht software bedrijf met een stel dombo's, of dat we klein maar van hoge kwaliteit blijven? Uiteraard is het belangrijk om goede kandidaten te vinden en iedereen binnen het bedrijf zou het als zijn taak moeten zien om slimme mensen die Dingen Gedaan Krijgen te zoeken. Maar áls je uiteindelijke iemand ondervraagt, doe dan net alsof Fog Creek genoeg kandidaten heeft. Verlaag nooit je standaarden, hoe moeilijk het ook lijkt om geschikte kandidaten te vinden.

Maar hoe maak je die moeilijke beslissing? Je moet jezelf tijdens het interview blijven afvragen: is deze persoon Slim? Krijgt hij of zij Dingen Gedaan? Om dat te achterhalen zul je de juiste vragen moeten stellen.

Voor de lol is hier de slechste sollicitatievraag op Aarde: "Wat is het verschil tussen varchar en varchar2 in Oracle 8i?" Dat is een nutteloze vraag. Het is volslagen onmogelijk enig verband te leggen tussen iemand die dit stukje trivia weet en een persoon die Fog Creek wil aannemen. Wat maakt het uit wat het verschil is? Op het Net kun je dat binnen 15 seconden opzoeken!

Nou ja, er zijn nog slechtere vragen mogelijk. Meer daarover later.

Nu komen we tot het leukste deel: de vragen. Mijn lijst van sollicitatievragen komt van mijn eerste baan bij Microsoft. Er zijn in feite honderden beroemde Microsoft sollicitatievragen. Iedereen heeft er een paar die hun goed bevalt. Ook jij zult een aantal vragen ontwikkelen in combinatie met een persoonlijke interviewstijl die je zal helpen de Doen/Niet Doen beslissing te maken. Hier zijn een aantal technieken die ik gebruikt heb die successvol zijn geweest.

Voor het gesprek lees ik het CV van de kandidaat en noteer een interview plan op een stukje papier. Dit is een lijstje vragen dat ik wil stellen. Hier is een typisch lijstje voor als ik een programmeur zie:

1. Introductie
2. Vragen over een recent projectvan de kandidaat
3. De Onmogelijke Vraag
4. C functie
5. Ben je tevreden?
6. Ontwerpvraag
7. De Uitdaging
8. Zijn er nog vragen?

Ik probeer altijd zeer zorgvuldig te vermijden dat ik van te voren een vooroordeel krijg over de kandidaat. Als je denkt dat iemand slim is voordat ze ook maar in de kamer zijn, alleen maar omdat ze een titel van MIT hebben, dan zal niets in dat ene uur van het gesprek je daarvan af kunnen brengen. Als je denkt dat het een clown is, zal niets dat ze kunnen zeggen die eerste indruk kunnen veranderen. Een sollicitatiegesprek is als een heel gevoelige weegschaal - het is erg lastig om iemand te beoordelen op basis van een gesprek van een uur en vooral als het een moeilijke beslissing wordt. Als je dan ook maar een heel klein beetje weet van de kandidaat van te voren, fungeert dat als een zwaar gewicht op één van de schalen en is het hele gesprek waardeloos.

Eens, vlak voor een gesprek, kwam de recruiter mijn kantoor binnenwandelen en zei: "Echt, de volgende kandidaat zul je fantastisch vinden." Wat ben ik daar kwaad om geworden, zeg. Wat ik had moeten zeggen was, "Nou, als jij hem zo fantastisch vindt, dan neem jij hem toch aan in plaats van er mijn tijd mee te verspillen?" Maar ik was jong en naïef, dus heb ik hem toch ondervraagd. Toen hij niet zulke slimme dingen zei, dacht ik bij mezelf, "Hmm, dit moet de uitzondering zijn die de regel bevestigt." Ik bekeek alles wat hij zei met een roze brilletje. Uiteindelijk zei ik Doen terwijl het een slechte kandidaat was. En weet je wat? Iedereen die hem had ondervraagd had Niet Doen gezegd. Dus: luister niet naar recruiters; vraag niet naar de persoon vóór het interview; en praait nooit, maar dan ook nooit, met andere collega's over de kandidaat totdat je onafhankelijk je mening hebt gevormd. Het is net wetenschap!

De Introductie is bedoeld om de kandidaat op zijn of haar gemak te stellen. In ongeveer 30 seconden vertel ik de persoon wie ik ben en hoe het gesprek in zijn werk gaat. Ik vertel de kandidaat altijd dat we meer geïnteresseerd zijn in hoe hij het probleem oplost, en niet het antwoord zelf. Trouwens, zorg er tijdens het gesprek voor dat je niet aan de andere kant van het bureau zit. Dit creëert een formele drempel waardoor de kandidaat niet ontspant. Het is beter om het bureau tegen de muur te zetten of aan de andere kant van het bureau bij de kandidaat te gaan zitten; dit helpt de kandidaat gerust te stellen. Het gevolg is een beter gesprek omdat het niet verstoord wordt door zenuwachtigheid.

Deel twee is een vraag over een recent project waar de kandidaat aan heeft gewerkt. Bij net afgestudeerde mensen vraag ik ze naar hun afstudeerwerk als ze er één hadden, of een vak dat ze gevolgd hebben dat een lang project omvatte dat ze echt leuk vonden. Soms vraag ik bijvoorbeeld: "Welk vak heb je het laatste semester gevolgd dat je echt leuk vond? Het hoeft niet iets met computers te maken te hebben." Vaak vind ik het zelfs beter als ze een niet-computer vak noemen. Soms kijk je naar hun CV en ziet het er naar uit dat ze het absolute minimum aan computer vakken hebben gevolgd, maar de rest is gewijd aan muziek. Dan vertellen ze dat hun favoriete vak Object Geörienteerde Databases was. Tuurlijk. Ik heb veel liever dat ze toegeven dat ze muziek veel leuker vinden dan computers, in plaats van mijn hielen te likken.

Wanneer je ervaren kandidaten ondervraagt, kun je over hun vorige baan praten.

Bij deze vraag kijk ik naar één ding: passie. Wanneer je praat over een onderwerp waar ze recentelijk aan gewerkt hebben, dan zijn dit de goede tekenen:

• Ze raken er opgewonden over; ze praten sneller en bewegen meer. Dit toont aan dat wanneer ze in iets geïnteresseerd zijn, ze er ook echt in duiken. Er zijn veel te veel mensen die aan iets kunnen werken zonder dat het ze eigenlijk veel kan schelen. Zelfs als ze ergens negatief over zijn, kan dat net zo'n goed teken zijn. "Ik werkte aan het installeren van Foo Bar Mark II voor mijn vorige werkgever, maar dat was zo'n eikel!" Dit zijn goede kandidaten die we willen aannemen. Slechte kandidaten kan het weinig schelen en worden gedurende het hele interview nergens enthousiast over. Een heel goed teken dat een kandidaat echt passie voor iets toont is dat ze tijdelijk vergeten dat ze in een sollicitatiegesprek zitten als ze erover praten. Soms komt een kandidaat binnen die erg nerveus is vanwege het gesprek - dit is normaal dus daar kijk ik over heen. Maar als je ze aan het praten krijgt over Computationele Monochromatische Kunst en ze worden enorm opgewonden dan verliezen ze die nervositeit. Uitstekend. Ik hou van geïnteresseerde mensen die om iets geven. (Om een voorbeeld te zien van Computationele Monochromatische Kunst, trek je de stekker van je monitor eens uit het stopcontact).
• Ze zijn zorgvuldig in het uitleggen van dingen. Ik heb kandidaten afgwewezen omdat ze niet in staat waren datgene wat ze in hun vorige project deden uit te legen in termen die een leek zou kunnen begrijpen. Vaak gaan ingenieurs er van uit dat iedereen wel weet wat Bate's Theorema is of what Peano's Axiomas zijn. Als ze dit doen, onderbreek ze even en zeg: "Zou je me een plezier kunnen doen en, gewoon voor de lol, dit uit kunnen leggen in termen die mijn grootmoeder nog zou kunnen begrijpen?" Veel mensen blijven dan nog steeds jargon gebruiken en lukt het niet om zich begrijpelijk uit te drukken. Doei!
• Als het project een team-project was, kijk dan naar tekenen dat ze een leidende rol aannamen. Een kandidaat zegt dan bijvoorbeeld: "we werkten aan X, maar de baas zei Y en de klant zei Z." Ik vraag dan: "Wel, wat deed jij dan?" Een goed antwoord kan zijn: "Ik ben samen met de andere teamleden om de tafel gaan zitten en ik heb toen een voorstel geschreven." Een slecht antwoord zou zijn: "Ik kon er niets aan doen. Het was een hopeloze situatie." Onthoud, Slim, en Dingen Gedaan Krijgen. Een goede manier om te achterhalen of iemand Dingen Gedaan Krijgt is om te kijken of ze dat in het verleden ook gelukt is. Je zou ze zelfs rechtstreeks kunnen vragen of ze een voorbeeld aan kunnen halen uit hun recente verleden waar ze een leidende rol hebben gespeeld en iets Gedaan Kregen - bijvoorbeeld door ergens bureaucratische traagheid te overwinnen.

Okay, het derde item op de lijst is de Onmogelijke Vraag. Dit is altijd leuk. Het idee is om ze een vraag te stellen waar ze onmogelijk een antwoord op kunnen hebben, gewoon om te zien hoe ze er mee om gaan. "Hoeveel opticiens zijn er in Seattle?" "Hoeveel ton weegt het Washington Monument?" "Hoeveel benzinestations zijn er in Los Angeles?" "Hoeveel pianostemmers wonen er in New York?"

• Slimme kandidaten beseffen dat je ze niet op hun kennis test en zullen proberen een antwoord te formuleren met een soort berekening-op-een-servetje. "Nou, eens kijken, Los Angeles heeft zeven miljoen inwoners; elke persoon heeft ongeveer 2,5 auto..." Natuurlijk maakt het niet uit als hun antwoord er volledig naast zit. Het belangrijkste is dat ze enthousiast aan de vraag werken. Ze proberen wellicht de capaciteit van een tankstation uit te dokteren. "Gut, het duurt ongeveer vier minuten om te tanken, een pompstation heeft ongeveer 10 pompen en is 18 uur per dag open..." Mogelijkerwijs proberen ze het uit te rekenen aan de hand van oppervlakte. Soms verbazen ze je met hun inventiviteit en vragen ze om de Gouden Gids. Allemaal goede tekenen.
• Niet zulke slimme kandidaten raken van streek en kijken je verdwaasd aan alsof je van Mars komt. Soms moet je ze een handje helpen: "Stel, je bouwt een stad ter grootte van Los Angeles, hoeveel pompstations zou je er in neer zetten?" Je kunt ze kleine hints geven: "Hoe lang duurt het om een benzine tank te vullen?" Met niet-slimme kandidaten zul je het antwoord er uit moeten trekken, terwijl ze daar stom zitten te wachten totdat je het verlossende antwoord geeft. Deze mensen zijn geen probleemoplossers en willen we niet voor ons laten werken.

Voor programmeervragen moeten kandidaten een kleine C functie schrijven. Hier zijn een paar typische problemen die ik ze voorleg:

1. Draai een string achterstevoren, ter plekke
2. Keer een linked list om
3. Tel alle bits die aan zijn in een byte
4. Binair zoeken
5. Vind de langste reeks in een string
6. atoi
7. itoa (leuk, want ze moeten een stack gebruiken of strrev)

Laten we er een paar wat nauwkeuriger bekijken. Nummer 1: draai een string achterstevoren, ter plekke. Iedere kandidaat die ik tot nog toe in mijn leven heb ondervraagd deed het de eerste keer fout. Zonder uitzondering proberen ze een buffer te alloceren en draaien de string in die buffer om. Het probleem is, wie alloceert die buffer? Wie geeft hem weer vrij? Nadat ik deze vraag aan een dozijn of wat kandidaten heb gesteld is me iets opgevallen. Veel mensen die denken dat ze C kunnen programmeren begrijpen niets van geheugen of pointers. Ze snappen het gewoon niet. Het is verbazingwekkend dat deze mensen als programmeur werken, maar toch is het zo. Met deze vraag zijn er een aantal manieren om je kandidaten te beoordelen:

• Is hun functie snel? Kijk hoe vaak ze strlen() aanroepen. Ik heb O(n^2) implementaties gezien voor strrev() terwijl het O(n) had moeten zijn omdat ze strlen() keer op keer aanroepen in een lus.
• Gebruiken ze pointers? Dat is een goed teken. Veel "C programmeurs" hebben geen flauw idee hoe pointers werken. Normaliter zou ik een kandidaat niet enkel en alleen afwijzen omdat hij één specifieke vaardigheid niet heeft. Niettemin ben ik er achter gekomen dat C pointers begrijpen geen vaardigheid maar aanleg vereist. In het eerste semester van het eerst jaar Informatica zijn er altijd plusminus 200 jochies in de klas, die allemaal complexe adventure games hebben geschreven in BASIC voor hun Atari 800 toen ze 4 jaar oud waren. Ze hebben het prima naar hun zin met het leren van Pascal tijdens college, tot de dag dat de leraar pointers introduceert, en opeens snappen ze het niet meer. Ze snappen helemaal niks meer. 90% van de leerlingen valt af en studeert af in Politieke Wetenschappen en vertellen hun vrienden dat er niet genoeg mooie exemplaren van de tegenovergestelde sexe op Informatica zaten, en dat ze daarom zijn geswitched. Om de een of andere reden worden de meeste mensen geboren zonder dat deel in hun hersens dat pointers begrijpt. Dit vereist aanleg, geen vaardigheid. Het vereist een vorm van indirect denken die sommige mensen eenvoudigweg niet kunnen.

Bij nummer 3 kun je zien hoe goed ze om kunnen gaan met bit operators in C... Maar dit is een vaardigheid, dus kun je ze een beetje helpen. Het is interessant om ze een subroutine te zien schrijven die alle bits in een byte telt, om ze vervolgens te vragen de routine veel sneller te maken. Echt slimme kandidaten maken een opzoek-tabel (het zijn tenslotte maar 256 posities) die ze maar één keer hoeven aan te maken. Met goede kandidaten kun je interessante discussies hebben over geheugen/snelheid afwegingen. Maak het ze nog lastiger: zeg hun dat je zelfs geen tijd wil besteden aan het opbouwen van de tabel gedurende de initialisatie. Briljante kandidaten kunnen zelfs een methode voorstellen waarbij de bits gedurende de eerste keer geteld worden, en ze dan opslaan in een cache zodat ze niet opnieuwd geteld hoeven te worden. De echte briljante kandidaten zullen een manier proberen te vinden om de tabel te berekenen aan de hand van de patronen die voorkomen.

Als je iemand code ziet schrijven zijn hier nog wat tips die kunnen helpen:

• Verzeker ze dat je weet dat het lastig is om code te schrijven zonder een editor, en dat je het ze niet kwalijk neemt als hun papier een rommeltje wordt. Ook begrijp je dat het lastig is bug-vrije code te schrijven zonder compiler, en dat je daar rekening mee zal houden.
• Indicaties van een goede programmeur: goede programmeurs hebben de gewoonte om bovenaan een { neer te zetten, en dan meteen onderaan de pagina een }, om dan pas de rest in te vullen. Ze hebben meestal ook een soort van variabelen naam-conventie, hoe simpel ook. Goede programmeurs gebruiken korte namen voor variabelen voor lussen. Als hun lus-index CurrentPagePositionLoopCounter heet, is dat een duidelijk teken dat ze niet veel code in hun leven hebben geschreven. Soms zie je een C programmeur iets als if (0 == strlen(x)) opschrijven, met de constante links van de ==. Dit is een heel goed teken; het betekent dat ze één keer te veel zijn gebeten door het verschil tussen = en == en zichzelf deze gewoonte hebben aangeleerd om dit te voorkomen.
• Goede programmeurs plannen voor ze iets opschrijven, in het bijzonders als er pointers bij zijn betrokken. Bijvoorbeeld, als je hun vraagt een linked-list om te draaien, dan zullen goede kandidaten altijd een klein tekeningetje in de kantlijn maken met de pointers en waar ze heen moeten wijzen. Ze moeten wel. Het is menselijk onmogelijk om code te schrijven die een linked list omdraait zonder vierkantjes met pijltjes te tekenen. Slechte programmeurs beginnen meteen met code kloppen.

Het is onvermijdelijk dat je een bug in hun code zie. Dus komt vraag numero 5: Ben je tevreden met deze code? Je kan ook vragen: "Ok, waar zit de bug?" De spreekwoordelijke Open Vraag Uit De Hel. Alle programmeurs maken wel een fout; daar is niks mis mee als ze hem maar kunnen vinden. Met de string functies vergeten ze bijna altijd om de nieuwe string met een nul af te sluiten. Met vrijwel iedere functie zitten ze er eens eentje naast. Ze vergeten soms een puntkomma. Hun functie werkt niet op strings met een lengtje van 0, of knallen eruit als hun malloc() faalt. Heel zelden zul je een kandidaat treffen waar de eerste keer geen bug in hun code zit. In dat geval is het nog leuker. Als je zegt "Er zit een bug in je code.", dan zullen ze hun code zorgvuldig nalopen, en dan moet je eens kijken of ze diplomatiek maar ferm stellen dat hun code toch echt correct is... Over het algemeen is het beter om de kandidaat nadrukkelijk te vragen of ze tevreden zijn over hun code alvorens verder te gaan.

Vraag 6: de ontwerpvraag. Vraag de kandidaten om iets te ontwerpen. Jabe Blumenthal, de oorspronkelijke ontwerper van Excel, vond het leuk om kandidaten een huis te laten ontwerpen. Volgens Jabe waren er kandidaten die onmiddellijk naar het whiteboard liepen en een vierkant tekenden. Een vierkant! Dat zijn dus onmiddelijk Niet Doen-ers.

Bij ontwerpvragen, waar kijk je naar?

• Goede kandidaten zullen proberen meer informatie uit je te halen. Voor wie is het huis? Als policy neem ik geen mensen aan die niet verder vragen dan voor wie het huis is. Vaak ben ik zo geïrriteerd dat ik ze midden in hun ontwerp onderbreek en zeg: "Wat ik nog vergeten ben te zeggen, was dat dit huis bedoeld is voor een familie blinde giraffen van zestien meter hoog."
• Niet zo slimme kandidaten denken dat ontwerpen net zoiets is als verven: je krijgt een blanco pagina en daar kun je mee doen wat je wilt. Slimme kandidaten begrijpen dat ontwerpen vooral het afwegen van een aantal moeilijke beslissingen is. Een goede ontwerpvraag is: ontwerp een afvalbak voor op de hoek van de straat. Denk eens aan al de tegenstrijdigheden! Hij moet makkelijk te legen zijn, maar onmogelijk te jatten; het moet makkelijk zijn om er dingen in te gooien, maar die mogen er niet uitwaaien op een winderige dag; hij moet stevig zijn, maar niet te duur; in sommige steden moet hij zodanig ontworpen zijn dat terroristen er geen bom in kunnen plaatsen.
• Creatieve kandidaten kunnen je soms verbazen met interessante, niet voor de hand liggende oplossingen. Eén van mijn favoriete vragen is Ontwerp een Kruidenrek voor Blinden. Uiteindelijk zullen de meeste kandidaten ergens Braille op de flesjes zetten, en over het algemeen belandt dat op de deksels om een aantal redenen die je wel zult ontdekken als je deze vraag 100 keer hebt gesteld. Ik heb één kandidaat gehad die het beter vond om de kruiden in een lade te doen, omdat het makkelijker is om Braille horizontaal dan vertikaal te 'lezen' met je vinger. (Probeer maar!) Dit was zo origineel dat het zelfs mij verbaasde - na tientallen interviews had ik dit antwoord nog nooit gehoord. And het vereiste een flink "sprong" buiten het probleem om. Vanwege dat ene antwoord, en geen andere negatieve punten, heb ik de persoon aangenomen die vervolgens één van de beste program managers van het Excel team is geworden.
• Zoek ook naar afmaken. Dit is een onderdeel van Dingen Gedaan Krijgen. Sommige kandidaten blijven treuzelen, kunnen geen beslissing nemen of vermijden lastige vragen. Soms laten ze moeilijke keuzes liggen en proberen toch door te gaan. Niet goed. Goede kandidaten hebben de neiging om in beweging te blijven, zelfs wanneer je ze probeert tegen de houden. Als de dicussie in kringetjes begint te draaien en de kandidaat zegt iets als "Tja, we kunnen hier de hele dag wel over blijven praten, maar we moeten iets doen dus laten we maar kiezen voor X," dan is dat een heel goed teken.

Hetgeen ons tot punt nummer 7 brengt, De Uitdaging. Ook dit is leuk. Gedurende het interview wacht je tot de kandidaat iets zegt dat ontegenzeggelijk, onherroepelijk en absoluut waar is. Dan zeg je "wacht eens even, momentje" en vervolgens speel je twee minuten lang advocaat van de duivel. Argumenteer met ze als je zeker weet dat zij gelijk hebben.

• Zwakke kandidaten geven toe. Niet Doen.
• Sterke kandidaten zullen je proberen te overtuigen. Ze hebben een complete waslijst met argumenten en tactieken om hun gelijk te krijgen. Misschien zeggen ze: "Ik heb het idee dat we langs elkaar heen praten." Maar, ze blijven bij hun standpunt. Doen.

Toegegeven, een sollicitatiegesprek is een ongelijke situatie, dus het risico bestaat dat de kandidaat je niet tegen durft te spreken omdat jij in een machtspositie verkeert. MAAR, goede kandidaten kunnen behoorlijk gepassioneerd raken tijdens de discussie en tijdelijk vergeten dat ze bezig zijn met een sollicitatiegesprek en zullen je niettemin proberen te overtuigen. Dat is het soort mensen dat we willen hebben.

Tenslotte vraag je aan de kandidaten of ze zelf nog vragen hebben. Sommige mensen willen graag weten of een kandidaat intelligente vragen stelt, hetgeen een standaard techniek is in alle boeken over sollicitatie-interviews. Persoonlijk interesseert het me niet wat voor vragen ze stellen omdat ik op dat moment mijn beslissing al genomen heb. Het probleem is dat de kandidaten soms vijf tot zes personen per dag moeten spreken, en het is lastig om voor al die mensen een intelligente, briljante vraag te verzinnen. Als ze niets te vragen hebben: prima.

Ik laat ook altijd een minuut of vijf over aan het einde van het interview om Fog Creek aan hun te verkopen. Dit is heel belangrijk, zelfs als je ze niet aanneemt. Als je het geluk hebt om een geschikte kandidaat te treffen, dan wil je er ook voor zorgen dat ze voor Fog Creek willen gaan werken. Zelfs al heb je een slechte kandidaat, dan nog wil je ze enthousiast maken over Fog Creek zodat ze weggaan met een goede indruk van het bedrijf. Zie het zo: deze mensen zijn niet alleen potentiële werknemers; het zijn ook mogelijke klanten. Het zijn ook goede aanknopingspunten voor eventuele nieuwe kandidaten; als zij denken dat Fog Creek een prima bedrijf is om voor te werken, zullen ze hun vrienden aanmoedigen om bij jou te solliciteren.

Oh ja, ik herinner me net dat ik ook nog wat voorbeelden zou geven van hele slechte vragen die je moet vermijden. Overigens, wat je ook wilt vragen, ga eerst na of het wel mag. Het volgende is bijvoorbeeld van toepassing in de Verenigde Staten.

Iedere vraag die ook maar enigzins gerelateerd is aan ras, religie, geslacht, land van herkomst, leeftijd, militaire dienst, veteranen status, sexuele voorkeur of lichamelijke handicap, is simpelweg onwettig. Als op hun CV staat dat ze in 1990 in het leger zaten, vraag ze niet, al is het maar terloops, of ze aan de Golfoorlog hebben meegedaan. Dat is verboden. Als hun CV vertelt dat ze aan het Technion in Haïfa hebben gestudeerd, vraag niet of ze toevallig Israëlisch zijn; ook dat is verboden. Deze site bevat een goede samenvatting van wat wel en niet mag (maar de rest van de sollicitatievragen op die site zijn nogal dom).

Vervolgens, vermijd vragen die er op zouden kunnen duiden dat we onderscheid maken of discrimineren op basis van iets waar we helemaal geen onderscheid in maken of op discrimineren. Een van de beste voorbeelden die ik kan bedenken is om te vragen of ze getrouwd zijn of kinderen hebben. Dit zou de indruk kunnen wekken dat we denken dat getrouwde mensen of mensen met kinderen niet genoeg tijd aan hun werk zullen besteden of met zwangerschapsverlof zullen gaan.

Tenslotte, geef ook geen opdrachten waarbij je zes lucifers zodanig neer moet leggen zodat je precies vier identieke gelijkzijdige driehoeken krijgt. Dit een typisch geval van een "aha!" vraag, je leert niets over Slim zijn/Dingen Gedaan Krijgen op die manier, of ze de mentale sprong nu maken of niet.

Interviewen is meer kunst dan wetenschap, maar als je je aan het Slim zijn/Dingen Gedaan Krijgen principe houdt, kan er weinig fout gaan. Als je de kans krijgt moet je je collega's eens vragen wat hun favoriete vragen zijn en wat voor soort antwoorden zij verwachten. In de kantine van Gebouw 16 in Redmond is dit altijd een favoriet gespreksonderwerp tijdens de lunch.