
Een scène uit de film 'Harry Potter en de gevangene van Azkabaan'
Het probleem in deze wereld is dat opgeleide mensen vol twijfels zitten, terwijl idioten vol zelfvertrouwen zijn.
Charles Bukowski
Onlangs had ik weer een persoonlijke programmeerles. In tegenstelling tot normale lessen was het onderwerp deze keer niet de taalconstructie of het oplossen van een probleem. De student deelde zijn zorgen over zijn toekomstige werkgelegenheid. Hij was een vrij slimme leerling. Een van die mensen die sneller dan iedereen door het programma heen gaat en originele oplossingen vindt, maar zichzelf voortdurend oprecht onderwaardeert. Naar mijn mening ontstaan zulke twijfels alleen door een gebrek aan informatie. Deze leemte heb ik tijdens de les geprobeerd aan te vullen met improvisatie.
De vragen waren ongeveer als volgt:
- Elk jaar komen er vele studenten van universiteiten af, en ze gaan allemaal op zoek naar werk. Dat zijn heel veel mensen. Ze zullen zeker de besten kiezen, en voor mij is er geen plek.
- Wat als ik een fout maak en ze me meteen ontslaan?
- Wat als ze tijdens het werk ontdekken dat ik dom ben en me wegsturen?
Deze student was niet de eerste persoon aan wie ik dergelijke vragen beantwoordde. Ze komen bij velen voor, en meestal moet ik zonder voorbereiding vertellen. Deze keer besloot ik mijn monoloog in een notitieboekje te schrijven. Ik dacht dat het een paar paragrafen zou zijn, maar het werd een heel artikel.
Het artikel beschrijft mijn kijk vanuit mijn perspectief en op basis van mijn ervaring. Onze wereld is echter zeer divers, en er gebeuren opvallende dingen. Als je het ergens niet mee eens bent of als jouw ervaring op een bepaalde manier anders is, laat dan alsjeblieft een reactie achter.
Het artikel is geschreven door een ontwikkelaar voor ontwikkelaars. Maar als je van plan bent om te testen, te administreren of iets anders in de IT te doen, dan zullen sommige van de tips ook voor jou nuttig zijn.
Ze zullen helemaal niet aannemen.
Wanneer je je voorstelt dat jaarlijks tientallen universiteiten honderden studenten afstuderen, wordt het ongemakkelijk. Hoe moet je concurreren met zo'n enorme menigte?
Helaas heeft niet elke afgestudeerde voldoende technische voorbereiding. Probeer een bekende student uit de universiteit te vragen: hoe krijgen mensen in zijn groep toegang tot examens in vakken zoals 'databases' of 'basisprincipes van algoritmiek en programmeren'? In een groep van 30 mensen zijn er in het beste geval 3-5 'gevorderde' jongens die alles echt zelf hebben gedaan. De anderen copiëren gewoon van hen, stampen antwoorden op vragen en slagen.
Dat was ook zo toen ik zelf studeerde. Mijn ervaring kan echter niet representatief zijn. Daarom heb ik deze vraag aan verschillende studenten gesteld. Het antwoord was ongeveer hetzelfde. De respondenten kwamen van verschillende hogescholen en universiteiten. De overwegingen over de redenen laat ik buiten dit artikel. Ik heb niet de middelen voor een volledig onderzoek, dus ik trek een conclusie uit de beschikbare feiten.
Van de honderden afgestudeerden zijn er slechts een paar tientallen die interesse wekken voor werkgevers.
Weinig afgestudeerden kunnen serieuze concurrentie vormen voor een capabele student met een goede voorbereiding. Ook al heb je hard geleerd, na het eerste sollicitatiegesprek word je waarschijnlijk alsnog niet aangenomen. Na de tweede waarschijnlijk ook niet. Het kan goed uitpakken, maar het is beter om je niet voor een aanval voor te bereiden, maar voor een belegering. Een mislukte poging om een baan te krijgen is slechts een reden om te leren van je fouten en het opnieuw te proberen. Ik zal niet ingaan op de voorbereiding op sollicitatiegesprekken. Daarover is al veel geschreven op internet. Ik zeg alleen dit: er zijn nuances in het doorlopen van sollicitatiegesprekken, waarvoor in jouw opleidingsprogramma waarschijnlijk geen tijd is besteed. Zoek deze informatie zelf op; het kan het aantal probeerpogingen verkorten.
Waanzin is het precies herhalen van dezelfde handeling. Steeds opnieuw, in de hoop op verandering.
Albert Einstein
Om te voorkomen dat sollicitatiegesprekken een waanzin worden, moet je na elke nieuwe poging beter worden. Vergeet niet of schrijf de vragen op die je tijdens het sollicitatiegesprek zijn gesteld. Bekijk deze lijst thuis en controleer jezelf met behulp van het internet. Zo ontdek je waar je een fout hebt gemaakt en waar de interviewer dat mogelijk ook heeft. Dit gebeurt ook. Herhaal of bestudeer de onderwerpen waarin je slecht hebt geantwoord, en probeer het opnieuw.
Bovendien is er een duidelijke seizoensgebondenheid op de arbeidsmarkt. Vernuftige bedrijven plannen hun wervingen met inachtneming van de afstudeerdatums van onderwijsinstellingen. In de lente zijn er meer vacatures voor nieuwkomers dan op andere momenten. Maar de concurrentie is in deze periode ook hoger.
Dom — zal worden ontslagen
Wanneer iemand zonder ervaring wordt aangenomen, zijn er bepaalde verwachtingen.
Van een nieuwkomer wordt verwacht:
- Kennis van de algemene technische basis
- Studie van de bijzonderheden van de bedrijfsdomein
- Beheersing van de gebruikte tools en praktijken
In sommige organisaties worden er opleidingscursussen georganiseerd voor nieuwkomers over de gebruikte technologieën, hulpmiddelen en lokale gewoonten. Bijvoorbeeld regels van goed gedrag bij het gebruik van de bedrijfs-e-mail, de procedure voor het wijzigen van documenten in de wiki, lokale bijzonderheden in het werken met VCS en issue trackers.
Er zijn ook technische inleidende cursussen, maar hun nut is twijfelachtig. Als het zo ver gekomen is dat je een baan hebt gevonden, betekent dat dat werkgevers hebben bevestigd dat je een bepaald niveau van kennis hebt. Het is het beste om dergelijke cursussen gewoon goed te doorlopen, als een kleine formaliteit. Misschien zit er inderdaad iets nuttigs in.
Wanneer je aan het werk gaat, onthoud dan dat een nieuwkomer beslist geen dringende, complexe en tegelijkertijd belangrijke taak toegewezen zal krijgen. Hoogstwaarschijnlijk is er slechts één van deze eigenschappen. Ofwel simpel maar dringend: de opmaak corrigeren, iemand een bestand toesturen, een probleem reproduceren. Ofwel complex, maar zonder enige hoop op voltooiing — alleen om ervoor te zorgen dat de nieuwkomer zo veel mogelijk hindernissen ontmoet. Ofwel belangrijk, maar experimenteel. Bijvoorbeeld een project dat iedereen al lang wil, maar waaraan ze geen tijd kunnen besteden voor de implementatie.
De taken om je instrumentarium te beheersen zullen "complex" en kunstmatig zijn. Hoogstwaarschijnlijk is dit een vereenvoudigde versie van het hoofd systeem. Bij dergelijke taken wordt dezelfde technologie-stack en dezelfde termen uit het domein gebruikt als in het hele project. Daarbij zal het resultaat van de uitvoering niet aan de eindgebruiker worden gegeven. Dit kan demotiverend zijn, maar het is beter om deze stemming te weerstaan. Een kunstmatige taak moet zorgvuldig worden uitgevoerd, alsof het lot van het project ervan afhangt.
Het resultaat van het oplossen van uw eerste taak zal de eerste indruk van u bij collega's, die niet op het interview waren, bepalen.
Een andere variant van de taak om de tools te beheersen is "een project op de lokale machine/testomgeving te starten". Soms is dit proces beschreven in de instructie. Maar die zijn meestal verouderd en soms niet meer relevant. U kunt een echte bijdrage aan het project leveren door een nieuwe instructie te schrijven met verduidelijkingen over de opgekomen problemen. U heeft vast wel ooit een RGR geschreven voor een rapport voor verschillende disciplines op de universiteit. Dit is bijna hetzelfde. In het document moeten de stappen worden weergegeven die nodig zijn om te starten.
De stappen voor het starten van het product op de testomgeving zijn meestal ongeveer als volgt:
- de repository klonen, schakelen naar een bepaalde tak of tag
- een configuratiebestand opstellen
- de database structuur voorbereiden
- deze vullen met testdata
- de build of compilatie van het project uitvoeren,
- een reeks console scripts in een bepaalde volgorde uitvoeren
Tijdens het lokaal opstarten van het systeem zullen onvermijdelijk onvoorziene problemen opduiken.
Gevonden oplossingen voor problemen moeten worden toegevoegd aan de implementatie-instructie. Dan zullen deze problemen de volgende keer niet meer optreden bij het volgen van de instructie. Bij het invullen van configuratiebestanden en het aanroepen van scripts moet men letten op welke waarde waar wordt gebruikt, en waarmee het moet overeenstemmen. Bijvoorbeeld, als het project wordt gebouwd met behulp van een CI-systeem en vervolgens wordt uitgevoerd met een script, is het belangrijk om te begrijpen waar de naam van de tak of het commitnummer moet worden geschreven. Soms is het zo dat het script vereist dat er een IP-adressen of DNS-naam voor de database, de gebruikersnaam en het wachtwoord worden doorgegeven. In dat geval moet men weten welk adres precies moet worden gebruikt voor de testomgeving, welke gebruikersnamen daar zijn en welke wachtwoorden daarvoor moeten worden opgegeven.
Sommige taken kunnen eenvoudig lijken voor ervaren ontwikkelaars, maar moeilijkheden veroorzaken voor stagiaires. Dit is heel normaal.
Ontwikkelaars staan dagelijks voor technische problemen. Ervaren medewerkers hebben veel problemen al eerder opgelost, terwijl nieuwkomers nog met deze uitdagingen moeten omgaan. De beste tactiek is om alle tegengekomen fouten vast te leggen in het document "probleemoplossing met ${taaknaam}". Voor elk probleem moet je een hypothese over de oorzaak formuleren, online naar oplossingen zoeken en deze één voor één uitproberen. Documenteer ook het resultaat van elke poging.
Het vastleggen van je bevindingen in een document stelt je in staat om:
- de kleine details uit je hoofd te halen. Bijvoorbeeld configuratie-instellingen, DNS/IP-adressen, consoleopdrachten en SQL-query's.
- je te herinneren aan "wat deed ik gisteren" wanneer een taak zich over meerdere dagen uitstrekt.
- niet rond in cirkels te dwalen. Je kunt altijd teruglezen wat je eerder deed en begrijpen dat je terug bij het oorspronkelijke probleem bent.
- duidelijk te antwoorden op de vraag: "wat heb je vandaag gedaan?" zelfs als er nog geen oplossing is.
Je moet in staat zijn om de status van je taken aan collega’s te vertellen.
Af en toe zullen collega's geïnteresseerd zijn in je vorderingen en hun successen delen. Hiervoor wordt dagelijks of wekelijks een klein beetje tijd besteed.
Als je de tegengekomen en opgeloste problemen niet bijhoudt, zal de beschrijving van je prestaties eruitzien als: "Ik heb geprobeerd deze taak te voltooien, maar het lukt me niet. Ik ben momenteel op zoek naar een oplossing." Uit zo'n verhaal blijkt niet of de stagiair iets heeft gedaan of gewoon aan het lezen was. Heeft hij hulp nodig? Is de situatie sinds gisteren veranderd?
Als je een document bijhoudt met oplossingen, kun je zeggen: "Ik probeer deze taak te voltooien. Ik heb deze fouten ondervonden. Deze heb ik zo opgelost. Deze ben ik nog niet tegengekomen. Ik heb enkele hypothesen en oplossingsmogelijkheden, die ik nu aan het testen ben."
Als een taak enigszins kan worden gemeten, moeten er cijfers in de status naar voren komen. Bijvoorbeeld, voor de taak "eenheidstests voor een module schrijven" kun je zeggen: "ik plan om 20 tests te maken, ik heb er nu 10 geschreven."
Hoe meer details je deelt, hoe beter je collega's begrijpen wat je hebt gedaan. Dit zal een positief beeld van jou bij je collega's vormen en hen laten begrijpen of je hulp nodig hebt of niet.
Wees niet bang om om hulp te vragen.
Boven heb ik geschreven dat wanneer er een probleem zich voordoet, je een hypothese over de oorzaken en mogelijke oplossingen moet formuleren. Het komt echter voor dat hypothesen niet kloppen en zelfgevonden oplossingen niet werken. In dat geval is het beter om hulp te vragen. Om de aandacht van collega's niet te veel te belasten, is het belangrijk om eerst zelf over elk probleem na te denken. Als je na een paar uur geen oplossing hebt gevonden, is het tijd om advies te vragen aan meer ervaren collega's.
Het is het beste om te beginnen met de vraag: "Heeft iemand eerder met dit probleem te maken gehad?" met een beknopte beschrijving van het probleem. Het is wenselijk om een stukje foutmelding of een screenshot bij te voegen. Dit bericht kun je het beste voor de eerste keer naar een algemeen werkchat sturen. Zo stoor je degenen die echt druk zijn niet. Vrije collega's zullen je bericht zien en kunnen helpen.
Als er na het bericht in de algemene chat niemand heeft geholpen, probeer dan een ervaren collega te benaderen tijdens een pauze: lunchtijd, het halen van thee/koffie, een potje tennis of een rookpauze. Als dat niet lukt, geef dan je problemen aan tijdens een vergadering of stand-up.
Bij het oplossen van bekende problemen kan het daarbij eindigen. Als het probleem nieuw is, begint het onderzoek, waarbij je moet handelen volgens de omstandigheden.
De "belangrijke" taken voor nieuwkomers, die door de eindgebruiker nodig zijn, zijn vaak saai en klein. Bijvoorbeeld "een extra kolom aan het rapport toevoegen" of "een typefout in het afdrukformulier corrigeren" of "een methode in het model implementeren om klantattributen uit de database te laden". Het doel van dergelijke taken is dat de nieuwkomer vertrouwd raakt met het onderwerp en zich integreert in het dagelijkse werk.
Het is belangrijk niet alleen technisch het probleem op te lossen, maar ook de kennis van het onderwerp uit te breiden.
In de taakbeschrijving, chats en gesprekken zullen termen voorkomen. Ze kunnen eruitzien als lange bekende zelfstandige naamwoorden. Maar binnen het kader van het informatiesysteem krijgen ze een speciale, nauwkeurigere betekenis. Het is het beste om de betekenis van de gevonden termen in een speciaal document vast te leggen - een terminologiewoordenboek. Bij het toevoegen aan het woordenboek is het voldoende om je begrip van het woord op te schrijven, maar voor de juiste uitleg kun je het beste een analist raadplegen. Als die er niet is, kunnen de oude rotten van het project helpen. Het bijhouden van een terminologiewoordenboek is een van de eenvoudigste manieren om je in te werken in het onderwerp van het project.
Zodra je een klik hebt gevonden met je collega's, zullen ze je niet meer zien als een stagiair, maar als een gelijke specialist.
Er zijn bijzondere taken, zoals 'schrijf unit tests voor de module'. Het is onwaarschijnlijk dat je hier lang vastkomt met het zoeken naar oplossingen. Tegelijkertijd is het een aanzienlijke taak die niet alleen voor de opleiding van de stagiair is. De geschreven tests verhogen de stabiliteit van het project door bugs in de applicatie te verminderen en de testtijd door mensen te verkorten. In een ideale wereld worden unit tests direct tijdens de ontwikkeling geschreven, maar de werkelijkheid is vaak anders. Soms houdt de ontwikkelaar van de module deze volledig in zijn hoofd en ziet hij de noodzaak niet om ze te schrijven. 'Het is allemaal zo duidelijk wat hier getest moet worden?' Soms worden modules in noodtempo geschreven en is er geen tijd voor unit tests. Daarom wordt de taak om unit tests te schrijven vaak aan de stagiair gegeven. Op deze manier kan de stagiair zich sneller in het project inwerken en kan het project tijd besparen van duurder betaalde specialisten.
Het komt voor dat stagiairs en nieuwkomers de rol van volledige testers krijgen. Gewoonlijk moet je hiervoor het product lokaal opzetten en de vereisten lezen. Van de nieuwe medewerker wordt het volgende verwacht:
- vragen zoals 'als ik dit zo doe, dan komt dit zo uit. Dit staat niet in de eisen. Hoe moet het zijn?'
- taken in de bugtracker 'het staat zo in de vereisten, maar in werkelijkheid is het anders'.
Testen is een uiterst breed werkterrein voor dit artikel. Als je een dergelijke taak krijgt, zoek dan op internet naar de beste manieren om het uit te voeren.
Als je fouten maakt, word je ontslagen.
In een normale organisatie, als het zou gebeuren dat een onervaren medewerker toegang krijgt tot iets kritisch en er iets verpest, dan is degene die dit heeft toegestaan de schuldige. Want een nieuwkomer heeft standaard geen toegang tot kritieke infrastructuur. Bij adequaat leiderschap zal niemand de schuld geven aan de onervaren stagiair.
Als er iets gebeurt, zullen ze niet iemand ontslaan vanwege één incident. Mensen leren van fouten. Een stagiair die een fout heeft gemaakt, heeft een waardevolle les geleerd en is daarmee heel anders dan andere stagiairs. Als je iemand ontslaat wegens een fout, komt er weer iemand anders die precies hetzelfde zal doen.
Het belangrijkste is om van fouten te leren en ze niet opnieuw te maken.
Als iemand echter geen lessen trekt uit zijn fouten, dan zal men proberen afscheid van hem te nemen. De wereld is echter divers. In een bepaalde criminele organisatie zou je meteen uit het raam gegooid kunnen worden bij de eerste fout. Maar het is beter om zulke bedrijven te vermijden; zorg ervoor dat je vooraf informatie verzamelt of meer leert tijdens het sollicitatiegesprek.
Incidenten moeten beter worden voorkomen.
Zelfs als je persoonlijk niet wordt ontslagen voor een fout, kan zo'n incident ongewenste problemen voor je team en het project als geheel veroorzaken. Wees dus bijzonder voorzichtig met operaties zoals het verwijderen of aanmaken van tabellen in de database, bestanden, service-instanties en documenten in de kennisbank van het project. Als je een nieuw verbindingsadres tegenkomt, vraag dan ten minste aan twee verschillende mensen wat er mogelijk is. Controleer je rechten in omgevingen niet door middel van proberen en fouten, maar met de juiste commando's. Bijvoorbeeld, controleer je rechten om bestanden te verwijderen met het commando `ls`, je rechten om met tabellen in mysql te werken met het commando `SHOW GRANTS FOR ‘user’@’host’;` en dergelijke. Bijna elke tool biedt deze mogelijkheid.
Bij het bewerken van bestanden, zorg ervoor dat je voor de zekerheid een kopie van het originele bestand opslaat.
Tussen de stagiair en de eindgebruiker worden verschillende barrières opgebouwd.
Als je jouw product meteen aan de consument zou kunnen aanbieden, zou je niet eens een baan hoeven nemen, maar zou je kunnen gaan freelancen. Maar zolang je die mogelijkheid (en daarmee ook de verantwoordelijkheid) niet hebt, moet je verschillende controlefasen op het project doorlopen.
De eerste stap is de beoordeling door een mentor. Hij evalueert de oplossing van de nieuwkomer vanuit een technisch perspectief. Als er geen mentor is aangesteld, moet je iemand vinden. Kies hiervoor een van de ervaren leden van het project en vraag hem tijdens de pauze om de oplossing te bekijken: is de taak goed opgelost? Als hij begint te kijken en te antwoorden, is de mentor gevonden. Als hij negeert, vraag dan iemand anders.
De volgende fase is Quality Assurance. In het Nederlands: testers. In de Sovjetstijl: normcontrole en kwaliteitscontrole. Zij moeten ervoor zorgen dat het resultaat van het werk van de stagiair overeenkomt met de taak die voor hem is gesteld. Zij zullen zelden de code lezen. Meestal controleren testers het verzamelde project dat de ontwikkelaar opslaat in het versiebeheersysteem.
De derde fase is de release manager. Voor deze taak is er misschien geen aparte persoon, maar iemand vervult deze rol toch. Hij controleert of de testers hebben bevestigd dat het project kan worden uitgebracht. Daarna onderneemt hij actie om het product aan de eindgebruikers te leveren.
In kleine organisaties kunnen deze barrières om verschillende redenen ontbreken. Maar zij zullen de nieuwkomer geen belangrijke wijzigingstaak geven. Dit risico is niemand waard.
Je moet eerst de strijd aangaan, en dan zie je wel verder.
Napoleon Bonaparte
Ik hoop dat dit artikel je helpt om je onzekerheid te overwinnen en je eerste cv te versturen. Natuurlijk moet je je van tevoren voorbereiden. Maar je moet het niet overdrijven. Je hebt waarschijnlijk al enkele jaren op de universiteit of hogeschool gestudeerd. Hoe lang wil je nog wachten? Uiteindelijk is het beter om eenmaal ‘nee’ van een specialist te horen en daarvan te leren, dan elke dag ‘nee’ tegen jezelf te zeggen en stagnatie in je professionele groei te ervaren.
Na de indiensttreding is het belangrijk om je te concentreren op de groei van stagiair naar volwaardig teamlid. Dergelijke groei gaat meestal gepaard met een verhoging van je salaris.
Ik wens je geduld en doorzettingsvermogen.
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Wat waren ongeveer je eerste taken op je eerste IT-werkplek?
Complexe taken
Belangrijke taken
Spoedeisende taken
Geen van de bovenstaande
75 gebruikers stemden. 20 gebruikers onthielden zich.
Wat moest je in het begin ongeveer doen op je eerste werkplek?
Installeer het product lokaal
Test een bestaand product
Voer een oefenopdracht uit
Werk aan een experimenteel, echt project voor een klant
63 gebruikers hebben gestemd. 25 gebruikers hebben zich onthouden.
Hoeveel studenten in uw groep konden tijdens de opleiding zelfstandig opdrachten uitvoeren op technische vakken?
1 op 10
1 op 5
Elke tweede
Iedereen, met enkele uitzonderingen
70 gebruikers hebben gestemd. 19 gebruikers hebben zich onthouden.
Bron: habr.com
