🥇Hvordan finder man et job med en god kontrakt

Hej, Habrovski!

For the past while, I've had to attend quite a number of interviews and even received offers from some well-known and lesser-known European companies. However, today I won't be discussing how to prepare for tricky programming tasks or how to better demonstrate soft skills. Instead, we will talk about open source and labor contracts, how well they correspond to each other, and what potential pitfalls exist. There is nothing sadder than being forced to drop out after three rounds of interviews and a week's worth of homework when you come to realize that you won't sign that labor contract even under the gun. I've seen many labor contracts and learned to differentiate very bad ones from bad ones, bad from mediocre, and mediocre from good ones. More details under the cut.

Ansvarsfraskrivelse: In this article, I will describe not only my own experience but also the experiences of my acquaintances. For obvious reasons, I will not name companies by name in this article.

So, imagine the situation: you spend a week working on a test assignment, go through three rounds of interviews, receive an offer for relocation to Western Europe with relatively good pay, and you're ready to drop everything and pack your bags. However, something raises a red flag; you ask for a bit more time to think it over and request a draft of the labor contract. You carefully review the contract, delve into all the details, and realize that this is an example of a very bad contract under which you:

Have no right to disclose anything at all. Otherwise, you'll face a hefty fine.
You can forget about your little projects. Otherwise, you'll face a hefty fine.
If there is even the slightest connection between what you create/invent long after being hired and what you worked on or even learned/experienced with this employer, you must transfer all rights accordingly to them. Even if this requires traveling to another country and filing for patents and rights transfers. Otherwise, you'll face a hefty fine.
You are looking at overtime without any additional compensation.
The employer can change the terms of the contract unilaterally.

And this is far from exhaustive. In general, it's clear — steer clear.

Even before this incident, I had been seriously contemplating about Intellectual property clause eller Afsnit om intellektuelle ejendomsrettigheder i ansættelseskontrakter for IT-industrien og programmører særligt. At skrive kvalitetskode er ofte den eneste færdighed, vi har, og som vi finpudser gennem mange år i håbet om at sælge den til en højere pris, men på et tidspunkt kommer forståelsen af, at færdigheder ikke kun kan sælges, men også investeres i open source, som i stigende grad kaldes den mørke materie i softwareindustrien, hvor der gælder sin egen 'tyngdekraft' og andre 'fysiklove'. At bidrage til åbne projekter kan være til selvudvikling og netværk med andre udviklere, men ofte også for at blive bemærket af potentielle arbejdsgivere. En profil på GitHub kan ofte sige meget mere om en udvikler end en profil på LinkedIn, og at skrive åben kode, deltage i kollektiv kodegennemgang, indberette fejl og skrive dokumentation for projekter med åben kildekode bliver en del af hverdagen for de mest aktive og målrettede udviklere.

Ved at deltage i forskellige IT-konferencer i Europa stødte jeg på termen IP-venlig i relation til ansættelseskontrakter. Denne betegnelse refererer til aftaler, der på ingen måde begrænser medarbejdere i at anvende deres intellektuelle indsats i fritiden, eller indfører rimelige begrænsninger for at beskytte arbejdsgiver mod konkurrence. For eksempel er kontraktbetingelser, der siger, at 'alt, hvad der er lavet på arbejdsgiverens udstyr og efter arbejdsgiverens direkte anvisning, tilhører arbejdsgiveren' - mere IP-venlige end 'alt, hvad der er lavet i løbet af ansættelsesaftalens gyldighed, tilhører uden forbehold arbejdsgiveren'. Som sagt, mærk forskellen!

Google var de første, der forstod vigtigheden af at støtte open source-projekter blandt udviklere ved at gøre det muligt for deres ansatte at bruge op til 20% af arbejdstiden på åbne projekter; andre førende virksomheder har taget tendensen op og følger med. Fordelen for virksomhederne er åbenlys; det er en win-win-strategi, da firmaet opnår et ry som hub for de mest talentfulde udviklere, hvilket i sin tur tiltrækker endnu flere dygtige fagfolk. Indgangen til sådan nogle virksomheder er meget høj, og de udvælger de bedste af de bedste.

De fleste mindre virksomheder kender kun til de nye tendenser af høring og forsøger at inkludere så mange begrænsninger som muligt i ansættelseskontrakten. Jeg har set sådanne, uden at overdrive, formuleringer som "Arbejdsgiveren ejer alt, hvad der skabes af medarbejderen." Det er en trist kendsgerning, men mange udviklere accepterer sådanne vilkår på grund af mangel på viden om intellektuel ejendomsret eller på grund af en svær livssituation (man har ikke overskud til at vælge mellem tilbud). Hvordan kan situationen blive bedre? Efter min mening er der flere måder:

Øge bevidstheden blandt IT-arbejdere om intellektuel ejendomsret.
Fremme idéerne om IP-venlige kontrakter blandt arbejdsgivere.
Ikke blot deltage i open source-projekter, men også være evangelister for open source.
Støtte udviklere i deres strid med virksomhederne, arbejde for at den offentlige mening er på udviklerens side, hvis virksomheden forsøger at "tage" projektet.

Som resultat fandt jeg et job med væsentligt bedre kontraktvilkår. Det vigtigste er ikke at kaste sig over det første tilbud og fortsætte med at søge. Og bidrage til open source, for udviklerens kulturelle arv er hans kode, og hvis al koden, udvikleren skriver, er for virksomheder, så er hans arv, hans synlige og håndgribelige aftryk på det digitale landskab lig med null.

P.S. Hvis du kunne lide denne artikel, så bliv mine følgere på Habré – jeg har mange urealiserede idéer, som jeg gerne vil skrive om, så du vil være de første til at høre om dem.

P.P.S. Artiklen planlægges at have en fortsættelse...

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.