Új hozzászólás Aktív témák
-
Lortech
addikt
válasz
buherton
#39289
üzenetére
Persze, hogy könnyű. De a fórumtárs még motiváltnak tűnik, sikerülhet neki karriert váltani - az üfsz melóban (vagy épp a mosogatásban) nincs perspektíva, ellenben korán kiéghet benne az ember.
Neked grat a certekhez.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
-
Lortech
addikt
Azért kiderült az utóbbi pár napban a topikból, hogy:
-a SAFe nagyot megy mostanában
nem, csak cargo cultos agyament helyeken dívik, ahol egy keretrendszertől várják az agilitást-a devops egy munkakör
továbbra sem az, hanem egy felfogás, munkamódszer, kultúra, amiben nincs fal a fejlesztő és üzemeltető között, hanem egy csapatban vagy legalábbis szoros kollaborációban közösen fejleszti és üzemelteti, ownolja a terméket, szolgáltatást.-devopsos ugyanazt csinálja, mint a sysadmin/ops-/infra engineer 20 évvel ezelőtt, csak épp fancy toolokkal
nem, aki üzemeltetéssel és infrával foglalkozik és kilométerekre van a fejlesztéstől, az továbbra sem devopsban dolgozik, csak a pozíciója át lett brandelve devopsra, mert már belépett egyszer aws konzolra.-a platform csapat a devops topológiák közül a király
nem az, hanem az egyik lehetséges antipattern, nem lebontja a silókat, hanem fenntartja-"a devopsos ember" (a topikban használt értelemben) az architekt, aki megmondja a frankót
nem az, általában fogalma sincs a termékfejlesztésről és az egyes alkalmazás domainekről, így adekvát architektúrát esélye se lenne lerakni, egy platform csapat leginkább egy közös toolsetet, runtime-ot tud adni, meg felette egy lehetőleg minél vékonyabb közös réteget, ami a szoftver architektúrának egy szelete csak-a banki informatika a szakmában az etalon
öö, valamelyik másik univerzumban.Amúgy jól mondod Madwe
a manuál tesztelő pozíció tökéletesen felesleges egy normális fejlesztő csapatban, ahol megvannak a megfelelő skillek tesztautomatizálásra. A jó ég mentsen meg attól a cégtől vagy projekttől, ahol manuál tesztelőn alapszik a tesztelési kultúra. Évek alatt a manuál tesztelősdi oda vezet, hogy nincs lefedettség, a release cycle lelassul, megnő a cost of change, majd lebénül a csapat release-elési képessége, a minőség pedig béka segge alatt.
Majd a manuál tesztelőnek fogom magyarázni, hogy mit hogy kell tesztelni, aztán majd release-kor arra fogok várni, hogy leteszteljen valamit a két kis kezével, ahelyett, hogy egyszer leautomatizáljuk a tesztet.Db team vagy dba megint tök felesleges általában a csapatok 99%-ába, mert semmi olyat nem tud, amit egy expert fejlesztőnek nem kéne tudnia megoldania.
Security team nem felesleges, de ugyancsak az ég óvjon attól a terméktől, ahol a security team biztosítja a termék biztonságosságát. Egy külön silós teamnek nem sok köze az egyes termékek alkalmazás fejlesztéséhez, céges szintű policykkel foglalkoznak, madártávlatból auditálnak, másik által írt toolokat, scannereket használnak, ami nem pótolja a fejlesztő csapaton belüli security funkciókat, megfelelő awarenesst, igényességet, kultúrát, és fordítva, ezek megléte nem helyettesíti a céges szintű security funkciókat, követelményeket, megfelelést. Ennek analógiájára a platform/ops/infra csapat se felesleges, sőt, csak tévesen devops csapatnak meg devops engineernek hívják őket.
A többi sem felesleges, csak nincs sok köze a fejlesztéshez, és nem keverendő ide.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
nyunyu
#32144
üzenetére
Az a "trükk", hogy mint mindenhez, JPA-hoz/Hibernate-hez is érteni kell. Egy ORM elrejt komplexitást és karbantarthatóbb, kényelmesebb megoldás lehetőségét kínálja a problémára, de a komplexitás ott marad. Mint a legtöbb +absztrakciónál, itt is az van, hogy nem neked kell megírni és maintainelni, de pontosan érteni kell, hogy hogy működik.
Van néhány ökölszabály, amit be kell tartani a fizikai adatmodell tervezésekor és ennek ORM-mel leképezése során, hogy szép és performáns legyen.
A memória használatot nagyon szépen lehet korlátozni és előre meghatározott keretek közötti tartani java adathozzáférésnél, és kell is. Ezek az apróságok különböztetnek meg egy robusztus rendszert egy naiv fejlesztők által összerakott, általában működik típusútól.
Nem stackoverflowt kell olvasgatni, hanem például Vlad Mihalceát. De mindenekelőtt olyan embert érdemes alkalmazni, aki ért a munkájához és nem egy próbálkozót.[ Szerkesztve ]
Thank you to god for making me an atheist
-
#32056
Lortech
addikt
Oppenheimer
#32015
Lortech
addikt
válasz
Oppenheimer
#32015
üzenetére
Semennyire. Magyar cégnél sem szeretnék dolgozni többet, az pedig súlyosbító tényező, hogy állami megrendelésekből és pályázatokból él. Dolgoztam beszállítóként állami ill. államhoz közeli cégeknek, a megrendelő oldali projektvezetés általában hányinger, és ez megfertőzi a szakmai és céges kultúrát a beszállító cégnél is, valamint a kollégák minőségét és motivációját is predesztinálja.
De persze lehet jó dolgokat csinálni ilyen projekteken is, csak senkit nem érdekel, mert nem ez a lényeg, hanem az, hogy papíron teljesüljekek a célok, és hogy a lóvé el legyen költve koppra, az értékteremtés teljesen sokadlagos. Kinek mit vesz be a gyomra, ha nem érdekel semmi, csak hogy megkapd a fizetést, és függetleníteni tudod magad a sok szarságtól, ami egy ilyen helyen van, akkor lehet, hogy neked való.
Ha eddig inkább saját termékfejlesztésen dolgoztál (?) és beszállító oldalra kerülsz, az ég és föld tud lenni, ezt érdemes körüljárni váltásnál.Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Vision
#29761
üzenetére
Ez oké, de nem nagyon kompenzálják túl ezért a kockázatért, amit azzal vállal, hogy a cégbe fekteti az idejét és segít leküzdeni a fizetési problémákat. Az alapfizetése, valamint az éves fizetés ~10%-nak megfelelő equity egy likviditási problémákkal küzdő, kétes jövőjű startupnál nem túl bíztató egy, a szervezet alján lévő mezítlábas fejlesztőként.
#29763 Tapsi
+1 kérdés, tud-e a cégben kulcsemberré válni idővel, hogy a termék sikeressé válása esetén megfelelően tudjon szakmailag vagy anyagilag profitálni ebből, és hogy a tulajdonos hajlandó-e osztozni a sikerekben, és nem csak a kockázatban...[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Én mostanában szívesen járok be irodába. Úgy választottam lakhelyet és munkahelyet, hogy jó legyen tömegközlekedéssel és autóval is bejárni. Parkolóhelyem van, 20percen belül beérek, tömegközlekedés itt tesz le az épület előtt.
Jó szakmai munka folyik az irodában, sokkal gördülékenyebb az információáramlás mind csapaton belül mind csapatokon átívelően, mikor többen bent vagyunk. Még erősen formálódó csapat vagyunk, ilyenkor különösen hasznos a gyakori személyes kollaboráció. Akkor járok be, amikor akarok, nincs semmi nyomás.
Az iroda kapacitása többszöröse az átlag bent tartózkodók számának, oda ülök ahova akarok, ha akarom, akkor olyan helyre, ahol egész nap nem nagyon találkozom senkivel. Rengeteg 1-2 fős tárgyaló van és boxok is, ahol el lehet lenni, ha túl sok az inger. Az iroda nagyon jól felszerelt, jó asztalok, székek, tágas terek vannak, de jól vannak határolva, így nincs openoffice érzése az embernek. Remek az ellátás, mindenféle étel, ital gyümölcs, az épületben színvonalas étterem.
Mikor bejövök, kevésbé folyik össze a munkám és a privát életem.
Bizonyos feladatokat hatékonyabban tudok megoldani otthon ingerszegényebb környezetben, például egy már fejemben lévő megoldást leimplementálni, más feladatokat - pl. emberekhez, folyamatokhoz kapcsolódó dolgokat viszont az irodában. Sokkal gyorsabban sokkal mélyebb kapcsolatokat lehet kialakítani személyesen, amik közvetlenebbé teszik a viszonyt a kollégákkal, ami sokkal gördülékenyebbé teszi a kollaborációt.Thank you to god for making me an atheist
-
Lortech
addikt
válasz
voodoo98
#27490
üzenetére
Alkalmazottként br. 1.6-2.2m
Értékelhető szakmai életúttal, cloud, devops tapasztalattal, jó angollal remote nyugat-európai helyek elérhetőek e felett is.Oppenheimer:
Én is a SonarSource-ot választanám a kevés ismert infó alapján, de az biztos, hogy semmilyen módon nem befolyásolna a fórum véleménye.
Thank you to god for making me an atheist
-
#26199
Lortech
addikt
CyberPunk666
#26197
Lortech
addikt
válasz
CyberPunk666
#26197
üzenetére
És a profithoz vastagon hozzátartozik, hogy a magyar IT cégek jelentős része nemzetközi piacra dolgozik, vagy magyar piacra dolgozó cégként nemzetközi piacra dolgozó cégekkel kénytelen versenyezni.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Jó lenne egyébként ha lenne mód ezeket nevesítve, nyíltan megírni anélkül, hogy hátránytól kelljen tartania az embernek. Tisztulna a piac.
Sajnos nem megvalósítható jogi és egyéb akadályok miatt, így marad ez a jelenlegi vacak helyzet konzerválva.
Tudom, glassdoor, de nagyon korlátozottan működik.Thank you to god for making me an atheist
-
Lortech
addikt
-
Lortech
addikt
-
Lortech
addikt
válasz
Drizzt
#23817
üzenetére
Ez egy érdekes kérdés.. én is hasonlóan viselkedem. És ha továbbgondolod, rájössz, milyen apróságokon múlhat az, hogy hová jutsz karriered során, hiszen nem te irányítod, hanem eleve szűri a lehetőségeidet az, hogy milyen lehetőség talál meg, feltételezve hogy ahogy mondod, abból szűrsz tovább. Pedig az egész életedet meghatározhatja egy ilyen döntés. Sokat gondolkoztam ezen mostanában, hogyan lehetne jobban összekötni a keresletet a kínálattal, hogy ne ilyen esetleges és bizonytalan legyen ez az egész, ahogyan most működik.
Erről írt emvy is korábban, szerintem abszolút így van, ha céltudatosan be akarsz jutni egy céghez, majdnem függetlenül attól, hogy magad találtál rá vagy recruitertől jött, sokkal rugalmasabb vagy és inkább hajlandó vagy belemenni egy hosszabb és szívatósabb felvételi eljárásba.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Vision
#23805
üzenetére
Szerintem meg nem.
Én meg ezért nem csinálom (felvételiztető oldalról).
A 6 kört viccből hoztam fel tényleg, hogy átmenjen, hogy értem, hogy ez is egy plusz információ, ha olvasol a sorok között, egyet is értek vele, és adnék én is házi kódolós feladatot, ha nem tartanám előnyösebbnek azt, hogy elmondhassuk magunkról, hogy egyszerű a felvételi folyamatunk és hogy -1 kör van nálunk (multi, 3 kör, de csak 1 technikai, többi minimálisan szűr), mert még így is baromi nehéz a recruitereknek a fejlesztőket megszólítani és rávenni, hogy pályázzanak.Thank you to god for making me an atheist
-
Lortech
addikt
válasz
MrSealRD
#23799
üzenetére
Pont ez a lényeg. Mi csapattársakat keresünk, akiknek szeretnénk látni egy kis ízelítőt a gondolkodásmódjából. Nem csak a szakmai skillek számítanak. Ha valakit már a feladat ténye elriaszt akkor nem őt keressük. Ez is egy attitűd. Tehát a házi feladat sikeresen működött. Hol itt a hiba?!
Ott a hiba az általad beidézett mondatomban, elriaszt értékes jelentkezőket, akik egyébként el tudnák látni a pozíciót. Ez nem egyértelműen hiba? Nem azért van a felvételi folyamat, hogy eldöntse, alkalmas-e ellátni a pozíciót a jelölt?
Az attitűd valóban fontos, csakhogy oda vissza működik, a te attitűdöd az, hogy gyere kiscsávó, ha végigmész a szívatáson, akkor esetleg majd szóba áll veled egy fejlesztő is pár kör után.. A pályázónak is lehet véleménye arról, hogy milyen egy jó felvételi folyamat, és ha nem tud vele azonosulni, akkor buktátok és ez egyáltalán nem biztos, hogy win-win.Miből gondolod hogy nem léteznek ilyen feladatok? Lehet te ilyeneket láttál, de gondolj erre kicsit nyitottabban.
Pontosan ezért vettük a fáradtságot és találtunk ki olyan feladatot ami nagyon egyszerű valós példát vesz alapul... Illetve egy nagyon egyszerű algoritmusos feladatot... Egyszerűen látni kell a gondolkodásmód leképzését...
Jól tettétek, hogy valós példát találtatok ki, de írtam, hogy a kontextus mégis hiányzik, amit a csapat, a projekt ad, amibe hónapok után rázódik bele egy kolléga, így a példa ugyan valós lehet, de a szituáció maga nem.
Egyszerű algoritmusos feladat azért nem releváns, mert lesz aki kiguglizza, ebből mit szűrsz le? Csak a nagyon oda nem illő jelölteket szűröd ki, te erre azt mondod, hogy tök jó. Én azt mondom, hogy a jó jelölteket viszont feleslegesen szívattad vele és ettől romlik az interjú élmény.
Erre írtam még, hogy ugyanazt a feladatot sokféleképpen meg tudom oldani, ami mind jó lehet, és megpróbálok a másik fejével gondolkodni infomorzsák alapján, hogy mi legyen hangsúlyos a megoldásban, vagy összejön vagy nem. Te ebből hogyan szűröd le a gondolkodásmódomat?Miért a való életben nálatok nincsenek deadlineok? Meglepődnék. Arra kell figyelni, hogy itt nem a szoros időhatár a cél... De ezt pont a tapasztalatból fakadó becslési készség alapján be lehet lőni viszonylag jól.
Való életben normálisan te adod a commitmentet és az estimate-et és ez határozza meg közvetett módon a deadline-t, és az nem ilyen fél-1-2 órás időtáv. Határidőt meg amúgy ne keverjünk már egy időkorláttal. Az időkorlát nem azért probléma, amit felhoztál, hanem azért amit írtam, mert bezavarhat az eredmény megfelelő értékelésébe, értsd: nem biztos, hogy az az eredmény jön ki a pályázóból, ami egyébként benne van. Erre mondhatod, hogy jó, akkor kuka, én viszont erre azt mondom, hogy nem jó a folyamat, mivel emiatt elbukhattunk egy értékes jelentkezőt, aki ha van +10 perce, talán szebben megcsinálja mint aki összekrampácsolt valamit a megadott időre./Többire reagáltam ebben vagy az előzőben. /
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Vision
#23801
üzenetére
Hagyd meg nekem, hogy értem a saját érvrendszeremet. Elnézést érte, ha nem lehetett eléggé követni.
Sehol nem vesznek fel embert csak egy otthoni feladat kör alapján, ez szerintem egyértelmű mindenki számára, én is így kezeltem ezt. A kérdés az, amit a hozzászólásom feszeget, hogy szolgáltat-e elegendő információt a házi feladat eredménye ahhoz, hogy megérje a jelölt szívatását (és így a visszatartó erejét) illetve a mindkét fél által belefektetett effortot.
Én ha tehetném, hiring managerként 6 interjú kört tartanék és még a felmenőit is leinterjúztatnám. A realitás az, hogy ezt nagyon kevés cég teheti meg anélkül, hogy versenyhátrányba kerülne a jelenlegi munkaerő piacon.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Egyébként miért?
Azért, mert az átlag fejlesztő nem opensource contributor, egyszerűen nem csinál ilyesmit sem munkája során, sem a szabadidejében, ismeretlen számára ez a közeg, ő a felhasználója ezeknek a projekteknek. És ez alapján könnyen arra juthat, hogy nem őt keresitek, hiszen joggal feltételezheti, hogy valamiért csak ezt a feladatot találtátok ki és releváns a pozícióra nézve. Vagy másik oldalról közelítve, ti nyilván azért adtok ilyen feladatot, mert olyat kerestek, aki nem az átlagjózsi fejlesztő, hanem olyan, aki ettől ambíciózusabb, aminek egyik ismérve lehet, hogy opensource projektekbe kontribútál, de legalábbis egy ilyen feladattól nem torpan meg.
az információ, amire szükség van a mi esetünkben: el tud olvasni egy bugreportot, tud csinálni egy pull requestet. Igazából totál nem a kódolás része a lényeg, hanem az írásbeli kommunikáció. Az meg tok releváns.
Tetszőleges, jelölt által választott opensource projekt és annak egy bugreportja tetszőleges komplexitású, vagy releváns vagy nem, a bugreport leírása lehet jó vagy béna, a contributor guide lehet best practice vagy hülyeség, tehát az ő választása alapvetően behatárolja a megoldást és annak jóságát is. Persze lehet az alapján is következtetést levonni, hogy milyen projekt milyen ticketét választja, de már ezen félremehet a dolog.
Én nem azt mondom, hogy ez nem egy jó megközelítés, mert szerintem nektek ez tök jól működhet, máskülönben nem csinálnátok ugye, én azt mondom, hogy ez kevés cégnél működne (részedről nem volt olyan állítás, hogy mindenkinek így kéne csinálni, még mielőtt valaki ezt látja bele, nem ezzel az el nem hangzott állítással vitatkoztam).Thank you to god for making me an atheist
-
Lortech
addikt
Nem csak az kerül pénzbe a cégnek, ha felvesz valakit, akit nem kéne, az sok esetben többe kerül, ha a béna, versenyképtelen felvételi folyamat elriaszt értékes jelentkezőket, akik egyébként el tudnák látni a pozíciót.
A házi feladat sem a felvételiztetés Szent Grálja. Szűr, de semmi olyan eredményt nem produkál, amivel benyomásokon túlmutató, egzakt választ kaphatnánk a jelentkező alkalmasságára.
Emvyék módszere jópofa, de nem skálázódik, és elég esetlegesnek tűnik. Eleve egy ilyen kiírás a jelentkezők felső szeletére lő, a maradékot élből elriasztja, ami egy átlag jelentkezőre lövő cégnél sajnos nem működne.Ezer probléma van a házi feladatokkal (is).
-Legyen releváns, valós probléma, aminek köze van a pozícióhoz: nem tud teljesülni, mert a valós problémák túl komplexek (időigényesek) ahhoz, hogy házinak feladjuk, vagy a kontextus, a rendszer miatt komplex, amibe illeszkednie kellene a megoldásnak, amit nem lehet odatenni a kiíráshoz több okból sem.
-Időkorlát? Legyen, ne legyen? Javasolt idő, vagy hard limit legyen pl. online felülettel garantálva?
Ha nincs időkorlát, akkor kérdés, ki mennyi időt szánt rá és mit látott bele a feladatba. Mire koncentrált, helyességre, teljességre, olvashatóságra, strukturáltságra stb? Ha van javasolt időkorlát, vajon betartotta-e vagy háromszor annyi időt tolt bele mint aki becsületesen csinálta. Ha van hard időkorlát, be van szorítva a jelentkező, és esetleg feláldozza az olvashatóságot és a strukturáltságot azért, hogy legyen egy működő megoldás, vagy épp szép kódot ír csak tesztek már nem készültek el, vagy épp a teszteket megírta, de az implementáció nem teljesen készült el hozzájuk...
-Feladat kiírás és maga a megoldás folyamata nem életszerű, ezért az eredményéből sem lehet egyértelműen arra következtetni, hogy valós setupban hogy teljesítene a jelentkező. Való életben nem úgy kapja a fejlesztő a feladatot, mint egy felvételi során, hogy kap egy levelet egy pár soros leírással, amiben definiálva van a probléma és van mellé néhány instrukció és kész. Mégha le is van írva, hogy lehet kérdezni, nem fog megtörténni. Való életben a szoftverfejlesztés egy interaktív, kollaborációra épülő műfaj, a feladatot megelőzi pl. egy planning, beszélgetünk róla, ha később nem tudunk valamit, tisztázó kérdést teszünk fel ( netán mi magunk alakítjuk rugalmasan a feladatot is, ami viszont házinál fix), ismerjük a rendszert, a konvenciókat, a szokásos megoldásokat, amik illeszkednek a meglévő kódhoz, van style guide, van DoD, ami mind mind segít belőni azt, hogy mi az elvárt megoldás.
Én sok év fejlesztés után ugyanazt a feladatot ugyanazon a nyelven ugyanannyi idő alatt többféle paradigmában, többféle stílusban, a strukturáltság más más szintjein meg tudom csinálni, elfogadhatóan. Ha a ráfordított idő sem korlátos, akkor pedig tényleg még sokkal többféle módon le tudom kódolni ugyanazt a feladatot. Nem azért, mert nincs véleményem arról, hogy mi a jó megoldás, hanem mert nincs egyetlen egy jó megoldás - ami segítene a jó megoldás kiválasztásában, a kontextus, az ebben a felállásban pont hiányzik.
-Nehéz jól mérni a szenioritást is házi feladattal, főleg olyanokkal, amik fél - 1 - 2 órás algoritmizálós feladatok, ahol nem azon van a hangsúly, hogy egy adott problémát szépen strukturáltan modellezzünk és kulturált módon kódoljunk le, hanem mondjuk azon, hogy működjön és optimális legyen a megoldás. Lehet, hogy ezt egy egyetemről kiesett jobb képességű pályakezdő könnyebben veszi mint aki 15 éve backendet hegeszt Springben..A felvételi során minden házi feladatot, minden kérdést úgy kell nézni, hogy mi az az információ, amit az ezekre adott válaszból kinyerünk, mennyire egyértelmű, mennyire objektív, mennyire összehasonlítható a válasz. A házi feladat sem ad egzakt választ, csak egy benyomást. Az otthoni feladat a munkaadónak is idő, ki kell találni feladatot, oda kell adni, fizetni a hackerrank előfizetést, ki kell értekelnie a megoldást egy szakértőnek..
Ha nagyon nem ment a feladat, akkor nem kell tovább erőltetni a pályázot, de ha mondjuk not great, not terrible kategória.. akkor ez alapján nem lehet kiszórni, de felvenni sem. És akkor, volt egy felesleges x órás kanyar?
Hasonló benyomást szóban a technikai interjú során 5 perc alatt ki tudok alakítani magamban, ezért én nem erőltetem az otthoni feladatot a mindenkori csapatomba való felvételiztetés során.Thank you to god for making me an atheist
-
Lortech
addikt
válasz
#41635072
#23522
üzenetére
Én pont nem az 0,1%-ról és fehér holló esetekből indulok ki, sok különböző role-ra felvételiztetek éppen, én is épp váltok, és jó néhány ismerős is váltott mostanában, sok számot ismerek.
Én is azt írtam, hogy autóval együtt jó ajánlat.
A 4x1.2 emelés majd akkor lesz jó, ha realizálódott.
8 év tapasztalattal 4 év múlva nem lesz már egy "brutál" az 1.65m ajánlat. Ma sem lenne brutál, csak átlagon felüli.
Nincs okom irigykedni. A lehúzós rész részemről az, amire csak utaltam, 15 fős IT céget szembrebbenés nélkül húznak le a klotyón egyik napról a másikra, ha rosszra fordul a dolog, ezért én a jelenre koncentrálnék. A kiszámíthatóság remek, de arra nem egy kiscéggel kötött szóbeli megállapodás a garancia. De még egyszer, ez a jelenben sem egy rossz ajánlat, ezért ha minden más szempont szerint is jó ajánlat, akkor minden happy.
Én olyan autót hajtok éppen, amiből havonta 5 darabot tudnék venni.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
tboy93
#23519
üzenetére
Addig működik, amíg jól mennek a dolgok ( persze miért ne mennének jól..) Mindenesetre én csak akkor mennék bele ilyenbe, ha a jelenre vonatkozó megemelt bérrel is maradéktalanul elégedett lennék.
4 év tapasztalattal egy helyen, ahol kezdesz kulcsemberré válni, a 800+20% ma nem kimondottan erős, de az autóval már jó.Thank you to god for making me an atheist
-
Lortech
addikt
Ez azért megmosolyogtató. Code review, de az automatizált tesztelés és clean code is nem úri huncutságok, amik csak az időt viszik, hanem konkrétan azért vannak, hogy időt, tehát pénzt spóroljunk alkalmazásukkal, más-más időtávban persze. Code review már rövidtávon időt spórolhat. Egy fegyelmezett, összeszokott csapatnál, jó coding és style guideline megléte esetén, megfelelően definiált és megfelelő méretű változtatásoknál általában csak formalitás. Ha sokáig tart vagy sok körös, akkor ott van egyéb baj is.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Nem gondoltam, hogy én leszek az, aki valaha érvel bootcampek mellett..
re: bootcamp vs autodidakta tanulás témakörre
Egy bootcampen a tanulók csapat projekteken dolgoznak, ahol felszedhetnek olyan skilleket is, hogy hogyan kell egy csapatban dolgozni, csapattagokkal hogyan lehet együttműködni, együtt tervezni, közös kódon együtt dolgozni, hogyan lehet a feladatokat felosztani és szétosztani..
Az is más, hogy van határidő, amikorra el kell készülnie egy projektnek, autodidakta módon nem mindenki tud olyan fegyelmezett lenni, hogy folyamatosan a tanulásra fókuszál és megfelelő intenzitással képzi magát külső nyomás nélkül is.
Folyamatos számonkérés is van és feedback, ami elősegíti, hogy kevésbé menjenek félre a dolgok közben. Említették már a mentorokat is, persze van, hogy vak vezet világtalant esete forog fenn, de kezdőnek több mint a semmi.
Demó is van, ami a kommunikációs, prezentációs készséget fejleszti és talán más hozzáállást is eredményez a projekthez, ha tudod, hogy az arcodat kell adni a végtermékhez.
Ezek a dolgok teljesen kezdőknél szerintem fontosak és lényegi különbségek. Több közük van a valós munkavégzéshez.
Elhiszem, hogy vannak, akik autodidakta módon és ingyen képesek eljutni használható szintre, de szerintem az átlagnak nagy segítséget jelentenek ezek a keretek.
(pályakezdőkről vagy pályaváltó kezdőkről írtam, nem olyanokról, akik 10 éve fejlesztők és a 3. mellé még egy 4. nyelvet is felszednek egy esős vasárnap délután alatt)Thank you to god for making me an atheist
-
#22733
Lortech
addikt
GeeForGolf
#22730
Lortech
addikt
válasz
GeeForGolf
#22730
üzenetére
Nem kell mindenhez is érteni mindenkinek.
Cross-functional fejlesztő csapatról írtam. Ez nem azt jelenti, hogy egy-egy csapattag külön-külön is rendelkezik minden tudással. Egy fejlesztő csapatban elférnek ops, network, cloud stb fókusszal rendelkező fejlesztők, ugyanúgy mint mondjuk egy test automation engineer is. És attól lesz ez hatékony, hogy mindenkinek van egy közös értése arról, hogy mit kell megcsinálni és mindenki a saját feladatát meg tudja csinálni, míg ha kiszervezed a képességek nagy részét másik csapatokba, akkor nekik át kelladni, hogy mit kell csinálni, aminek egy része fog csak átmenni, mivel nincs ugyanaz az értésük, aztán erre commitmentet kérni, ütemezni, koordinálni, bevasalni rajtuk, aztán ha félremegy, kezdődik elölről és megy az egymásra mutogatás és seggvédés.
Azt értem, hogy nálatok szarul mennek a dolgok, de az egy komoly félreértése a fejlesztői szakmának, hogy devnek csak a kódot kell valahogy összekrampácsolni, utána meg próbálja meg életre kelteni az üzemeltetés, ahogy tudja.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Vision
#22720
üzenetére
De ez hogy néz ki a gyakorlatban? Ki üzemelteti, ki alakítja ki a cicd-t házon belül, ha nem egy devops csapat?
Gyakorlatban egy hatékony, ütőképes, minőségi emberekből álló, devops modellben dolgozó cross-functional fejlesztő csapat rendelkezik többek között azzal a képességgel, hogy a saját maga által választott toolokkal kialakítsa a saját CI/CD megoldását, továbbmegyek menedzselje a buildjeit és releaseit, megtervezze, kialakítsa, üzemeltesse és monitorozza az infráját. A fejlesztői csapatban a mozgástér és autonómia az alapja mindennek, akkor lesz (lehet) agilitás, ha a fejlesztő csapat meg tudja választani az eszközeit, önállóan tud dönteni, és önállóan el tudja végezni a feladatai nagy részét, és nem kell más csapatoktól függnie vagy azokhoz igazodnia. Nyilván szükséges mértékben kell igazodni és kell együttműködni más csapatokkal, de ezt is könnyíteni és elősegíteni kell, processzekkel és adminisztrációval való körbebástyázás helyett (pl. nyiss ticketet minden szarra).
Lehet azt mondani, hogy ehhez a működéshez a feltételek nem adottak sok szervezetben, pl. nem tudják elengedni a kontrollt, vagy nem elég rugalmas a szervezet, hogy megfelelően rugalmasan kezelje a csapatok összeállítását, nincs minőségi emberanyag és emiatt nincs teljesítmény, így bizalom és autonómia - mindenesetre az átcímkézés aligha old meg bármit.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Vision
#22710
üzenetére
Hogyne lehetne megcsinálni, de legtöbb középszerű (és középszerű emberekkel dolgozó) cég csak cargo cultig jut el, átcímkéz, átnevez, mímel, megvásárolja a polcról a dobozos "agilis" metodológiát, pl. SAFe, átnevezi az opsot devopsra, összedobálja a jól hangzó technológiákból a stacket mint egy receptet, aztán reméli, hogy majd jönnek az eredmények, közben pedig csak a dolgok lényege veszik el. Aztán időnként cserélődik a középmenedzsment kezdődik egy újabb iteráció és csodavárás.
Nem tankönyvi devopsról beszélek, a devops lényegi eleme a dev és ops közötti kommunikációs siló problematikájának orvoslása, ha meghagyjük egy külön fókusszal rendelkező, külön csapatként az opsot, nevezhetjük akárhogy, akadályozó tényezőként jelenik meg a szervezetben.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Ezzel részben egyet tudok érteni, ott van lényeges véleménykülönbség, hogy én ezt a központi teamet alapvetően nem devops teamként kezelem, kivéve ha ez a közös "platformfejlesztés" olyan szintű önálló hozzáadott fejlesztői tevékenységgel bír, ami önmagában is devopsszá teszi, de inkább olyan példákat látok, amikben ez egy devops enablement teamként értelmezhető, de ő maga nem devops.
Ideális esetben devops szemléletben dolgozó feature teamek számára nyújt ops szolgáltatásokat, kevésbé ideális esetben ugyanolyan silóként jelenik meg, mint a klasszikus dev vs ops felállásban, pl. ha túl kicsi mozgástér marad a dev(ops) teamnek, ha túl nagy a bürokrácia, túl magas a fal. Ilyen esetben én egyik oldalt sem tekintem devops szemléletben dolgozó teamnak, dolgozzon az a legkurrensebb technológiai stackkel is.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
#79563158
#22688
üzenetére
Ez azért van, mert jópár cég és "devops pozícióban lévő" kolléga is félreértelmezi a devopsot és átnevezett opsot ért alatta, aki modern toolokkal dolgozik és ez az értelmezés válik sztenderdé, negligálva a problémát, amire a devops válaszként kialakult. Ez a topik is jól szemlélteti ezt.
A devops nem fancy cloud infrastruktúra, automatizálás, microservices, CI/CD és egyéb gyakorlatok és toolok.
Valójában nincs ilyen, hogy devops csapat és benne devops pozíció, ezek antipatternek, mert ugyanahhoz a throw it over the wall és kommunikációs siló problémához vezetnek, a devops egy paradigma, egy módszer, amit egy fejlesztő csapat gyakorolhat, de ez a gyakorlat fejlesztői csapaton belül történik vagy legalább azonos fókuszú kollégák között, nem két/több csapat között. Az hogy van egy vagy több devopsnak csúfolt ops csapat aki a cloud platformot és azok szolgáltatásait biztosítja a feature teameknek, akik meg annyira devopsok, hogy legfeljebb a CI toolt nyomogathatják, annak nem sok köze a devopshoz.Valahol szánalmas, hogy a job descriptionbe már nem lehet lassan beleírni a devopsot kultúrát semmilyen formában egy mert ops / cloud emberek jelentkeznek, és csak magyarázkodni kell miatta.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
#22564
Lortech
addikt
CyberPunk666
#22560
Lortech
addikt
válasz
CyberPunk666
#22560
üzenetére
Én másik oldalon el szoktam mondani jót is, rosszat is, jobban is, mint amennyire érdekli a jelentkezőt, nem csak arra keresem a választ, hogy nekünk megfelel-e a jelölt, hanem hogy ő minket keres-e. Fontosnak tartom az őszinteséget a legelejétől kezdve. Én is azon dolgozom nap mint nap, hogy őszintén azt tudjam mondani, hogy jó az, amit csinálunk.
Jelöltként ezer apróságból le lehet szűrni értékes információkat, csak kérdezni kell, jókat és sokat, nyilván ha ebben nem partner a másik fél és nem biztosít erre lehetőséget, csak arra összpontosít, hogy te megfelelsz-e nekik, akkor kuka.
Megírhatnám, hogy számomra mely szempontok fontosak és konkrétan miket járok körbe egy felvételinél, de ez mindenkinél más és más. Át kell gondolni, mik azok az értékek, témák, amik fontosak számunkra, mik azok a problémák vagy helyzetek, amiket szeretnénk elkerülni egy új helyen, mik azok a pozitívumok, amiket viszontlátnánk, és ezeket kell körüljárni.
Nyilván nincs 100%-os bizonyosság, erre van a próbaidő, de azért lehet csökkenteni a kockázatot egy tudatos hozzáállással, szemben azzal, hogy beleugrunk az ismeretlenbe 2 órányi ismerkedés után.Thank you to god for making me an atheist
-
Lortech
addikt
Hogyha teszem azt nem egy-egy rövidebb, projekt alapú 'custom developmentre', hanem hosszútávú termékfejlesztésre interjúztatok, ahol nem az határozza meg egy-egy csapattag produktivitását, hogy mennyire tud programozni, hanem inkább az, hogy mennyire ismeri a komplex terméket, a domaint, a szervezetet, akár ügyfeleket, hogyne lenne már hendikep a korábbi évenkénti váltás.
Nekem nincs semmi problémám azzal, hogy valaki váltogat, de hülye lennék egy stabil hosszútávú fejlesztésnél bele invesztálni az időmet, mikor jó eséllyel nem térül meg és csak rontja a morált, ha onnan is feláll egy év után.
Általában ezek azok a jelöltek (az itt jelenlévők megelőlegezem, hogy kivételek!) egyébként, akik nem tájékozódnak a cégről, a termékről egy interjú előtt, interjún sem nagyon kérdeznek, csak annyit látni, hogy mennének valahonnan bárhova, mert megunták az előző helyet vagy elfogyott a levegő körülöttük. De nem elég érettek ahhoz, hogy tudják magukról, hogy mit szeretnének, és nem elég tudatosak ahhoz, hogy megbizonyosodjanak arról a felvételi eljárás során, hogy a nekik megfelelő helyre csatlakoznak-e.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
azbest
#21695
üzenetére
Más az, hogy van egy továbbszámlázandó idő, amit rá kell tolni valami ticketre és az, hogy minden fejlesztőnek ki kell legóznia napi 8 órát különböző activitykből csak azért, hogy ott legyen valami nyilvántartásban. Ez utóbbi popsitörlése se jó, mivel se az inputot se az outputot nem lehet formalizálni, így összehasonlítani és mérni se.
Estimate témára csak egyik kedvenc videómat tudom ajánlani:
#NoEstimates (Allen Holub)[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
VirsLee
#21616
üzenetére
Nem akartam ekézni a kollégát, de kb. egyetértek.
the dealer:
Ha évet kellene mondani, akkor kb. 3 év alatt illik megugrani, bár ennek értelme csekély, egyénenként, cégenként, csapatonként más és más. Szenioritást nem pusztán technikai tudásban mérik, ezért van korlátozott értelme a kérdésednek.
Érdekes lenne, ha nekiállnál bevágni az összes algoritmust, frameworköt, patternt stb és hirtelen úgy éreznéd, hogy te már seniorabb vagy mindenkinél, nem így működik.
Vannak dolgok, amik tanulhatóak, vannak dolgok, amik az idővel és tapasztalattal fejleszthetőek vagy rádrakódnak. Ezért sem mindegy, hogy milyen környezetben töltöd az első éveidet.
Leginkább szerintem akkor lesz valaki medior, senior stb, ha a többiek, a kollégái, vezetői úgy tekintenek rá, és ennek megfelelő bizalmat, felelősséget, feladatokat adnak neki.
Ha úgy érzed, keveset keresel az adott helyen, akkor jelezd a vezetődnek, vagy menj el interjúzni, és mérd le magad a piacon. Leginkább a vezetődnek kellene tudnia válaszolnia egyébként, hogy mi az elvárás medior szinten, neki ill. vele közösen kellene tudni olyan célokat megfogalmazni, amik támogatnak téged abban, hogy a következő szintet megugord. Jobb esetben részletesen el kellene tudnia mondani, adatokkal, konkrét viselkedési mintákkal megtámogatva, hogy hogy állsz most és miben kellene fejlődnöd a következő szinthez. Ennek csak egyik - fontos - komponense a technikai tudás.[ Szerkesztve ]
Thank you to god for making me an atheist
-
#21611
Lortech
addikt
Bóbitatáncol
#21585
Lortech
addikt
válasz
Bóbitatáncol
#21585
üzenetére
-Én első megkeresésben egy dolgot szeretnék látni biztosan, hogy melyik cégről van szó. A közvetítő fejvadászok, recruiterek nagy része nem írja le, régebben még elmondtam, hogy akkor tudunk tovább menni, ha tudom egyáltalán, melyik cégről van szó. Erre egy részük elárulta, de nagyobb részük tovább kötötte az ebet a karóhoz, hogy csak akkor tudja megmondani, ha küldök CV-t meg telefonszámot meg mittudomén. Még 10 percet sem szeretnék elpazarolni egy megkeresésre olyan céggel kapcsolatban, akikhez biztosan nem akarok menni, mert már előtte 10-szer megkerestek vele. És a telefonszámomat sem szeretném odaadni boldog boldogtalannak, hogy aztán mindenféle adatbázisba bekerüljek. Megértem, hogy nem akarják elmondani rögtön a cégnevet, csak nem érdekel. Sosem kerültem meg fejvadászt egyébként.
1-2 éve már nem reagálok ilyenekre, ill. annyit, hogy köszi a megkeresést, de nem érdekel.-Második fontos tényező, amiről ha későn derül ki, hogy nem egyezik az elképzelésünk, megintcsak felesleges időpazarlást jelent mindkét vagy mindhárom fél számára: bérsáv / napidíj. Ezért ha ez nem megismerhető a folyamat legelején, akkor én nem fogok beleinvesztálni eggyel több percet sem.
-Nagyobb eséllyel reagálok egy megkeresésre, ha személyre szabott, kiderül belőle, hogy legalább átfutotta a recruiter a profilomat, és nem valami teljesen inadekvát pozíciót próbál eladni. Tapasztalati szint belövésével is vannak bajok, heti szinten kapok megkeresést a jelenleginél kettővel alacsonyabb tapasztalati szintre, amiben 10 évvel ezelőtt dolgoztam.
-Direkt céges vagy ismerős recruiter vagy ismerős korábbi kolléga vagy vezetőim általi megkeresések általában sokkal relevánsabbak és kevesebb felesleges kör van velük, szóval mostanság nagyon ritkán jutunk el akár az első körig közvetítői megkeresésnél, mert egyszerűen többségében semmiféle hozzáadott értéket nem tudnak nyújtani. Alapvető kérdésekre nem tudnak választ adni, mert legtöbb esetben sem a pozíciót sem a céget nem ismerik eléggé.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
OPiiPO
#21396
üzenetére
Ha meg lenne osztva a topikban a felhasználónév és jelszó, visszaélnének vele. Annak volna értelme, ha csak ebben a topikban tudna hozzászólni, de nem tudom, tud-e ilyet a ph motor. (És még ezzel együtt is vissza lehetne élni vele itt.)
Mintha rémlene olyan megoldás a múltból, hogy privátban elküldve az adatokat egy usernek, az user posztolta ide. Vagy valami ilyesmi.[ Szerkesztve ]
Thank you to god for making me an atheist
-
#21183
Lortech
addikt
repeter1000
#21179
Lortech
addikt
válasz
repeter1000
#21179
üzenetére
Kobe leírta a második esetet, de jogilag még az első is szürkezóna lehet, ha munkaerő kölcsönzés címen, tehát akár közvetítő közbeiktatásával a tényleges munkát végző kontraktor ugyanúgy betagozódik a megrendelő szervezetébe mint egy alkalmazott és ott ugyanazt a munkát végzi a megrendelő cég eszközein, ugyanannak a főnöknek a direkt utasításai alapján stb. Ez nem szolgáltatás nyújtás, hanem munkaviszony. Tipikusan mikor eladnak 3 évre valahova... Más kérdés, hogy nehéz egyértelműen fellépni ellene, ezért kvázi meg van tűrve és KKV-k úgy adják veszik egymás között az embereket mint a rabszolgapiacon.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
OPiiPO
#21172
üzenetére
Lefelé torzíthatja a számokat az is, hogy hazánkban elég erős az adóoptimalizálás miatt "papíron kontraktor" (de egyébként ugyanúgy kézivezérelt IT munkás, mint az összes többi alkalmazott) réteg. Az se mindegy, hogy a statisztikában a tényleges munkát elvégző vállalkozó és egy ügynökség közötti rate vagy egy ügynökség és a tényleges megrendelő közötti rate van.
Thank you to god for making me an atheist
-
Lortech
addikt
2020-ashoz képest emelkedtek a számok, nem hiszem, hogy covid negatívan befolyásolta volna a rate-eket. Az biztos, hogy bizonyos szektorokban szélnek eresztették a kontraktorokat, de ha konszolidálódik a helyzet, lehet hogy éppen ezen pozíciók bővülnek a kockázatkerülés és rugalmasság miatt (munkáltatói részről).
Nem ismerem a mintájukat, csak spekulálok, de sok multi, aki jól fizet, és aki az ő látókörükben lehet egyébként, egyáltalán nem is alkalmaz ezekben a "tömegpozíciókban" kontraktorokat.Thank you to god for making me an atheist
-
Lortech
addikt
Ami még érdekes szerintem, hogy a legmagasabb (java, frontend, mobile) fejlesztői kontraktor napidíj 132000-re (~370 EUR) jön ki.
Typical pedig 104000 (~290 EUR).
Software architectnél uez (~390 vs ~325 EUR).
Ezek nem túl acélos számok.Pont ma reggel kerestek 300EUR-ért tapasztalt architekt pozícióra Spanyolországba 300 EUR napidíjért. Máris csomagolok.
szerk: junior java számok teljesen rendben vannak.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Szerintem ezek egy része biztosan nem valódi pályakezdő, ami felfelé húzza az átlagot.
Erre enged következtetni az info BSC MSC közötti különbség is.
+"viszont esetükben már csak 0,27 hónap telik el az első munkavégzésig"
Ezt nehezen tudom máshogy elképzelni, minthogy sokaknak 0.0 hónap telik el az első munkavégzésig, mivel már eleve munkában állnak, és emiatt magasabb az MSC 'kezdő', mert már x éve dolgozik, nem pedig azért, mert a piac ezt ennyivel magasabbra árazza (nem teszi) valódi kezdőként.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Ha alkalmazott vagy, most is 10+-szor több adót fizetsz mint egy minimálbéres.
A progresszív adózás, tehát hogy a magasabb fizetéseddel nem csak egyenes arányosan több adót fizetsz, hanem még annál is sokkal töbet, nem a társadalmi igazságozságról szól máshol sem, senki az égvilágon nem akar több adót fizetni, a felvilágosult nyugati társadalmakban sem, tehát ne állítsuk be társadalmi akaratnak, hogy így alakult. Egyszerűen az átlag feletti keresőktől lehetséges beszedni, mert nekik van elvonható jövedelmük, miközben nem gyújtják rá a politikusokra a parlamentet, mivel kevesebben vannak, mint a csóró réteg, aki amúgy köcsög burzsujnak tekint rájuk, miközben aki bérből él az még bőven nem számít sehol gazdagnak, valamint az érdekérvényesítő képességük meg zéró, nem úgy mint a valóban gazdag embereknek, akik adóoptimalizálás, lobbi, korrupció és egyéb úton módon nem adózzák túl magukat.Thank you to god for making me an atheist
-
Lortech
addikt
válasz
OPiiPO
#20557
üzenetére
Neked is meg többieknek pár gondolat.
Persze, de egy senior dev az önmagában nem egy spec szaktudás. Ha SME az adott területen, és valódi kontraktor felállás annak minden kockázatával, kiszámíthatatlanságával, az lehet olyan, amiért rövidebb távon sokat fizetnek. Pl. fizettek értem (sajnos nem nekem) 25k EUR-t / hónap, és ez nem egy kirívó eset, de cég - cég között az más dimenzió.
Nekem az nem volt egyértelmű a kolléga beírásából, legalábbis amikor írtam a hsz-t, hogy ő rendes kontraktor vagy "kontraktor", aki alternatív módon veszi ki a fizetését egy adott ponttól, de igazából nem egy klasszikus kontraktor.
Utóbbiból van több szerintem a magyar piacon és ott még a Tapsi által említett intervallum is eléggé a teteje annak, ami egyszemélyes vállalkozásnál céggel szemben beszámlázva szóba jöhet.
Magyar piacon inkább az jellemző, főleg így covid idején, hogy bedobja a munkáltató az alkalmazottnak, hogy holnaptól inkább akkor számlázni kéne és nem a munkáltatói költség dupláját, hanem kb. a bruttó + áfát.
De simán megtalálnak időről időre külföldről is olyan nevetséges napidíjakkal, hogy csak nézek, például 250-400 EUR Belgiumban (EU commission).[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Vision
#20553
üzenetére
Így van, de azért nem mindegy, hogy 120-150 vagy 140-190, meg az se, hogy cég szerződik céggel, vagy senior jóskapista beszámlázna. Amíg egy jó senior devet megkapni alkalmazottként 1.3-1.5m körül, ami munkáltatói költségben juttatásokkal meg egyéb költségekkel mondjuk 2m, nem fognak tömegével 4milliót kifizetni értük a cégek havonta.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Vision
#20538
üzenetére
Emvy fél óra minőségi együtt töltött időt írt, 4 óra közös tévézéshez viszonyítva, ahol a szülő hozzáadott értéke ~0.
Abban igaza is van szerintem, hogy előbbi többet ér, azt meg nem írta, hogy ez elég vagy hogy ez az ideális. Szóval önmagában inkább csak trollkodás, amin lehet csámcsogni.
Óvodásom sokkal többet igényel például, sokszorosát. De ő még 0 screen time-on van, a tableten a spotify igazgatását leszámítva . Thank you to god for making me an atheist
-
#19754
Lortech
addikt
GeeForGolf
#19750
Lortech
addikt
válasz
GeeForGolf
#19750
üzenetére
Nekem nincs meg. Fejlesztő csapat hatásköre (értelmes helyen), hogy hogyan valósítja meg azt, amire vállalást tett. A QA nem ír unit tesztet, a fejlesztő ír unit tesztet, nem azért mert a QA béna, hanem mert nem lát a fejlesztő fejébe, a unit teszt írása a kódírás része, normális esetben vele egyszerre történik azon fejlesztő által, aki a tesztelendő kódot írta vagy módosította. Be is b*szna ha QA-ra kéne várnom, hogy legyen megfelelő lefedettség ahhoz, hogy kimenjen egy módosítás, meg ha legalacsonyabb implementációs szinten kellene diskurálni egy másik emberrel, hogy mi meg hogy, megölné a produktivitást. Ha QA unit tesztet ír, azt úgy hívják, hogy fejlesztő.
Hangsúlyozom, unit testről beszélek, nem unit test frameworkkel meghajtott integrációs vagy e2e tesztekről, amit valóban írhat QA. Az a szomorú, hogy még tágabb értelemben vett szakmabeliek se értik, mi a unit test és mire való.#19749 mobal:
Az nálam no-go. Már az irritál, ha windowst be kell bootolnom. Öregszem.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Ami engem jobban bosszant a téma kapcsán, hogy akikre ki lett találva elvileg a KATA, KIVA stb., azok nem látom, hogy fehéredtek volna.
Elmúlt évben felújítottam, költöztem stb. sok szolgáltatást igénybe vettem, teljesség igénye nélkül:
-villanyszerelő
-vízszerelő (2)
-gázszerelő
-autószerelő (2)
-festő
-költöztető
Egyenként 100 ezres tételekről van szó.
Ezek közül szerintetek ki adott nyugtát vagy számlát magától vagy akár megkérdezte, hogy kérek-e? Az egyik autószerelő a fizetéskor jelezte, hogy számla vagy nem számla, így ennyi, úgy annyi, ajánlatában természetesen a számla nélküli összeggel kalkulált, hiszen ki az a hülye, aki 1 forinttal többet fizetne azért, hogy ne feketén menjen. Összes többinél fel sem merült, pedig nem az aljából válogatok, amikor szakembert keresek.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
-
#16234
Lortech
addikt
CyberPunk666
#16223
Lortech
addikt
válasz
CyberPunk666
#16223
üzenetére
És mennyi szja-t, eü hozzájárulást, szochot nem fizet egy színlelt munkaviszonyban dolgozó, menő IT-s KATA-s egy alkalmazotthoz képest? Félmilliós tétel. Ne nevettess már ilyenekkel, hogy több költés, több áfa.
Kiderül mindjárt megint a topikban, hogy a kevesebb az új több.Thank you to god for making me an atheist
-
Lortech
addikt
Jaja, főleg banki környezetben, ahol van rendesen mozgástér (nope).
bandus: minden, amit nem nem ma írtak angular 28-ban és kotlinban. Vagy: minden amit nem "mi" írtunk, hanem a semmirekellő régi gárda.
Vagy: néhány (10) éve cobolban írt őskövület. Thank you to god for making me an atheist
-
Lortech
addikt
válasz
axioma
#15477
üzenetére
írásos kommunikáció félreérthető
Mondom én.
Nyilván tisztázni lehet, de mivel az írásos kommunikációnál az élőszóhoz képest időben és térben is függetlenek a kommunikáló felek, azaz a fogadó fél majd egyszer valamikor olvassa, amit írtak neki, aztán majd egyszer a másik fél is elolvassa a válaszát stb, közben eltelik idő, ami overhead, aztán ebből még lehet több kör. Ezt vesd össze azzal, hogy direkt kommunikációban azonnal megtörténhet a visszakérdezés, tisztázás.
Másik probléma a kommunikációra fordított idő. Írásban időigényesebb leírni valamit szabatosan, hogy 100%-ban átmenjen, főként ha még szemléltetni is kell, vagy hivatkozni valamire, egy ábrára mondjuk vagy kódrészletekre. Másik oldalról közelítve azonos idő alatt tömörebben (vagy akár információ vesztéssel) lehet valamit kommunikálni írásban mint szóban, személyesen. Nyilván témától, kontextustól függ ez is.
További probléma, ami kapcsolódik az előzöhöz a lustaság vagy igénytelenség, mikor nem is tud értelmesen fogalmazni vagy lusta hozzá, ne adjisten nem is érdeke átadni infókat, na vele próbálj zöldágra vergődni írásban. Persze ilyennel személyesen se egyszerű, de direkt kommunikációban nehezebb a kérdések elől elbújni.
Nap mint nap tapasztalom a kommunikációs problémákat fejlesztők között, a junior / domain tudással nem rendelkező dev nem tud még jól kérdezni, az expert meg nem tud a kezdő fejével gondolkodni, nem tudja a helyébe képzelni magát, ezért nem tudja, hogy milyen infóra van szüksége a kezdőnek, szóban néhány keresztkérdéssel megfogható általában a probléma, írásban ugyanez rendes kínlódássá tud válni. Félig megoldás erre a hívás, de az már egy fokkal ceremoniálisabb mindkét félnek, némi előkészületet igényel, az időben meg kell állapodni, el kell vonulni tárgyalóba, hogy másokat ne zavarj stb. Emiatt azt tapasztalom, hogy kevesebb ilyen hívás születik, mint amennyi ideális volna, vagy már csak akkor történik meg, amikor már nagyon muszáj, mert régóta van elakadás.
A mentorkodásnak csak egy oldalát említed, ami a mentornak szerinted kisebb és jól körülhatárolt ideig tart (én mint mentor ezzel egyébként nem értek egyet, munkaidőm kb. egyharmadát veszi el folyamatosan), az a mentoráltnak folyamatos, hónapokig tartó időszak lehet, amikor mások információ átadására és segítségére van utalva és rendesen a bőrén érzi és a saját teljesítményét is meghatározza, hogy ez milyen hatékonysággal működik. Volt próbálkozásunk földrajzilag elosztott, közös fókuszú csapatok között mentorálásra, nem nagyon működött, sokkal kevesebb interakció lett a vége, azaz a mentorált kevésbé fejlődött. Miért? Nem tudok más okot, egyszerűen mert körülményesebb. Találkoztam olyannal, hogy mentorált fel is állt ilyen miatt.
Egyébként mindazok ellenére, amit írok, abszolút WFH és remote munkavégzés párti vagyok, és azon dolgozom, hogy a csapatomban ez jól működjön, ugyanakkor látom és tapasztalom a problémákat.szerk: még valami, nyilván az írásos kommunikációnak is megvan a helye, előnye bizonyos kontextusban, magától értetődő, hogy akkor az preferált, de itt nem ez a kérdés, nem azt mondom, hogy ne kommunikáljunk írásban, hanem hogy remote nem mindig van más opció ill. sokszor akkor is azt választják a felek kommunikációs csatornának, ha nem ideális.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Te most akkor fejlesztő vagy vagy mit csinálsz? Ticketeket nyitogatni? Az baromira agilis lehet.
Fejlesztő csapaton belüli Interakciók alatt pl. arról van szó, hogy juniorok fél óránként kérdeznak valamit, amit pár perc alatt megbeszélek velük. Vagy ha együtt kell tervezni egy megoldást, az több mint ötször () körülményesebb ha nem személyesen csináljuk.
Vagy code reviewzok pl. több projektnek több időzónában, saját lokál csapatomban ha át kell beszélni valamit, akkor egymás mellé ülünk és lezavarjuk pár perc alatt. Ugyanez kinti csapattaggal több órás vagy napos átfutású, mert épp nincs ott a gépnél, mikor írok, vagy mikor válaszol már én kezdek másba, írásos kommunikáció félreérthető, felhívni nincs mindig lehetőség azonnal, nem call center vagyunk, hiába meg vagyunk támogatva minden toollal, kizárt, hogy ugyanolyan hatékonyságot elérj.Teams vs slack, szerintem nem említhetők egy napon. A teams röviden egy lassú, megbízhatatlan, okádék bloatware fos, mint az MS stack nagyrésze, fejlesztőként kerülöm ahogy tudom.
FLx-nek is, remote munka szempontjából eléggé más jellegű egy ops vagy infra meló, mint egy néhány fős fejlesztő csapat tagja lenni remote munka szempontjából. Másfajta interakciót igényel és más hatékonysággal.
Felállástól függ meg csapat érettségétől, de egy olyan csapat, ami nem egy hónapok, évek óta összeszokott csapat és ahol nem min. medior/experienced mindenki, megfelelő domain tudással, ott kizárt dolog, hogy ugyanolyan hatékonysággal tudjon együttműködni egy csapat ha full lokál dolgoznak együtt vagy ha remote.Menedzserek nem csak azért szokták home office-t korlátozni, mert attól tartanak, hogy az emberek nem dolgoznak, hanem a hatékonyság miatt.
(#15453) FLx: nem teljesen naprakészen ezek az infók.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Because
#12858
üzenetére
És hogy lehet ebből vajon kitörni? Úgy, hogy még több szakmunkást képzünk, akik kielégítik a jelenlegi igényt olcsó munkaerőre. Vagy esetleg mérnököket és egyéb gondolkodókat képzünk, akik hosszú távon képesek lehetnek innoválni, saját megoldásokat létrehozni, amit majd mi gyártatunk más, olcsó munkaerőt biztosító országokban?
Thank you to god for making me an atheist
-
#12309
Lortech
addikt
letsdothis
#12307
Lortech
addikt
válasz
letsdothis
#12307
üzenetére
Persze, hogy visszakérheti, és vissza is fogja.
Tuti biztos vagy benne, hogy el van számolva? Ezeket általában nem kézzel számolgatják, hanem egy szoftver csinálja, bérszámfejtő csak az inputokat adja meg.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
tboy93
#11926
üzenetére
Az egy dolog, de ennyi erővel akkor hívhatod kiskutyanak is az SM szerepkört, pont annyi köze lesz a scrumhoz. Amit leírtál, szöges ellentétben áll a scrummal de úgy általában az agile-lal is.
Ezek a szerepkor elnevezések kb azert szoktak lenni az altalad leirt felallast alkalmazo cegeknel, hogy az ugyfelnek elmondhassak, hogy persze, mi fullkretenagile-ba' toljuk.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
tboy93
#11913
üzenetére
Scrum masternek nem sok köze közvetlenül a backloghoz, PO felel a backlogért.
SM max segédkezhet abban, hogy normális backlog előálljon, pl. ha nincs eléggé feltöltve, vagy nem elég jó minőségű, akkor presszionálhatja a PO-t, vagy ha grooming hiányzik, akkor segít időt allokálni és megszervezni a csapattal és PO-val közös groomingot.
Ahogy írták, alapvetően nem menedzseri pozíció, végezheti menedzsment személy, ez az impedimentek hatékony elhárításában előny tud lenni, de Scrum master sapkában elsősorban szolgálja a csapatot, és nem menedzseli, semmiképp sem a csapat felett áll.
Más kérdés, hogy néhány cégnél, ahol finoman szólva félreértelmezik az agilis irányt, az SM az ostorcsattogtató és menedzsment felé felelős, reportoló személy.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Ironizer
#11566
üzenetére
amúgy nyilván neki sem érdeke, hogy olyan valaki dolgozzon alatta, aki nem elégedett a helyén.
Vagy hogy lelepjen a cegtol. Nalunk tamogatott a cegen beluli mozgas, de meg kell palyazni a poziciot. Minimum eltoltott ido nincs. Site-on belul joval egyszerubb azert egy ilyen valtas.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
X Factor
#11170
üzenetére
Kezdjünk már el akkor beszélgetni erről a 7 pontról. Fontos leszögezni, nem vagyok jogász, sem adótanácsadó, csak egy a sok érintett közül.
1, A kisadózó a tevékenységet nem kizárólag személyesen végezte vagy végezhette.
2, A kisadózó a naptári évi bevételének legalább 50 százalékát nem az adatszolgáltatásra köteles személytől (praktikusan fogalmazva a megrendelőjétől) szerezte.
3, Az adatszolgáltatásra köteles személy (=megrendelő) nem adhatott utasítást a tevékenység végzésének módjára vonatkozóan.
4, A tevékenység végzésének helye a kisadózó birtokában áll.
5, A tevékenység végzéséhez szükséges eszközöket és anyagokat nem az adatszolgáltatásra köteles személy (=megrendelő) bocsátotta a kisadózó rendelkezésére.
6, A tevékenység végzésének rendjét a kisadózó határozza meg.
7, A kisadózó vállalkozás minden kisadózóként bejelentett tagja, illetve a kisadózó egyéni vállalkozó a naptári év egészében nem minősül főállású kisadózónak feltéve, hogy a kisadózó vállalkozás naptári évi bevételének legalább 50 százalékát olyan személytől szerezte, akivel/amellyel a kisadózó a naptári évben nem állt 36 órát meghaladó munkaviszonyban, illetve főállású vállalkozásban.Legyen példa a szoftverfejlesztés. Erre van rálátásom, és egyik leggyakoribb szakma a topikban is.
Nézzünk egy tipikus szoftverfejlesztéssel foglalkozó kkv-t, ahol felmerül a katázás. /Legtöbb nagy multinál, ahol több 100 ember dolgozik, fel se merül tapasztalataim szerint, bár biztosan akadnak itt is kivételek. /A jelölt egy tipikus junior/medior/senior fejlesztő, ezekből van a legtöbb, 50 fős cégnél (menedzsmenttel, hr-rel, gazdaságisokkal és mindennel együtt) mondjuk 30, tehát nem az 50-ból néhány architekt, vezető fejlesztő, CTO, CXO vagy külsős sysadmin egyike. A pozíció normál 8 órás munkaviszonynak van hirdetve.
A jelöltnek felajánlják, hogy lehet alkalmazott vagy KATA-zhat. Ilyenkor legritkábban szokott elhangzani, hogy ha KATA-t választ a jelölt, akkor hirtelen úgy kezelik, mint egy EV-t és más szabályok vonatkoznának rá mint bárki másra a cégben. A választásától teljesen függetlenül a következők igazak rá:
-egy csapat tagjaként dolgozik, egyértelmű alá-fölérendeltségi viszonyban, főnöke kézivezérléssel irányítja / irányíthatja, de semmiképp sem megbízás alapon dolgozik és nem önjáróan, és nem szállít le minden egyes fejlesztést.
-kényszerűen a munkáltató / ügyfél eszközeit - úgymint laptop és szerver infrastruktúra - használja, esetleg van egy saját laptopja, ha elfogadja a BYOD-t a cég, sok helyen nincs ilyen lehetőség (és ennek ugyancsak semmi köze a jogviszonyhoz). A szoftvereszköz is eszköz az én fogalmaim szerint, egy fejlesztő nagyon ritkán tudja kikerülni azt, hogy legyen a cégnél pl. egy saját email fiókja, az accountja az issue tracking és egyéb rendszerekbe, amiket aktívan használnia is kell, egyéb fejlesztői szoftverek, amiket a cég áll. Fontos, hogy ezen eszközök nem az ő eredménytermékének a részei, hanem eszközök annak előállításához.
-mivel csapatban dolgozik, munkaidejének (mert hogy van neki, mégha papíron nincs is) nagy részét a cég irodájában tölti, ugyanúgy, mint bárki más fejlesztő, megintcsak függetlenül attól, hogy KATA-zik vagy alkalmazott. Persze elmegy home office-ba, időnként, heti 1-2 nap nem szokott legtöbb helyen gondot okozni.
-munka közben fel sem merül, hogy valaki KATA-zik vagy alkalmazott, mert nincs semmi különbség, csak hó végén. Többnyire nem is tudnak a kollégák arról, hogy ki hogy veszi ki a fizetését, a külsőségekből pedig nem derül ki.És akkor nézzük a pontokat:
1, no fucking way, hogy beküldj magad helyett valakit helyettesíteni, mert úgy kivágnak, hogy lábad nem éri a földet.
2, kiesik, emberünk napi 8-10 órát dolgozik, és elenyésző (kb. 10-ből 1 tapasztalatom szerint) azok száma, akik egy főállás (mert az) mellett fusiznak.
3, de bizony, egy ilyen helyen főnököd van, aki megmondja, hogy min dolgozol és megmondhatja, hogy hogyan dolgozz
4, ezt szokták felhozni KATA-zók biztosan teljesíthető pontként, valóságban mégis tipikusan, többségében a cég telephelyén történik a munkavégzés, és ez nem csak az egyeztetésekre korlátozódik. Nem kérek olyan kommentet, hogy háde én full remote-ba tolom a kanapéról, van ilyen, egyre több, csak messze nem ez a tipikus. Még a fejlesztő cégek is azt preferálják még manapság is, ha ott rohad az ember az irodában. (A manapság tipikus agilis fejlesztés is így tud egyébként leghatékonyabban működni).
5, másik biztosnak tűnő pont, amikre a fentiekben kitértem, saját laptopot és egy-két szoftverlicencet fel lehet mutatni, lehet, hogy el is fogadja a NAV, ha szívemre teszem a kezem és mint szakmabeli közelítem meg a kérdést, a NAV helyében én ezt baromira nem fogadnám el saját eszközként, mert egy enterprise környezetben tipikusan semmire nem megyünk önmagában a saját eszközeinkkel, nem tudnánk előállítani az eredményterméket, amire vállalkoztunk.
6, teljesen egyértelműen nem emberünk határozza meg, hanem a lead dev, a po, a pm a stb, és a mozgástér minimális. Lehet ezzel is vitatkozni, de szerintem belemagyarázás lenne érvelni e pont teljesíthetősége mellett.
7, tipikusan ez sem teljesül, mivel emberünknek egy munkahelye van, ahonnan jövedelme egészét szerzi.Van két véleményes pont tehát, ami megállhat a NAV előtt, de nem állnak stabil lábakon szerintem. És valószínűleg azért nem halljuk, hogy a KATÁ-s fejlesztőket vegzálnák, mert nem éri meg a NAV-nak, hogy ezekből perek szülessenek. De a jogalkotó szándéka vélemény szerint nem az volt, hogy KATÁ-s adózást legitimáljon egy ilyen általam leírt jogviszonynál, ami munkaviszony az én fogalmaim szerint.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Goose-T
#10691
üzenetére
Ismerek pár architektet, én is az vagyok, bár jelenleg épp nem ilyen pozícióban dolgozom, de egyikük se nyalással, taposással került oda, én se. Én úgy, hogy az elmúlt 10 évbe beleraktam 15-öt.
Br. 1m hófehéren ma egy sima senior fejlesztő pozícióban elérhető. Még normálisabb kkv-nál is.Jhonny06: ja, egy fecske biztosan nem csinál nyarat ebben a témában. De itt nem is erről van szó, a többség után befizetik az adót szerintem ma is. Igaz, hogy szarul használják fel, és lehetne sokkal jobb az infrastruktúra, de a be nem fizetett adóból semmilyen infrastruktúra nem lesz. Aki meg nem fizet adót, annak nincs is alapja számon kérni semmit. Ez szerintem fontos, ha mindenki fizetne adót, és pl. ha kijön a burkoló, nála is alap lenne, hogy nyugtát ad, akkor megváltozna a társadalom szemlélete is az adóval és annak újraelosztásával szemben. Kialakulna, hogy ha más is befizeti, én is befizetem, és lenne egy erősebb, tudatosabb elvárás az állammal szemben, hogy jogosan kérhetem számon az rajta, hogy ne nyúlja le és/vagy költse hülyeségekre az adót. Most mi van? Más is elcsalja, akkor szarok rá, én is elcsalom, ahol tudom, úgyse kapok érte semmit. Ez nem vezet sehova. Nyugati társadalmakhoz való felzárkózáshoz biztosan nem.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
#10674
Lortech
addikt
H A M M E R
#10671
Lortech
addikt
válasz
H A M M E R
#10671
üzenetére
Velem még soha nem történt, hogy felmerült volna, hogy bármilyen részben feketén kapnám a fizetésem.
Azonnal megköszönném a lehetőséget és elköszönnék.
Semmi nem fog változni ebben az országban, amíg ez megy, még az egyik legjobban menő szektorban, az IT-ban is.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
EQMontoya
#10522
üzenetére
Még véletlenül se tűnjön úgy, hogy én általánosan fogalmaztam meg, milyen kell legyen egy interjú és hogy milyen kell legyen egy senior.
Persze, hogy bonyolultabb a képlet, ez egy baromi szerteágazó szakma, millió szakterülettel, és a szenioritás is egy olyan fogalom, ami minden cégben más, sőt cégen belül is.
Szerintem is elvárható tudni, mi történik a háttérben, csak más dimenziókban. Ezek közül csak egy, hogy adott algoritmus vagy adatszerkezeten végzett művelet milyen komplexitású. Ha nem tudod, és érdekes a probléma szempontjából, nézd meg a cheat sheetet, puff. Ha nem tudod a sleep sort komplexitását, az nálam nem dealbreaker, fejből én se tudom. Szoktam olyat kérdezni, hogy elképzelt problémához milyen adatszerkezetet használna, és milyen beépített java implementációt tud rá, esetleg ha több opció van, össze tudja-e őket hasonlítani, de ez a max.
Ha egész nap ezt csinálod, mert ezzel kapcsolatos a munkád és a kollégákkal való kommunikációban folyamatosan előkerülnek a komplexitások, akkor más a helyzet, akkor erre kell rámenni interjúm, de szerintem nem ilyen a szoftverfejlesztési munkák többsége. Pont azt látom problémának, hogy sok helyen, ahol egyáltalán nem erről szól a munka 99,9%-a, ott is tolják ezt interjún.]"Ha egy ügyviteli rendszer fejlesztésére kell n+1. ember, arra nem kell senior fejlesztő."
Dehogyisnem kell senior fejlesztő. Itt is lehet/van komoly komplexitás, csak másfajta.
Többivel nincs ellentmondás szerintem, tapasztalt embertől én is azt várom, hogy hozzon valami plusz képességet, szemléletmódot.Kérdés, tételezzük föl xx év tapasztalattal rendelkező senior fejlesztő, aki az adott pozíciót jól el tudná látni, de ha nem készül külön az interjúra, akkor nem megy át, ha készül pár órát és átmegy, akkor az az interjú jó volt-e?
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
axioma
#10519
üzenetére
Seniornál mind a két véglet értelmetlen. Az szerintem nem jó interjú egy senior pozícióra, ha olyan feladatok vannak, amit felsőoktatásból kiesve xx éve jobban meg tudtam volna oldani. Ugyanígy nem jó szintmérő olyanra rákérdezni, amit egy API leírásból 20mp kiguglizni.
Én 1-1,5 órás szakmai interjúkat szoktam tartani, és ez egy kötetlen beszélgetéshez jobban hasonlít, ahol vannak elméleti, technológiához közelebbi elméleti és gyakorlatiasabb példák is, előfordul hogy táblánál vagy papírra rajzolás rész is van, de ez csak a közös gondolkodáshoz kell, nem egy algoritmushoz vagy adatszerkezethez. Van mindig egy előre megírt vázlatos forgatókönyvem, amit az adott CV-re készítek el, a közös pontokat, a jelölt erősségeit keresve, nem pedig azt a témakört próbálom erőltetni, hogy éppen milyen tech stackű csapatba keresünk embert.
Speciálisabb területre, pl. egy algoritmus fejlesztő pozícióra nyilván nem ilyen szemléletben interjúztatnék, de ha n+1. enterprise ügyviteli rendszer fejlesztésére keresünk embert, ahol kb. szökőévente kell megírni pl. egy listából kiválasztásnál komolyabb algoritmust, ott nem kell interjún sem ezt erőltetni.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
kexksz
#10438
üzenetére
.net és erlang között pont nem csak toolset es szintaktika a különbség, mas paradigmat mas kodolasi, mas problema modellezesi es megoldasi stílust vagy ha ugy tetszik mindsetet igenyel.
Abban egyetértek, hogy ha valaki valóban senior, akkor nem .net-ben, javaban stb-ben senior, hanem altalaban, es nem kell egy ilyen valtasnal juniorkent kezdeni.
.net - erlang valtas amugy szakmailag, karrierileg nem biztos hogy a legjobb döntés.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
tboy93
#10274
üzenetére
Azért majd kérdezd meg őt is, mit gondol erről.
Addig úgy is ezer körülmény változhat. Addig kell otthon lenni vele, amíg bírja, amíg szükség van rá vagy amíg megtehetitek.
Én bölcsibe biztos nem adnám a gyerekemet, jelen állás szerint.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Te írtad korábban az ingyenpénzt is, most meg bezzegország lettünk USA-val szemben.
Azért ne tegyünk már úgy, mintha ez nem kerülne súlyos adóforintjainkba. Itt sokat adózol (legalábbis egyesek), cserébe kapsz egy kis alamizsnát. Mintha ezekből a támogatásokból becsületesen gyereket lehetne nevelni.
Befizetek életem során sok 10 millió forint összegű szochót, meg párom is. Cserébe párom kap egy kis gyest/gyedet.
Más felfogás, ott az öngondoskodást ösztönzi az adórendszer, ennyi. Itt meg arról nyúzzák le az utolsó bőrt, akiről még lehet.
Ja és mellékhatásként a gyerekvállalási korban lévő nőktől úgy félnek a munkáltatók mint a tűztől.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
bernel
#10156
üzenetére
Cége válogatja, hogy mennyire ismerik el. Vannak olyan tech cégek, ahol a felsorolt skillek és erős CS skillek számítanak inkább nyelvfüggetlenül, ezek azok akik lehalásszák a legjobb koponyákat.
A magyar valóság inkább az, hogy van a Java fejlesztő, meg a C++ fejlesztő stb és főleg az adott nyelvvel kapcsolatos tapasztalat számít és nehezen ismernek el egy ilyen pozícióra a más nyelvekben szerzett tapasztatot. Interjún is ennek megfelelően kérdeznek.
Persze vannak kivételek itthon is.Jhonny06: attól függ, mit csinál a cég és mire van szüksége. Ha arra, hogy a Senior Javás 0. perctől kezdve az x frameworkökben hatékonyan termelje a kódot valami ügyviteli vagy ERP rendszerben, akkor nem fog felvenni 10 év python tapasztalattal rendelkező embert, mert az nem hogy nem fogja segíteni a projektet rövid távon, nem fog hatékonyan termelni, nem fogja tudni mentorálni a többieket, zsűrizni a többiek munkáját, hanem lassítani fog.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
Goose-T
#10063
üzenetére
Attól, hogy munkaerő közvetítő cégen keresztül folyik a munkavégzés, mitől válik a jogviszony vállalkozói munkavégzéssé? Pl. Qualy kiközvetít MS-hez, ahol pontosan ugyanúgy ülsz ott 8 órát az ottani manager kézivezérlése alatt, az MS eszközeit használva, mint bármelyik ottani alkalmazott.
Tényleg kérdezem, nem kötözködök, nem tudom, hogy milyen speciális jogszabályok vonatkoznának rám és azok KATA kontextusban hogyan változtatnának a szükséges feltételek megítélésén, ha munkaerő kölcsönzőn keresztül dolgoznék ott.
Én azt látom, hogy a fejlesztői pozíciók nagy többségére továbbra is a munkaviszony illik a munkaadó elvárásai ill. munkaszervezése miatt, és a KATA-ra jogosító legalább 2 feltételt nem, vagy csak igen erőltetetten lehet teljesíteni, ami adott esetben vagy megáll NAV előtt, vagy nem.
Cégeknek a különféle tenderekhez és pályázatokhoz sok esetben fel kell mutatniuk egy magas alkalmazotti létszámot, ezért sem mindenhol szeretik a számlás munkaerőt.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Nyilván általánosságban nehéz belőni, de egy lakótelepen, ahol van még több tíz ugyanilyen lakás, és hirdetnek most is néhányat, valamint adtak el többet is a környékünkön (egyik vevőt ismerem is és megkérdeztem mennyiért vették) ott viszonylag jól be lehet lőni. Te esetedben valószínűleg egy ingatlanos be tudná lőni jól. Csak utána győzd levakarni..
[ Szerkesztve ]
Thank you to god for making me an atheist
-
#9916
Lortech
addikt
stickermajom
#9914
Lortech
addikt
válasz
stickermajom
#9914
üzenetére
Azért ha valaki a pár éve vett panelt alacsony kamatú hitelre (és itt nem azokra gondolok, akik 20 év hitelre és még így is túlvállalták magukat), jól járhatott, mert közben 30-40-50+%-ot ér a lakása. Például amit 2016 elején vettem, most +40%-os áron tudnám eladni. Az azóta felhalmozott megtakarításaimmal pont ott lennék, hogy ugyanezt tudnám megvenni, így viszont jócskán előrébb járok úgy, hogy jóval kevesebbet költök lakhatásra (még úgy is kevesebbet költenék, ha hitelre vettem volna).
Jelenleg az van, hogy az elmúlt néhány évben többel nőtt a számomra távolabbi célként kiszemelt ingatlanok ára, mint amennyit meg tudok takarítani a jóval átlag feletti jövedelmemmel, ezt a lakásvásárlással tudtam picit tompítani.Thank you to god for making me an atheist
-
Lortech
addikt
válasz
petyus_
#9623
üzenetére
Az adórendszernek nem igazságosnak, hanem méltányosnak kell lennie.
Mármint szerinted, meg egyesek szerint.az egykulcsos adó a társadalom szétszakadását eredményezi. Általa a szegények még szegényebbek lesznek, a gazdagabbaknál még több marad
Mint korábban, igen. Az egyenlő / átalány adózáshoz képest, ahol az állam működéséhez szükséges adóbevételt szétdobnánk egyenlő részre az adófizetők között, ahhoz képest meg nem. Az a baj, hogy az egykulcsos adót tekinti mindenki alapnak, mintha az volna az origó, hogy valaki fizet x-et, valaki meg 10x-et ugyanazért a szolgáltatásért.
Az idézet bármilyen rendszerre, melyben a fizetések és az adók különbözőek lehetnek, igaz. És? Legyenek a fizetések egyenlőek, és az adók is? Akkor már ne álljunk meg itt, kobozzuk el a gonosz "gazdagok" vagyonát is.Máshol is nagyok a bérkülönbségek, aztán mégsincs mindenhol favela dzsungel.
Magyarországon nem azért csúszik le az alsó réteg, mert egykulcsos adó van, hanem mert mesterségesen alacsony a minimálbér, sőt van még ezalatt egy intézményesített modernkori rabszolgatartás is (közmunka), azokat a szolgáltatásokat (oktatás) amik a kiutat jelentenék, fokozatosan leépítik. A tömegekből jól irányítható, ostoba, tehetetlen embereket akar az állam.
Különösen akkor nehéz elfogadni ezt, mikor egyébként volna lehetőség (pénz) felzárkóztatni, innoválni, fejleszteni, stadionok és külföldi focicsapatok támogatása helyett.Kedvenceim ezek a mondatok:
Úgy gondolom ezek nem olyan összegek, amiért nagyon ki kellene akadni.
és (nem tőled)
Ha sávos adózás lenne a a nagyobb jövedelmű valamicskét többet fizetni,de valószínűleg ,hogy nem rázná meg annyira.
Azután, hogy fizet valaki 10x-et a minimálbéres x-hez képest, nyilván még szeretne 10x helyett mondjuk 15x-et fizetni. Nyilván.
Gondolom a jelenlegi csúnya igazságtalan, méltánytalan rendszerben te is átutalod a fizetésed bizonyos százalékát egy rászoruló minimálbéres családnak.
Ha meg esetleg felmerül, hogy a több tízszeres adófizetésért cserébe esetleg valamivel többet kapjon az adófizető, mint aki alig fizet valamit, pl. prioritást élvezzen ügyintézésben, vagy egészségügyben, vagy mittudomén, bármiben, az azonnal óriási felháborodást vált ki, mert az továbbra is a világ legtermészetesebb dolga, hogy többet fizetsz, ugyanazt kapod.
Továbbra se tudom máshogy lefordítani, hogy a jól kereső fizessen a kurvasoknál is még több adót, mert csak, mert akinek nincs miből, attól nem lehet elvonni. Elfogadom a progresszív adózás szükségességét, de a morális érveket, hogy én érezzem szarul magam, mert csak 10x-et akarok fizetni, azt nem.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
- Másrészt morális oldala van a társadalmi szolidaritás szempontjából, hogy te valamivel többet adózol bizonyos jövedelmi szinteken.
Igen, ez valósul meg az egykulcsos szja-val. Valahogy ezt mindig elfelejtik megemlíteni a progresszív adózásról moralizálók. Mivel százalékban van meghatározva, 10-szer annyi adót fizetek mint a minimálbéres, és ugyanúgy lószar egészségügyhöz jutok. Szerinted ez akkor kevés, szerintem meg sok. Az egyenlő rendszer az, ha fix összeget kell adózni jövedelem után mindenkinek, ehhez képest a százalékban meghatározott egykulcsos adózás elég kedvező az alacsony jövedelműek számára, mivel a befizetésükhöz képest jobban részesülnek az állam áltatt nyújtott szolgáltatásokból. A progresszív adózás szimplán extra büntetés a magasabb jövedelműek számára, attól lehet lenyúlni, akinek van miből címszóval.[ Szerkesztve ]
Thank you to god for making me an atheist
-
#9262
Lortech
addikt
tehPwnerer
#9257
Lortech
addikt
válasz
tehPwnerer
#9257
üzenetére
"Egyszer az egyik toborzó azt mondta a telefonban, hogy neki annyi volt a kitétel, hogy legyen minimum szumma 3 év (!) tapasztalata az embernek, akkor már senior."
Ilyen nem nagyon van. Helyesen úgy hangzik, hogy akkor már pályázhat bizonyos senior pozíciókra, mert ki lehet pipálni a pozícióhoz minimálisan szükséges évek számát a kritériumok közül. A toborzó meg örül, hogy +1 pályázót hozott.
Ez nem jelenti azt, hogy valaki automatikusan seniorként elismerhető pusztán a munkában töltött évek száma alapján. Ahhoz olyan referencia kell, ami garanciát jelent. Az ilyen pedig ritka.Másik:
"Négy év tapasztalattal egy senior fejlesztőnél már szinte természetes az 1 millió forint feletti fizetés".
Itt nincs kapcsolat a senior és a négy év között, mármint nem azt jelenti a mondat, hogy ha valaki 4 év tapasztalattal rendelkezik, az magától értetődően senior is. Ha megnézzük az index cikk eredetijét, akkor jóval árnyaltabb a kép, ott senior kategória mellé 4 évnél több tapasztalat van írva és az 1 millió átlagban kb. a sávok közepe, azaz erős túlzás, amit az indexes újságíró ebből összehozott. Ráadásul nem az egész magyar piacról szólt az eredeti cikk, hanem startupokról.Thank you to god for making me an atheist
-
#8656
Lortech
addikt
Oppenheimer
#8652
Lortech
addikt
válasz
Oppenheimer
#8652
üzenetére
Még fordítva is az autót választanám. Hányingerem van a BKV-n utazó emberek egy részétől, és ha lehet, akkor elkerülöm a velük való érintkezést, főleg a pesti oldalon.
Inkább araszolok a dugóban és zenét hallgatok, kikapcsolódok közben, ráhangolódok a munkanapra vagy az estére.Thank you to god for making me an atheist
-
Lortech
addikt
Vezető fejlesztő alatt általában team leadet értünk, nem fejlesztési v. IT vezetőt, aki valóban magasabban szokott lenni egy céges hierarchiában.
Tervez, fejleszt, minőségbiztosít, egy csapat szakmai deliveryjéért felel általában, más csapatokkal, ügyféllel ő tartja a kapcsolatot, esetleg riportol felsőbb szintek felé a csapattal kapcsolatban. Szakmai, team fit interjúkat tart, teljesítményértékelésben részt vesz. Van, hogy a csapaton belüli erőforrásgazda is ő.
Nem kell, hogy ő legyen a legjobb fejlesztő a csapatban, de ilyen pozíció betöltéséhez - ha csak nem full juniorokból áll a csapat rajta kívül - nem árt egy legalább 5+ év tapasztalattal rendelkező fejlesztő, hogy legyen tekintélye mondjuk egy 4x éves 20 év tapasztalattal rendelkező senior fejlesztő kolléga előtt is. Nyilván ezek közül amit írtam, egyik sincs kőbe vésve, az évek száma sem, cégről cégre mást és mást jelent ez a pozíció, már ahol van ilyen egyáltalán.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Mit jelent az, hogy lekötni? Az ilyeneken csak nevetni tudok. Nem csoda, hogy 345-ért, ami még szürke is, meg akarnak tartani, a hülyének is megéri.
Java vezető fejlesztők ennek kb. a dupláját szokták keresni hófehéren, persze a tapasztalatod - legalábbis évek száma alapján - ehhez még kevés.
Mi van, ha azt mondod, hogy oké, maradsz? Szerződésbe foglalják, hogy márpedig nem mehetsz el 2019 előtt? Mit csinálnak, ha mégis?
Én megmondanám, hogy biztosítsák a megfelelő körülményeket, beleértve a szakmai és bérfejlődést, meg ami a komfortodat növeli, és akkor maradsz ameddig maradsz.Thank you to god for making me an atheist
-
Lortech
addikt
Csak meg kell nézni a junior és senior .NET-es fizetést és különbségét, komolytalan. De gyakorlatilag az összes ilyen átlagfizetés statisztika értelmetlen, mivel vidék / Budapest között nagy a különbség, és adott pozíción belül is meglehetősen nagy a szórás a tudásszinttől és a cégektől függően. Így aztán a végén az átlag nem sokra jó egyénekre levetítve.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
EQMontoya
#7650
üzenetére
Na jó, persze JS azon túl, hogy egy erős eszköz, nem olyan egyszerű, mint amilyennek elsőre tűnik, igencsak nyakatekert, félrevezető tud lenni még nem kezdő számára is. Nem véletlenül csináltak több elegánsabbnak szánt nyelvet is, ami js-re fordul. Valamint nem túl egyszerű jó minőségű kódot írni benne, és a nyelvek közötti átjárásban sem segít túl sokat a JS-ben felszedett tudás.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
EQMontoya
#7640
üzenetére
Ez már nem teljesen a "jó-e az xy nyelv első nyelvnek" kérdéskör. Ha végig C#-ot erőltetik a prog 1..x-en, és a nem prog tárgyak beadandóit is ebben várják, és a C++ csak valami választhatóként kerül elő, akkor a munkaerőpiacra kerülve is C# felé próbál elkelyezkedni inkább a pályakezdő, amihez jobban ért, amivel több esélye van. Azt nem tudom, hogy mi volna, ha kezdene valaki C#-pal prog1-2-t, majd még kötelezően ráerőltetnének mondjuk legalább 4 félév C++-t, gondolom, C++ fejlesztő lenne belőle - persze a példának értelme nem sok van.
Igazából oktatni kéne legalább 5 nyelvet, amivel a különböző paradigmák jól szemléltethetőek, és legalább egyet ezek közül mélyebben, ugyanakkor ennyi idő alatt ennyi nyelvben nehéz lenne értelmes tudást felszedni (kezdőként), és talán egyikben sem tudna dolgozni, mire pályakezdőként elhelyezkedne.
Nekem egyébként nem az következik az állításból, amit mondasz, hanem az, hogy minek akarna C vagy C++ fejlesztő lenni, ha C#-pal már barátságba került. Ez az átlag, aki pedig annak ellenére inkább C++-ozna, hogy C#-ot erőltetik az egyetemen, az úgyis megtanulja a C++-t.
C-t és C++-t nem helyezném egymás mellé tanulás szempontjából. Nem gondolom egyébként, hogy C>C++ könnyebb, vagy előnyösebb, mint C# > C++, az OOP-t nem biztos, hogy C++-on a legegyszerűbb felszívni. C# > C irány más kérdés, szerintem azért sem népszerű (gyakori), mert aki hozzászokott a kényelemhez, az nehezen mond le róla.
Egyébként szomorú, ha ez a kérdés nem szakmai alapon dől el az egyetemeken, hanem az alapján, hogy melyik multi szponzorolja az egyetemet, vagy épp melyik nyelvhez van már jól bejáratott tanterv, oktató, oktatási anyag, stb.
Tanítanak bárhol rubyt, pythont, urambocsá javascriptet első vagy "fő" nyelvként?Thank you to god for making me an atheist
-
Lortech
addikt
válasz
EQMontoya
#7631
üzenetére
Szerintem oké (de akkor már inkább Java
) C#-pal kezdeni, ha van egy jó rálátással rendelkező profi oktató ( ez baromi fontos ). Teljesen jól el lehet bohóckodni console applicationnel, GC. OOP stb. ismerete nélkül. Amikor memóriafoglalás és felszabadítás a téma, akkor szépen el kell magyarázni, hogy pl. C-ben hogy van, és ehhez képest egy menedzselt környezetben hogy van. Nem olyan nagy dolgok ezek, normális bevinfón, architektúrákon, esetleg asm-en már az alapjait meg kell tanulják. Részese voltam olyan évfolyamnak, akinek kb. fele-kétharmada nem programozott korábban, és C#-pal kezdett, és egész sikeres évfolyam volt, előtte C volt az első nyelv. Volt idő, mikor a NIK-en Turbo Pascallal kezdtek, na annak milyen sok értelme volt, 2007-ben.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Srácok, azért egy bónusz (egy része) miatt szerintem nem célszerű jogászkodni. (akkor sem, ha ott akarsz maradni, de akkor sem, ha váltanál)
Kicsi a magyar piac, bármikor szembe jöhet egy régi kolléga, főnök, hr-es, vagy új pályázatnál ha felhívják az előző helyet referencia miatt, könnyen lehet, hogy hátránnyá válik egy ilyen húzás.
Ami jár az jár, de tudni kell szépen távozni.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz
chabeee
#7516
üzenetére
A leírásod alapján abszolút jogosnak tűnik. Az viszont, hogy munkaszerződésben ilyen konkrét kritérium le van írva bónusz kapcsán, nekem nagyon fura. Ennél már csak az furább, hogy egy library leváltása bárhogyan érinti a fizetésedet. Ez valami kis szarrágó cég vagy csak ez a főnököd nem százas?
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Saját (vagy max 2-3 emberrel megosztott) iroda szerintem tök jó. Elmélyült, hatékony fejlesztői munkához az kell, hogy csend legyen körülöttem és csak a szükséges interakció legyen. Hogy ez nem reális? Lehet. El lehet férni 10-en is 30 négyzetméteren, mert a cégnek első számításra ez éri meg, ettől még nem feltétlenül ez a kifizetődő. Nem mindenki akar 500 vagy 1000 emberrel egy épületben dolgozni. Nem mindenki akar menő creative workplace-t, hülyeségekkel, a belvárosban, ahova sok idő bejutni, ha nem akar békávézni (én nem akarok), ahol szívás parkolni, tele emberrel minden, openoffice.. Ha saját preferenciát kéne felállítani, inkább legyen kevésbé menő irodaházban, de jobban megközelíthető helyen, és maradjon több tér egy emberre.
Thank you to god for making me an atheist
-
#6125
Lortech
addikt
dellfanboy
#6112
Lortech
addikt
válasz
dellfanboy
#6112
üzenetére
Alapvetően elvárás, de bárkit meghallgatunk, és ha valaki bizonyítja a tudását, akkor részemről nincs vétó emiatt és nem is szempont a továbbiakban.
Thank you to god for making me an atheist
-
-
Lortech
addikt
válasz
EQMontoya
#5589
üzenetére
Nálam (kb) +50% volt, majd +50% 3 év alatt, majd még +10% a következő két évben, egy cégnél. Nem azért, mert átlag alatt kerestem kezdőként. Ha a kezdeti és utolsó béremet nézem tehát, a végén 2,5-szeresét kerestem a kezdőfizetésemnek.
Fel kell vállalni a feladatokat, felelősséget, így fontos emberré lehet válni egy cégben. Soha nem mondtam egy feladatra, hogy inkább ne, mert nem biztos, hogy meg tudom csinálni, sőt inkább azt mondtam már juniorként is, hogy bármit ide nekem, én is meg tudom csinálni.
A hozzáállásomon kívül persze sok egyéb tényező volt, ami lehetővé tette ezt:
-teljesítményt értékelő tulajdonos, nem jófejségből, hanem racionalitásból
-alapvetően jól jövedelmező cég, jól fizető, stabil (külföldi) ügyfelekkel
Ez mindennek az alapja, magyar piacon ilyen 50-140k + áfa közötti szakértői napidíjakat látok, Nyugat-EU, USA meg inkább e felett kezdődtek.
-valamelyest speciális piac, szolgáltatások, nem az n+1. "egyedi" szoftvereket fejlesztő cég, bármit lefejlesztünk jeligére
-előbbiból következik, hogy SME-t nem talál magyar piacon, aki pedig nem tapasztalt adott domainben, de bárhol megállja a helyét, az ugyancsak drága, ergo érdemesebb volt megtartani az embereket
-igen magas százalékban továbbszámlázható órák az én esetemben
-lapos struktúra, kezdetben minimális vízfej, aztán amikor ez rossz irányban változott, léptemHa egyéb juttatásokat és bónuszt nem számolom, +20%-ért jöttem el a jelenlegi helyre, itt is megfizetnek, de látom, hogy nehezebben jut előre az átlag fejlesztő, kicsi a marzs, és hiába magas a fluktuáció, sok a favágó meló és átlag programozóból kell több, akit azért pótolni lehet a piacról. Nekem sincs nagy mozgásterem itt, nincsenek pótolhatatlan emberek, nincs olyan minőségi elvárás az ügyfelek részéről vagy olyan SLA, ami miatt megérné sokkal emelni. Persze szeretnének megtartani, de azért tudom, hogy nem ragaszkodnának hozzám mindenáron. Érzésre +20% még menne, de felette már megfeküdné a vezetés gyomrát. Cserébe legalább kapom a bónuszokat, így elégedett lehetek, de az alapfizetésem nem sokat fog változni. No mindegy, úgyis váltani kéne már.
[ Szerkesztve ]
Thank you to god for making me an atheist
Azért kiderült az utóbbi pár napban a topikból, hogy:
De simán megtalálnak időről időre külföldről is olyan nevetséges napidíjakkal, hogy csak nézek, például 250-400 EUR Belgiumban (EU commission).
Java vezető fejlesztők ennek kb. a dupláját szokták keresni hófehéren, persze a tapasztalatod - legalábbis évek száma alapján - ehhez még kevés.![;]](http://cdn.rios.hu/dl/s/v1.gif)
) C#-pal kezdeni, ha van egy jó rálátással rendelkező profi oktató ( ez baromi fontos ). Teljesen jól el lehet bohóckodni console applicationnel, GC. OOP stb. ismerete nélkül. Amikor memóriafoglalás és felszabadítás a téma, akkor szépen el kell magyarázni, hogy pl. C-ben hogy van, és ehhez képest egy menedzselt környezetben hogy van. Nem olyan nagy dolgok ezek, normális bevinfón, architektúrákon, esetleg asm-en már az alapjait meg kell tanulják. Részese voltam olyan évfolyamnak, akinek kb. fele-kétharmada nem programozott korábban, és C#-pal kezdett, és egész sikeres évfolyam volt, előtte C volt az első nyelv. Volt idő, mikor a NIK-en Turbo Pascallal kezdtek, na annak milyen sok értelme volt, 2007-ben.
Új hozzászólás Aktív témák
- WoW avagy World of Warcraft -=MMORPG=-
- PLEX: multimédia az egész lakásban
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- BestBuy topik
- One otthoni szolgáltatások (TV, internet, telefon)
- Fűzzük össze a szavakat :)
- Starlink
- Elektromos (hálózati és akkus) kéziszerszámok, tapasztalatok/vásárlás
- Kuponkunyeráló
- További aktív témák...
- HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 16/512 FHD HUN
- Szép! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 8/512 FHD HUN
- 486 CPU bazár
- S3 Trio64V2/DX 1 MB PCI videokártya
- Gamer Pc eladó! I5-9400F/Asus GTX 1660 Ti/16GB RAM 3000mhz/256GB SSD+500GB HDD
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest