Hoe ga je om met technische testen die absurd zijn (bijvoorbeeld een onredelijk grote taak met een korte tijdslimiet)?

Door weg te lopen van hen.

GS (Goldman Sachs) wilde ooit een klein code monster van mij, die liep naar een uitwisseling orderboek simulator. Niets bijzonders, EXCEPT specificeerden ze volledige testdekking en PRODUCTION CODE QUALITY. Voor iets wat zo kritisch is, loopt het terug tot een week van werk testen van elk afzonderlijk geval, omdat dit type code extreem kritisch is.

Ik stuurde de recruiter een aanbod en vertelde hem dat als ze niet betalen - no play.

Sommige bedrijven hebben domme ideeën en zetten belachelijke tests op. Jouw voorbeeld is vergelijkbaar - er is geen rare manier om dat in 2 uur te doen buiten het feit dat je het al voorbereid hebt. Ik durf te zeggen dat dit borderline fraude is. Het is waarschijnlijk slechts een teken van komische incompetentie.

Onthoud dat dit IT is - en IT is een verkopersmarkt. Tonnen banen - geen specialisten. Gedraag je zo. Ga niet met idioten om. Ik weiger codeerwerk zonder PRIOR-interviews, want er is een andere kant: Al die “interessante, uitdagende” projecten zijn toch net zo dom. Ik wil eerst weten of ik MIJN tijd wil verspillen, want ik hou ervan om projecten te doen die ik leuk vind, en recruiters hebben geen idee wat voor projecten er tegenwoordig aan de hand zijn.

Vergeet niet, wanneer een bedrijf je interviewt, ben je ook aan het interviewen.

Gebruik inane tests als een screening tool.

Als de TEST je onredelijke doelen en tijdlijnen geeft, ** raad eens wat je kunt verwachten op de baan.**

Neem het niet persoonlijk, een slechte test is geen bruikbare maatstaf voor je vaardigheden. Als ze zeggen dat je werk niet goed genoeg was, en je weet dat dat wel zo was, dan zullen ze je natuurlijk ook niet op je werk waarderen.

Nogmaals, jij bent het niet, maar zij.

Achteraf gezien is dat 20/20. Dit is wat je de volgende keer moet zeggen:

“Als vuistregel geldt dat ik geen huiswerk maak tenzij ik eerst met de klant spreek.”

“Ben jij de klant? Nee, verbind me dan door met de inhuurmanager van de klant. En nee, als je voor HR werkt (je bent niet de klant tenzij je wilt dat ik een HR-gerelateerde applicatie bouw)”

“Ok, wat doet deze persoon voor je bedrijf? Zal hij/zij de persoon zijn aan wie ik verslag uitbreng als uw bedrijf mij in dienst neemt? Ok, ja. Ik wil die persoon spreken.”

Als je eindelijk met die persoon praat, dan zeg je zoiets als:

“Ok, heb je mijn cv gelezen? Denkt u dat we dit hele project kunnen overslaan?”

In de veronderstelling dat de inhurende manager het nog steeds niet wil overslaan, dan zou u kunnen zeggen:

“Het probleem is dat ik al eens eerder ben verbrand.

Ik weet ten eerste niet of ik het project gewoon van de grond af aan moet opbouwen, of gewoon wat van de code moet hergebruiken die ik heb liggen? De ene keer bouwde ik het project vanaf nul in een paar uur, maar ik kreeg kritiek omdat ik geen productieklare applicatie had.

En een andere keer was er een kleine versie-mismatch, en hun IT wist niet hoe ze het configuratiebestand moesten aanpassen om mijn project te laten werken.”

Maar wat je ook doet, geef deze uitleg niet aan de rekruteerder. Leg het niet uit en rechtvaardig jezelf niet aan de recruiter. Het heeft geen zin om jezelf uit te leggen aan een Poortwachter. Hoe meer informatie je een gatekeeper geeft, hoe groter de kans dat hij/zij die informatie tegen je zal gebruiken, want een gatekeeper heeft van nature zelden de macht om concessies te doen, maar aan de andere kant gaat het bij hem/haar meer om het zoeken naar redenen om kandidaten te screenen.

Dus in de veronderstelling dat je met de eigenlijke beslisser hebt gepraat, de inhuurmanager aan wie je eigenlijk rapporteert, en in de veronderstelling dat je goede vibraties krijgt van deze persoon, zou je kunnen zeggen:

“Ok, ik ben bereid om het take-home project te doen, maar ik ben er liever bij als mijn project is geïnstalleerd en geëvalueerd.

Denk je dat we een moment kunnen instellen waarop ik met mijn code binnen kan komen en we het samen kunnen instellen op een van je ontwikkelaarsmachines? ”

“Hoe zit het met de komende woensdag? […] Zal je er zijn? Zal een van de ontwikkelaars er ook zijn? ”

Maar nogmaals, doe dit alleen als je goede vibraties krijgt van deze persoon. Vertrouw op je eigen onderbuikgevoelens. Als je om welke reden dan ook het gevoel hebt dat ze dit project voor thuisgebruik gebruiken als een luie manier om vele tientallen sollicitanten te screenen. Of als je om wat voor reden dan ook het gevoel hebt dat ze proberen wat vrij werk uit je te halen, zodat ze het in productie kunnen nemen, niet akkoord gaan met het huiswerk.

Hetzelfde geldt als je komt opdagen en ze je project niet willen installeren/reviewen als je er bent. Als ze willen dat je hun huiswerk maakt, moeten ze ook wat tijd in jou investeren. Het is een blijk van wederzijds respect.

En als je om wat voor reden dan ook niet komt opdagen, krijg je dat respect niet. Bijvoorbeeld, als ze de ingenieur hebben verwisseld die je op het allerlaatste moment zou ontmoeten met een HR persoon. Wees beleefd, maar wees vastberaden. Geef ze niet je meeneemproject. Zeg ze dat je het interview graag opnieuw inroostert en weggaat.

Ik hou er niet van om in mijn antwoorden naar andere antwoorden te verwijzen, omdat antwoorden op zichzelf moeten kunnen worden begrepen. Echter, het topgestemde antwoord komt in principe neer op “Het bedrijf is een bende idioten”. Loop van ze weg.“ Dit geeft de OP niets om zichzelf te verbeteren, en niets om in de toekomst te veranderen. Ik zie gebieden die de OP zou kunnen verbeteren, ongeacht of het bedrijf iets verkeerds heeft gedaan of niet, wat wij als antwoordgevers eigenlijk niet weten, omdat we maar één kant van het verhaal hebben gehoord.

Voor zover ik kan zien, communiceerde je niet voor je begon met de taak waarvan je vaststelde dat het niet in twee uur kon worden gedaan.

Hier is de volgorde van de gebeurtenissen hoe ik het zie:

1. Je werd gevraagd om een coderingsuitdaging 2 af te ronden. Toen je de uitdaging kreeg, in plaats van je zorgen te communiceren, begon je met het coderen van
2. 3. Je hebt de uitdaging gehaast en de hoeken afgesneden
3. Je hebt een project van lage kwaliteit ingediend dat niet werkte zonder veel gepruts

4. Na het ontvangen van feedback, begon je je werk te verantwoorden

5. De kandidaat accepteerde alle voorwaarden van de uitdaging

6. 1. De kandidaat heeft het project op tijd ingediend

7. De kandidaat heeft het project op tijd ingediend. Het project werkte niet

8. Onze hoofdontwikkelaar zei dat de code erg slecht was

9. De kandidaat begon excuses te maken voor hun werk

Stel je voor dat je in een werksituatie zit en je manager/teamleider je vraagt om een taak in een onredelijke hoeveelheid tijd af te ronden. Als je niet direct communiceert dat je niet zoveel werk kunt doen in die korte tijd, dan is elke mislukking jouw schuld voor het accepteren van de aanvankelijke voorwaarden. _Je bent de expert, niet zij, en ze vertrouwen erop dat je met hen communiceert.

Ik kan niet benadrukken hoe belangrijk het is dat beide partijen een gemeenschappelijk begrip van de situatie hebben. Je had een onoverkomelijke kloof van begrip omdat je je kans om het aan te pakken gemist hebt. De volgende keer dat je een probleem hebt, communiceer het dan meteen of de andere partij zal denken dat alles in orde is! Het niet communiceren van belangrijke informatie is liegen door weglating, en elke vorm van liegen is onprofessioneel. Hoe zij reageren op de informatie is hun verantwoordelijkheid, niet de jouwe.

Ik raad aan om De Schone Coder te lezen: Een gedragscode voor professionele programmeurs van Robert C. Martin (Oom Bob), in het bijzonder:

• Hoofdstuk 2: Nee zeggen
• Hoofdstuk 3: Ja zeggen
• Hoofdstuk 10: Schatting
• Hoofdstuk 11: Druk

Als het bedrijf uw aanvraag afwijst omdat u om feedback en verduidelijking vroeg voordat u met de taak begon, hebben ze u er niet uit gefilterd, u hebt ze deze eruit gefilterd als een bedrijf waar u niet voor wilt werken.

Ik heb een aantal slimme en een aantal domme tests (SQL/BI) en heb actief uit een die dom was, uit te leggen dat wat ze wilden was de verkeerde aanpak.

Ik heb ook gezien tests die waren eigenlijk pogingen tot een gratis project, met “monster werk” dat was in wezen een nieuwe oplossing. Nogmaals, ik heb geweigerd om deze af te ronden.

Het gebeurt, ik krijt het op om te ervaren en verder te gaan. Ik plan interviews altijd in voor na de uren, dus er is geen echt verlies van mijn kant.

Nou vertel je ze precies wat je je baas zou vertellen als je met die taak wordt geconfronteerd.

Ofwel weten ze niet wat ze doen, dan leer je veel over het bedrijf, ofwel willen ze zien dat je geen tijd (bedrijfsgeld) verspilt aan het slecht doen van dingen in plaats van te praten met de persoon zonder de technische kennis om dit te beoordelen.

Er zijn twee uitkomsten, je passeert met vlag en wimpel om het juiste te doen, of je hebt de kogel ontweken en hoeft niet over twee maanden terug te komen om ons te vertellen hoe je baas onmogelijke dingen eist ;)

Hier is mijn aanpak:

1. Communiceer met je contactpersoon bij het bedrijf dat je denkt dat het niet mogelijk is in de tijd, en wat je daadwerkelijk van plan bent te doen.

2. 1. Als er tijd is om te wachten op een antwoord, wacht dan; zo niet, doe dan wat je van plan was, en documenteer je keuzes in detail
3. 1. Schets in het ideale geval waar je de rest zou nemen.

4. Merk op dat allemaal weinig interviewers daadwerkelijk kalibreren en testen dat een taak 2 uur in beslag neemt. Als je de baan echt wilt, neem hem dan in een bepaalde tijd mee naar een bepaald niveau van volledigheid.

Zoals je hebt ontdekt, is kwaliteit meestal een troef die in de tijd past, tenzij ze strikte mechanismen hebben om ervoor te zorgen dat alle kandidaten binnen de tijd passen.

Deze geur van valse test om je persoonlijkheid in kaart te brengen, vooral hoe je omgaat met absurde en stressvolle gebeurtenissen. Ben jij het soort dat

1. zich ergert en weggaat of
2. degene die het in stilte probeert uit te werken of
3. daadwerkelijk probeert te discussiëren en uit te leggen met het management wat er onredelijk is of
4. zo gestrest raakt dat je niet weet wat je moet doen of
5. jij degene bent die doet alsof je het probeert uit te werken maar even absurde verzonnen resultaten teruggeeft omdat dat precies is wat iedereen die met zo'n taak op de proppen komt, zou verdienen?

Het is mijn deskundige mening dat niemand ooit zou zeggen dat dit zoiets is als twee uur werk, als het goed gedaan wordt. Ik zou op z'n minst een paar dagen neerzetten om de architectuur goed te krijgen etc.

Pardon, maar u mist het punt.

Denk er maar eens over na vanuit het perspectief van het team. Ze willen iemand die bekend is met alle ASP.NET, MVC, REST, praten met een database, en de matig geavanceerde functie van een autocomplete tekstbox.

Kan I deze dingen gedaan krijgen? Ja, uiteindelijk. Immers, ik heb gehoord van al deze dingen, dus ik zou ze misschien op mijn cv kunnen zetten. Een expert als jij zal in staat zijn om een werkend systeem in elkaar te zetten onder de tijdslimiet omdat je de hele tijd met deze stapel te maken hebt, maar ik zou uren moeten graven in de handleidingen.

Een cv is een stuk papier waar het opsommen van opsommingstekens onbeduidend is. Een slechte huur is erger dan geen huur. Ik neem aan dat je geen persoonlijke aanbeveling had van iemand van het team, dus de inhurende manager is op zoek naar een demonstratie van bekwaamheid. Het is waar dat een echt productieklaar systeem veel langer zou duren, maar de test vroeg niet om productieklaar te zijn, omdat het vroeg wat je met meer tijd zou hebben gedaan. Succes op de test toont aan dat je vloeiend met alle lagen omgaat en nog belangrijker dat je weet hoe je prioriteiten moet stellen. Laat het werken en maak het mooi!

Een twee uur durende test is niet de tijd voor architectuur-astronautica.

Bovendien ben je bijna zeker niet de eerste kandidaat die deze test te zien krijgt. Het team heeft hun filter meerdere keren gebruikt en misschien zelfs aangepast, en ten minste één ontwikkelaar is erdoor gekomen. Door je neus op te steken - zoals de laatste jaren in de mode is geraakt - in rechtvaardige verontwaardiging of door ze te “op te voeden” waarom het een slechte test is, kom je volgens hen in de bozo-categorie terecht. Ze zullen denken, een andere uitsteller of primadonna we hebben niet te maken met.

Hoe gaan we er mee om? Bekijk het vanuit het perspectief van uw potentiële klant. In plaats van het af te doen als absurd, geef je het voordeel van de twijfel. Noteer voor een twee uur durende test kort uw aannames, maak de sunny-day-case voor het eenvoudige demowerk, en maak in het resterende tijdsbestek duidelijk hoe u een echt systeem robuust zou maken.

Zoals andere antwoorden ten minste hebben laten doorschemeren, kan de motivatie achter de test kan redelijk zijn, vooral als de test:

1. goed is afgestemd op de werkelijke functievereisten;
2. 2. Minimaliseert minder belangrijke elementen;
3. Is goed afgestemd op de huidige functie-eisen;
4. Is goed afgestemd op de huidige functie-eisen;
5. Is goed afgestemd op de huidige functie-eisen;
6. Is goed afgestemd op de huidige functie-eisen;
7. Is minder belangrijk;
8. Is goed afgestemd op de huidige functie-eisen;
9. Is minder belangrijk;
10. Is goed afgestemd op de huidige functie-eisen;
11. Is goed afgestemd op de huidige functie-eisen;
12. Is goed afgestemd op de huidige functie-eisen;
13. Is goed afgestemd op de huidige functie-eisen;
14. Is goed afgestemd op de behoeften van de gebruiker;
15. Is minder belangrijk;
16. Is minder belangrijk;
17. Is goed afgestemd op de behoeften van de gebruiker;
18. Is niet geschikt voor het gebruik van de functie. 3. is duidelijk geen poging om “vrij werk” te krijgen; en mogelijkerwijs
19. is het een poging tot “vrij werk”. 4. Komt met tenminste wat hints over wat de recensenten “zoeken”.

Bij een vorige baan heb ik een aantoonbaar “absurde” programmeertoets ontworpen en uitgevoerd. De taak was altijd een senior-level full-stack ASP.NET/SQL Server ontwikkelaar baan, en de taak bestond uit het maken van een zeer eenvoudige webapplicatie met een pagina en twee of drie eenvoudige opgeslagen procedures. De kandidaat voerde de test ter plaatse uit met behulp van standaard tools:

1. 1. Visual Studio (versie van de keuze van de kandidaat binnen de afgelopen twee of drie versies);
2. 2. SQL Server Management Studio; en
3. SQL Server Management Studio. 4. Een webbrowser, niet alleen voor het testen maar ook voor het opzoeken van documentatie, resources, enz,

Ik heb de kandidaat voorzien van een basis “shell” oplossing (in elk van de toegestane Visual Studio versies), en ik heb de database en tabellen op voorhand aangemaakt.

Ik gaf de kandidaat een beschrijving van één pagina en vertelde de kandidaat dat ik binnen tien minuten terug zou komen om elke vraag hierover te beantwoorden, waarna ze een uur de tijd zou hebben om de opdracht af te ronden.

Toen ik na tien minuten terugkwam, na het beantwoorden van eventuele vragen, vertelde ik de kandidaat dat als ze niet zeker wist dat ze elk deel van de taak binnen het uur kon afmaken, ze zou kunnen overwegen zich te concentreren op een deel van de taak die ze kon afmaken en binnen de toegewezen tijd aan de slag te gaan. Ik zei ook dat als ze nog meer vragen had tijdens het uur, ze me twee cellen verderop kon vinden en vragen kon stellen.

Omdat ik de test schreef, kon ik hem van begin tot eind in ongeveer vijfenveertig minuten afwerken. Ik had absoluut niet verwacht dat de kandidaten de hele test in een uur zouden afronden. De “absurde” tijdslimiet was er om drie redenen:

1. We wilden zien of de kandidaat zelfs maar een half-redelijke greep had op de functie-eisen. Vergeet niet, dit was voor een hogere functie. (Meer dan de helft van de tijd was het antwoord “nee.”)
2. 2. De kandidaat moet in staat zijn om de basisvereisten te analyseren en deze op te splitsen in hanteerbare, discrete taken.
3. De kandidaat moet in staat zijn om de basisvereisten te analyseren. 3. Het verlengen van de test na een uur zou meer van de tijd van de kandidaat vergen zonder ons veel of geen aanvullende informatie te geven.

Aan het einde van het uur vroeg ik de kandidaat om mij te laten zien wat ze had, of ze een deel van een lopende oplossing had om te demonstreren, enz. Over het algemeen namen we op dit moment ongeveer vijf minuten de tijd om het werk door te nemen, waarna de kandidaat een één-op-één gesprek had met de manager. Tijdens dat interview keek het ontwikkelingsteam allemaal naar wat de kandidaat had ingediend. We keken reëel uit naar deze taak omdat het nooit saai was.

Als de kandidaat een lopende oplossing had die het beoogde deel van de totale taak afhandelde, kwam de kandidaat vrijwel zeker door deze fase van het interview heen. Zelfs als de oplossing nog niet gelopen was, zouden we, als we substantiële vooruitgang en bewijs van de competentie van de kandidaat konden zien, de kandidaat normaal gesproken nog steeds in overweging nemen. We hebben altijd de browsergeschiedenis van de kandidaat gecontroleerd om te zien welke bronnen zij heeft geraadpleegd.

Redenen waarom de feitelijke kandidaten niet zijn geslaagd, zijn onder andere:

1. 1. Letterlijk niets produceren na het hele uur. Het spijt me te moeten zeggen dat deze situatie meerdere keren is gebeurd.
2. 2. Het plagiaat van de huidige baan van de kandidaat en het proberen (en falen) om deze aan te passen om aan de eisen van de test te voldoen. Toen we dit vermoedden, zou de browser geschiedenis het weggeven.
3. 3. Het onvermogen om een verbindingsreeks te vormen om de applicatie met de database te verbinden. Dit lijkt misschien een beetje oneerlijk, maar vergeet niet dat we op zoek waren naar senior-level kandidaten, inclusief senior-level SQL Server-ontwikkelingservaring. We verwachten zeker niet dat de kandidaat zich herinnert hoe een connectie string te bouwen, maar we verwachten dat de kandidaat het snel kan opzoeken. ConnectionStringBuilder zou ook prima zijn geweest, maar niemand heeft er ooit gebruik van gemaakt. Het allereerste voorbeeld van https://www.connectionstrings.com/sql-server/ zou prima hebben gewerkt.

Er was nog een deel van het interview met de manager en het ontwikkelingsteam samen, en we stelden vragen over de oplossing van de kandidaat, hoe ze de rest van het project zou hebben benaderd, etc.

Samenvattend adviseer ik om de motivatie van de werkgever voor een “absurde” test in overweging te nemen, alvorens deze uit de hand te laten lopen.

_ Dit antwoord zegt niet of dit soort testen goed zijn of niet (of dat ik ze door de vingers zie), maar richt zich op de specifieke vraag._

Hoe kan ik beslissen of ik technische testen moet uitvoeren die ik absurd vind (e. g. een onredelijk grote taak met een korte tijdslimiet) in de toekomst?

Zoals je in de echte wereld zou doen:

• Communiceer hoe lang de taak redelijkerwijs zou duren.
• Maak een plan van wat je moet doen in de gegeven tijd (d.w.z, Doe minder, of doe het slechter, of beide).
• Doe zoveel als je kunt, tot het minste niveau van kwaliteit dat je kunt verdragen. Focus op het krijgen van een werkende oplossing voor een complete oplossing.
• Documenteer duidelijk waar je de hoeken van het net haalt, wat de implicaties zijn, en de resulterende TODO’s.

Dit alles zou me enorm helpen, als werkgever of klant, om te beoordelen of ik met je wil werken.

Afhankelijk van de managementstructuur van de werkgever/klant, kan de man die je in dienst heeft (d.w.z. je directe baas/klant) heel goed in een positie zijn waar hij geen invloed kan hebben op wat voor werk je krijgt. Matrix management bestaat wel degelijk… in dit geval heb ik liever iemand die dergelijke situaties met gratie kan afhandelen dan een held die de grootste code aller tijden levert, maar niet in staat is om te communiceren over tijd/kwaliteitslimieten.

De exacte maatstaf om voor meer kwaliteit te gaan, of voor meer inhoud, hangt af. Bijvoorbeeld, in jouw geval zal je waarschijnlijk vooral geïnteresseerd zijn in het feit dat je kwaliteitswerk kunt leveren. Dus je zou een paar functies kunnen knippen (door het gebruik van een plaatshouder enz.), maar houd de kwaliteit van je code hoog. Op dezelfde manier, als het werk, zeg maar, veiligheidsgerelateerd is, zou u hetzelfde doen. Maar als het een volledig onkritisch bewijs is van het concept van iets, dan zou men meer de andere kant op kunnen gaan. Documenteer dit alles (beknopt), en je bent goed op weg.

PS: Ik hou ervan om “gekke of slechte” oordelen te vermijden. Dat wil zeggen, je moet je er niet druk over maken of de klant gewoon gek is, of er op uit is om je te pakken te krijgen (d.w.z. gratis werk te laten verrichten), alleen te oordelen naar de omvang van de taak. De reële hoeveelheid die voor u van belang is, is uw tijd, en dat stond vast. Zolang je het goed vindt om de twee uur te investeren in een potentiële nieuwe klant, maakt het niet uit of de taak gemakkelijk te doen is, of een hogedrukklus, of slechts twee uurtjes kletsen op hun kantoor.

Er is absoluut niets mis met de 2 uur durende krankzinnige technische test. Alle andere kandidaten zouden dezelfde test moeten doen, dus de kans dat je de baan aangeboden krijgt is niet anders dan een eenvoudige beginnersprogrammeeroefening. Er was geen vooroordeel; je werd gevraagd om het te doen omdat je gewoon gesolliciteerd had voor de functie.

Je bent de verkoper op de arbeidsmarkt, en het is jouw verantwoordelijkheid om de kopers zoveel mogelijk tegemoet te komen. Je hebt weinig onderhandelingskracht, behalve dan dat je voor een andere functie gaat. Zeker, een programmeertoets die alle kandidaten zouden moeten doen is niet onredelijk, ongeacht of je er daadwerkelijk mee kunt concurreren of niet. Als u hooggekwalificeerd bent voor de baan, maar de test niet kunt afleggen, zouden andere kandidaten ook niet in staat zijn om de test af te leggen. Dus wat is het probleem?

Je doet je best. Ben je boos omdat je niet voor de functie wordt aangeboden? Het bedrijf moet iemand inhuren, dus iemand anders zou het misschien beter gedaan hebben. Het punt voor een onmogelijke programmeertest is om de best presterende kandidaat te vinden. Of de beste kandidaat de oefening afmaakt is niet relevant.

hoe kan ik beslissen of ik technische testen moet doen die ik absurd vind

Je moet je op je gemak voelen voor elke technische test als je denkt dat je de vaardigheden voor de baan hebt en alle andere kandidaten het zouden moeten doen. Doe nooit een krankzinnige test als je denkt dat het een poging is voor gratis programmeerwerk of/en die je krijgt vanwege vooringenomenheid (bv. racisme).

PS: Ik heb nooit gezegd dat OP niet “goed genoeg” is. @TessellatingHeckler