Gesprek voeren met sollicitant (Java developer)

[Standeman]

Kijk ik na een lang (maar toch veeelste kort) weekend in mijn mailbox, zie ik opeens dat ik ben uitgenodigd om een sollicitatiegesprek bij te wonen. En dan bedoel ik niet dat ik op zoek ben naar werk (heb het nu wel naar mijn zin hiero), maar dat ik een of andere vent vragen moet gaan stellen om er achter te komen of hij een beetje om kan gaan met Java. Ik moet vooral naar het technische vlak kijken, personeels zaken kijkt wat meer naar het sociale / menselijke vlak.

Mijn probleem: Wat moet ik 'm in godsnaam gaan vragen? Hoe kom je er achter dat iemand een beetje aardig kan programmeren

Ik kan natuurlijk een uitgebreide casus neer kwakken en 'm er op laten zweten. Helaas heb ik de tijd er niet voor om deze voor te bereiden. Misschien wel een mini-casusje, met de nadruk op mini.

De sollicitant heeft pas een jaar Java ervaring, maar wel wat meer ervaring met C++ / Fortran.

Het volgende had ik al bedacht:

• Een aantal vragen gericht op JSP / servlets.
• 1 of 2 J2SE certificatie vragen (instinkers?).
• Vragen over hoe hij een project zou aanpakken.
• Bereidheid tot curssussen?
• Kennis van 3rd party software (Hibernate / Spring).

Heeft iemand nog iedeëen of tips? Wat maakt iemand tot een redelijk (goede) programmeur / ontwikkelaar. Wat zou jij vragen als je een sollicitant op bezoek hebt.

Overigens, misschien niet geheel onbelangrijk, de man komt uit het midden-oosten en woont nog niet zo heel erg lang in Nederland (< 10 jaar). Maakt denk ik voor Java-programmeren weinig uit. Het feit dat hij arabisch leest en schrijft is wel erg handig hier.

[sariel]

Wat is jou baan?

Ik kan hierboven niet uitmaken wat jij voor werk doet. Als je zelf programmeur bent, dan kan je zo wel wat vragen uit je mouw schudden. Ben je geen programmeur of projectleider, dan zal het toch een stuk zwaarder worden.

[kamstra]

Volgens mij is het niet zo handig om m een casus onder zijn neus te drukken, want 10 tegen 1 dat die kerel ook een beetje zenuwachtig is en dan niet 1 2 3 een pasklaar gewenst antwoord heeft, maar daar ook ff over na moet denken. Dan krijg je nogal een vreemde situatie als je daar met 2-3 man tegenover m zit te wachten tot ie met iets komt.

Dan zou ik eerder nu een gesprek voeren, en als dat bevalt kan je m altijd voor een 2e rond laten komen en m een test voorleggen\


edit:
en bereidheid tot cursussen vragen, dat is natuurlijk open deuren intrappen, daar gaat ie heus geen nee op zeggen

[ Voor 12% gewijzigd door kamstra op 16-01-2007 09:42 ]

[Arnout]

Vragen naar de "minder goede kanten". Noem eens een paar.

Ik heb al meerdere keren meegemaakt dat mensen doodleuk zeiden "geen" slechte eigenschappen te hebben, ook niet na het veranderen van de vraagstelling.

[whoami]

Is het niet beter of je even kijkt of die gast wel kan programmeren ? Of hij bepaalde technieken / methodieken kent / begrijpt / kan toepassen, ipv specifiek java-kennis te gaan testen ?
Ik bedoel maar, hij heeft pas 1 jaar ervaring in Java; als hij de knepen van het vak kent op OO gebied bv, dan hoeft hij nog niet zoveel Java kennis te hebben; hij zal het wel snel oppikken als hij de achterliggende ideeën kent / kan toepassen.

Vragen naar de "minder goede kanten". Noem eens een paar.

Da's eerder het sociale aspect Hetgeen waar de TS dus niet mee te maken heeft; aangezien andere personen dit gaan doen.

[ Voor 18% gewijzigd door whoami op 16-01-2007 09:51 ]

[Jaspertje]

Vraag m over standaard zaken in Java, om te controleren of ie basic kennis heeft, wij hadden ooit een 'ASP' programmeur die alleen met frontpage had gewerkt... dat was niet wat wij zochten. Of iemand die nog nooit met COM objecten had gewerkt binnen ASP, kan.., maar dan is je level anders dan wij zoeken.. Zulke dingen kan je vragen

Laat m iets opzetten op papier in OO, dat is misschien een casus die niet te moeilijk is, maar waaruit je wel kan zien wat iemand kan. Ik kreeg laatst een rij met velden en moest een relationeel model modeleren op papier.. (appeltje eitje, maar geeft wel een beelf over de sollicitant)

(eigelijn dus het zelfde als whoami, alleen anders verwoord )

[ Voor 5% gewijzigd door Jaspertje op 16-01-2007 09:53 ]

[onkl]

Vraag hem eens wat hij al gedaan heeft, eventueel als hobbyprojectjes en wat hij daar zelf goed of slecht aan vond gaan. Dat is voor een solicitant vertrouwd terrein, zodat je van de "onzekerheidruis" minder last hebt.

[Megamind]

Ik heb wel eens bij een gesprek wat source code laten zien (PHP dan wel), toen ze zagen dat veel OOP was, waren ze al dik tevreden.

Je kan natuurlijk wel veel zien aan source code, is het netjes geschreven, is het logisch opgezet, werkt het uberhaubt goed etc.

[Piels]

Denk eens terug aan je eigen sollicitatie gesprek, wat kwam er toen naar voren?

Maar ik zou eerst wat algemene vragen stellen zoals zijn sterke kanten, maar ook zoals hierboven wordt gezegd, zijn minder goede kanten. Is hij leergierig, wat vind hij van werken in team verban, etc.

Als je daar een goed beeld bij hebt zou ik erachter proberen te komen wat hij weet vn programmeren, maar dan niet specifiek op Java gebied. Zoals whoami al zegt, ik denk dat het belangrijker is om te kijken of hij bepaalde kennis heeft van programmeren in het algemeen en deze kan toepassen.
Vraag wat zijn ervaringen zijn met programmeren in de zin van projecten / hobby projecten. En vraag door op deze projecten. Zoals wat zijn aandeel was in deze projecten, waar hij verantwoordelijk voor was. Wat ging er niet goed tijdens dat project, wat heeft hij daarvan geleerd...

Zulke dingen zou ik vragen denk ik

[Janoz]

Ikzelf heb al meerdere interviews afgenomen. Ikzelf ga altijd hun CV af en vraag ze wat te vertellen over de technieken die ze in hun CV hebben genoemd. Vraag voor-, maar vooral ook nadelen. Of iemand knelpunten bij een specifieke techniek kent geeft al snel aan of iemand alleen iets er over gelezen heeft of ook daadwerkelijk heeft gebruikt.

Ikzelf werk bij een detacheerder. We hebben dus niet specifieke interne eisen mbt kennis (als in, we gebruiken struts met spring en dat zou je moeten kunnen). Mocht dat bij jou wel zo zijn dan zou ik die vragen vooral daarop richten. Vaak willen solicitanten wat moeilijk los komen (vooral programeurs). Vaak begin ik dan een beetje en koetjes kalfjes gesprek. Als ze bezig zijn nadelen te vertellen val ik ze af en toe bij om te laten zien dat het helemaal niet erg is om kritiek te hebben op technieken.

Meestal nemen wij een solicitatie met z'n 2en af. De andere persoon is dan meestal geen java developer. Hij gaat vaak in op de non-core eigenschappen van de solicitant. Vragen als 'Wat doe je als je vrij bent' en 'Wat motiveert je' zijn vaak vragen die van de ander af komen om te kijken wat voor type het is.

Uiteindelijk kijken we naar type en technische vaardigheden. Maken een oordeel en geven advies aan het hoger managment. Ikzelf vind het wel handig om mezelf als maat te geven. Het is een 0,8 Janoz of een 1,2 Janoz of ik vergelijk hem met een directe collega. Dat is een stuk makkelijker inschalen.

[Standeman]

sariel schreef op dinsdag 16 januari 2007 @ 09:40:
Wat is jou baan?

Ik kan hierboven niet uitmaken wat jij voor werk doet. Als je zelf programmeur bent, dan kan je zo wel wat vragen uit je mouw schudden. Ben je geen programmeur of projectleider, dan zal het toch een stuk zwaarder worden.

Vergeten te vermelden.. Ik ben zelf ook java developer

@kamstra
Inderdaad, vragen of hij een cursus wil volgen is een open deur. Alleen een idioot zegt er nee op (tenzij je van het CWI moet solliciteren )
En misschien dat ik een mini-casus inderdaad oversla. Misschien is een niet zo moeilijke j2se certificatie vraag beter als simpele test..

zoiets:

code:

class A {
  public static void main(String[] args) {
    char a = 'a', b = 'b'; // 'a' = 97, 'b' = 98
    System.out.print(a + b + "" + a + b);
}}

a. Prints: 390
b. Prints: 195195
c. Prints: 195ab
d. Prints: ab195
e. Prints: abab
f. Run-time error
g. Compile-time error
h. None of the above

lekker simpel en niet echt moeilijk.

@arnout
Minder goede kanten (op programmeer gebied), check.

Whoei.. dat gaat hard hier

Ik heb even mijn lijstje aangepast waarover ik zaken ga (door)vragen:

• (Hobby) projecten. Wat gebouwd en hoe gebouwd.
• 1 J2SE certificatie vraag als ik over zijn java kennis twijfel.
• Kennis van OO (bijv. design patterns? Singleton / Composite?).
• Kennis / ervaring van 3rd party software (Hibernate / Spring / Tomcat) en zijn mening hierover.
• Vragen over hoe hij een project zou aanpakken.
• Bereidheid tot curssussen?
• Een aantal vragen gericht op JSP / servlets.

Als laatste bekijken hoe hij overeenkomt / verschilt van collega's of mijzelf en dat rapporteren.

[ Voor 21% gewijzigd door Standeman op 16-01-2007 10:16 ]

[tyrion70]

Denk ook eens aan ontwikkelmethodieken.. Hoe werken jullie? RUP/RAD/Extreme? Vraag eens aan hem hoe hij het liefste ontwikkeld.. Als hij Extreme antwoord, en jullie werken zo totaal niet heb je een aardig beeld van hoe hij in jullie team past..

Ik durf ik te stellen dat alle programmeurs kunnen programmeren, en daarmee wil ik zeggen ook in elke taal. Dus tenzij je diep op een taal ingaat kun je moeilijk inschatten of de persoon toevallig ook veel hobby'd in PHP, of dat hij echt veel van Java weet. De voorbeeld vraag die jij gaf kan ie maar beter goed beantwoorden.. Geef hem een vraag waar discussie over mogelijk is.. "Hoe zou jij dit oplossen en waarom?", in plaats van "wat is het goede antwoord?".

Als je echt zijn java kennis wil weten, loop dan je laatste project eens door, en pak daar dat ene *** stukje code uit waar je je een uur op blind heb lopen staren voor je de oplossing zag (Je weet wel, die punt-comma, niet gedefinieerde variabele, of juist globaal gedefinieerde var). Geef hem daar wel de tijd voor, en ga met je collega even koffie halen ofzo..

Voor de rest denk ik dat je al een heel aardig lijstje hebt.. Hoop dat je er genoeg tijd voor hebt. Ikzelf ervaar het bij sollicitaties altijd als erg prettig als er een techneut bij zit, die wat inhoudelijke vragen stelt. Een PZ-er kijkt echt naar heel andere dingen.

Succes!

[Woy]

Standeman schreef op dinsdag 16 januari 2007 @ 09:58:
[...]

code:

class A {
  public static void main(String[] args) {
    char a = 'a', b = 'b'; // 'a' = 97, 'b' = 98
    System.out.print(a + b + "" + a + b);
}}

Ik denk dat zoiets niet echt een toegevoegde waarde heeft. Als de persoon dit weet toont dat alleen aan of hij weet wat het resulting type is als je 2 chars of een char en een string optelt. IMHO niet echt een belangrijk punt. Ik zou eerder wat vragen stellen over de globale werkwijze van java en wat hij daar goed/minder goed aan vindt. Vraag bijvoorbeeld wat hij van Garbage Collection vindt of hoe hij denkt over de platform onafhankelijkheid door de VM. Of vraag op wat voor manier hij een bepaalde situatie aan zou pakken.

Dit soort certificatie vragen vindt ik altijd nogal triviaal.

[Standeman]

rwb schreef op dinsdag 16 januari 2007 @ 13:57:
[...]

Ik denk dat zoiets niet echt een toegevoegde waarde heeft. Als de persoon dit weet toont dat alleen aan of hij weet wat het resulting type is als je 2 chars of een char en een string optelt. IMHO niet echt een belangrijk punt. Ik zou eerder wat vragen stellen over de globale werkwijze van java en wat hij daar goed/minder goed aan vindt. Vraag bijvoorbeeld wat hij van Garbage Collection vindt of hoe hij denkt over de platform onafhankelijkheid door de VM. Of vraag op wat voor manier hij een bepaalde situatie aan zou pakken.

Dit soort certificatie vragen vindt ik altijd nogal triviaal.

Heb je op zich een punt. Alleen als hij die vraag niet kan beantwoorden is het wel dramatisch gesteld met z'n java kennis. Ik zal een dergelijke vraag ook pas stellen als ik daar ernstig aan twijfel .

Maar ik ga zeker de vraag stellen op welke platformen hij ervaring heeft en hoe hij denkt over cross-platform ontwikkelen.

[TukkerTweaker]

Standeman schreef op dinsdag 16 januari 2007 @ 09:58:
[...]

zoiets:

code:

class A {
  public static void main(String[] args) {
    char a = 'a', b = 'b'; // 'a' = 97, 'b' = 98
    System.out.print(a + b + "" + a + b);
}}

a. Prints: 390
b. Prints: 195195
c. Prints: 195ab
d. Prints: ab195
e. Prints: abab
f. Run-time error
g. Compile-time error
h. None of the above

lekker simpel en niet echt moeilijk.

En wat als hij hier niet 'c' antwoord? Is ie dan afgeschreven?

Ik zou puur naar werkervaring kijken, vragen of hij technieken kent die jullie gebruiken of gaan gebruiken en dan vragen wat zijn ervaring daarmee is...
Wat was zijn rol in de verschillende projecten en vraag naar de keuzen die hij gemaakt heeft in bepaalde trajecten.
Hieruit kan ik meestal prima opmaken of iemand kaas gegeten heeft ontwikkelen en geschikt om een functie te vervullen.

[Standeman]

Hij heeft dus weinig werkervaring in het vakgebied. Sinds 2006 programmeert hij in Java en heeft wat C++ / Fortran ervaring.

Maar goed, ik zal een dergelijke vraag niet stellen als ik niet ernstig twijfel aan zijn java-kennis.

[frickY]

Probeer zijn manier van denken na te gaan, met behulp van wat praktijk voorbeelden.
Ik heb met een aantal mensen gewerkt welke de taal en syntax prima onder de knie hebben, maar gewoon niet logisch kunnen nadenken en daarom de meest bizarre constructies verzinnen voor de meeste simpele taken.

[Anoniem: 125106]

Zo van die "pop quiz" programmeervraagjes vind ik pure onzin.
Of je daar nu ter plekke op kan antwoorden of niet, zegt helemaal niets over het feit of je al dan niet een goeie programmeur bent

[Woy]

Standeman schreef op dinsdag 16 januari 2007 @ 14:59:
Maar goed, ik zal een dergelijke vraag niet stellen als ik niet ernstig twijfel aan zijn java-kennis.

Zelfs dan zou ik toch eerder een vraag stellen waar wat meer discussie over mogenlijk is. Dan kan je ook beter kijken wat het algemene inzicht is.
Vraag bijvoorbeeld iets over het gebruik van abstracte klassen en interfaces. Omdat je vraag een stuk opener is is het wat makkelijker om daar een gesprek over te voeren. Anders lijkt het zo snel op een overhoring.

[Cardinal]

Standeman schreef op dinsdag 16 januari 2007 @ 14:59:
Hij heeft dus weinig werkervaring in het vakgebied. Sinds 2006 programmeert hij in Java en heeft wat C++ / Fortran ervaring.

Daarvoor hebben ze een proeftijd uitgevonden. Voor functies waar het moeilijk is om te zeggen of iemand geschikt is. Bevalt die, hou je hem, zo niet

[KatirZan]

Ik denk eerlijk gezegd dat je het bovenstaande niet eens aan moet pakken. De sollicitant heeft al aangegeven ervaring te hebben in Java, dus in principe hoef je op die stof niet verder in te gaan. Wel zou ik vragen welke gedeeltes hij/zij wel heeft bestudeerd.

Ik zit zelf geregeld bij sollicitaties en uit ervaring kan ik vertellen dat je iemand op de werkvloer beter te kennen krijgt dan in een sollicitatiegesprek, dwz, probeer zoveel als mogelijk nuttige informatie naar boven te krijgen, informatie waar je iets aan hebt VOORDAT hij/zij begint met werken.

Dua achtergrond met Java (en programma's van derden), ervaring met hobbies is inderdaad een goeie (de meest echt goede programmeurs zijn begonnen als hobbyist), die zou ik zeker plaatsen. Verder moet je ook naar het persoon achter de java programmeur kijken, maar dat is het sociale gedeelte (wat dus opgevangen wordt door de andere mensen die bij het gesprek aanwezig zijn.)

Wat voor vragen zou jij zelf verwachten als je zelf zou solliciteren, welke vragen heb je zelf bij je sollicitatie gehad? Probeer die lijn een beetje aan te houden. Je kan moeilijk van iemand verwachten een applet te schrijven waar je bij staat... Ik was zelf altijd zwaar nerveus bij sollicitatiegesprekken en kan je vertellen dat ik bij zoiets helemaal dicht geklapt zou zijn.

Maar... ik ben dan ook geen programma schrijver...ik ben maar een "simpel" netwerkbeheerder....

[JvS]

En referenties.

[Standeman]

Ik denk dat een zo'n specifieke vraag inderdaad niet veel zin gaat hebben en dat ik 'm ook achterwege laat.
Ik hoef gelukkig ook niet te oordelen, slechts het kennis niveau in te schatten en te kijken of hij in het team past.

Mijn huidige lijstje is:

Mening over java (positief / negatief)
Welke 3rd party api's kent hij
Werkzaamheden huidige werkgever, projecten
Hobby projecten? Wat, hoe en waarom?
OO kennis (bijv. abstract classes, design patterns, etc).
Gebruikte ontwikkelmethodes (RUP / Xtreme)
Team mini casus (wat als collega X dat doet, wat doe jij).

En uiteraard overal over doorvragen.

JvS schreef op dinsdag 16 januari 2007 @ 15:43:
En referenties.

Staan al in zijn CV (en is ook niet mijn taak, mag PZ lekker gaan nabellen )

[ Voor 13% gewijzigd door Standeman op 16-01-2007 15:46 ]

[KatirZan]

JvS schreef op dinsdag 16 januari 2007 @ 15:43:
En referenties.

uiteraard ook nagaan waar het persoon hiervoor gewerkt heeft, waarom dit persoon daar weg gegaan is (of ontslagen is) (onthoudt wel, hij/zij hoeft hier geen antwoord op te geven en je kan dit persoon er ook niet toe verplichten).

[JvS]

Dat doen alle sollicitanten toch wel als je het ze vraagt.

[KatirZan]

JvS schreef op dinsdag 16 januari 2007 @ 15:51:
Dat doen alle sollicitanten toch wel als je het ze vraagt.

mits ze niet ontslagen zijn ja

[paknaald]

"Wat voor type problemen vind je lastig, maar niet onmogelijk, om uit te werken?" Een oneerlijk antwoord op zo'n vraag valt snel door de mand, denk ik. Of het is ver buiten het haalbare, of je merkt dat iemand niet weet waar hij het over heeft, of het is gewoon een eerlijk en weloverwogen antwoord. Iedere programmeur zou op deze vraag een antwoord moeten kunnen geven, vaak natuurlijk een probleem aanhalend dat hij / zij in het recente verleden succesvol getackled heeft.

[KatirZan]

paknaald schreef op dinsdag 16 januari 2007 @ 16:44:
"Wat voor type problemen vind je lastig, maar niet onmogelijk, om uit te werken?" Een oneerlijk antwoord op zo'n vraag valt snel door de mand, denk ik. Of het is ver buiten het haalbare, of je merkt dat iemand niet weet waar hij het over heeft, of het is gewoon een eerlijk en weloverwogen antwoord. Iedere programmeur zou op deze vraag een antwoord moeten kunnen geven, vaak natuurlijk een probleem aanhalend dat hij / zij in het recente verleden succesvol getackled heeft.

Is ook een erg goede inderdaad, dit stelt de sollicitant in staat een boekje over zichzelf open te doen waarbij de sollicitant ook nog moet nadenken. Op deze manier kom je er inderdaad het beste achter of hij/zij capabel genoeg is voor het bedrijf.

[Soultaker]

Standeman schreef op dinsdag 16 januari 2007 @ 15:44:
Ik denk dat een zo'n specifieke vraag inderdaad niet veel zin gaat hebben en dat ik 'm ook achterwege laat. Ik hoef gelukkig ook niet te oordelen, slechts het kennis niveau in te schatten en te kijken of hij in het team past.

Ik zou wel een paar relevante inhoudelijke vragen stellen. Verschillende mensen hebben een verschillend idee van wat 'kunnen programmeren' inhoudt; het lijkt me onverstandig om er blindelings vanuit te gaan dat zijn idee met dat van jou overeenkomt.

Je kunt dan denken aan iets als: "schrijf een functie die een string, bestaande uit woorden gescheiden door spaties, omzet in een string waarbij elke letter aan het begin van een woord een hoofdletter is, en de overige letters kleine letters zijn". Het moet iets zijn waaruit blijkt dat 'ie weet hoe 'ie een probleem moet aanpakken, waarvoor 'ie niet direct een enkele API-functie kan gebruiken, en waarvoor ook geen gedetailleerde API-kennis nodig is.

Voor een vraag als deze kun je al kijken of 'ie een StringBuffer gebruikt, of gewoon stringconcatenatie doet (inefficiënt!), en later vragen waarom 'ie daarvoor gekozen heeft. Nog een paar van die vragen en je hebt een idee of 'ie een beetje begrijpt hoe Java werkt, of dat 'ie slechts een paar trucjes kent.

[.oisyn]

paknaald schreef op dinsdag 16 januari 2007 @ 16:44:
"Wat voor type problemen vind je lastig, maar niet onmogelijk, om uit te werken?"

Wat een kutvraag (om gesteld te worden bedoel ik dan ). Ik zou niet weten wat ik hier op zou moeten antwoorden. Want is de onderkenning van een probleem niet al het grote deel van de oplossing? Of ben ik gewoon arrogant als ik van mezelf vind dat ik nooit moeite heb met een bepaald soort type probleem? Als ik dan als antwoord geef "geen idee eigenlijk", wat voor beeld geeft dit dan bij de andere partij? "Ik heb nooit last van problemen" komt ook niet erg geloofwaardig over, of getuigt iig niet echt van zelfkennis.

[ Voor 8% gewijzigd door .oisyn op 16-01-2007 17:13 ]

[Woy]

Soultaker schreef op dinsdag 16 januari 2007 @ 17:08:
[...]
Je kunt dan denken aan iets als: "schrijf een functie die een string, bestaande uit woorden gescheiden door spaties, omzet in een string waarbij elke letter aan het begin van een woord een hoofdletter is, en de overige letters kleine letters zijn". Het moet iets zijn waaruit blijkt dat 'ie weet hoe 'ie een probleem moet aanpakken, waarvoor 'ie niet direct een enkele API-functie kan gebruiken, en waarvoor ook geen gedetailleerde API-kennis nodig is.

Zoiets lijkt me inderdaad een stuk beter. Omdat het een redelijk open vraag is waar niet maar een antwoord goed is kan je hier ook een goed gesprek over houden. Juist de onderbouwing waarom hij op een bepaalde manier iets doet is interesant. API kennis en dergelijk is iets wat redelijk makkelijk aan te leren valt.

.oisyn schreef op dinsdag 16 januari 2007 @ 17:10:
[...]

Wat een kutvraag (om gesteld te worden bedoel ik dan ). Ik zou niet weten wat ik hier op zou moeten antwoorden. Want is de onderkenning van een probleem niet al het grote deel van de oplossing? Of ben ik gewoon arrogant als ik van mezelf vind dat ik nooit moeite heb met een bepaald soort type probleem? Als ik dan als antwoord geef "geen idee eigenlijk", wat voor beeld geeft dit dan bij de andere partij? "Ik heb nooit last van problemen" komt ook niet erg geloofwaardig over, of getuigt iig niet echt van zelfkennis.

Hier ben ik het wel met je eens. Ik zou ook geen goed antwoord op de vraag weten. Natuurlijk heb ik wel punten waar ik minder goed in ben, maar ik zou geen type probleem kunnen opnoemen "Wat ik net nog op kan lossen"

[Tubby]

Heb de laatste tijd hier intern ook wat af moeten nemen en een collega van mij had een goede vraag om een idee te krijgen wat zijn java kennis is:

Wat zijn de verschillen en overeenkomsten tussen final, finally en finalize?

En dan vooral de sollicitant laten vertellen

De overeenkomsten zijn overigens alleen eerste 5 characters

Het is overigens een vraag welke vooral toepasbaar is voor juniors (schoolverlaters/<2jaar ervaring) want als ik een senior (5+ jaar ervaring) voorgeschoteld is het imho beledigend om 'm te stellen als je uit de andere vragen al kan opmaken dat ie veel meer ervaren is dan dat je zelf bent (heb zelf ondertussen pas 2 jaar werkervaring met java)

En verder vooral wat-als stellingen om een idee te krijgen van zijn houding tov
- werkdruk
- support werkzaamheden
- samenwerken
- discussieren
- minder ideale oplossingen

Overigens zit er bij mij ook altijd iemand bij voor het algemene deel van het beoordelen van een persoon. Mijn taak is vooral het vak-inhoudelijke deel toetsen

[ Voor 19% gewijzigd door Tubby op 17-01-2007 08:07 ]

[Standeman]

even een update,

inmiddels is het interview afgenomen en het was redelijk duidelijk dat het om een "junior" gaat (wel een beetje maf, aangezien hij 10 jaar ouder is dan ik). Niet zo raar natuurlijk omdat hij pas 1 jaar werkervaring heeft met java. Hij heeft nog geen diepgaande kennis van bijv. de servlet api, maar weet ze wel te gebruiken.
Op zich past hij wel in het team, dus ik heb wat dat betreft wel een positief advies gegeven aan het MT.

Op zich was het wel een rare ervaring om een keer aan de andere kant van de tafel te zitten.

[KatirZan]

Standeman schreef op woensdag 17 januari 2007 @ 09:16:
even een update,

inmiddels is het interview afgenomen en het was redelijk duidelijk dat het om een "junior" gaat (wel een beetje maf, aangezien hij 10 jaar ouder is dan ik). Niet zo raar natuurlijk omdat hij pas 1 jaar werkervaring heeft met java. Hij heeft nog geen diepgaande kennis van bijv. de servlet api, maar weet ze wel te gebruiken.
Op zich past hij wel in het team, dus ik heb wat dat betreft wel een positief advies gegeven aan het MT.

Op zich was het wel een rare ervaring om een keer aan de andere kant van de tafel te zitten.

Ik vind het altijd wel een leuke ervaring ipv een rare ervaring het brengt wel wat verantwoordelijkheid met zich mee, als jij zegt dat hij het niet is, dan wordt hij het niet...en andersom

[jaaoie17]

Arnout schreef op dinsdag 16 januari 2007 @ 09:45:
Vragen naar de "minder goede kanten". Noem eens een paar.

Ik heb al meerdere keren meegemaakt dat mensen doodleuk zeiden "geen" slechte eigenschappen te hebben, ook niet na het veranderen van de vraagstelling.

dat kan toch?

[Alarmnummer]

Je zou ook gewoon een leuk gesprek met hem kunnen aangaan over techniek: kijken of de juiste vibe aanwezig is. Je merkt snel genoeg of iemand uit zijn nek loopt te lullen of niet. en ook al heeft iemand wat minder ervaring met bepaalde technieken, dat soort dingen schaaf je vrij snel bij. Je zou een paar vragen aan hem voor kunnen leggen, maar pas op dat mensen ook nerveus kunnen zijn en dan dat soort dingen verknoeien.

Zowel het sollicitatie gesprek bij mijn huidige en mijn vorige werkgever zijn op deze informele manier verlopen en dat is mij heel goed bevallen. Eventueel zou je hem nog een assessment kunnen geven om te kijken om zeker te weten dat je iemand met technische kennis hebt ipv iemand die mooie praatjes kan verkopen.

Ik zou het dus niet al te formeel doen, en niet al te veel dingen voorbereiden.

[Alarmnummer]

Soultaker schreef op dinsdag 16 januari 2007 @ 17:08:
[...]

Ik zou wel een paar relevante inhoudelijke vragen stellen. Verschillende mensen hebben een verschillend idee van wat 'kunnen programmeren' inhoudt; het lijkt me onverstandig om er blindelings vanuit te gaan dat zijn idee met dat van jou overeenkomt.

Je kunt dan denken aan iets als: "schrijf een functie die een string, bestaande uit woorden gescheiden door spaties, omzet in een string waarbij elke letter aan het begin van een woord een hoofdletter is, en de overige letters kleine letters zijn". Het moet iets zijn waaruit blijkt dat 'ie weet hoe 'ie een probleem moet aanpakken, waarvoor 'ie niet direct een enkele API-functie kan gebruiken, en waarvoor ook geen gedetailleerde API-kennis nodig is.

Voor een vraag als deze kun je al kijken of 'ie een StringBuffer gebruikt, of gewoon stringconcatenatie doet (inefficiënt!), en later vragen waarom 'ie daarvoor gekozen heeft. Nog een paar van die vragen en je hebt een idee of 'ie een beetje begrijpt hoe Java werkt, of dat 'ie slechts een paar trucjes kent.

Op het moment dat ik dit soort dingen op een gesprek zou krijgen zou ik direct vertrekken. Iets meer diepgang mag wel. Op het moment dat een bedrijf op dit nivo naar mensen gaat kijken, dan weet ik dat dit niet een goed bedrijf (voor mij) is.

Dus niet vragen naar kleine technische trivialiteiten. Als het een Java Enterprise programmeur is zou ik hem vooral vragen naar ervaring met api's. Kijken hoe api's/concepten aan elkaar gerelateerd zijn. JSF vs Wicket vs Presentation Layer... Hibernate vs IBatis vs JDBC vs OR-Mapping.

Kijken of hij genoeg ervaring heeft om in te zien dat verschillende technieken belangrijk zijn, en wanneer bepaalde technieken een voorkeur hebben boven andere. Maar als de persoon in een kwestie nog maar een jaar Java ervaring heeft, denk ik niet dat hij in staat is om antwoorden te geven op dit soort vragen. Uiteraard hoeft iemand niet de details overal te van weten, daarvoor bestaat documentatie. Maar ik vind het wel interessant om te zien hoe iemand zijn 'mindmap' van technieken eruit ziet. Deze mindmap laat imho veel belangrijkere informatie zien. En verder zijn proces gerelateerde vragen ook belangrijk: zorg ervoor dat je iemand hebt die ervaring heeft met een goed proces, of die willing is om een goed proces onder de knie te krijgen. Mensen die niet bereid zijn om te veranderen die zijn wellicht minder interessant voor een bedrijf.

Eventueel is het ook interessant zijn of hij ergens bepaalde visies over heeft: hoe denk je dat EJB over 5 jaar eruit ziet.. noem maar iets.. Leg de bal misschien bij hem neer.. laat hem wat tooling uitkiezen (waar hij misschien veel mee bezig is) over wat zijn ideeën zijn. Hoe zou het verbeterd kunnen worden? Wat zijn de goeie dingen? Hoe zie jij dit product over een aantal jaar? Dat laat zien dat iemand in staat is om verder te denken dan alleen de directe toepassing van een bepaalde techniek.

[ Voor 36% gewijzigd door Alarmnummer op 17-01-2007 12:53 ]

[Janoz]

jaaoie17 schreef op woensdag 17 januari 2007 @ 11:32:
[...]


dat kan toch?

Ja, maar geeft wel aan dat de kandidaat niet aan zelfreflectie doet, zichzelf dus blijkbaar nog nooit een spiegel voorgehouden heeft. Niemand is perfect, maar weten waar je eigen imperfecties liggen zorgt wel dat je daar dichter bij komt. Men zegt niet voor niks 'de slimste mensen zijn degenen die weten hoe dom ze zijn'.

[Iblies]

Als je geen slechte eigenschappen hebt ben je vrijwel zeker afgeschreven.
Ook al denk je dat je die niet hebt,
dan geef je aan dat je slecht tegen drank kunt of iets dergelijks of iets wat je irriteert. Op internet staan een heel scala aan voorbeelden wat voor slechte eigenschappen je kunt hebben.

Wat betreft TS,
heb je bij je meerdere nagevraagd wat precies van een sollicitant verwacht wordt en waarom deze persoon moet worden aangenomen? Je geeft nu een positief advies, maar waarom eigenlijk? Heeft hij als hij wordt aangenomen tijd nodig om te worden ingewerkt,
moet hij niet alleen worden bijgespijkerd op bedrijfsniveau maar is het misschien nodig om ook extern wat extra scholing te geven omdat de kennis dermate tekortschiet dat je dit intern niet kunt oplossen,
etc etc.

Ook gelijk doorgeven aan het management dat het gesprek goed verliep maar dat zijn skills als junior moeten worden bestempeld ipv positief. Jouw oordeel maakt je in principe mede-verantwoordelijk, en aangezien het hier ging om een stukje waar het daadwerkelijk om draait,
kan de jongen programmeren of niet, kan er wel eens veel waarde aan jouw oordeel worden gehecht.

[Standeman]

Iblies schreef op woensdag 17 januari 2007 @ 15:56:
Als je geen slechte eigenschappen hebt ben je vrijwel zeker afgeschreven.
Ook al denk je dat je die niet hebt,
dan geef je aan dat je slecht tegen drank kunt of iets dergelijks of iets wat je irriteert. Op internet staan een heel scala aan voorbeelden wat voor slechte eigenschappen je kunt hebben.

Wat betreft TS,
heb je bij je meerdere nagevraagd wat precies van een sollicitant verwacht wordt en waarom deze persoon moet worden aangenomen? Je geeft nu een positief advies, maar waarom eigenlijk? Heeft hij als hij wordt aangenomen tijd nodig om te worden ingewerkt,
moet hij niet alleen worden bijgespijkerd op bedrijfsniveau maar is het misschien nodig om ook extern wat extra scholing te geven omdat de kennis dermate tekortschiet dat je dit intern niet kunt oplossen,
etc etc.

Ook gelijk doorgeven aan het management dat het gesprek goed verliep maar dat zijn skills als junior moeten worden bestempeld ipv positief. Jouw oordeel maakt je in principe mede-verantwoordelijk, en aangezien het hier ging om een stukje waar het daadwerkelijk om draait,
kan de jongen programmeren of niet, kan er wel eens veel waarde aan jouw oordeel worden gehecht.

*kickje*

Ik heb een positief beoordeeld wat betreft inpassing in het team, ik vond het namelijk wel een aardige en spontane vent. Dat is en blijft toch altijd een gevoels kwestie gebaseerd op een paar "wat zou je doen als" vragen. Verder heb ik een inschatting gemaakt van zijn kennisniveau (~x% van collega y).
Ik heb ze niet verteld dat hij aangenomen moet worden en dat zou ik ook nooit doen (kijk wel uit).

Maar goed, straks weer een andere sollicitant.. Ben benieuwd.. CV ziet er wel goed uit.

[flowerp]

Alarmnummer schreef op woensdag 17 januari 2007 @ 12:40:
Je zou ook gewoon een leuk gesprek met hem kunnen aangaan over techniek: kijken of de juiste vibe aanwezig is..

Dat probeer ik zelf ook te doen. Ik heb wel een hele reeks vragen, maar ik zeg altijd duidelijk erbij dat het niet direct om goed/fout gaat, maar dat de vragen zijn bedoeld als uitgangspunt voor een discussie.

Bijvoorbeeld, de vraag die ik dan eerst stel is of de kandidaat weet aan welke eisen een Object in Java (of andere taal) moet voldoen om als key te kunnen dienen in een HashMap. Het zou heel goed kunnen dat iemand niet weet om welke 2 specificieke methoden het gaat, gewoon omdat iemand altijd standaard types als keys heeft gebruikt. Ik vraag dan door of iemand kan beredeneren wat het mogelijk zou kunnen zijn.

Op de manier waarop iemand antwoord kun je dan weer afleiden of iemand uberhaupt weet hoe een HashMap werkt. Mocht de term Hashcode vallen, dan vraag ik of ie ongeveer kan schetsen hoe een algoritme dat voor een goede distributie over de buckets zorgt eruit zou kunnen zien.

Natuurlijk weet lang niet iedereen dit, en het is ook zeker niet de bedoeling dat iemand dit perse weet (ik heb het zelf wel ooit gedaan, maar zou het nu ook niet zo 1,2,3 snel kunnen zeggen), maar -als- de persoon hier een redelijk antwoord op geeft, dan weet je dat het iemand is die goed kan nadenken over algoritmen.

Als de persoon wat dingen over de HashMap heeft verteld, vraag ik dan weer of het de meest ideale structuur is in alle gevallen. Mischien vertelt ie nu wat over index tables, die sneller kunnen zijn als je key een integer is, of iets over cache locality, waarna ik dan weer op die dingen probeer in te haken. Etc etc...

Mocht het gesprek doodlopen, omdat de kandidaat niets meer weet over het huidige onderwerp, dan ga ik naar m'n volgende vraag op de lijst.

De laatste tijd heb ik echter minder succes met deze aanpak. De kandidaten die langskomen (en dat zijn er tegenwoordig bedroevend weinig) kunnen eigenlijk helemaal nergens over mee praten.

Alle onderwerpen die ik probeer lopen meteen dood omdat de kandidaat telkens meteen al de hele verkeerde richting op gaat. Ik probeer te ontdekken of iemand iets weet van hoe dingen werken, maar van de mensen die wij kregen lijkt niemand zich hier mee bezig te houden.