Oplossend vermogen als programmeur

[TheFrames]

Dit is een vervolg op een vorige topic. Ik heb recentelijk twee game-based assessments gemaakt waarop ik laag scoorde op oplossend vermogen.

Ik ben meer een trial-and-error persoon. Het lukt wel, maar pas door het grondig te onderzoeken en verschillende toepassingen erop los te laten.

Ik ben altijd een beetje sceptisch met dit soort testen, omdat deze niet code gerelateerd zijn waarbij ik algoritmische problemen moet oplossen.

Maar blijkbaar heb ik een laag oplossend vermogen en dat is nou waar het hele programmeren om draait.

Ik vind het leuk en dat maakt het al goed en natuurlijk zijn deze vaardigheden te trainen.

Maar dan ga ik dus nu aan mezelf twijfelen of ik wel voor de juiste professie heb gekozen, ondanks een HBO-ICT diploma richting software engineering op zak te hebben.

Zal dit later een barrière in mijn carrière vormen? (Heeuhh, dat rijmt )

Opmerking: Volgens mij stel ik teveel vragen op dit forum, klopt dat? Vertel het maar als ik moet minderen.

[CVTTPD2DQ]

Oh man. Er loopt al een hele discussie over de zin en onzin van assessments in het Recruiters en HR topic. Tenzij je van zelfkwelling houdt zou ik die niet teruglezen, maar het komt er op neer: bewijs dat ze werken is er niet.

De mensen tegenover jou zitten in de situatie dat ze zich binnen een uur een mening moeten vormen over hoe jij, als persoon, binnen hun organisatie gaat functioneren.

Dat kunnen ze niet, en dat kan eigenlijk niemand.

En dus wordt de beslissing meestal overgelaten aan de mensen die zichzelf voor de gek kunnen houden dat ze dat wél kunnen.

En meestal is dat een excuus voor de meest middelmatige mensen om hun meest idiote theoriën de vrije loop te laten. Alles van de opmaak van het CV tot de kracht van de handdruk wordt een relevant feitje in hun ogen.

Een assessment is dan verhoudingsgewijs nog "objectief". Er zijn volwassen mensen die het met een stalen gezicht op "intuitie" gooien.

En jij zit op het moment aan de andere kant van de tafel van dit soort figuren.

Je hebt recent een vier-jarig assessment afgerond dat specifiek gericht is op je Software Engineering vaardigheden. Daarbij is over een langere periode gekeken naar je prestaties, inclusief opdrachten in groepsverband die werk op een kantoor nabootsten. Inclusief stages van meerdere maanden waarin je in een bedrijfssetting hebt moeten functioneren.

In een rationele wereld zou een diploma meer gewicht in de schaal moeten leggen dan een assessment. Maar het bedrijfsleven is helaas alles behalve rationeel.

[wiemelen]

TheFrames schreef op vrijdag 22 september 2023 @ 02:14:
Ik heb recentelijk twee game-based assessments gemaakt waarop ik laag scoorde op oplossend vermogen.

Ik ben meer een trial-and-error persoon. Het lukt wel, maar pas door het grondig te onderzoeken en verschillende toepassingen erop los te laten.

Zodra je met nieuwe functionaliteit, software of processen aan de slag gaat, is er veel trial & error werk bij.
Zelfs de beste cursussen, help pagina's, blogs en google zoekopdrachten leveren je niet altijd het juiste antwoord op. Zeker als je aan het pionieren bent met nieuwe/nieuwste versie van software.
Als je dan een junior profiel hebt, ben je vaak aangewezen op trial & error of een senior collega (als je die hebt en als die uberhaupt al meer weet dan jou). Belangrijk hierbij is wel dat je een mooi oplopende leercurve hebt zodat je na verloop een mooi pakketje baggage hebt waaruit je kan putten.

Maar blijkbaar heb ik een laag oplossend vermogen en dat is nou waar het hele programmeren om draait.

Ik vind het leuk en dat maakt het al goed en natuurlijk zijn deze vaardigheden te trainen.

Maar dan ga ik dus nu aan mezelf twijfelen of ik wel voor de juiste professie heb gekozen, ondanks een HBO-ICT diploma richting software engineering op zak te hebben.

Of oplossend vermogen is waar programmeren om draait is puur theorie
Ja, het is mooi meegenomen als je het kan, maar naar mijn mening heb je 3 soorten programmeurs/functies profielen waar naar gezocht wordt:
1) Programmeurs die maar 2 woorden nodig hebben om een hele analyse en applicatie zelfstandig te bouwen.
2) Programmeurs die je in detail moet uitleggen wat ze moeten gaan bouwen en niet kunnen/willen/mogen meedenken.
3) Programmeurs die ergens tussen 1 en 2 in zitten.

In mijn ervaring heb je :
Type 1 : zo zijn er altijd enkele op een project, maar die hebben vaak best al wat ervaring.
Dit zijn ook de profielen die je absoluut aan je bedrijf/project wil binden.
In sommige gevallen is het ook wel nodig hun enthousiasme en ambitie te temperen
Type 2 : kom je vaak tegen bij outsourcing naar verre landen, maar eigenlijk wil je dit type liever vermijden.
Type 3 : De meerderheid van programmeurs. Kunnen een stukje programmeren en zorgen dat alles blijft
draaien. Afhankelijk van de combinatie ervaring, functie profiel en leercurve zitten ze perfect op
hun plek in een organisatie of wil je ze zo snel mogelijk kwijt.


Dus vooral je eigen ding blijven doen, leergierig blijven en aan je leercurve werken, dan vind je vast wel de juiste plek in een organisatie.

[Mavamaarten]

Oplossend vermogen is heel belangrijk. Maar hoe je een probleem oplost kan op verschillende manieren. Trial and error is er daar een van, maar je moet natuurlijk wel snappen wat er gebeurt en waarom je oplossing werkt. Een oplossing waarvan je niet weet waarom deze werkt, kan perfect om de verkeerde reden werken, met een niet-onderhoudbare toekomst voor je codebase tot gevolg.

Dat komt met de jaren ook wel vanzelf, je zal zo merken dat je onderbuikgevoel begint te kweken voor "daar zit het probleem" en op dat punt is de grens tussen trial en error en het weten kleiner.

Dat gezegd zijnde, imo is het belangrijkste van een programmeur-collega de mindset. De juiste vragen stellen, niet te veel assumpties maken, nauwkeurig en niet slordig zijn. En de drive om zelfstandig dingen te doen zonder iemand die micromanagement-gewijs aanstuurt is misschien nog belangrijker.

Het is goed dat je je hiervan bewust bent, maar neem het met een korrel zout. Zo'n test hoeft voor je carriere niets te betekenen. Als je het graag doet, dan zit je goed

[mannowlahn]

TheFrames schreef op vrijdag 22 september 2023 @ 02:14:
Dit is een vervolg op een vorige topic. Ik heb recentelijk twee game-based assessments gemaakt waarop ik laag scoorde op oplossend vermogen.

Ik ben meer een trial-and-error persoon. Het lukt wel, maar pas door het grondig te onderzoeken en verschillende toepassingen erop los te laten.

Ik ben altijd een beetje sceptisch met dit soort testen, omdat deze niet code gerelateerd zijn waarbij ik algoritmische problemen moet oplossen.

Maar blijkbaar heb ik een laag oplossend vermogen en dat is nou waar het hele programmeren om draait.

Ik vind het leuk en dat maakt het al goed en natuurlijk zijn deze vaardigheden te trainen.

Maar dan ga ik dus nu aan mezelf twijfelen of ik wel voor de juiste professie heb gekozen, ondanks een HBO-ICT diploma richting software engineering op zak te hebben.

Zal dit later een barrière in mijn carrière vormen? (Heeuhh, dat rijmt )

Opmerking: Volgens mij stel ik teveel vragen op dit forum, klopt dat? Vertel het maar als ik moet minderen.

Ik heb ooit een assessment moeten doen voor een partij. Ik heb zonder voorbereiding, dat is mijn persoonlijke eigenschap, meteen de test gedaan. Ik scoorde een 1 op een schaal van 10 , je kan prima stellen dat ik tegen het geretardeerde denkvermogen aan zat. Nadien wel gewoon als freelancer aan de bak gekomen en nog steeds met veel succes.

Ik was al jaren werkzaam als developer en tegenwoordig als azure architect. Ik weet ook dat je mij geen algoritmes moet laten maken, dat is niet mijn sterkste kant. Ik heb ook trial en error nodig. Uiteindelijk gaat het om de oplossing naar mijn inziens. Maar sommige banen vereisen een iets ander denkvermogen. Dat s prima, die zijn niet aan mij besteed en daar kan ik mee leven.

Maar assessments doen zal niet in mijn voordeel spreken Til er niet te zwaar aan.

[TheWalrus]

Ik was ook een trail and Error persoon. Maar door ervaring ben ik nu veel meer een oplossend persoon. Waarom, omdat ik door ervaringen dingen erken en herken. Grote monden willen weleens hun maniertje door drammen, maar meestal eindig het voor mij als een "told you so" richting die grote monden.

[ Voor 5% gewijzigd door TheWalrus op 22-09-2023 10:28 ]

[Rukapul]

Tja, wat is oplossend vermogen?

Enerzijds heb je de aanpak: analytisch, trial and error, intuitief/ervaring, etc.
Anderzijds heb je vaardigheden: algoritmiek, engineering, architectuur, testen, etc.

Welke van bovenstaande combinaties is getest, hoe scoor je op elk, en waar kun je jezelf positioneren voor een succesvolle werkinvulling?

Met 'trial and error' moet je wel uitkijken. Het schaalt namelijk niet en leidt tot suboptimale oplossingen indien onvoldoende kritisch.

[TheFrames]

Rukapul schreef op vrijdag 22 september 2023 @ 10:39:
Tja, wat is oplossend vermogen?

Enerzijds heb je de aanpak: analytisch, trial and error, intuitief/ervaring, etc.
Anderzijds heb je vaardigheden: algoritmiek, engineering, architectuur, testen, etc.

Welke van bovenstaande combinaties is getest, hoe scoor je op elk, en waar kun je jezelf positioneren voor een succesvolle werkinvulling?

Met 'trial and error' moet je wel uitkijken. Het schaalt namelijk niet en leidt tot suboptimale oplossingen indien onvoldoende kritisch.

Ja,wat ik vaak bij mezelf merk, is dat ik echt goed verschillende paden visueel moet uitdenken en de problemen goed moet opdelen in kleinere stukken. Ik ben echt visueel gericht, dus ik moet deze plannen goed uittekenen.

Vaak probeer ik dan iets -> Bekijk het resultaat -> Vanaf daar verder gaan.

Maar op den duur hoop ik natuurlijk van: Ah, dat is het probleem, dit is het pad die ik moet afleggen. Je probeert dan iets wel alleen, waar eerder 50 mogelijkheden voor waren, doe je het in 1 - 5 pogingen.

Dat komt dan door oefening en ervaring. Vaak lijken problemen erg op elkaar of heb je deze al eerder getackled, waardoor het oplossen soepeler verloopt.

Wat ik nu aan het doen ben, is dagelijks een Leetcode probleem aan het oplossen en mijn algoritme en datastructuren kennis aan het opfrissen.

Algoritmisch denken is waar ik vaak de mist in ga en dat was vooraf die testjes ook zo. Vaak ben ik deze complexiteit nog niet tegengekomen in werkzaamheden als front-end en backend. Iedereen kan makkelijk een Express.JS service met REST API endpoints opzetten. Ik moet zeggen dat ik het daar nooit nodig voor heb gehad.

[olafmol]

Er zijn 1000 wegen naar Rome. Waar het uiteindelijk allemaal om draait (ook voor een werkgever): kun jij een vraagstuk (probleem) voldoende analyseren en begrijpen, om binnen de constraints (vaak van tijd) met een acceptabele oplossing te komen?

Maw heb je voldoende communicatieve en analytische vaardigheden om "de vraag achter de vraag" boven water te krijgen, kun je vervolgens in een realistische tijd de boel in stukjes hakken, en voor elk van de subproblemen een oplossing ontwikkelen, die dan weer met elkaar samenwerkend een goed werkend geheel vormen. Jouw hamer is in dit geval programmeercode.

Of je dat nu met tekeningen doet, met veel praten, met prototyping etc, maakt uiteindelijk niet uit, als er maar iets uitkomt dat een oplossing is voor het originele vraagstuk.

Als je hier erg onzeker over bent, je hebt je studie gehaald, dat is een teken dat je afdoende skills hebt om dit te kunnen. Nu moet je nog laten zien aan "de markt" dat je op bovenstaande wijze kunt (samen)werken.

Vraag bv om een programmeeropdracht die je op locatie dan in bv 1 dag of een paar uurtjes kunt gaan oplossen, op jouw eigen unieke manier. Daarmee krijg jezelf, en de werkgever, een goed beeld over hoe je werkt en wat je kunt.

[Kheos]

probleemoplossend vermogen is natuurlijk niet zozeer 'kun je dat probleem oplossen' maar vooral hoe.
Hoe ga je te werk? google je de foutmelding? doorpluis je de logfiles? probeer je het probleem te simuleren? deel je het probleem op in deelproblemen? of probeer je maar wat tot je een andere foutmelding krijgt?

[eric.1]

Ligt ook volstrekt aan hoe die assessments het samenvatten.

Je hebt van die assessments die perse iets werkend moeten zien (het liefst van die standaard dingen als vage algoritmes gebruiken) en automatisch een score uitspugen. Het moet binnen een tijdslimiet uitvoerbaar zijn, zo min mogelijk iteraties bevatten enz. Heb ik een hekel aan, ben ik persoonlijk ook niet erg sterk in.

Maar je hebt ook assessments waar je een stuk code, of eigenlijk meer een concept, uitwerkt om een probleem op te lossen en samen met een technisch onderlegd persoon het doorneemt om je process erachter te doorgronden. Dus waarom heb je X gedaan, wat zou je doen als ik nu Y verander, er zit een bug in..hoe zou je het aanpakken om dit op te lossen enz.

Ik vermoed dat zo'n tweede vorm dan geen probleem zou zijn voor jou. Persoonlijk ken ik maar weinig mensen die direct een ideale oplossing uit hun mouw schudden, laat staan als beginnend programmeur (denk ik).

[jbdeiman]

Ik heb dit in het topic over de zin en onzin van assessments ook wel eens aangegeven, wij doen ook wel een soort van opdracht (assessment) niet met het doel dat iemand in een kort tijdsbestek iets afmaakt, maar met als doel te zien hoe iemand te werk gaat.
De voorkeur gaat uit naar mensen waarbij je ziet dat die volgens een structuur werken (op z'n boeren verstands, eerst denken dan doen). We hebben daarbij kandidaten gehad die gelijk al de ontwikkelomgeving pakten en driftig begonnen te bouwen, maar de voorkeur gaat uit naar kandidaten die (kritische) vragen over het probleem stellen en die eigenlijk eerst een plannetje maken.

Simpel gezegd:
Trial en error kan wel, als je weet wat er van je gevraagd wordt en hoe je dat (ongeveer) denkt te bereiken. Dat wordt vanzelf beter, maar als je niet weet wat je wilt/ moet bereiken kan je er beter niet aan beginnen want dan weet je bij voorbaat al dat je waarschijnlijk niet op de juiste uitkomst komt.

We hebben daarom bij het assesment bewust ervoor gekozen een paar (essentiele) zaken open te laten en indien een kandidaat de (juiste) kritische vragen weet te stellen, laten we deze vaak niet eens meer programmeren. (Reden is omdat we in een eerste/ 2e gesprek ook de kandidaat vragen voorbeelden van zijn/ haar werk aan te leveren (geen complete software, maar stukken code die ze hebben gemaakt) waarover ze uit moeten leggen wat het doet, waarom ze bepaalde keuzes gemaakt hebben. Daar pik je gauw genoeg uit of iemand weet wat die (qua programmeren) aan het doen is.

[TheFrames]

Kheos schreef op vrijdag 22 september 2023 @ 13:03:
probleemoplossend vermogen is natuurlijk niet zozeer 'kun je dat probleem oplossen' maar vooral hoe.
Hoe ga je te werk? google je de foutmelding? doorpluis je de logfiles? probeer je het probleem te simuleren? deel je het probleem op in deelproblemen? of probeer je maar wat tot je een andere foutmelding krijgt?

Meestal een analyse van het probleem. Opdelen in sub problemen. Google altijd. Logs en foutmeldingen bekijken. Zelf debuggen. Nadat een oplossing bedenken en implementeren. Als laatste daarna verder kijken.

[TheFrames]

eric.1 schreef op vrijdag 22 september 2023 @ 13:13:
Ligt ook volstrekt aan hoe die assessments het samenvatten.

Je hebt van die assessments die perse iets werkend moeten zien (het liefst van die standaard dingen als vage algoritmes gebruiken) en automatisch een score uitspugen. Het moet binnen een tijdslimiet uitvoerbaar zijn, zo min mogelijk iteraties bevatten enz. Heb ik een hekel aan, ben ik persoonlijk ook niet erg sterk in.

Maar je hebt ook assessments waar je een stuk code, of eigenlijk meer een concept, uitwerkt om een probleem op te lossen en samen met een technisch onderlegd persoon het doorneemt om je process erachter te doorgronden. Dus waarom heb je X gedaan, wat zou je doen als ik nu Y verander, er zit een bug in..hoe zou je het aanpakken om dit op te lossen enz.

Ik vermoed dat zo'n tweede vorm dan geen probleem zou zijn voor jou. Persoonlijk ken ik maar weinig mensen die direct een ideale oplossing uit hun mouw schudden, laat staan als beginnend programmeur (denk ik).

Het waren assessments zonder code.

[ Voor 70% gewijzigd door TheFrames op 22-09-2023 13:18 ]

[eric.1]

TheFrames schreef op vrijdag 22 september 2023 @ 13:16:
[...]


Het waren assessments zonder code.

Ah ok, nouja, eigenlijk geldt voor die assessments hetzelfde. Het kan indicatief zijn, maar als de vorm van vraagstelling (om maar iets te noemen) je niet ligt dan scoor je logischerwijs lager. Dit hoeft niet direct iets te zeggen over jou als programmeur, al is een degelijk analytisch vermogen natuurlijk wel de basis.

Je kan online wel her en der oefenen trouwens. Dat kan wellicht helpen om die initiële horde te overbruggen om uiteindelijk bij een techneut aan tafel te kunnen schuiven voor een gesprek.

[Lethalis]

TheFrames schreef op vrijdag 22 september 2023 @ 02:14:
Dit is een vervolg op een vorige topic. Ik heb recentelijk twee game-based assessments gemaakt waarop ik laag scoorde op oplossend vermogen.

Ik werk al ruim 20 jaar als programmeur en ik heb nog nooit zo'n test gedaan.

Waar kan ik hem doen? Ik ben benieuwd

[Kheos]

Lethalis schreef op vrijdag 22 september 2023 @ 13:59:
[...]

Ik werk al ruim 20 jaar als programmeur en ik heb nog nooit zo'n test gedaan.

Waar kan ik hem doen? Ik ben benieuwd

De test is al begonnen en hem vinden was er een onderdeel van. Tot hiertoe doe je het niet zo goed.

[Bender]

Kanttekening: Ik weet niet zeker of ik je vraag goed begrijp, dus wellicht interpreteer ik het niet goed.

Ik merk bij veel programmeurs dat ze wel goed in staat zijn opdrachten uit te voeren, maar niet om oplossingen te bedenken.
Veel denken dat code een oplossing is, maar code is enkel een middel in het te behalen doel.

Wellicht wordt in de vraagstelling gekeken of je in staat bent een vraagstuk van een klant om te zetten naar een oplossing, in plaats van het uitvoeren van een codeopdracht (want een klant geeft geen code opdrachten).

[ Voor 6% gewijzigd door Bender op 22-09-2023 14:58 ]

[TheFrames]

Lethalis schreef op vrijdag 22 september 2023 @ 13:59:
[...]

Ik werk al ruim 20 jaar als programmeur en ik heb nog nooit zo'n test gedaan.

Waar kan ik hem doen? Ik ben benieuwd

Uhh... dat was in de tijden waar het internet nogal primitief was en wat nu is, zal in de toekomst ook primitief zijn.

[ Voor 26% gewijzigd door TheFrames op 22-09-2023 15:14 ]

[Lethalis]

Kheos schreef op vrijdag 22 september 2023 @ 14:48:
[...]
De test is al begonnen en hem vinden was er een onderdeel van. Tot hiertoe doe je het niet zo goed.

Verdorie

[Napo]

Kheos schreef op vrijdag 22 september 2023 @ 14:48:
[...]

De test is al begonnen en hem vinden was er een onderdeel van. Tot hiertoe doe je het niet zo goed.

Of juist wel als de test een red herring is.

[CodeCaster]

Bender schreef op vrijdag 22 september 2023 @ 14:57:
Kanttekening: Ik weet niet zeker of ik je vraag goed begrijp, dus wellicht interpreteer ik het niet goed.

Ik merk bij veel programmeurs dat ze wel goed in staat zijn opdrachten uit te voeren, maar niet om oplossingen te bedenken.
Veel denken dat code een oplossing is, maar code is enkel een middel in het te behalen doel.

Wellicht wordt in de vraagstelling gekeken of je in staat bent een vraagstuk van een klant om te zetten naar een oplossing, in plaats van het uitvoeren van een codeopdracht (want een klant geeft geen code opdrachten).

Dit klinkt echt als Jos Hoeheetdie, die een borenverkoper vertelt dat zijn klanten geen boortjes willen, maar gaten.

[mind blown.gifv]

Als je een assessment doet voor een developer-rol, dan heeft de potentiële werkgever al een gebrek aan developers geconstateerd. Je bent dan niet op de plek om klanten te gaan vertellen dat ze helemaal geen code nodig hebben.

[Paprika]

TheFrames schreef op vrijdag 22 september 2023 @ 12:16:
[...]
Wat ik nu aan het doen ben, is dagelijks een Leetcode probleem aan het oplossen en mijn algoritme en datastructuren kennis aan het opfrissen.

Algoritmisch denken is waar ik vaak de mist in ga en dat was vooraf die testjes ook zo. Vaak ben ik deze complexiteit nog niet tegengekomen in werkzaamheden als front-end en backend. Iedereen kan makkelijk een Express.JS service met REST API endpoints opzetten. Ik moet zeggen dat ik het daar nooit nodig voor heb gehad.

Dergelijke vraagstukken ga je ook sneller tegenkomen wanneer je aan de backend werkt van een recommendatie service (Amazon, Netflix, Spotify, Algolia Recommend etc). Wanneer je alle ontwikkelaars wereldwijd zou nemen, dan zou het percentage van deze groep dat dergelijke scenarios met regelmaat (tot dagelijks) in zijn of haar werk tegen zal komen op 1 hand te tellen, vooral als je de groep beperkt tot waar de kleinste optimalisaties een impact zouden hebben.

[Bender]

CodeCaster schreef op vrijdag 22 september 2023 @ 17:42:
[...]
Als je een assessment doet voor een developer-rol, dan heeft de potentiële werkgever al een gebrek aan developers geconstateerd. Je bent dan niet op de plek om klanten te gaan vertellen dat ze helemaal geen code nodig hebben.

Dat ligt er aan wat voor developer je wil zijn.

Ben je een developer die alles aangereikt moet krijgen op welke manier iets gemaakt moet worden en met welke tools.
Of ben je een developer die zelf kan bedenken op welke manier het gedaan kan worden en welke tools het meest efficient zijn.

Ik ken niet veel organisaties die nog zitten te wachten op de eerste, alleen degene die nog ruimte hebben voor junioren.

[ Voor 11% gewijzigd door Bender op 22-09-2023 18:03 ]

[CodeCaster]

Bender schreef op vrijdag 22 september 2023 @ 18:02:
[...]


Dat ligt er aan wat voor developer je wil zijn.

Ben je een developer die alles aangereikt moet krijgen op welke manier iets gemaakt moet worden en met welke tools.
Of ben je een developer die zelf kan bedenken op welke manier het gedaan kan worden en welke tools het meest efficient zijn.

De eerste is een junior, de tweede mag je van een medior verwachten.
Maar binnen een bedrijf heb je niet veel aan alleen maar junioren.

Of ze komen er dankzij jouw input achter dat ze eigenlijk een kaasfabriek hadden willen zijn.

Nogmaals: als je ergens een assessment zit te doen voor een developer-rol waarop je hebt gesolliciteerd, dan is men op zoek naar een developer, en niet naar iemand die ze komt vertellen dat ze helemaal geen developers nodig hebben.

Dat staat verder los van het feit dat 80% van de developers simpele CRUD-applicaties zit te bouwen omdat sales aan de klant heeft verkocht dat men een CRUD-applicatie nodig heeft, hoeveel toeters en bellen je er ook omheen hangt, of van het niveauverschil tussen developers of van het feit dat inderdaad, als je een aap (developer) een hamer (code) geeft, dat elk probleem eruitziet als een spijker.

[ Voor 18% gewijzigd door CodeCaster op 22-09-2023 18:05 ]

[Bender]

CodeCaster schreef op vrijdag 22 september 2023 @ 18:04:
[...]als je ergens een assessment zit te doen voor een developer-rol waarop je hebt gesolliciteerd, dan is men op zoek naar een developer, en niet naar iemand die ze komt vertellen dat ze helemaal geen developers nodig hebben.

Wie zegt dat dan?

CodeCaster schreef op vrijdag 22 september 2023 @ 18:04:
[...]

Dat staat verder los van het feit dat 80% van de developers simpele CRUD-applicaties zit te bouwen omdat sales aan de klant heeft verkocht dat men een CRUD-applicatie nodig heeft, hoeveel toeters en bellen je er ook omheen hangt, of van het niveauverschil tussen developers of van het feit dat inderdaad, als je een aap (developer) een hamer (code) geeft, dat elk probleem eruitziet als een spijker.

Sorry, maar ik denk dat je echt nogal onderschat wat een software developer doet en wat er allemaal 'gedevelopped' wordt.

[CodeCaster]

Bender schreef op vrijdag 22 september 2023 @ 18:29:
[...]


Wie zegt dat dan?

Sorry, ik probeer op een grappige manier de open deur die jij hier opentrapt weer een beetje dicht te doen.

Jij zegt dat je bij veel ^{[definitie vereist]} developers merkt dat ze nogal snel naar code grijpen om een bepaald probleem op te lossen. Dat lijkt me logisch, met name voor junioren, waar TS onder valt.

Nogmaals, jij zegt:

Wellicht wordt in de vraagstelling gekeken of je in staat bent een vraagstuk van een klant om te zetten naar een oplossing

Voor de gemiddelde developer is, op het moment dat die klantvraag op diens bord komt, die vraag al vertaald naar een wens om code.

Sorry, maar ik denk dat je echt nogal onderschat wat een software developer doet en wat er allemaal 'gedevelopped' wordt.

Ik denk dat jij overschat waar de meeste mensen aan werken. Waar denk je dan dat de gemiddelde self-taught, mbo'er en hbo'er terechtkomt? Die gaan grotendeels werken aan CRM, ERP, webshops, portfoliosites, apps die een website "native" beschikbaar maken; grid/CRUD-systemen om regels in databases te bewerken, if that.

[CVTTPD2DQ]

TheFrames schreef op vrijdag 22 september 2023 @ 12:16:
Algoritmisch denken is waar ik vaak de mist in ga en dat was vooraf die testjes ook zo. Vaak ben ik deze complexiteit nog niet tegengekomen in werkzaamheden als front-end en backend. Iedereen kan makkelijk een Express.JS service met REST API endpoints opzetten. Ik moet zeggen dat ik het daar nooit nodig voor heb gehad.

Het komt voor, maar dan is het vrijwel nooit zo dat je gevraagd wordt om een algoritme uit je hoofd op een whiteboard te schrijven. Meestal heb je gewoon alle tijd om een nette oplossing op te zoeken en te implementeren.

[mannowlahn]

Bender schreef op vrijdag 22 september 2023 @ 18:29:
[...]


Wie zegt dat dan?


[...]


Sorry, maar ik denk dat je echt nogal onderschat wat een software developer doet en wat er allemaal 'gedevelopped' wordt.

Wel nee joh simpele data mappings etc, het is vaak echt geen hogere wiskunde en veel repeteer werk. Niks mis mee hè. Er komt meer bij kijken, pipelinetje daar, dashboard hier, wat alerting inregelen bla bla bla, maar het gros is echt niet next level aan het devven. Zolang je dat prima vind is dat ook niet erg. Na verloop van tijd denk je, is dit alles en dan ga je richting bv devops of architectuur. Who knows, ga je aan product ownerships proeven. Maar meerendeel van devven is idd gewoon crudjes.

[TheFrames]

Paprika schreef op vrijdag 22 september 2023 @ 17:55:
[...]

Dergelijke vraagstukken ga je ook sneller tegenkomen wanneer je aan de backend werkt van een recommendatie service (Amazon, Netflix, Spotify, Algolia Recommend etc). Wanneer je alle ontwikkelaars wereldwijd zou nemen, dan zou het percentage van deze groep dat dergelijke scenarios met regelmaat (tot dagelijks) in zijn of haar werk tegen zal komen op 1 hand te tellen, vooral als je de groep beperkt tot waar de kleinste optimalisaties een impact zouden hebben.

Ja, dan heb je het over grote en complexe systemen waar code meer impact heeft dan de gemiddelde bedrijven met een SaaS-oplossing. Dat laatste is vaak CRUD-apps bouwen met wat business logica.

[Bender]

CodeCaster schreef op vrijdag 22 september 2023 @ 18:48:
[...]

Ik denk dat jij overschat waar de meeste mensen aan werken. Waar denk je dan dat de gemiddelde self-taught, mbo'er en hbo'er terechtkomt? Die gaan grotendeels werken aan CRM, ERP, webshops, portfoliosites, apps die een website "native" beschikbaar maken; grid/CRUD-systemen om regels in databases te bewerken, if that.

Ik vind dat je nogal oneerbiedig denkt over developers door gebrek aan kennis wat developers doen, want dat is wel iets meer dan alleen crud systemen (gezien die tegenwoordig out of the box bestaan).

[Bender]

mannowlahn schreef op vrijdag 22 september 2023 @ 19:08:
[...]
het gros is echt niet next level aan het devven.

Dat doen er vast ook wel veel, maar volgens mij blijkt uit de vraagstelling van de TS ook wel dat tegenwoordig behoeftes ook wel liggen op plekken waar het meer is dan dat.

[CodeCaster]

Bender schreef op zaterdag 23 september 2023 @ 14:00:
[...]


Ik vind dat je nogal oneerbiedig denkt over developers

Waarom is de realiteit oneerbiedig?

door gebrek aan kennis wat developers doen

Waarom neem je aan dat ik niet weet wat een developer doet? Ik ontwikkel nu zo'n vijftien jaar waarvan tien als zzp'er voor een tiental verschillende bedrijven en sectoren, en geloof mij dat het leeuwendeel van de ontwikkelaars die van school komen, gaat werken aan CRUD.

Je zou ze de kost moeten geven die Wordpress-templates gaan maken, die websites gaan omtoveren in apps, die schermen bouwen om gegevens in te voeren, die API-controllers maken om invoer op te slaan in een database en opgeslagen invoer weer uitvoeren als JSON, die ETL-processen maken om data van de ene database te transponeren naar de andere, in lowcodeplatforms invoervelden aan databasevelden aan het koppelen zijn, enzovoorts, enzovoorts.

Ik durf mijn hand ervoor in het vuur te steken om te zeggen dat de meeste mensen niet met high-tech bezig zijn.

Misschien sla ik een groot deel van ons vak op deze manier plat, maar het is wat het is. Het kan ook komen doordat ik in een bepaalde hoek blijf hangen, sure.

[Bender]

CodeCaster schreef op zaterdag 23 september 2023 @ 14:21:
[...]

Waarom is de realiteit oneerbiedig?

Omdat vrijwel alle developers die ik ken wel iets meer doen dan wat crud systeempjes maken.

CodeCaster schreef op zaterdag 23 september 2023 @ 14:21:
[...]

Waarom neem je aan dat ik niet weet wat een developer doet? Ik ontwikkel nu zo'n vijftien jaar waarvan tien als zzp'er voor een tiental verschillende bedrijven en sectoren, en geloof mij dat het leeuwendeel van de ontwikkelaars die van school komen, gaat werken aan CRUD.

Je zou ze de kost moeten geven die Wordpress-templates gaan maken, die websites gaan omtoveren in apps, die schermen bouwen om gegevens in te voeren, die API-controllers maken om invoer op te slaan in een database en opgeslagen invoer weer uitvoeren als JSON, die ETL-processen maken om data van de ene database te transponeren naar de andere, in lowcodeplatforms invoervelden aan databasevelden aan het koppelen zijn, enzovoorts, enzovoorts.

Ik durf mijn hand ervoor in het vuur te steken om te zeggen dat de meeste mensen niet met high-tech bezig zijn.

Misschien sla ik een groot deel van ons vak op deze manier plat, maar het is wat het is. Het kan ook komen doordat ik in een bepaalde hoek blijf hangen, sure.

Nu ben je ineens aan het minimaliseren dat het schoolverlaters gaat, daar is niet waar ik het over heb.
Ik gaf zelfs voorbeelden van junioren en senioren waar ik volgens mij duidelijk onderscheid maak.

[Ionicawa]

Ik weet niet of deze assessments ook mondeling met jou besproken worden, maar ik zou je in ieder geval op het hart willen drukken dat je de term "trial and error" niet moet gebruiken. Dat klinkt alsof je niet echt nadenkt over een probleem en gewoon maar wat doet. Maar dat is waarschijnlijk niet hoe het gaat. Zoals anderen al hebben aangegeven is "probleemoplossend vermogen" niets meer of minder dan details herkennen in een probleem en op basis van jouw ervaring daar de meest voor de hand liggende oplossing voor toe te passen. Dat komt veel bewuster over en dat is waar bedrijven naar zoeken.

Als je het probleem niet volledig begrijpt en je een aantal scenario's uittest met als doel om het probleem beter te begrijpen en ze je daar op afrekenen dan is het een slechte test en dat zou ik ook echt als feedback geven aan een bedrijf als ze mij dat zouden flikken.

[ Voor 0% gewijzigd door Ionicawa op 24-09-2023 13:34 . Reden: foutje ]

[pennywiser]

jbdeiman schreef op vrijdag 22 september 2023 @ 13:13:
Ik heb dit in het topic over de zin en onzin van assessments ook wel eens aangegeven, wij doen ook wel een soort van opdracht (assessment) niet met het doel dat iemand in een kort tijdsbestek iets afmaakt, maar met als doel te zien hoe iemand te werk gaat.
De voorkeur gaat uit naar mensen waarbij je ziet dat die volgens een structuur werken (op z'n boeren verstands, eerst denken dan doen). We hebben daarbij kandidaten gehad die gelijk al de ontwikkelomgeving pakten en driftig begonnen te bouwen, maar de voorkeur gaat uit naar kandidaten die (kritische) vragen over het probleem stellen en die eigenlijk eerst een plannetje maken.

Simpel gezegd:
Trial en error kan wel, als je weet wat er van je gevraagd wordt en hoe je dat (ongeveer) denkt te bereiken. Dat wordt vanzelf beter, maar als je niet weet wat je wilt/ moet bereiken kan je er beter niet aan beginnen want dan weet je bij voorbaat al dat je waarschijnlijk niet op de juiste uitkomst komt.

We hebben daarom bij het assesment bewust ervoor gekozen een paar (essentiele) zaken open te laten en indien een kandidaat de (juiste) kritische vragen weet te stellen, laten we deze vaak niet eens meer programmeren. (Reden is omdat we in een eerste/ 2e gesprek ook de kandidaat vragen voorbeelden van zijn/ haar werk aan te leveren (geen complete software, maar stukken code die ze hebben gemaakt) waarover ze uit moeten leggen wat het doet, waarom ze bepaalde keuzes gemaakt hebben. Daar pik je gauw genoeg uit of iemand weet wat die (qua programmeren) aan het doen is.

Ik weet niet hoeveel mensen voor jullie deur staan te dringen om aangenomen te worden, maar kan je in deze tijd nog wel zo kritisch zijn? Of kun je ook leren on the job, klinkt of jullie echt alleen de kersen van de taart willen. Niet weten wat je wilt bereiken is vaak opgelost met een aantal aha momenten, omdat het vaak behoorlijk abstract is. Dan moet je wel durven investeren in iemand.

[pennywiser]

Ionicawa schreef op zondag 24 september 2023 @ 13:27:
Zoals anderen al hebben aangegeven is "probleemoplossend vermogen" niets meer of minder dan details herkennen in een probleem en op basis van jouw ervaring daar de meest voor de hand liggende oplossing voor toe te passen.

Die ervaring moet je wel kunnen en mogen opdoen. Die details die je noemt doen zich vaak alleen voor in een werkomgeving. De bereidheid tot investeren moet er dan dus wel zijn.

[pennywiser]

TheFrames schreef op vrijdag 22 september 2023 @ 02:14:
Ik ben meer een trial-and-error persoon. Het lukt wel, maar pas door het grondig te onderzoeken en verschillende toepassingen erop los te laten.

Dit is een goede zelflerende eigenschap, laat niemand je iets anders wijsmaken. De mensen die hier beweren nu zaken in 1 keer goed te herkennen kunnen dit vaak alleen maar op hun huidige werkplek, of met 1 of slechts enkele technieken. Dat moet je dan toch ook kunnen herkennen bij jezelf.

[ Voor 24% gewijzigd door pennywiser op 24-09-2023 13:54 ]

[boxlessness]

Bender schreef op vrijdag 22 september 2023 @ 18:02:
[...]


Dat ligt er aan wat voor developer je wil zijn.

Ben je een developer die alles aangereikt moet krijgen op welke manier iets gemaakt moet worden en met welke tools.
Of ben je een developer die zelf kan bedenken op welke manier het gedaan kan worden en welke tools het meest efficient zijn.

Ik ken niet veel organisaties die nog zitten te wachten op de eerste, alleen degene die nog ruimte hebben voor junioren.

We hebben dat een keer geprobeerd: als devs gezegd dat ze het hele project beter konden oplossen met een kladblokje en een pen, opgehangen bij de deur van de patient. Goedkoper, sneller, minder foutgevoelig, en duidelijker.
Sales noch klant waren het met ons eens...zelfs een miljoen aan dev kosten later niet.

[jbdeiman]

pennywiser schreef op zondag 24 september 2023 @ 13:33:
[...]

Ik weet niet hoeveel mensen voor jullie deur staan te dringen om aangenomen te worden, maar kan je in deze tijd nog wel zo kritisch zijn? Of kun je ook leren on the job, klinkt of jullie echt alleen de kersen van de taart willen. Niet weten wat je wilt bereiken is vaak opgelost met een aantal aha momenten, omdat het vaak behoorlijk abstract is. Dan moet je wel durven investeren in iemand.

Leren on the Job is gemakkelijker met mensen die zelfstandig kunnen werken en (na) kunnen denken. Dat is wat we eruit proberen te halen. We werken juist veel met juniors, maar proberen diegenen die niet (goed) in staat zijn een probleem te begrijpen (of niet kritisch zijn op de voorgelegde opdracht/ vraag) wel buiten de deur te houden. Natuurlijk kan je 'leren on the job', graag zelfs. Dat levert ook weer een bepaalde mate van binding op, als men het gevoel heeft bij jou wawt geleerd te hebben.
Maar 'alles leren on the job' en maar hopen dat iemand zijn gehele werkhouding veranderd, dat is in het verleden wel meer dan eens een utopie gebleken (uitzonderingen daar gelaten, maar op uitzonderingen gokken, kom je niet zo ver mee).


Punt van onze markt is ook dat het een hele ingewikkelde (en snel veranderende) markt is, ivm ook steeds wijzigende regelgeving. Iemand die dan mee denkt en (kritische) vragen kan je veel sneller mee werken dan iemand die 'blind doet wat iemand vraagt' of die zelf maar gaat interpreteren wat hij/ zij denkt dat er gebeuren moet, dan is een keer een vraag stellen helemaal niet erg.

[pennywiser]

jbdeiman schreef op zondag 24 september 2023 @ 21:01:
[...]

Leren on the Job is gemakkelijker met mensen die zelfstandig kunnen werken en (na) kunnen denken. Dat is wat we eruit proberen te halen. We werken juist veel met juniors, maar proberen diegenen die niet (goed) in staat zijn een probleem te begrijpen (of niet kritisch zijn op de voorgelegde opdracht/ vraag) wel buiten de deur te houden. Natuurlijk kan je 'leren on the job', graag zelfs. Dat levert ook weer een bepaalde mate van binding op, als men het gevoel heeft bij jou wawt geleerd te hebben.
Maar 'alles leren on the job' en maar hopen dat iemand zijn gehele werkhouding veranderd, dat is in het verleden wel meer dan eens een utopie gebleken (uitzonderingen daar gelaten, maar op uitzonderingen gokken, kom je niet zo ver mee).


Punt van onze markt is ook dat het een hele ingewikkelde (en snel veranderende) markt is, ivm ook steeds wijzigende regelgeving. Iemand die dan mee denkt en (kritische) vragen kan je veel sneller mee werken dan iemand die 'blind doet wat iemand vraagt' of die zelf maar gaat interpreteren wat hij/ zij denkt dat er gebeuren moet, dan is een keer een vraag stellen helemaal niet erg.

Ik vind je toonzetting niet helemaal de goede, "werkhouding die geheel veranderd moet worden", "buiten de deur houden", "een keer een vraag stellen niet erg".

Alles leren on the job heb ik het ook niet over. Mensen een kans geven, daar heb ik het over. Dat haal ik er bij jou niet uit, het moet direct goed wezen. Die utopie waar je het over hebt, hoe groot is jullie eigen talent dan om de juiste mensen te vinden en vervolgens het juiste naar boven te halen, ik denk dat je beter daar eerst eens kritisch naar kan kijken. Lees het best gemarkeerde bericht hier nog eens.

Het klinkt als 1 richting verkeer waar jij zit, blij dat ik in een andere cultuur mag zitten.

[ Voor 12% gewijzigd door pennywiser op 24-09-2023 21:49 ]

[Frame164]

Trial&error zie ik als laatste stap. Als de basis niet goed is kom je met trial&error niet ver. Grote kans ook dat later niemand meer snapt hoe het nu werkt. Leuk als het hobbymatig is, maar horror als het om serieuze software gaat.

[ Voor 19% gewijzigd door Frame164 op 24-09-2023 21:23 ]

[P_Tingen]

Trial & error klinkt wat prutserig, je zou het ook kunnen presenteren als een "exploratieve oplossingsstijl, waarbij ook alternatieve oplossingen aan bod komen"

Maar eerlijk, dat is ook precies de manier waarop ik werk en ik heb al jaren goede reviews en klanten willen mij meestal niet weer kwijt.

Wat ik wel gezien heb bij oudere projecten is dat er veel verschillende stijlen van werken zijn en de een is niet perse beter dan de ander omdat ze elkaar versterken. Zo had ik een collega die je at random een programma kon geven met een probleembeschrijving erbij en hij lost het op. Ik kan dat niet; ik moet eerst weten wat een programma moet doen en hoe het opgebouwd is. Dan ga ik vaak eerst eea refactoren om grip op het programma te krijgen en als ik een beetje door heb hoe het zou moeten werken, zoek ik naar de oplossing voor het probleem.

Is mijn manier beter? Ja, soms. Soms ook niet. Mijn collega is sneller maar ik ben dan vaak grondiger en het hangt van de situatie af wat beter is.

Als je jezelf wil trainen kan ik ook van harte de advent of code aanraden. Dit is een adventskalender van 1 tot 25 dec met elke dag een probleem dat met programmeren is op te lossen (in elke willekeurige taal). Check www.adventofcode.com en vanaf eind november het bijbehorende topic in het forum

[TheFrames]

Ik denk dat velen 'trial & error' zien als van 'Je probeert maar gewoon iets zonder erover na te denken'. Dat is een definitie die je zo zou kunnen opvatten, maar het kan ook zijn dat je nadenkt over de mogelijke oplossingsroutes die je zou kunnen afleggen, deze dan ook toepast in bepaalde scenario's en dan daaruit een keuze maakt.

Het hangt ook erg van de schaal en type software. Inderdaad bij grote enterprise systemen kan ik me voorstellen dat er weinig ruimte is voor fouten, waardoor je voorzichtiger te werk moet gaan. Maar met wat kleinschalige software is daar meestal iets meer speelruimte.

[TheFrames]

P_Tingen schreef op zondag 24 september 2023 @ 21:38:
Trial & error klinkt wat prutserig, je zou het ook kunnen presenteren als een "exploratieve oplossingsstijl, waarbij ook alternatieve oplossingen aan bod komen"

Inderdaad, zo zou je dit ook kunnen noemen.

[jbdeiman]

pennywiser schreef op zondag 24 september 2023 @ 21:11:
[...]

Ik vind je toonzetting niet helemaal de goede, "werkhouding die geheel veranderd moet worden", "buiten de deur houden", "een keer een vraag stellen niet erg".

Alles leren on the job heb ik het ook niet over. Mensen een kans geven, daar heb ik het over. Dat haal ik er bij jou niet uit, het moet direct goed wezen. Die utopie waar je het over hebt, hoe groot is jullie eigen talent dan om de juiste mensen te vinden en vervolgens het juiste naar boven te halen, ik denk dat je beter daar eerst eens kritisch naar kan kijken. Lees het best gemarkeerde bericht hier nog eens.

Het klinkt als 1 richting verkeer waar jij zit, blij dat ik in een andere cultuur mag zitten.

Als jij dit eruit haalt moet ik je toch adviseren een cursus begrijpend lezen te gaan volgen. Wat ik duidelijk aangeeft is dat het om de houding/ aanpak gaat. Waar wij op aansturen is dat mensen niet zomaar wat gaan doen, omdat ze denken iets te begrijpen, maar juist gebrand zijn het probleem echt te begrijpen zodat ze een echte oplossing kunnen bedenken.

Wij geven zoals ik ook benoem juist veel junioren de kans, maar wel diegene die qua houding het best passen bij ons als organisatie en diegenen die niet zomaar wat gaan doen, het gaat ons niet eens om de pure kwaliteit van een programmeur/ van het programmeren zelfs. Dat is iets dat je juist wel in the job kan leren. Maargoed, als jij bovenstaande denkt te moeten halen uit wat ik beschrijf, prima. Moet je dan zelf weten, dan ga ik niet meer verder in discussie.

Dat je een opleiding hebt afgerond en hebt laten zien dat je kan programmeren (staat in het gemarkeerde bericht) en dat dat op zichzelf een assessment is, zo kan je het zien. Maar in elke groep en opleiding heb je mensen die zelfstandig kunnen denken en mensen die vooral goed zijn in het uitvoeren van een opdracht. Beiden hebben hun voors en tegens, maar wij zoeken toch met name de eerste Categorie.

[ Voor 11% gewijzigd door jbdeiman op 24-09-2023 22:05 ]

[pennywiser]

jbdeiman schreef op zondag 24 september 2023 @ 22:02:
[...]
Beiden hebben hun voors en tegens, maar wij zoeken toch met name de eerste Categorie.

Maar dat lukt dus niet heel goed zeg je zelf. Ondanks de strenge selectie. Een paar uitzonderingen nagelaten.

Ik denk dat we wel ongeveer hetzelfde bedoelen, zoals ik zei de toon van je bericht vond ik wat opvallend. Ik haal niets ergens uit, het staat er volgens mij gewoon.

[ Voor 3% gewijzigd door pennywiser op 24-09-2023 22:23 ]

[pennywiser]

P_Tingen schreef op zondag 24 september 2023 @ 21:38:
Trial & error klinkt wat prutserig, je zou het ook kunnen presenteren als een "exploratieve oplossingsstijl, waarbij ook alternatieve oplossingen aan bod komen"

Deze is mooi

Als ik iets geleerd heb is het wel dat je met professioneel taalgebruik het beeld dat mensen van je hebben kan bijsturen ten voordele van jezelf.

[Hydra]

TheFrames schreef op vrijdag 22 september 2023 @ 02:14:
Zal dit later een barrière in mijn carrière vormen? (Heeuhh, dat rijmt )

Ik denk dat het belangrijk is dat je gaat zien dat er twee heel arg gescheiden 'issues' zijn hier.

Als software engineer, problemen oplossen is in de basis gewoon wat wij doen. Geen problemen kunnen oplossing zou je een slechte developer maken.

Maar we hebben nul inzicht in die test en of deze dat daadwerkelijk aantoont.

Daarbij; je bent enorm junior. Dit is iets wat je ook gewoon door ervaring leert. Je zit nu nog in de fase dat je net je rijbewijs hebt; je bent nog lang geen ervaren autorijder.

[Bender]

P_Tingen schreef op zondag 24 september 2023 @ 21:38:
Trial & error klinkt wat prutserig, je zou het ook kunnen presenteren als een "exploratieve oplossingsstijl, waarbij ook alternatieve oplossingen aan bod komen"

Maar eerlijk, dat is ook precies de manier waarop ik werk en ik heb al jaren goede reviews en klanten willen mij meestal niet weer kwijt.

Ik doe ook veel T&E vanwege het gebrek aan documentatie en dat het vaak sneller is om 10 situaties te creëren welke errors of juist successes geeft, dan de hele code te begrijpen waarom ergens voor gekozen is.
(of eigenlijk dus gewoon reverse engineering)

[P_Tingen]

Bender schreef op maandag 25 september 2023 @ 10:39:
[...]
Ik doe ook veel T&E vanwege het gebrek aan documentatie en dat het vaak sneller is om 10 situaties te creëren welke errors of juist successes geeft, dan de hele code te begrijpen waarom ergens voor gekozen is.
(of eigenlijk dus gewoon reverse engineering)

Dat herken ik wel, zeker in een oud en groot systeem, zonder documentatie en tests is het lastig om zomaar iets door te voeren of te wijzigen. Dan moet je eerst wat experimenteren voordat je wat kan doen....

[RM-rf]

TheFrames schreef op vrijdag 22 september 2023 @ 02:14:

Zal dit later een barrière in mijn carrière vormen? (Heeuhh, dat rijmt )

Dat zal vermoedelijk vooral liggen aan twe zaken:

1) Of je er zelf voor kunt zorgen dat je juist in bepaalde gebieden waar je eigen sterktste punten het meest gebruikt worden en eventuele zaken waarin je wat minder bent niet gevraagd worden van je.

2) Of je zelf ervoor kunt zorgen dat je dingen waarmee je zelf moeite hebt, minder natuurlijk 'gevoel' wel kunt aanwennen of -leren.
Ofwel het daadwerkelijk beter worden op die gebieden door oefening en training... Of de andere optie daarbij is het aanwennen van bepaalde 'trucjes' of middelen om de gevolgen van het kennen van je zwaktepunten te ondervangen.


Het positieve daaraan is dat mensen die hun eigen zwaktepunten goed kennen, maar er wel constructief mee omgaan vaak erg prettige collega's zijn...
Iedereen heeft natuurlijk altijd bepaalde sterktes en zwaktes en het is des te prettiger als iemand weet waaraan hij moet werken.

Werken is natuurlijk altijd ook iets intermenselijks en ook programmeurs hebben niet enkel met code en algoritmes te doen, maar moeten ook kunnen samenwerken in een team, kunnen communiceren.

Een 'problem-oplossende' instelling hebben betekent voroal ook dat je een probleem ziet als deel van het ontwikkelingsproces...
Probleem-oplosen begint al voordat je een applicatie of toepassing opzet, in de Concept-fase en het vooruitdenken over potentiele issues die kunnen optreden en mogelijk al voorkomen kunnen worden door de structuur van het project op een bepaalde wijze op te zetten.

Het kan ook een kwestie zijn van het praten met anderen, project-managers, sofftweare-architecten en Business-Analysts die misschien al aanpassingen kunnen doen o te voorkomen dat er later code geschreven moet worden om ontstane problemen te omgaan.

[Gaius]

RM-rf schreef op maandag 25 september 2023 @ 11:24:
[...]
Een 'problem-oplossende' instelling hebben betekent voroal ook dat je een probleem ziet als deel van het ontwikkelingsproces...
Probleem-oplosen begint al voordat je een applicatie of toepassing opzet, in de Concept-fase en het vooruitdenken over potentiele issues die kunnen optreden en mogelijk al voorkomen kunnen worden door de structuur van het project op een bepaalde wijze op te zetten.

Even hierop voortbordurend:
Ik vind "problemen oplossen" dan ook een te vaag statement. Koffie moeten halen en het koffiezetapparaat is kapot is ook een probleem. Om dan koffie te zetten met oploskoffie vind ik geen oplossing.

Maar serieus; ik denk dat je als hoofdtaak als ontwikkelaar niet het oplossen van problemen is, maar het vertalen van functionele wensen naar code. En ja, tijdens dat proces kun je tegen problemen aanlopen, maar het oplossen daarvan kan op veel verschillende manieren.

Trial and error is een werkwijze die kan leiden tot een goede oplossing. Hulp inroepen van een meer senior collega kan ook leiden tot een prima oplossing. Maar dat zijn allebei oplossingsmethodes die niet goed tot hun recht komen op zo'n assessment. Terwijl een sorteringsalgoritme kunnen schrijven juist weer leuk is voor een assessment, maar als je dat doet op mijn project, dan keur ik je pull request keihard af. Doe maar het (.NET) framework gebruiken, of een 3rd party library opzoeken. We gaan niet het wiel opnieuw uitvinden, zonde van je tijd.

Interessanter is wat je doet (zeker als junior) als je een probleem tegenkomt die inderdaad op het verkeerde niveau zit. Bijvoorbeeld een userstory die een aanpassing aan de architectuur vereist. Ga je hackwerk opleveren, blijf je een week je hoofd kapot beuken omdat je er niet uit komt, of ga je in gesprek met de juiste personen? En wat (en hoe snel) leer je ervan als junior?

[Hydra]

Gaius schreef op maandag 25 september 2023 @ 15:49:
Maar serieus; ik denk dat je als hoofdtaak als ontwikkelaar niet het oplossen van problemen is, maar het vertalen van functionele wensen naar code.

Dat is dus "problem solving". Je neemt "probleem" iets te letterlijk als "iets dat niet hoort te zijn" maar je moet het zien zoals een "wiskunde probleem".

[jbdeiman]

pennywiser schreef op zondag 24 september 2023 @ 22:18:
[...]

Maar dat lukt dus niet heel goed zeg je zelf. Ondanks de strenge selectie. Een paar uitzonderingen nagelaten.

Ik denk dat we wel ongeveer hetzelfde bedoelen, zoals ik zei de toon van je bericht vond ik wat opvallend. Ik haal niets ergens uit, het staat er volgens mij gewoon.

Waar zeg ik dan dat dit ons niet goed lukt? Dat mis ik dan, het lukt ons juist goed om mensen te vinden, ze blijven allemaal ook wel een tijdje (behalve een enkele keer als we een zzp'er inhuren voor tijdelijk opschalen voor een project) . Dus nee, het gaat ons juist goed, mensen die zelfstandig nadenken en zorgen dat ze alle informatie hebben om een goede oplossing te bouwen, blijken ook sneller te leren en de materie eigen te maken. (Op zich niet verrassend lijkt mij).

De toon was wellicht niet helemaal voorzichtig uitgedrukt met de gebruikte termen, maar het gaat er voor mij om dat je prima dergelijke methoden kan toepassen om ervoor te zorgen dat je passende kandidaten treft, of in elk geval de kans vergroot dat een kandidaat passend is.

[pennywiser]

jbdeiman schreef op maandag 25 september 2023 @ 20:46:
[...]

Waar zeg ik dan dat dit ons niet goed lukt? Dat mis ik dan, het lukt ons juist goed om mensen te vinden, ze blijven allemaal ook wel een tijdje (behalve een enkele keer als we een zzp'er inhuren voor tijdelijk opschalen voor een project) . Dus nee, het gaat ons juist goed, mensen die zelfstandig nadenken en zorgen dat ze alle informatie hebben om een goede oplossing te bouwen, blijken ook sneller te leren en de materie eigen te maken. (Op zich niet verrassend lijkt mij).

De toon was wellicht niet helemaal voorzichtig uitgedrukt met de gebruikte termen, maar het gaat er voor mij om dat je prima dergelijke methoden kan toepassen om ervoor te zorgen dat je passende kandidaten treft, of in elk geval de kans vergroot dat een kandidaat passend is.

Je zei is meer dan eens een utopie gebleken uitzonderingen daargelaten. Dat klinkt anders dan wat je nu zegt lukt ons goed om mensen te vinden. Dat is mooi, wil iedereen graag dus top.

Verder no hard feelings we bedoelen hetzelfde

[TheFrames]

jbdeiman schreef op maandag 25 september 2023 @ 20:46:
[...]

Waar zeg ik dan dat dit ons niet goed lukt? Dat mis ik dan, het lukt ons juist goed om mensen te vinden, ze blijven allemaal ook wel een tijdje (behalve een enkele keer als we een zzp'er inhuren voor tijdelijk opschalen voor een project) . Dus nee, het gaat ons juist goed, mensen die zelfstandig nadenken en zorgen dat ze alle informatie hebben om een goede oplossing te bouwen, blijken ook sneller te leren en de materie eigen te maken. (Op zich niet verrassend lijkt mij).

De toon was wellicht niet helemaal voorzichtig uitgedrukt met de gebruikte termen, maar het gaat er voor mij om dat je prima dergelijke methoden kan toepassen om ervoor te zorgen dat je passende kandidaten treft, of in elk geval de kans vergroot dat een kandidaat passend is.

Naja, ieder bedrijf z'n ding. Moet daarbij wel zeggen, dit is 99,99 procent van wat ik hoor. Allemaal zoeken jullie naar de diamenten speld in de gouden hooiberg

Maar capaciteit zegt niet alles. De tweede die lager scoort doet er langer over. Dat is het voornaamste verschil, maar beide kunnen succesvol zijn.

Ik moet ook wel zeggen, ik analyseer liever mijn problemen door er mee te spelen lokaal. Als ik een functie heb kan ik deze wel lezen, maar liever draai ik de functie om de output ervan te zien. Dan snap ik wat de return waarde is als datatype, maar niet de inhoud. Leuk dat het een array met strings is, maar wat staan er in die strings en waar wordt deze array gebruikt?

Zo'n spelletje is vrijwel beperkt. Blokjes van spiesjes slepen moet mij maar vertellen hoe mijn probleemoplossend vermogen is. Letterlijk het programmeren heeft zoveel meer aspecten waar je rekening mee moet houden. Ook heeft de werkstijl invloed hoe iemand een probleem aanpakt, wat totaal niet in zo'n test wordt getoetst.

[CVTTPD2DQ]

Gaius schreef op maandag 25 september 2023 @ 15:49:
Terwijl een sorteringsalgoritme kunnen schrijven juist weer leuk is voor een assessment, maar als je dat doet op mijn project, dan keur ik je pull request keihard af. Doe maar het (.NET) framework gebruiken, of een 3rd party library opzoeken. We gaan niet het wiel opnieuw uitvinden, zonde van je tijd.

Wat dat betreft is het vak wel veranderd. Sorteeralgoritmen zitten natuurlijk al heel lang in de standaard libraries. ([Grappig genoeg: soms zitten daar jarenlang bugs in die niet in een quicksort-implementatie van een willekeurige HBO-afstudeerder zouden zitten), maar vijftien en zelfs tien jaar geleden was er lang niet zo'n overschot aan open source libraries voor vanalles en nogwat.

Daar worden we allemaal productiever door, maar het is wel een beetje alsof je opgeleid bent tot meubelmaker, om dan alleen nog IKEA-kasten in elkaar hoeven te zetten.

[Croga]

Ken je Cynefin?

Cynefin is een complexiteitstheorie. Cynefin stelt dat problemen zich in 4 categoriën voordoen:
- Simpel: Je kunt iets zien en weten wat de oplossing is.
- Gecompliceerd: Je ziet iets, kunt het analyseren en weten wat de oplossing is.
- Complex: Je ziet iets, probeert dingen uit om meer informatie te krijgen en gaat door tot je de oplossing hebt.
- Chaos: Je ziet iets, probeert iets uit en hoopt dat het goed is.
(Uiteraard is het ingewikkelder dan dit maar, this is the gist)

Het soort assessments waar hier over gesproken wordt bevindt zich over het algemeen in het Gecompliceerde domein. Software ontwikkeling bevindt zich nagenoeg altijd in het Complexe domein. En dus zijn dit soort assessments totaal ongeschikt voor waar ze voor gebruikt worden.
Het is ook het grootste probleem van de meeste bedrijven. In het gecompliceerde domein bestaat enige vorm van voorspelbaarheid. Software ontwikkeling is nauwelijks voorspelbaar. En dus praten managers (die alleen gecompliceerde domeinen kennen en begrijpen aangezien ze volledig gefocussed zijn op controle) een hele andere taal dan software ontwikkelaars.

Lees gerust de stukken van Dave Snowden er op na. Hij heeft jarenlang onderzoek gedaan naar dit soort zaken (en Cynefin is ondertussen alweer redelijk achterhaald; het is bijna 25 jaar oud).

[jbdeiman]

pennywiser schreef op maandag 25 september 2023 @ 21:50:
[...]

Je zei is meer dan eens een utopie gebleken uitzonderingen daargelaten. Dat klinkt anders dan wat je nu zegt lukt ons goed om mensen te vinden. Dat is mooi, wil iedereen graag dus top.

Verder no hard feelings we bedoelen hetzelfde

En hierom zei ik ook dat begrijpend lezen wel belangrijk is in deze: er staat dat iemand alles laten leren on the job en hopen dat de werkwijze/ houding veranderd (niet analyseren/ het probleem begrijpen, maar gelijk maar wat proberen) al meermalen een utopie is gebleken.
Niet dat kandidaten vinden een utopie is gebleken, of dat we teveel uitfilteren vooraf.

Het gaat er dus om dat wij de ervaring hebben (uitzonderingen zullen er vast zijn) dat als iemand de houding heeft halsoverkop gewoon wat te proberen ipv eerst even wat langer na te denken of het probleem/ de vraag wel begrijpelijk is, je dit er niet snel uit krijgt.

[pennywiser]

jbdeiman schreef op woensdag 27 september 2023 @ 10:50:
[...]

En hierom zei ik ook dat begrijpend lezen wel belangrijk is in deze: er staat dat iemand alles laten leren on the job en hopen dat de werkwijze/ houding veranderd (niet analyseren/ het probleem begrijpen, maar gelijk maar wat proberen) al meermalen een utopie is gebleken.
Niet dat kandidaten vinden een utopie is gebleken, of dat we teveel uitfilteren vooraf.

Het gaat er dus om dat wij de ervaring hebben (uitzonderingen zullen er vast zijn) dat als iemand de houding heeft halsoverkop gewoon wat te proberen ipv eerst even wat langer na te denken of het probleem/ de vraag wel begrijpelijk is, je dit er niet snel uit krijgt.

Zoals je ziet hebben we daar allemaal wel eens last van

[jbdeiman]

pennywiser schreef op woensdag 27 september 2023 @ 18:44:
[...]

Zoals je ziet hebben we daar allemaal wel eens last van

Haha, kan gebeuren, maar dan snap je nu in elk geval waarom ik je reactie niet helemaal begreep, heb e.e.a. een paar keer terug gelezen maar kon het niet plaatsen, tot jij zei dat ik het over de utopie had, daar voel het kwartje.
Bedankt voor je geduld en uitleg in deze, kan ik weer rustig slapen. (Doe ik toch wel, maar zo is het volgens mij voor iedereen prettiger.)

[PinusRigida]

CVTTPD2DQ schreef op vrijdag 22 september 2023 @ 02:35:
...
En dus wordt de beslissing meestal overgelaten aan de mensen die zichzelf voor de gek kunnen houden dat ze dat wél kunnen.

En meestal is dat een excuus voor de meest middelmatige mensen om hun meest idiote theoriën de vrije loop te laten. Alles van de opmaak van het CV tot de kracht van de handdruk wordt een relevant feitje in hun ogen.

Een assessment is dan verhoudingsgewijs nog "objectief". Er zijn volwassen mensen die het met een stalen gezicht op "intuitie" gooien.

En jij zit op het moment aan de andere kant van de tafel van dit soort figuren.
...

Exactly...

Bvb. het type mensen die belang hechten aan horoscopen en dat soort zweverige onzin, die dan geloven dat hun intuïtie ingegeven is door een hogere spirituele kracht, verbonden aan een totaal arbitraire eigenschap van hun sterrenteken. (dat, zoals elk sterrenteken, gebaseerd is op de totaal arbitraire positie van hemellichamen die vaak niks met elkaar te maken hebben, maar ze met heel veel verbeelding een quasi-herkenbaar figuurtje vormen vanuit onze waarnemerspositie)

...waarom begin ik daarover: omdat ik zo iemand tegenover mij heb gehad... die het weliswaar -toch nog ietwàt slim van haar- niet op papier liet meetellen, maar vanaf het gesprek van start ging begon ze erover, hoe ze bvb. "de gave had om mensen aan te voelen en dat een typische eigenschap was van haar sterrenbeeld"... waarbij ik dan uiterste moeite moest doen om mijn ogen niet uit mijn gezicht te laten rollen...

...en dit soort ""volwassenen?"" moeten dus over serieuze mensen hun professionele toekomst beslissen. Moest het zo pijnlijk niet zijn voor de betrokkenen, ik zou schaterlachen.

[Bender]

In bijna je hele post kan ik me vinden, behalve net die laatste 2 zinnen.

CVTTPD2DQ schreef op vrijdag 22 september 2023 @ 02:35:

In een rationele wereld zou een diploma meer gewicht in de schaal moeten leggen dan een assessment. Maar het bedrijfsleven is helaas alles behalve rationeel.

Want een van de minst boeiende dingen voor developers vind ik doorgaans hun diploma..

[CVTTPD2DQ]

Bender schreef op donderdag 5 oktober 2023 @ 00:16:
Want een van de minst boeiende dingen voor developers vind ik doorgaans hun diploma..

De TS heeft recent zijn HBO diploma informatica gehaald. Dat is een vierjarig programma. Als je denkt dat je (niet eens software development gerelateerde) testje van een half uur betrouwbaarder is ben je jezelf voor de gek aan het houden.

[Bender]

CVTTPD2DQ schreef op donderdag 5 oktober 2023 @ 07:15:
[...]


De TS heeft recent zijn HBO diploma informatica gehaald. Dat is een vierjarig programma. Als je denkt dat je (niet eens software development gerelateerde) testje van een half uur betrouwbaarder is ben je jezelf voor de gek aan het houden.

Gelukkig zegt ook niemand dit.