
Still uit de film “Harry Potter en de Gevangene van Azkaban”
Het probleem met deze wereld is dat goed opgeleide mensen vol twijfels zijn, maar idioten vol vertrouwen.
Charles Bukowski
Onlangs heb ik weer een één-op-één programmeerles gegeven. In tegenstelling tot reguliere lessen was het onderwerp niet taalconstructie of probleemoplossing. De student deelde zijn zorgen over de toekomstige werkgelegenheid. De student zelf was behoorlijk slim. Een van degenen die naar de cursus komt, voltooit het hele programma sneller dan wie dan ook en met originele oplossingen, maar onderschat zichzelf voortdurend oprecht. Naar mijn mening komen dergelijke twijfels alleen voort uit een gebrek aan informatie. Ik heb tijdens de les geïmproviseerd geprobeerd deze leemte op te vullen.
De vragen waren ongeveer zo:
- Jaarlijks studeren veel studenten af aan de universiteit en gaan allemaal op zoek naar werk. Dat zijn veel mensen. Ze zullen waarschijnlijk de beste mensen aannemen, maar ik krijg geen plek.
- Wat moet ik doen als ik het verpruts en meteen wordt ontslagen?
- Wat als ze tijdens het werk beseffen dat ik dom ben en me eruit schoppen?
Deze student was niet de eerste persoon aan wie ik dergelijke vragen beantwoordde. Veel mensen hebben ze, en meestal moeten ze zonder voorbereiding op de hoogte worden gesteld. Deze keer besloot ik mijn monoloog in een notitieboekje op te schrijven. Ik dacht dat het een paar alinea’s zouden zijn, maar uiteindelijk waren het genoeg voor een heel artikel.
Het artikel beschrijft het standpunt vanuit mijn standpunt en op basis van mijn ervaring. Onze wereld is echter zeer divers en er gebeuren verbazingwekkende dingen. Als u het ergens niet mee eens bent of als uw ervaring op de een of andere manier anders is, schrijf dan een reactie.
Het artikel is geschreven door een ontwikkelaar voor ontwikkelaars. Als u echter van plan bent tests, administratie of iets anders op IT-gebied te doen, zullen sommige adviezen ook nuttig voor u zijn.
Ze zullen je helemaal niet aannemen
Als je je voorstelt dat veel universiteiten jaarlijks honderden studenten afstuderen, wordt het ongemakkelijk. Hoe kan je concurreren met zo’n groot publiek?
Helaas hebben niet alle afgestudeerden voldoende technische opleiding. Vraag eens aan een universiteitsstudent die je kent: hoe krijgen mensen in zijn groep toegang tot examens in disciplines als ‘databases’ of ‘grondbeginselen van algoritmisering en programmeren’? In een groep van 30 mensen zullen er op zijn best 3-5 "gevorderde" jongens zijn die eigenlijk alles zelf hebben gedaan. De rest kopieert er eenvoudigweg van, vult antwoorden op vragen en verzendt deze.
Zo was het toen ik alleen studeerde. Mijn ervaring is echter mogelijk niet representatief. Daarom stelde ik deze vraag aan verschillende studenten. Het antwoord was vrijwel hetzelfde. De respondenten waren afkomstig van verschillende universiteiten en hogescholen. Discussies over de redenen laat ik buiten het bestek van dit artikel vallen. Ik heb niet genoeg tijd voor een volwaardig onderzoek, dus ik zal een conclusie trekken uit de beschikbare feiten.
Van de honderden afgestudeerden zijn er slechts enkele tientallen interessant voor werkgevers
Er zijn maar weinig afgestudeerden die echte concurrentie kunnen bieden aan een capabele student met een goede voorbereiding. Maar zelfs als je gewetensvol hebt gestudeerd, word je na het eerste sollicitatiegesprek hoogstwaarschijnlijk niet aangenomen. Na de tweede waarschijnlijk ook. Alles kan goed aflopen, maar het is beter om je niet voor te bereiden op een aanval, maar op een belegering. Een mislukte poging om een baan te krijgen is slechts een reden om aan je fouten te werken en het opnieuw te proberen. Ik zal het niet hebben over de voorbereiding op interviews. Er is op internet al veel over dit onderwerp geschreven. Ik wil alleen zeggen dat er nuances zijn in interviews die je trainingsprogramma waarschijnlijk niet de tijd zal nemen om uit te leggen. Zoek deze informatie zelf op, dit kan het aantal pogingen verminderen.
Waanzin is de exacte herhaling van dezelfde actie. Keer op keer hopen op verandering
Albert Einstein
Om te voorkomen dat interviews in waanzin veranderen, moet je na elke nieuwe poging verbeteren. Onthoud of schrijf de vragen op die u tijdens het interview werden gesteld. Wanneer u thuiskomt, bladert u door deze lijst en controleert u uzelf via internet. Zo begrijp je waar jij en de interviewer een fout hebben gemaakt. Dit gebeurt ook. Bekijk of bestudeer de onderwerpen waarop u slecht heeft gepresteerd en probeer het opnieuw.
Bovendien is er sprake van een uitgesproken seizoensinvloed op de arbeidsmarkt. Slimme bedrijven plannen personeel op basis van afstudeerdata. In het voorjaar zijn er meer vacatures voor nieuwkomers dan op andere momenten. De concurrentie is op dit moment echter groter.
Stom - ontslagen worden
Wanneer iemand zonder ervaring wordt aangenomen, gelden er overeenkomstige verwachtingen voor hem.
Van een nieuwkomer in de functie wordt verwacht dat hij:
- Kennis van algemene technische basis
- Het bestuderen van de specifieke kenmerken van het vakgebied van het bedrijf
- Het beheersen van de gebruikte tools en praktijken
Sommige organisaties bieden trainingen aan voor nieuwkomers over de gebruikte technologieën, hulpmiddelen en lokale procedures. Bijvoorbeeld goede manieren bij het gebruik van zakelijke e-mail, de procedure voor het wijzigen van documenten in een wiki, lokale functies van het werken met VCS en een bugtracker.
Er zijn ook technische introductiecursussen, maar het nut ervan is twijfelachtig. Als het om werkgelegenheid gaat, zijn de werkgevers ervan overtuigd dat je over voldoende kennis beschikt. Het is het beste om dergelijke cursussen gewoon te goeder trouw te volgen, als een kleine formaliteit. Misschien zit er echt iets nuttigs in.
Wanneer u met uw werk begint, onthoud dan dat een beginner zeker niet de taak krijgt om een dringende, complexe en tegelijkertijd belangrijke taak op te lossen. Hoogstwaarschijnlijk zal er slechts één van deze eigenschappen zijn. Of eenvoudig maar urgent: repareer de lay-out, stuur iemand een bestand, reproduceer het probleem. Of moeilijk, maar zonder enige hoop op voltooiing - zodat de beginner meer rake verzamelt. Of belangrijk, maar experimenteel. Bijvoorbeeld een project dat iedereen al heel lang wil, maar geen tijd kan vinden om uit te voeren.
Taken voor het beheersen van de tools zullen “moeilijk” en kunstmatig zijn. Hoogstwaarschijnlijk zal dit een vereenvoudigde versie van het hoofdsysteem zijn. Dergelijke taken gebruiken dezelfde technologiestapel en dezelfde domeintermen als het hele project. In dit geval wordt het uitvoeringsresultaat niet aan de eindgebruiker doorgegeven. Dit kan demotiverend zijn, maar het is beter om dit sentiment te weerstaan. Een kunstmatige taak moet gewetensvol worden uitgevoerd, alsof het lot van het project ervan afhangt.
Het resultaat van het oplossen van uw eerste probleem zal de eerste indruk van u vormen bij collega's die niet bij het interview aanwezig waren.
Een andere optie voor de toolmastering-taak is “het project uitvoeren op een lokale machine/testomgeving.” Soms wordt dit proces beschreven in de instructies. Maar ze zijn meestal oud en op sommige plaatsen verouderd. U kunt echte voordelen voor het project opleveren als u nieuwe instructies schrijft met verduidelijkingen over de problemen die zich hebben voorgedaan. Op de universiteit moest je voor sommige vakgebieden toch een RGR schrijven voor een rapport. Het is hier bijna hetzelfde. Het document moet de acties weerspiegelen die moeten worden uitgevoerd om te lanceren.
Normaal gesproken zijn de stappen om een product in een testomgeving uit te voeren ongeveer als volgt:
- kloon een repository, schakel over naar een bepaalde branch of tag
- maak een configuratiebestand
- bereid de databasestructuur voor
- vul het met testgegevens
- het project bouwen of compileren,
- voer een reeks consolescripts in een bepaalde volgorde uit
Tijdens het lokaal draaien van een systeem zullen zich onvermijdelijk onverwachte problemen voordoen.
Het vinden van oplossingen voor problemen moet worden toegevoegd aan de implementatie-instructies. Op die manier zullen deze problemen zich de volgende keer dat u de instructies volgt niet meer voordoen. Let bij het invullen van configuratiebestanden en het aanroepen van scripts goed op welke waarde waar wordt gebruikt en waarmee deze moet overeenkomen. Als een project bijvoorbeeld wordt gebouwd met een CI-systeem en vervolgens wordt uitgevoerd door een script, is het belangrijk te begrijpen waar de branchenaam of het commitnummer moet worden ingevoerd. Soms vereist het script dat er gegevens worden doorgegeven. IP-adressen Ofwel de DNS-naam van de database, de bijbehorende gebruikersnaam en het wachtwoord. In dit geval moet u het specifieke adres voor de testomgeving weten, welke gebruikersnamen deze bevat en welke wachtwoorden u daarvoor moet opgeven.
Sommige taken lijken misschien eenvoudig voor ervaren ontwikkelaars, maar uitdagend voor stagiaires. Dit is normaal.
Ontwikkelaars moeten elke dag technische problemen oplossen. Ervaren medewerkers hebben al veel problemen opgelost, terwijl nieuwkomers er nog mee om moeten gaan. De beste tactiek is om alle aangetroffen fouten vast te leggen in het document “problemen oplossen met ${taaknaam}”. Voor elk probleem moet je een hypothese formuleren over de oorzaak, oplossingen op internet zoeken en ze een voor een proberen. Het resultaat van elke poging moet ook worden geregistreerd.
Door uw onderzoek te registreren in de vorm van een document kunt u:
- ontlaad kleine details uit je hoofd. Bijvoorbeeld configuratieparameters, DNS/IP-adressen, consoleopdrachten en SQL-query's.
- onthoud “wat heb ik gisteren gedaan” wanneer de taak meerdere dagen duurt
- dwaal niet in cirkels. U kunt altijd lezen wat u eerder hebt gedaan en begrijpen dat u bent teruggekeerd naar het oorspronkelijke probleem
- geef duidelijk antwoord op de vraag: “wat heb je vandaag gedaan?” ook al is er nog geen kant-en-klare oplossing.
Je moet de status van je taken kunnen communiceren met collega's
Van tijd tot tijd zullen collega's geïnteresseerd zijn in uw successen en die van hen delen. Reserveer hier dagelijks of wekelijks wat tijd voor.
Als je de problemen die je tegenkomt en hebt opgelost niet bijhoudt, zal het beschrijven van je successen er als volgt uitzien: “Ik heb geprobeerd de taak uit te voeren, maar ik kan het niet. Ik zoek nog steeds naar een oplossing.” Uit dit verhaal wordt niet duidelijk of de stagiair iets deed of alleen maar zat te lezen. Heeft hij hulp nodig? Is de situatie sinds gisteren veranderd?
Als u een document zoekt naar oplossingen, kunt u zeggen: 'Ik probeer deze taak uit te voeren. Ik had dit soort fouten. Dit is hoe ik besloot. Deze heb ik nog niet behandeld. Er zijn deze hypothesen en oplossingen. Ik ben ze nu aan het controleren."
Als de taak op een of andere manier kan worden gemeten, moet de status cijfers bevatten. Voor de taak 'eenheidstests voor een module schrijven' kunt u bijvoorbeeld zeggen: 'Ik ben van plan twintig tests uit te voeren, nu heb ik er tien geschreven.'
Hoe meer details u verstrekt, hoe beter uw collega's zullen begrijpen wat u hebt gedaan. Dit zal een positieve houding ten opzichte van u creëren bij uw collega's en hen in staat stellen te begrijpen of u hulp nodig heeft of niet.
Vraag gerust om hulp
Ik schreef hierboven dat wanneer zich een probleem voordoet, je een hypothese moet formuleren over de oorzaken en mogelijke oplossingen. Het komt echter voor dat de hypothesen niet gerechtvaardigd zijn en dat onafhankelijk gevonden oplossingen voor het probleem niet werken. In dit geval is het beter om hulp te vragen. Om de aandacht van je collega's niet te misbruiken, moet je elk probleem zelf aanpakken. Als je binnen een paar uur geen oplossing hebt kunnen vinden, is het tijd om advies in te winnen bij meer ervaren kameraden.
Een goed beginpunt is door te vragen: “Heeft iemand dit probleem eerder tegengekomen?” met een korte beschrijving van het probleem. Het is raadzaam een stukje van de foutmelding of een screenshot bij te voegen. Het is beter om dit bericht voor de eerste keer naar een algemene werkchat te sturen. Zo leid je degenen die het echt druk hebben niet af van hun werk. Gratis collega's zien uw bericht en kunnen u helpen.
Als na een bericht in de algemene chat niemand heeft geholpen, probeer dan een ervaren collega op te vangen tijdens een pauze: lunchen, thee/koffie gaan drinken, een partijtje tennis spelen of een rookpauze houden. Als dit niet lukt, meld dan uw moeilijkheden tijdens de vergadering of stand-up.
Als bekende problemen worden opgelost, kan dit allemaal eindigen. Als het probleem nieuw is, wordt er een onderzoek gestart, waarbij afhankelijk van de omstandigheden moet worden gehandeld.
De “belangrijke” beginnerstaken die de eindgebruiker nodig heeft, zullen saai en klein zijn. Bijvoorbeeld: “voeg een extra kolom toe aan het rapport” of “corrigeer een typefout in de afgedrukte vorm” of “implementeer een modelmethode voor het laden van clientkenmerken uit het DBMS.” Het doel van dergelijke taken is dat de beginner vertrouwd raakt met het vakgebied en deze integreert in het dagelijkse werk.
Het is belangrijk om niet alleen het probleem technisch op te lossen, maar ook om de kennis van het vakgebied uit te breiden.
Termen verschijnen in de taakbeschrijving, in chats en gesprekken. Ze kunnen op bekende zelfstandige naamwoorden lijken. Binnen het kader van het informatiesysteem hebben ze echter een speciale, preciezere betekenis. De betekenis van ontdekte termen kan het beste worden vastgelegd in een speciaal document: een woordenboek met termen. Bij het toevoegen aan het woordenboek volstaat het om uw begrip van het woord op te schrijven, maar voor een echte decodering is het beter om contact op te nemen met een analist. Als het ontbreekt, ga dan naar de oldtimers van het project. Het bijhouden van een termenwoordenboek is een van de eenvoudigste manieren om vertrouwd te raken met het onderwerpgebied van een project.
Zodra je een gemeenschappelijke taal hebt gevonden met je collega's, zullen ze je niet als een nieuwe stagiair gaan zien, maar als een gelijkwaardige specialist.
Er zijn speciale taken, bijvoorbeeld 'eenheidstests voor een module schrijven'. Je kunt er nauwelijks lang mee bezig blijven op zoek naar oplossingen. Tegelijkertijd is het behoorlijk serieus en wordt het niet alleen gegeven voor stagiaires. Schriftelijke tests verhogen de stabiliteit van het project door het aantal bugs in de applicatie te verminderen en de tijd voor menselijke tests te verkorten. In een ideale wereld worden unit-tests onmiddellijk tijdens de ontwikkeling geschreven, maar de realiteit is altijd anders. Het komt voor dat de ontwikkelaar van een module deze volledig in zijn hoofd houdt en de noodzaak niet ziet om ze te schrijven. “Alles is duidelijk, wat valt er te testen?” Soms worden modules in de haastmodus geschreven en is er geen tijd meer voor unit-tests. In de echte wereld zijn er dus mogelijk geen unit-tests. Daarom wordt de taak van het schrijven van unit-tests toevertrouwd aan een beginner. Op deze manier kan de stagiair sneller aan het project wennen en kan het project tijd besparen van beterbetaalde specialisten.
Het komt voor dat stagiaires en nieuwkomers de rol van volwaardige testers krijgen toegewezen. Meestal moet u, voordat u dit doet, het product lokaal implementeren en de vereisten lezen. Als gevolg hiervan wordt van de nieuwe medewerker verwacht dat hij:
- vragen als ‘als je het zo doet, zal het ook zo uitpakken. Dit staat niet in de eisen. Dat zou zo moeten zijn?"
- taken in de bugtracker “de vereisten zeggen dit, maar in werkelijkheid is het anders geschreven.”
Testen is een te breed terrein voor dit artikel. Als u een soortgelijke taak krijgt, zoek dan op internet naar de beste manier om deze te voltooien.
Als je het verprutst, word je ontslagen
Als het in een normale organisatie plotseling gebeurt dat een onervaren medewerker toegang krijgt tot iets cruciaals en iets bederft, dan zal degene die dit heeft laten gebeuren de schuld krijgen. Omdat een beginner standaard geen toegang heeft tot kritieke infrastructuur. Met de juiste begeleiding zullen ze niet alle honden aan een onervaren stagiair laten verspillen.
Als er iets gebeurt, zullen ze je niet ontslaan vanwege één incident. Mensen leren van fouten. De stagiair die de fout heeft gemaakt, heeft een waardevolle les geleerd en is heel anders dan andere stagiaires. Als je iemand ontslaat die een fout maakt, zal iemand anders in zijn plaats komen en op dezelfde manier een fout maken.
Het belangrijkste is om van fouten te leren en ze niet opnieuw te herhalen.
Als een persoon geen conclusies trekt uit zijn fouten, zullen ze proberen afscheid van hem te nemen. De wereld is echter divers. Bij sommige gangsterorganisaties kunnen ze je bij de eerste fout meteen uit het raam gooien. Maar het is beter om dergelijke bedrijven te vermijden door eerst navraag te doen of tijdens het sollicitatiegesprek meer te weten te komen.
Het is beter om incidenten te vermijden
Zelfs als u persoonlijk niet wordt ontslagen vanwege een fout, zal een dergelijk incident ongewenste problemen veroorzaken voor uw team en het project als geheel. Wees daarom bijzonder voorzichtig met het verwijderen of maken van tabellen in de database, bestanden, service-instances en documenten in de projectkennisbank. Kom je het adres van een nieuwe aansluiting tegen, check dan met minimaal twee verschillende mensen wat daar gedaan kan worden. Controleer uw rechten in omgevingen niet door vallen en opstaan, maar door de juiste opdrachten te gebruiken. Bijvoorbeeld rechten om bestanden te verwijderen met behulp van het `ls` commando, rechten om met tabellen in mysql te werken met behulp van het `SHOW GRANTS FOR 'user'@'host';` commando, en dergelijke. In bijna elke tool heb je een vergelijkbare mogelijkheid.
Wanneer u bestanden bewerkt, bewaar dan voor de zekerheid een kopie van het origineel.
Er worden verschillende barrières opgetrokken tussen de stagiair en de eindgebruiker.
Als je je product meteen aan de consument zou kunnen geven, kun je geen baan vinden, maar ‘vrij zwemmen’. Maar hoewel u niet zo'n kans (en tegelijkertijd verantwoordelijkheid) heeft, moet u verschillende stadia van controle over het project doorlopen.
De eerste hiervan is verificatie door een mentor. Hij evalueert de beslissing van de nieuweling vanuit technisch oogpunt. Als er geen mentor is toegewezen, moet je er een vinden. Om dit te doen, moet je een van de oldtimers van het project kiezen en hem tijdens een pauze vragen om naar de oplossing te kijken: is het probleem correct opgelost? Als hij gaat kijken en reageren, dan is er een mentor gevonden. Als hij het negeert, is het de moeite waard om het aan iemand anders te vragen.
De volgende fase is kwaliteitsborging. In het Russisch - testers. In Sovjetstijl - standaardcontrole en kwaliteitscontroleafdeling. Zij moeten ervoor zorgen dat de prestaties van de stagiair consistent zijn met de hem opgedragen taak. Ze zullen de code zelden lezen. Meestal controleren testers het gebouwde project, dat de ontwikkelaar opslaat in het versiebeheersysteem.
De derde fase is de releasemanager. Er is misschien geen aparte persoon voor deze taak, maar toch speelt iemand de rol. Hij controleert of testers hebben bevestigd dat het project kan worden vrijgegeven. Hierna voert het de activiteiten uit om het product aan de eindgebruikers te leveren.
In kleine organisaties bestaan deze barrières om verschillende redenen mogelijk niet. Ze zullen een nieuweling echter niet de taak geven om iets belangrijks te veranderen. Omdat niemand dit risico nodig heeft.
Je moet eerst betrokken raken bij de strijd, en dan zullen we zien.
Napoleon Bonaparte
Ik hoop dat dit artikel je zal helpen je onzekerheid te overwinnen en je eerste CV in te dienen. Natuurlijk moet je je eerst voorbereiden. Maar het is niet nodig om te overdrijven. Waarschijnlijk heb je al een aantal jaren aan een universiteit of hogeschool gestudeerd. Waar moet je heen? Uiteindelijk is het beter om een keer ‘nee’ te horen van een specialist en aan fouten te werken, dan elke dag ‘nee’ tegen jezelf te zeggen en te stoppen met professioneel groeien.
Eenmaal aangenomen, moet je je concentreren op het doorgroeien van stagiair tot volwaardig teamlid. Dit soort groei gaat meestal gepaard met een verhoging van uw loon.
Ik wens je geduld en doorzettingsvermogen.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Wat waren je eerste taken in je eerste baan in de IT?
Complex
Belangrijk
Dringend
Geen van bovenstaande
75 gebruikers hebben gestemd. 20 gebruikers onthielden zich van stemming.
Wat moest je eerst doen bij je eerste baan?
Installeer het product lokaal
Test een bestaand product
Voer een training uit, neptaak
Doe een experimenteel, echt project voor een klant
63 gebruikers hebben gestemd. 25 gebruikers onthielden zich van stemming.
Hoeveel studenten in uw groep hebben tijdens de training zelfstandig opdrachten in technische vakken kunnen uitvoeren?
1 van 10
1 van 5
Elke seconde
Alles, met zeldzame uitzonderingen
70 gebruikers hebben gestemd. 19 gebruikers onthielden zich van stemming.
Bron: www.habr.com
