0x00

Wenn die Daten selber egal sind wieso erstellst du nicht ein paar Tabellen und flutest diese mit random UUIDs und random numbers?

Es geht nicht darum was du, ich, @t0pioder sonst wer hier gut findet. Es mag sein, dass deine letzte Ausbildung sehr gut war, die Regel sind solche Ausbildungen (leider) nicht und deine aktuelle scheint es auch nicht unter diese Kategorie zu fallen. Die Frage ist wie kannst du das Beste aus der aktuellen Situation machen? Die Situation in deinem Betrieb kannst du vielleicht minimal verbessern, die 180 Grad Wende zur perfekten Ausbildung zu erwarten wäre allerdings naiv. Stell dich also darauf ein dir selbst Sachen beibringen zu können - ob es dir taugt oder nicht. Das wird später auch mit Abstand dein wichtigster Skill sein. Technische Fähigkeiten hin oder her, wer in der Lage ist sich schnell in neue Themengebiete einzuarbeiten, dem steht die Welt offen. Das mag zwar zu Anfang unangenehm sein und ist auch später nicht immer leicht, es wird dich aber langfristig sehr weit bringen. Hol dir die sachliche und zeitliche Gliederung, gehe die Punkte darin durch und erstelle einen Lehrplan für dich. Wenn dir dein Ausbilder dabei hilft, gut. Wenn nicht musst du es wohl oder übel alleine machen. Ein paar Ideen von mir: - Setz mal ein Linux System auf, erst was einfacheres wie Ubuntu, später etwas schwierigeres wie Gentoo oder Arch. - Arbeite dich weiter in Netzwerktechnik ein. Du könntest dich zum Beispiel an den Themengebieten des CCNA entlang hangeln und ggf. auch auf dieses Zertifikat hinarbeiten. - Je nachdem ob ihr mehr Windows oder Linux machst versuch die Basics von PowerShell oder Bash zu lernen. - Versuch die Grundlagen einer Programmiersprache zu erlernen (ich empfehle Python oder was auch immer ihr in der Berufsschule macht). Du musst nicht der nächste Programmiergott werden, aber die Basics schaden auch als FISI nicht. Mit Basics meine ich If/Else Verzweigungen, Schleifen sowie die weit verbreiteten Datentypen wie Integer, Floats, Strings und Arrays. Wenn du weißt was ne Hash Map, und OOP kein Fremdwort für dich ist wäre das auch ein Plus. - Setz mal eine SQL Datenbank auf und mach dich mit den CRUD Befehlen vertraut. - Recherchiere zu Themen wie AD, RAID, NAS, SAN usw. Ja, in einer optimalen Welt solltest du das alles nicht tun müssen, aber das ist Träumerei. Was zählt ist deine aktuelle Position und wie du das Beste daraus machen kannst.

Und wenn der Betrieb schlecht ist was dann? Dann lässt du die Ausbildung schleifen und wenn dich nach deiner Ausbildung jemand fragt wieso du nichts kannst, spielst du die "mein Betrieb war schlecht" Karte? Na das wird den Personaler sicher überzeugen. Es ist doch egal wer eigentlich was tun müsste, helfen musst du dir selber.

Rein aus Interesse: In was hast du deinen Bachelor gemacht?

Das kann ich nur ganz dick unterstreichen. Ab einer gewissen Anzahl von Wechseln wirst du weniger interessant, da sich die Kosten durch Recruiting, Onboarding und Einarbeitung nicht mehr wirklich rentieren wenn du eh nur 1 Jahr da bleibst. Deine Anzahl potenzieller Wechsel innerhalb eines gewissen Zeitraums ist also begrenzt. Deshalb ist es auch wichtig nicht für jede kleine Lohnerhöhung zu wechseln (es sei denn du bekommst kein besseres Angebot und stagnierst schon ein Weile, das dürfte allerdings eher später in deiner Karriere passieren) sondern nur zu wechseln wenn es sich wirklich lohnt. Ich persönlich würde nur wechseln, wenn ich stagniere und keinen Raum für Wachstum mehr in dieser Firma sehe, wenn ich unzufrieden bin, oder aber für mindestens 20% Gehaltserhöhung - je nachdem wie die Gehaltsaussichten in der aktuellen Firma sind sogar eher 25-30%. Wenn du gerade 50k verdienst und du ein Angebot für 60k hast könnte man das machen, wenn du allerdings vermutest, dass du bei der nächsten Gehaltsrunde in 4 Monaten 54k raushandeln kannst, dann fände ich persönlich die 60k schon wieder nicht attraktiv. So zumindest meine Sichtweise.

Also wenn du in diese Gehaltsregionen vordringen willst solltest du auf jeden Fall in der Lage sein dir eigenständig Informationen zu erarbeiten - erst Recht solch einfache wie Gehaltsstatistiken Ansonsten hier ganz grob übern Daumen gepeilt meine persönliche und stark verallgemeinerte Erfahrung mit Einstiegsgehältern im Informatikbereich, allerdings komplett ohne Statistik um das ganze zu untermauern: - FI 35-45k - BSc 45-55k - MSc 55-65k

Stimmt alles. Ich halte es allerdings grundsätzlich falsch sich am Durchschnitt zu orientieren und man kann durchaus einige Sachen tun um die Wahrscheinlichkeit in seinem Sinne zu beeinflussen. Es ist also definitiv mehr als nur Berufserfahrung und Glück - auch wenn diese beiden eine große Rolle spielen. Vermutlich, im Durchschnitt auf jeden Fall. Ggf auch 4500 wenn du richtig gut bist und Glück hast. Ich will mich jetzt aber gar nicht länger an der Wahrscheinlichkeit aufhalten, wir wissen alle, dass 70k über dem Durchschnitt liegt - weit über dem Durchschnitt für die ersten 5 Jahren nach der Ausbildung. Eine Garantie für 70k+ gibt es also nicht, man kann es aber natürlich trotzdem probieren und schauen wo man landet. Aber direkt nach der Ausbildung 70k? Vergiss es. Zunächst einmal die drei großen offensichtlichen Optionen die mir einfallen würden um irgendwann da hin zu kommen: - Übertarifliches IGM in z.B. der Automobilindustrie - US-Tech (ist gerade ein schlechter Zeitpunkt, aber könnte ja wieder besser werden und die richtig talentierten Leute werden immer eingestellt) - Selbstständigkeit (wobei es sich da zumindest in den ersten Jahren mit der 40h Woche hat) Es ist aber so, dass dich alle diese Firmen nicht für Abschlüsse oder Zertifikate bezahlen sondern für das was du kannst. Und das wächst - nicht nur, aber vor allem - mit der Berufserfahrung. Berufserfahrung ist schön und gut, aber du brauchst auch die Richtige. @Alexej_a7x 10 Jahre First Level Support Erfahrung bringt auch nicht unbedingt mehr Gehalt Mir spontan fallen zwei Optionen ein wo du in einigen Jahren bei 70k+ landen könntest: Das erste wäre Networking und Network Automation (CCNA -> CCNP -> ggf CCIE oder alternativ/ergänzend DevNet Associate -> Professional -> ggf Expert um mal bei Cisco zu bleiben) und das zweite wäre die DevOps/SRE/Linux Schiene. Wenn es dir nur ums Geld geht bist du denke ich bei DevOps besser aufgehoben, allerdings finde ich es immer sehr traurig wenn Menschen nur für Geld zur Arbeit gehen. Aber gut, muss jeder selbst wissen. Der wichtige Punkt ist jedoch folgender: Du wirst so viel bezahlt wie du auf dem Markt wert bist und wie viel Geld du der Firma einbringst. Bringst du wenig Gewinn ein bekommst du auch wenig Gehalt. Der beste Weg zu mehr Gehalt ist mehr Mehrwert zu liefern und hier ist Automatisierung ein sehr wichtiger Bestandteil, zumindest solange du dich weiterhin im technischen Bereich befindest. Wenn du fit in Automatisierung wirst - sei es nun IaC mit Terraform, Konfiguration mit Ansible oder Skripting mit Bash, PowerShell oder Python wirst du vermutlich mehr verdienen als jemand der alles noch per Hand machst. Falls dir das Thema Programmieren liegt würde ich auch den Wechsel in die Softwareentwicklung nicht ausschließen. Je nach Branche, Firma und Position sind hier auch 70k+ möglich. Am Schluss nochmal ein bisschen was zum Mindset: Ich gehe jetzt mal davon aus, dass du gut bist in dem was du tust, bereit bist dich stets weiterzubilden, auch mal über deinen eigenen Schatten zu springen und auch unanagenehmere Aufgaben zu übernehmen sowie den Ansporn hast besser zu werden als alle deine Kollegen. Und das bedeutet auch unbezahlte Überstunden, auf deiner 40h Woche kannst du dich vielleicht ausruhen wenn es soweit ist, aber wenn du schnell(!) in diese Gehaltsregionen vordringen willst musst du viel Zeit und Energie reinstecken. Wo sich dann bei mir die Frage stellt: Wieso gehst du nicht studieren? Das würde die Chancen erheblich verbessern.

So, zwei Wochen und zwei Zertifikate später kann ich jetzt auch endlich was zu den Professional Zertifikaten sagen (hab den DevOps Pro gemacht). Die Udemy Kurse von Stephane Maarek kann ich weiterhin sehr empfehlen. Natürlich muss man nicht den ganzen Kurs machen aber wenn man in gewissen Themen Schwächen hat (wie ich in CloudFormation ), dann lohnt es sich schon sehr die entsprechenden Sektionen zu wiederholen. Ansonsten habe ich für den DevOps Engineer noch mit tutorialsdojo gelernt was ich uneingeschränkt weiterempfehlen würde. Den Exam Readiness Kurs (die alle kostenlos sind!) fand ich sehr hilfreich um schnell (der geht nicht so in die Tiefe wie der Udemy Kurs von Maarek) nochmal einen Überblick über die Themen zu bekommen. Hier gibt es auch nach jeder Sektion ein paar Fragen was das ganze abrundet. Ansonsten kann man auf tutorialsdojo noch zusätzliche Fragen sowie ein PDF wo nochmal alles zusammengefasst ist (> 250 Seiten!) erwerben. Die Fragen würde ich wieder kaufen (ca 15 Euro), ins PDF habe ich kaum reingeschaut, hier reicht meiner Meinung nach die AWS Doku auch. Bei mir musste es jetzt mit der Vorbereitung schnell gehen weil der alte DevOps Engineer ja zum 6. März ausläuft, aber wenn ich noch ein Zertifikat mache würde ich auf jeden Fall mehr in der AWS Konsole ausprobieren und ein bisschen mehr mit den Sachen rumspielen - aber das braucht halt Zeit die man sich nehmen muss.

Das ist überall so, egal was du machst. Wo ziehst du die Linie zwischen dumm und klug? Wo zwischen faul und fleißig? Mir scheint als wäre beides eher ein Spektrum und die wenigsten Personen befinden sich am äußeren Ende der Skala. Und ich finde es ehrlich gesagt ganz schön daneben 80% der Leute als dumm abzustempeln, sagt meiner Meinung nach mehr über dich aus als über dein Umfeld. Zumal eine "dumme" Person (auf den IQ bezogen) nicht unbedingt schlecht in ihrem Fach sein muss - ebenso wie eine kluge Person nicht unbedingt gut in ihrem Fach sein muss. Ich kenne genug Beispiele - in beide Richtungen. Eine gewisse Korrelation besteht natürlich schon, mehr aber auch nicht. Wenn du wirklich von so vielen "dummen" Menschen umgeben bist hast du mein vollstes Beileid. Ich glaube aber eher, dass die Leute einfach nicht wissen was sie tun und einfach ein wenig Anleitung brauchen - motiviert sind sie ja. Zumal ja auch technische Vorkehrungen getroffen werden können die verhindern, dass diese Leute zu viel kaputt machen bis sie sich besser auskennen. Dies würde aber implizieren, dass man die Ursache in fehlendem Wissen (änderbar) und nicht in Dummheit (nicht änderbar) sieht. Wie gesagt, ich denke sowas sagt mehr über dich als über dein Umfeld aus. Sorry, das musste jetzt mal raus.

Gibt doch schon MLOps, wofür braucht man dann den KI DevOps Engineer?

3600 sind ca 70k brutto Jahresgehalt bei SK1. Meiner Erfahrung nach definitiv mit den richtigen Skills und ein bisschen Engagement in der IT (v.a. Softwareentwicklung) erreichbar - vielleicht befinde ich mich aber auch in einer Bubble.

Ich störe euch alle nur echt ungern, aber wollt ihr das nicht vielleicht per PN klären? Zudem ich bezweifle, dass das @CoffeeJunkiebei der aktuellen Entscheidungsfindung behilflich ist.

Hmmm, weiß nicht. Klar ist Knowledge Sharing wichtig aber gewisse Sachen sollte man doch einfach mal voraussetzen dürfen. Bei einem Azubi erkläre ich sowas auch gerne aber bei einem Vollzeitentwickler würde ich schon erwarten, dass er weiß, dass man für private Repos Zugangsrechte in Form von Credentials braucht. Oder wenn er es nicht weiß zumindest googlen kann. Einen gewissen Mindestanspruch darf man doch wohl haben dürfen ohne als Kollegenschwein abgestempelt zu werden, zumal es sich hier ja wirklich um die Basics der Basics handelt.

Hört sich für mich so an als wäre Frontend wieder nur eine Notlösung und du willst eigentlich was anderes machen. Notlösungen würde ich in deiner Position jedoch nicht nehmen weil ich denke, dass du mindestens 2, eher 3 Jahre beim nächsten Arbeitgeber bleiben solltest.

Automotive teilt sich hierbei auf 3 Monate DevOps bei Tochterfirma und 1 Jahr React bei aktueller Firma auf? Habe ich das richtig verstanden? Die Branchen sind relativ egal, was zählt ist wie lange du bei welcher Firma warst. Und wie passt mit zusammen?

Die drei Bananen und dein merkwürdiger Manager hin oder her, aber bei so vielen Wechseln würden bei mir als Personaler langsam die Alarmglocken losgehen. Natürlich kannst du nochmal wechseln, aber dann würde ich auch sicher gehen wollen, dass das vorerst dein letzter Wechsel ist und du mal ein bisschen länger bei einer Station verharrst. Bei der Anzahl an Stationen in der kurzen Zeit stellt sich dann nämlich schnell die Frage ob du nicht vielleicht das Problem bist. Was wäre denn überhaupt deine Alternative bzw. dein Traumjob? Und was garantiert auch dir selber, dass du da nicht wieder nach einem halben Jahr weg bist?

Zumal es laut dieser Definition ja auch ausreicht irgendwas zu schreiben was über Rechnernetze (z.B. Internet) erreichbar ist. Muss keine Webseite sein, muss keine UI haben, muss nicht von einem Menschen genutzt werden (Maschine-Maschine Kommunikation reicht auch) und muss nicht mal zwangsläufig HTTP(S) nutzen. Mit dieser Definition dürfte man wohl >95% der Softwareentwickler erschlagen. Das einzige was vermutlich nicht unter diese Definition fallen dürfte sind Offlineapplikationen sowie eventuell Betriebssysteme. Webentwicklung im engeren Sinne waren für mich stets Websites und Webapplikationen mit HTTP(S) Schnittstellen, nicht jedoch Webservices. Vielleicht hatte ich aber auch eine falsche Definition von Webentwicklung. Dennoch: wenn auch z.B. IoT unter Webentwicklung fällt frage ich mich doch ob die Definition nicht ein wenig zu weit gegriffen ist - gerade wenn man die Umfrage und die potentielle Verwertbarkeit der Informationen im Hinterkopf behält.

Willst du das Zertifikat oder das Wissen was für das Zertifikat vorhanden sein sollte? Ersteres wirst du vermutlich bekommen, bei Zweiterem wäre ich mir nicht so sicher, bzw. könnte mir vorstellen, dass du das nach der Woche noch ordentlich nacharbeiten müsstest. Ich denke wenn die Teilnehmer regelmäßig durch die Zertifikatsprüfungen fallen würden würde da keiner mehr hingehen. Eine gewisse Quote muss also bestehen. Jetzt nochmal zu deinem CCNA: 2 Monate sind ca 60 Tage. Unter der Annahme, dass du jeden Tag eine Stunde lernst (keine Ahnung ob das realistisch ist) sind das 60 Stunden. 60 Stunden muss man also in lernen investieren. Das aufgeteilt auf 6 Tage sind 10h/Tag was knackig, aber dennoch möglich ist. Falls du eher zwei oder drei Stunden pro Tag gelernt hast (also 120 oder 180h insgesamt) ließe sich durchaus das Argument bringen, dass Lernen mit Trainer vielleicht schneller geht als alleine und du ja nur die Prüfung bestehen und nicht alle Inhalte können musst. Also ja, ich kann mir durchaus vorstellen, dass man nach 6 Tagen prüfungsreif ist. Ich glaube allerdings nicht, dass man nach 6 Tagen alle Inhalte verstanden und verinnerlicht hat, sowas braucht einfach Zeit. Gar nicht mal aktive Lernzeit, aber Zeit die dein Gehirn das im Hintergrund verarbeitet. So zumindest meine Erfahrung. Wenn du kurzfristige Kenntnisse brauchst würde ich persönlich eher selbständig auf Lücke lernen anstatt so einen Kurs zu besuchen. Wenn du allerdings gar nicht weißt was dich erwartet und was deine Lücken sind kann man das schon Mal machen um die Basics eingetrichtert zu bekommen. Nur stell dich halt auf ordentlich Nachbereitung ein wenn du das ganze auch vollständig verstehen willst. Was sagt denn dein Chef zu dem ganzen?

Könntest du die Aussage ein bisschen erläutern? Mir scheint das kommt ganz stark aufs Produkt an, oder etwa nicht?

Wo hast du das gelesen? Auf der Bayer Homepage? In Posts von Bayer-Dualis? EDIT: Verdammt, @alleswegwar schneller.

"Teilzeit oder Vollzeit, was ist dir am Liebsten?" - 40k Teilzeit ist je nach Stunden gar nicht mal so schlecht

Ist das so? Ich hab mittlerweile schon mit einigen Personen aus prestigeträchtigen Unternehmen zusammengearbeitet und auch hier schwankt die Qualität und Motivation. Dass bei DAX und FAANG nur die fähigsten und kompetentesten reinkommen würde ich garantiert nicht unterschreiben, auch da gibt es eine Menge Gschaftler und Dampfplauderer. Ist aber auch zu erwarten, bei der Größe kann nicht jeder gut sein. Ob der Durchschnitt oder Median da besser ist... Dazu will ich keine Aussage treffen. Ausgenutzt ist relativ und viel Arbeit führt nicht zwangsläufig zu Burnout. Wenn die Arbeit einem Spaß macht würde ich bei viel Arbeit nicht zwangsläufig von Ausnutzung sprechen. Die Gefahr besteht allerdings durchaus. Schlussendlich bleibt mir nur übrig zu sagen, dass Leistungswille und Fähigkeit auch nur der Normalverteilung unterliegen und man es selber in der Hand hat mit welchen Leuten man viel (Arbeits-)Zeit verbringt. Allerdings gesellt sich gleich und gleich gerne

Ich würde nicht sagen, dass der Zug schon abgefahren ist. Wir sprechen hier von jemandem frisch nach der Ausbildung, hier stehen noch alle Türen offen. Ich würde die ganze Entscheidung nicht davon abhängig machen wie gut man wo verdienen kann, sondern was dir Spaß macht. Die allermeisten Entwickler verdienen gut genug um sich dieses Privileg leisten zu können. Was die Zukunft bringt kann eh keiner sagen, man kann höchstens raten. Technologisch kann man sich allerdings oft an den USA orientieren, was da technologisch passiert kommt oft mit 3-5 Jahren Verzögerung auch zu uns. Wenn du Bock auf Frontend hast, dann mach Frontend. Wenn du dir noch nicht sicher bist würde ich an deiner Stelle eher versuchen eine Fullstack Stelle zu finden, damit hälst du dir mehr Optionen offen. Ansonsten gilt das was immer geht: Je besser du bist, desto schwerer bist du zu ersetzen (sofern deine Skills gefragt sind). Je tiefer dein Wissen geht (das hat nichts mit Generalist vs Spezialist zu tun), desto gefragter bist du in der Regel. Und schlussendlich sollte dir bewusst sein, dass du in den gut dotierten Stellen nicht fürs Coden sondern fürs Denken bezahlt wirst.

Je größer das Team/Abteilung/Firma, desto eher kann man sich als Einzelner hinter den Leistungen der Masse verstecken. In kleinen Teams fällt sowas i.d.R. aber sehr schnell auf. Vielleicht solltest du wirklich wieder in eine kleinere Firma wechseln. Da gehören aber auch zwei dazu, man muss sich nicht alles anhören. Wenns dich nervt sag deinen Kollegen sie sollen jemand anders damit nerven. Man muss seine Zeit nicht jedem schenken. Vielleicht. Vielleicht hat aber auch die Masse Unrecht (soll auch vorkommen) oder die persönlichen Ansprüche sind nur bedingt mit der der Masse kompatibel. Und gerade in Großkonzernen will meiner Erfahrung nach die Masse nicht performen. Wenn das aber der Anspruch an einen selbst ist kann das durchaus zu Konflikten führen, dennoch muss die Konsequenz nicht zwangsläufig "an sich selbst arbeiten" lauten. Alternativen gibt es auch ausreichend: Stelle oder Projekt innerhalb des Unternehmens wechseln, Abkapseln von Kollegen, AG wechseln (wenn man weiß, dass dort eine andere Kultur herrscht) oder auch Firmengründung oder Selbstständigkeit. EDIT: So viel zum Thema Leistungsbereitschaft. Zum Thema fachliche Herausforderung kann ich nur sagen, dass im Endeffekt alle nur mit Wasser kochen. Bei mir hat diese Erkenntnis zu einer gewissen Enttäuschung, ja sogar Resignation geführt. Einigen anderen Entwicklern mit denen ich gesprochen habe ging es genauso. Ich denke man muss sich einfach damit abfinden, dass es ab einem gewissen Level keine Leute mehr gibt von denen man wirklich noch viel (fachliches) Lernen kann, bzw. dass man diese Leute exponentiell schwerer findet. Ab einem gewissen Level muss man sich die Sachen einfach selber beibringen und sich die Herausforderungen ggf. auch außerhalb der Arbeit suchen.

Hi, ich hab Ende letzten Jahres den AWS Developer Associate gemacht, hier sind die Sachen die ich zur Vorbereitung genutzt habe: - Die Practice Questions von Stephane Maarek - Die Practice Questions von Neal Davis - Der Kurs von Freecodecamp auf YouTube: Die Probefragen habe ich nicht gemacht weil ich stumpf Fragen auswendig lernen wollte (dafür gibt es andere Seiten), vielmehr wollte ich ein Gefühl für die Art von Fragen und vor allem die Themen entwickeln. Ich habe mit den Fragen von Stephane Maarek begonnen weil ich hier die Erklärungen besser fand, habe mich aber nicht nur auf die Fragen verlassen. Manche Sachen musst du einfach wissen (X-Forwarded-For Header zum Beispiel), bei den meisten Themen musst du allerdings ein Grundverständnis für die Services und deren Funktionsweise entwickeln und hier helfen die Fragen enorm. Wenn ich jedoch gar nichts verstanden habe (z.B. habe ich KMS am Anfang nicht verstanden) bin ich auf andere Resourcen umgeschwenkt. AWS Docs, Whitepapers und das oben genannte Video haben mir hierbei sehr geholfen. Das Video habe ich nicht komplett durchgeschaut, ich habe es nur benutzt um Lücken zu füllen. Nach den Fragen von Stephane Maarek bin ich auf die Fragen von Neal Davis geswitched, diese sind näher an den Prüfungsfragen (hatte auch 2-3 die genau so in der Prüfung dran kamen) und helfen noch einmal um ein bisschen zusätzliche Routine reinzubringen. Wenn es aber nur um stumpfes Auswendiglernen geht gibt es wie gesagt bessere Seiten Wie der Sprung vom Cloud Practicioner ist kann ich nicht sagen da ich diesen nicht gemacht habe. Auch hatte ich ~1 Jahr AWS Vorerfahrung (und davor Azure), bin also schon vorbelastet. Deswegen war für mich die sehr theoretische Vorbereitung ausreichend, falls du nicht ähnlich vorbelastet bist würde ich dir empfehlen ein bisschen mit den Services rumzuspielen um ein Gefühl dafür zu bekommen. Fast die gleiche Strategie verwende ich gerade um aktuell für den AWS Solutions Architect Associate zu lernen, das einzige was ich verändert habe ist, dass ich die Probefragen auch in Anki kopiere um mithilfe von Spaced Repition lernen zu können. Für die Professionals/Specialities muss ich mir noch was einfallen lassen, da es hier deutlich weniger Probefragen gibt