Zum Inhalt springen

Velicity

Mitglieder
  • Gesamte Inhalte

    630
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    5

Alle Inhalte von Velicity

  1. @skylake Klingt alles interessant und ist eigentlich viel mehr als wir unseren neuen Kollegen in erster Zeit abverlangen. Wobei wir als kleines Unternehmen auch nicht zig Leute hier hätten für sowas. Geht ja meist eher um einzelne Stellen, wo ggf. 2-3 Leute mögliche Treffer wären. Bzgl. dem Buch, ich habe kein Problem für ein gutes Produkt ein paar Euro auszugeben, ist ja nun nicht unbezahlbar. Ein weitreichenderes Problem, wo auch die Infrastruktur involviert ist, wie in deinem Beispiel der Webserver, finde ich auch ganz spannend. Letztlich brauchen wir eben auch Generalisten, die sich auch an sowas rantrauen. Sprich verstehen wo befinde ich mich gerade mit dem Bug, was kommt davor, was danach. Eben ein grober Überblick. Unlösbare Aufgaben oder Bugs die keine sind usw. finde ich ziemlich mies. Klar sagt auch was über die Bewerber aus. Habe ich bis dato in einen Bewerbungsgespräch nie gehabt aber mal in einen Lehrgang bzgl. Elektroinstallationen, wo wir nacheinander Fehler an Anlagen suchen durften. Ging dann um nix Wichtiges wie einen Job, sondern einen Döner für die Runde. War trotzdem gemein, da man sich natürlich sehr unsicher war, wenn der Ausbilder sagt da ist ein Fehler, such ihn und man eben keinen findet und meint das passt alles. Und ja mit Stress gehen Leute auch unterschiedlich um. Wobei wir z.B. auch Leute haben die richtig schnell ins schwimmen kommen bei Stress aber sonst super sind. Da ergänzt man sich eben.
  2. @allesweg ich glaube wir hatten einfach mehr Glück als Verstand. Weiß nicht wie das Bewerbungsgespräch der anderen Leute aussah, die vor mir da waren aber meines war ein wenig Smalltalk und erzählen was ich gemacht habe und das wars. Und ich war mit so gut wie keiner Technologie die hier genutzt wird wirklich vertraut. Bei mir war aber auch noch die Empfehlung von einem Lehrer im Hintergrund, keine Ahnung ob das was geändert hat. Aber rein vom Bewerbungsgespräch hatte das Unternehmen 0,0 belastbare Belege, dass ich in irgendeiner Weise für das Unternehmen brauchbar sein könnte.
  3. @Rabber ich glaube diese Themen werden gerade hier im Forum auch heißer gekocht als gegessen. Hier sind eben vorwiegend Leute unterwegs, die aktiv ihre Karriere pflegen und sich da groß Gedanken drum machen. Wir haben ja ansonsten kein Problem gehabt gute Leute zu finden. Fällt halt nur auf, dass wir bei den letzten vier Einstellungen zwei wieder gehen lassen haben und der eine in der Probezeit aktuell auch nicht überragend ist. Ich glaube auch so viel niedriger ist die Bezahlung für unsere Region nicht. Wir haben einige Leute, die von einem der größten Arbeitgeber der Region abgewandert sind und zu uns gekommen sind. Sicher wird man Stellen finden, wo man mehr Gehalt kriegt, ich gehe aber davon aus, dass man genug findet wo man das Gleiche oder Weniger kriegt. Klar zahlt ein 10-15 Mann Unternehmen in einer nicht so lukrativen Branche in Bremen nicht so viel wie ein Konzern einer lukrativen Branche in München, Stuttgart oder Frankfurt. Die Lebensunterhaltskosten sind natürlich auch ganz andere. Und ja der Stack bzw. hauptsächlich PL/SQL und die Business-Logik da drin ist halt ziemlich altbacken. Aber daneben hat man durchaus mal mit neueren Sachen zutun. Ich persönlich finde auch das Anbinden von Maschinen und Fördertechniken ganz spannend, daneben gibt es bei uns im Webbereich eben MDE Geräte, die letztlich nix sind als Android Geräte, haben ein paar Projekte mit Wearables z.B. Datenbrillen usw. Und neben dem PL/SQL Part ist es neben normale Web- und Desktopentwicklung. Ist nun nicht so als leben wir komplett in den 70igern. Wenn ich mal negative Aspekte ausklammere, über die wir hier denke ich auch genug geredet haben, kann ich dem Laden auch eine Menge Positives abgewinnen. Zumindest mir macht die Abwechslung sehr viel Spaß. Auch fand ich es auch immer interessant in so gut wie alle Abläufe einen Einblick zu haben und auch mitreden zu können. Klar ist alles nix, was man gut nach außen vermarkten kann aber ich nehme mal an das geht bei uns den meisten so, sonst würden der Großteil vermutlich nicht so lange im Unternehmen bleiben. Klar gibt es da auch andere Faktoren, ist eben alles ein wenig Nische und nicht so als findet man 5 Meter weiter einen AG, der das Gleiche oder was Ähnliches macht.
  4. Habe von dem Buch schon häufiger gehört es aber selbst noch nicht gelesen. Sollte ich ggf. nachholen. Generell finde ich es eine schöne Idee halbwegs realistische Aufgabe zu geben, weiß nur nicht ob das nicht Overkill ist vom Zeitaufwand für den Bewerber und es müsste eben trotzdem was sein, was leicht genug ist aber eben schwer genug um vernünftig zu sehen, was der Bewerber kann bzw. wie er an Aufgaben rangeht. Da sehe ich schon Branchespezifika als Problem und das viele noch nicht groß mit PL/SQL gearbeitet haben. Aber ggf. müsste man da einfach mal ein wenig Zeit reinstecken, da was passendes zusammenzustellen.
  5. Nein, wüsste auch nicht, wo ich das gesagt habe. Inbetriebnahmen laufen i.d.R. mit 2-6 Leuten ab, je nach Größe und das sind auch erfahrene Leute. In der Regel wird hier im Büro entwickelt. Bei Kunden ist man ggf. 10 Wochen im Jahr + ein paar Einzeltermine und da sind dann entsprechend Leute, die das System hier in der Geschäftsstelle umgesetzt haben, um es zu testen, mit dem anderen Gewerken, dem Kunden, um Schulungen durchzuführen etc. pp. Das sind eben dann auch neue Anforderungen. Du hast einen neuen Fördertechnikhersteller als Partner bei einem Projekt oder ein vorheriger hat eine komplett neue Schnittstelle, ein anderes Produkt etc. pp. Das ist eben keine Stangenware, die Anlagen sind Unikate und damit häufig auch die Schnittstellen. Sowohl die nach außen, als auch die Funktionalitäten, welche sie mitbringen, die in unser System abgebildet werden müssen. Das sind eben keine fertigen Standardschnittstellen, die ich mal eben mit einer beliebten Sprache anbinde, wo ich bereits fertige Lösungen in einer Paketverwaltung runterlade, wie für irgendeine Shop-Software. Angebundene Schnittstellen kriegen wir natürlich als Dokumentation und das sind dann lebende Dokumente, bis das Projekt live geht. Nein, an Positionen kann ich nicht rumdrehen. Bzw. ich kann überall Ideen einbringen. Sind eben ein kleiner Laden. Per se bin ich erstmal nur Entwickler. Und wir brauchen schon Leute, die wir vollumfänglich einsetzen können. Solche sind es eben auch, die in Rente gegangen sind. Wir brauchen nicht Leute für Kleinigkeiten, sondern Redundanzen, gerade in Bezug auf Krankheit, Urlaub, Inbetriebnahmen usw. Wie gesagt, die Reisetätigkeit war bei einer Person ein Problem, der schon mehrere Jahre da war, einfach weil er ein Kind bekommen hatte. Das ist kein generelles Problem. Tun wir denke ich siehe: Mal davon ab, dass beschriebene Probleme nix mit unseren System zutun haben, sondern mit reiner Logik und wie man etwas in Code bringt. Alles was Wissen in unserem System erfordert hätte wurde fertig vorgegeben. Ich sagte nach 1-2 Jahren. 6 Monate ist eben die Probezeit. Da wollen wir sehen, dass man der Person eine Aufgabe geben kann und der sich da zumindest langhangeln kann. Das hat nix zutun mit man darf keine Fragen stellen, kriegt keine Hilfe oder was auch immer. Aber eine halbwegs klar definierte Aufgabe oder etwas Vorhandenes nehmen und anpassen sollte da drin sein. Wie gesagt, die Aufgaben sind keine Raketenwissenschaft.
  6. Das waren die zwei Rentner, deshalb auch in Klammern und der Kollege der zunehmend immer häufiger gefehlt hat. Das war noch ganz lustig als es einzelne Tage waren, ging dann eben von seinen Urlaub ab, war unschön aber gut. War dann später aber auch mal Wochen inkl. keiner Erreichbarkeit. War nicht Vorort als es zum Kunden raus ging und nicht erreichbar, wo dann Leute quasi Montag morgen einspringen müssen und spontan ne Woche wegfahren usw. Sowas geht halt nicht. Und ja, das Problem hat eben mit der Zeit zugenommen und war irgendwann untragbar, auch wenn er sonst menschlich ein super Typ war und auch Fachlich gut war. Habe nun seinen Code nicht gesehen aber ich habe keine Beschwerden von der anderen Abteilung bzgl. seiner Arbeit gehört und der hat seine Tickets durchgeballert wie nix gutes. Drei, wie gesagt. Den Kollegen der immer fehlte und den Leuten am Ende der Probezeit, wie auch oben unter deiner Bonus-Frage angeführt. Oder eben daran, dass man den Mitarbeitern beim Bewerbungsgespräch so gut wie gar nicht auf den Zahl fühlt. Ich mein ich habe auch so gut wie nix von dem gemacht, was meine Tätigkeit umfasst und ich kann sicher nicht gut reden, gerade in einer Bewerbungssituation und bin hier trotzdem untergekommen. Ich hätte mich genauso 0 rein finden können in das System, in die verwendeten Programmiersprachen etc. pp. Bin quasi als Webentwickler für den Bereich PHP rein, ohne je eine Zeile PHP geschrieben zu haben. PL/SQL habe ich ebenfalls nie gesehen und meine SQL Kenntnisse waren auch eher ein paar Tutorials durcharbeiten. Ich habe also nix mitgebracht, von dem was gesucht wurde. Und die Ansprüche sind eben letztlich, dass ein Entwickler entwickeln kann. Dass er den Rest nach 1-2 Jahren Arbeit abnehmen kann und nicht mehr Betreuung kostet, als er Arbeit fertigbringt. Weil wir uns im Kreis drehen, viele nicht auf die Frage eingehen oder die Probleme woanders suchen, mit anderen Kontext und was weiß ich. Ich sag der Kollege hat Probleme etwas Neues zu entwickeln, den Aufruf in unserem System kriegt er fertig vorgegeben, er hat nix mit unser Codebase zutun und da drauf folgen ewig lange Diskussionen um lange PL/SQL Funktionen, Refactoring, dass keine Frameworks genutzt werden. Er soll ein paar verdammte Loops schreiben und Daten von ein paar Feldern in ein paar andere packen. Und wer wann geht von sich aus oder aus völlig anderen Gründen gekündigt wird, in Rente geht usw. tut auch nix zur Sache, dass unser Einstellungsprozess mangelhaft ist. Haben halt in Summe 2-3 Leute geschafft auch nur minimal auf die Fragestellung einzugehen. Ich weiß das andere macht mehr Spaß.
  7. Nun erstmal ist das Problem wie gesagt AN DER STELLE, nicht unsere Codebase, sondern neuen Code zu schreiben, der ein Problem abbildet. Das waren keine Probleme, die komplexere Stellen unseres Codes widerspiegeln würden, sondern einfache Aufrufe, die vorgegeben wurden. Die ewig großen PL/SQL Funktionen sind bei uns durchaus in großer Menge vorhanden. Wie gesagt, das war mal C und wurde nach PL/SQL überführt. Funktionen mit tausenden Zeilen sind keine Seltenheit, ebenso etliche Flags und was weiß ich was. Da bin ich aber nicht dein Horst, sondern eher der Gegenpool. Leider kann ich da schlecht an die Hauptfunktionen ran, denn hier das Interface zu ändern würde viele Wochen Arbeit nach sich ziehen, die ich mir nicht mal eben nehmen kann. Da schaffe ich dann aber Packages die zumindest leichtere Interfaces bieten und aus einer Funktion mit 7 Übergabeparametern von denen 2 Flags sind, wobei das noch untertrieben sind, es sind eher Modi als Int, von 0 bis 2-3 gehen, eben etliche Funktionen, die den Namen tragen was sie machen, 2-3 Parameter maximal brauchen und gut und dann auch keinen errorcode als return auswerten müssen, sondern Exceptions werfen. Wie gesagt, technische Probleme haben wir viele, da bin ich in der Ecke Web und PL/SQL dran und ein anderer Kollege im C# Bereich. Das ist aber nicht das, wo wir neue Kollegen reinwerfen und nicht das Problem. Sind sie nicht. In den letzten 5 Jahren, zumindest geschätzt, sind zwei in Rente und einer gekündigt wurden, weil er ständig mehrere Tage in Folge ohne irgendeine Meldung oder Erreichbarkeit gefehlt hat. Die sind eben nur nach deinen 12 Monaten gegangen (worden). Sind sie, was mit das Problem ist. Es sind zwei Leute in Rente gegangen, die um 30 Jahre im Betrieb waren, alle Projekte kannten und was auf den Kasten hatten. Es wurde einer gekündigt, der ebenfalls was auf den Kasten hatte und einige Jahre im Betrieb war, weil er regelmäßig fehlte. Dafür hatten wir dann zwei neue in der Probezeit, die diese beide nicht Überstunden haben und haben nun wieder zwei neue in der Probezeit. Mit einen hatte ich noch nicht so viel zutun, der macht auf mich aber den Eindruck, dass er zwar vieles noch nicht kann aber durchaus lernfähig ist und technisches Verständnis hat. Bei dem anderen sehe ich auch eher schwarz, wobei wir den vermutlich auch behalten werden. Drei, die vorher erwähnten. Zwei am Ende der Probezeit nach 5-6 Monaten, einem nach mehreren Jahren, weil er immer häufiger mehrere Tage am Stück fehlte.
  8. Steht letztlich in den Text oben aber wenn es dir zu lang ist: Zwei. Keiner. Waren nur welche, die länger dabei waren. Rente und keine Lust mehr auf Reisetätigkeit, weil Nachwuchs bekommen. Aktuell einer weniger.
  9. Das fällt bei den ersten größeren Aufgaben auf, wo derjenige ein wenig nachdenken muss und nicht kleine Aufgaben hat, um unser System kennenzulernen, wo die Programmierung banal ist und es darum geht, dass er versteht wie der Datenfluss im System ist, wie bestimmte psychische Abläufe abgebildet sind usw. Erstmal sieht der Mitarbeiter in seiner Probezeit die Anwendung an sich, aus Benutzersicht. Anschließend entsprechend die Leitstands/Poweruser Features. Dann die entsprechenden Anwendungen und Tools, Standard und Richtlinien usw. Dabei wird auch erklärt wie die Abläufe denn physisch wirklich aussehen, viele hatten ja mit der Branche noch nix am Hut. Dann die entsprechenden Datenbanktabellen und wie das Schema aufgebaut ist bzgl. der wichtigsten Konzepte, Routinen und co. die hinter diesen Sachen hinter stehen. Dann kriegt er kleinere Aufgaben zur Übung das mal auf Anwenderebene durchzuführen und das gleiche auf Codeebene. Sprich ein paar Datenbankoperationen und API Aufrufe. Danach gibt es langsam kleinere Aufgaben. Das sind dann eben kleinere Änderungen an bestehenden Code, wo eigentlich schon vorgekaut ist, was er zutun hat. Ich sag mal meine ersten Aufgaben dieser Art im Webbereich waren ein paar kosmetische Sachen, sprich etwas CSS, in PL/SQL eine Host-Schnittstelle, was eigentlich nur ein Mapper ist und solche Sachen eben, damit man mit den Tools, den Workflow und co. warm wird. Das nimmt eben zu von der Schwierigkeit aber irgendwann ist eben der Punkt, da kriegt man einen Ablauf, den man selbst umsetzen soll. Da kann der Kollege natürlich so viele Fragen stellen wie er möchte, hat Schnittstellenbeschreibungen und häufig auch Quellcode von einer Funktionalität, die ähnliches umgesetzt hat. Wie gesagt, eigentlich nicht wild aber eben der Punkt, wo es auch darum geht selbstständig komplexere Aufgaben zu verstehen. PL/SQL ist wie gesagt der Core, indem die Business Logik ist. Wir haben zwar auch 2-3 Leute, die nix anderes machen, der Großteil ist aber erstmal in einer Abteilung die vor allem die Anwendungen machen, die darauf aufsetzen. Sprich eine Web-Abteilung, die mit PHP hantiert und eine Desktop-Abteilung, bei der C# zum Einsatz kommt. Hier und da gibt es dann auch Insellösungen z.B. Java (Android) für Wearables. Die Leute sind schon relativ engagiert und viele sind am Zahn der Zeit, setzen auch privat verschiedenste Hobbyprojekte um, in verschiedenen Sprachen usw. Sicher hast du auch immer mal Leute, die älter sind, ihre Freizeit nicht mehr mit IT Themen verbringen. Von denen profitiert man dann eben in Bezug auf Know-How, Projektkenntnisse usw. PL/SQL ist eher verhasst aber war eben eine Entscheidung vor Jahrzehnten. Und wie auch schon erwähnt, der Code da ist schrecklich. Ist quasi ein Port aus einer riesigen C-Anwendung, der vermutlich auch ohne große Kenntnisse von PL/SQL ziemlich 1:1 übernommen wurde. Der Großteil ist wie bereits erwähnt Jahrzehnte hier. Es ging in dem Fall um zwei Leute und nun einen Dritten, wo ich auch glaube, dass das nix wird. Das sind immer noch Ausnahmen, die man aber ggf. vorher hätte erkennen können. Irgendwann muss man sich eben entscheiden, ob man glaubt, dass die Person eine Bereicherung für die Zukunft sein wird und das ist spätestens am Ende der Probezeit. Was der Kollege da an Aufgabe kriegt ist noch weit, weit entfernt von den wirklich komplexen Sachen aber schon mal etwas größeres als der Spielkram davor, was Aufschluss da drüber gibt, ob der Kollege in 1-2 Jahren ggf. auch mal den Laden schmeißen kann oder ob ich egal ob im Urlaub, krank oder was weiß ich für ihn erreichbar sein muss, wenn es z.B. mein Bereich ist.
  10. Kommt drauf an was Kurzzeit ist. Die letzten zwei haben wir vor Ablauf der Probezeit gekündigt, da offensichtlich war, dass sie am Ende nicht selbstständig arbeiten können und nicht die Leute Vorort entlasten, sondern auch weiterhin zusätzlich Ressourcen binden werden. Die waren also gut 6 Monate da. Für die sind aktuell zwei neue in der Probezeit, davon weiß ich bei einen auch nicht ob das was wird, macht auf mich nicht den Eindruck als kann ich ihm in einem Jahr eine komplexe Aufgabe geben und er würde wissen, wie er da ran geht. Davor haben wir auch einen gekündigt, der war gut 1-2 Jahre da, waren aber andere Probleme. War eigentlich sowohl fachlich, als auch menschlich top aber hatte irgendwelche Probleme, häufiger nicht da gewesen ohne sich abzumelden und das teilweise mehrere Tage und das auch während er quasi für eine Fahrt zum Kunden eingeteilt war und solche Späße, hat sich nie abgemeldet und auch nicht mit sich reden lassen, was denn los ist. Um die Zeit dann auch zwei in Rente gegangen. Davor habe ich nur einen kennengelernt, der mal gekündigt hat nach 3-4 Jahren. War einfach nicht sein Fall mit der Reisetätigkeit, weil er ein Kind bekommen hat und mehr Zuhause sein wollte. Wie gesagt, der Großteil ist halt schon mindestens ein Jahrzehnt hier. Ich nehme mal an, dass viele, wie ich auch Spaß dran haben, ein wenig mitwirken zu können, ein wenig mehr Verantwortung zu haben. Der mir auch nicht hilft, wenn er interne Anforderungen nicht umsetzen kann, mit externen technischen Schnittstellenbeschreibungen nicht klar kommt usw. Wie gesagt, die Kundenwünsche sind schon sehr fachlich. Das Problem ist es gewesen, das in Code umzusetzen. Unsere Kunden kommen dir mit ich möchte in der Maske 37/2 zusätzlich die Aufträge im Status 62 sehen mit einer roten Hintergrundfarbe, um es mal für ein einfaches Beispiel darzustellen, die sagen dir quasi schon die Quellcodedatei und Datenbankabfrage. Waren eben eher Logikfehler. Nicht verstehen, dass etwas in der Implementierung in einer bestimmten Reihenfolge passieren muss, aufeinander aufbaut, an welcher Stelle im Code man welche Informationen hat oder nicht etc. Anforderung in Code bringen, ist das Problem, nicht die Anforderung per se zu verstehen, sondern wie man sie im Code abbildet und das kann dir keiner abnehmen, der nicht entwickeln kann und in unserem System drin ist. Wenn Kundenwünsche nicht verstanden werden, dann kommuniziert man eben mit dem Kunden und das muss auch kein neuer Kollege machen, das macht ein erfahrener Projektleiter, das macht der Entwicklungsleiter etc. pp. Ist nicht so als muss hier der Kollege in der Probezeit mit dem Geschäftsführer oder Lagerleiter größere Abläufe beschnacken. Aber wenn ich dem Kollegen sage, er muss aus der Tabelle eine Zeile auslesen, die hinteren 10 Felder, in die vorderen 10 Felder übertragen, die Status Spalte auf Status X stellen und den Satz als neuen Satz einfügen im Status Y und anschließend mit dem eingefügten Satz eine Funktion aufrufen, dann erwarte ich, dass der Kollege das versteht und er nicht Wochen lang probiert irgendwie die Funktion am Ende mit dem ersten Datensatz aufzurufen. Das ist keine Raketenwissenschaft was gefordert wird.
  11. Nach deinem Glauben Erstes. Aber auch nur weil 90% der Sachen, die ihr anspricht nicht das Problem sind, weshalb die Leute gegangen sind und Probleme sind, mit denen 80% aufwärts der Bewerber problemlos klarkommen und welche die Leute nicht so stark zu stören scheinen, wie euch. Denn eine starke Fluktuation haben wir bei weiten nicht. Zwei Leute sind kürzlich in Rente gegangen, die 30 Jahre da waren, eine Person geht bald in Rente und ist auch schon 30 Jahre dabei, einer ist knapp 20 Jahre dabei, einer 15 Jahre und alle außer zwei neueren Kollegen, welche die in Rente gegangenen ersetzt haben seit knapp 10 Jahren. Das Symptom ist der Finger tut weh. Die Ursache ist, weil wir ihn auf den Finger gehauen haben. Und ja, da will ich an der Ursache ran, die für mich ist, den Bewerber vernünftig zu vermitteln, was von ihn erwartet wird und auch zu prüfen, dass er dem gerecht werden kann, denn die meisten können das. Ja es gibt viele andere Probleme, wir packen ihn eine Reiszwecke auf den Stuhl und hauen ihn gleichzeitig noch auf den kleinen Zeh. Das sind aber nicht die Ursachen für das Symptom, dass ihn die Hand wehtut. Das sind andere Probleme, die sicher auch Aufmerksamkeit benötigen, die aber nicht das erste Problem nicht existent machen. Sicher gibt es unendlich viele Dinge, die ich gerne anders hätte bei uns im Betrieb, die aber schlicht komplett nicht in meiner Verantwortung liegen und auf die ich keinen Einfluss habe, gerade eben Sachen, die am Ende viel Zeit und Geld kosten, sofern ich nicht vorhabe Geld mitzubringen, um vorhandene Software zu verbessern, zu dokumentieren, zusätzliche Leute für bestimmte Nischenprobleme einzustellen etc. pp. Gerade die Situation, dass die Leute bei uns eher Generalisten sind, liegt mir z.B. sehr. Ich fände es stinklangweilig nur ein kleines Zahnrad in einem System zu sein, das ich nicht verstehe. Mir gefällt es, dass ich alles mitkriege von der Angebotsphase, über die Pflichtenheftgespräche, die Planung, Umsetzung und die Betreuung das Projekts. Bei so einfachen Sachen, wie ein wenig am Bewerbungsprozess rumschrauben kann ich mich aber problemlos einbringen. Ich möchte mich halt einbringen, wo ich es kann und da kann man sich sicher weiter rantasten aber irgendwo muss man anfangen und das ist nicht bei, Chef was hältst du davon, dass wir alle aktiven Projekte in dem nächsten Jahrzehnt refactoren und keine neuen Projekte mehr umsetzen während dieser Zeit. Die Gehälter, Miete, Lizenzen und co. übernehme ich für diese Zeit. Außerdem stellen wir noch einen dedizierten Anforderungsmanager, einen DBA, ein paar Projektleiter, einen Scrummaster, einen FISI, einen UI und UX Designer an. Es sind schlicht Sachen, die erstmal einfach ein wenig Verbesserung bringen. Denn Zeit, die so für die Einarbeitung von jemand verschwendet wird den man nicht hält, ist auch wieder Zeit, die für all die anderen Probleme fehlt. Und da in diesem Prozess eben wohl auch Fehler gemacht werden, sehe ich kein Problem diese vermutlich leichter anzugehenden Probleme fix zu lösen. An vielen anderen Sachen, gerade technischer Natur bin ich eh dran. Das sind aber eben keine Sachen ala wir nutzen einfach mal eine komplett andere Sprache mit bestimmten Frameworks und co. für das Core System, sondern Dokumentationen, ein paar saubere Interfaces mit denen man arbeiten kann, ein paar Tests, ein paar Simulatoren um komplexere Prozesse vernünftig testen zu können, ein paar interne Tools und Snippets, um die Entwicklung zu vereinfachen und zu standardisieren, um Fehler zu vermeiden, den Kram konsistenter zu haben und es den Entwickler zu vereinfachen und Zeit zu sparen. Was für Rollen wir nun zusätzlich einstellen oder das Core System zu ändern und 20+ Kunden abzustoßen die Millionen in die Kassen spülen mit Wartung, Erweiterung und co., weil ich ein wenig mehr Developer Happiness oder schnellere und leichtere Einarbeitung von neuen Mitarbeitern haben möchte sind eben Entscheidungen weit über meiner Gehaltsklasse. Keine Ahnung, warum das immer in so einer sinnlosen Diskussion ausufern muss. Was wäre denn so schwer daran zu sagen, wir nutzen quasi Probleme aus der Realität und vereinfachen diese stark und nutzen das als Grundlage für einen Test oder jo wir nutzen Aufgaben ähnlich LeetCode, damit ist zumindest halbwegs sichergestellt, dass es am Programmieren nicht scheitert, auch wenn die echte Arbeit stark davon abweicht etc. pp. Wir machen das kurz im Gespräch selbst, wir schicken ihn mit einer Aufgabe nachhause, wir machen das über einen Tag, wo er mal im Team mitarbeiten kann ala 1 Tages Praktikum etc. pp. Denn das war dir ursprüngliche Frage. Nicht was alles im Unternehmen bei uns schief läuft, was refactored werden soll, welche Sprache oder welche Frameworks genutzt werden sollten oder dass wir einen Anforderungsmanager einstellen sollten. Mir geht es am Ende eben um Sachen, die ich beeinflussen kann und verbessern kann.
  12. Die Entwickler machen bei uns ebenfalls Support und Rufbereitschaft, das ist nicht rausgetrennt. Ist eben auch kundenspezifisch und relativ komplex, da kann man keinen Callcenter eine Anleitung in die Hand geben. Die Leute kennen sich quasi auch vom sehen durch die Inbetriebnahmen Vorort, führen die Schulungen durch usw. So viel an Support fällt da auch nicht an. Unsere Kunden sind da auch relativ fit in unseren System und die Anforderungen sind oft auch ziemlich technisch und auch beim Support weiß er schon wen er anruft, welche Abteilung das betrifft usw. Der Vertriebler kann da auch nicht viel mit anfangen. Das geht dann meist eher die andere Richtung. Also jetzt ab von den großen Projekten, die über Vertrieb, Entwicklungsleiter, Pflichtenheft und co. gehen. Sprich der Kunde ruft mich an, er wünscht sich eine Erweiterung für etwas, was meinen Fachbereich betrifft. Fängt an zu reden und ich muss eben einschätzen ob das Kleinkram ist bzw. schau mir das mal an oder kann ihn gleich abwürgen und sagen dass werden wir über ein entsprechendes Angebot machen und nicht einfach über den normalen Stundensatz abrechnen und muss auch nochmal schriftlich her, denn das ist nicht mal eben so. Dann schickt der Kunde seine Ausführung an den Vertriebler, der schickt es wieder zu mir für die Aufwandsschätzung, ich schau mir das an, sag wie der Aufwand aussieht und was gemacht werden muss, der Vertriebler probiert die Abläufe zu beschreiben für das Angebot, holt mich nochmal rüber zum drüberlesen/korrigieren und dann geht das raus zum Kunden. Daraus mach ich dann eben entsprechende Arbeitspakete in JIRA. In der Regel setzt es auch der um, der das mit den Kunden schonmal angeschnitten hat, es sei denn da gibt es große zeitliche Lücken oder derjenige ist komplett dicht mit Arbeit. Angerufen wird da für sowas aber auch nicht ein Frischling, sondern eben Leute die in der Regel schon Jahre hier sind bzw. die Leute die den Kram auch umgesetzt haben und einschätzen können. Bei Sachen wo der Kunde auch gleich weiß, dass geht über mehrere Bereiche und ist was größeres wendet er sich i.d.R. gleich an den zugehörigen Projektleiter.
  13. Korrekt. Wobei "Standard" da ein großes Wort ist. Es gibt ein Leitprojekt, was am aktivsten ist, wo quasi alles reinkommt, was für den Kunden ist, als auch der "Standard" ist. Damit kriegt der Kunde eben auch Features, die er nicht brauch aber auch welche, die er brauchen kann quasi für Lau zu den Releases, wo er seine aktuellen Erweiterungen kriegt. Neue Projekte sind dann Leitprojekt + kundenspezifischen Erweiterungen. Je nachdem ob es Sinn macht für den Standard wird das ins Leitprojekt übernommen. Stellen sind da verschieden. Wenn das Kleinkram ist an nicht kritischen Stellen, dann entscheidet das im Zweifel der Entwickler selbst. Größeres wird dann in Besprechungen angesprochen. Mittelgroße Sachen entscheiden dann eben die Projektleiter, richtig große Sachen der Entwicklungsleiter. Nicht ganz so starr, ala so ist es und muss es gemacht werden. Denke die Leute hier wissen schon, wo ihre Grenzen sind, was sie entscheiden können und wo sich die Sachen in größerer Runde ansprechen. Die Leute haben in Summe aber schon sehr viel Freiraum und Mitspracherecht aber eben auch Verantwortung.
  14. @allesweg Keine Ahnung, ich habe noch nie gesehen, was so ein Anforderungsmanager macht und womit man den 40 Stunden die Woche beschäftigen könnte. Bei uns steht am Anfang des Projektes die Projektleitung, die das Lastenheft durcharbeitet, dann die Pflichtenheftspräche beim Kunden führt und dieses erstellt, da draus dann Arbeitspakete für die einzelnen Abteilung macht, welche angereichert werden mit Schnittstellenbeschreibungen. Daneben gibt es eben Kleinkram, der via JIRA, Mail oder Telefon läuft, genauso wie der Support. Dafür muss der Entwickler trotzdem die Sprache des Kunden sprechen können. Gibt natürlich noch Sachen dazwischen, da sind dann i.d.R. die erfahrenen Leute der Fachabteilungen gefragt, die das entsprechend definieren. Den Code muss der Entwickler aber eben schon selbst noch zu Stande bringen, genauso wie technische Schnittstellen verstehen. Oder soll da einer neben stehen und diktieren?
  15. Weil es komplette Zeitverschwendung für beide Seiten ist. Wir haben knapp über 10 Leute hier. Da drunter viele, die schon Jahrzehnte hier sind, einige die ein paar Jahre da sind. Mal geht wer in Rente, mal wechselt auch wer nach ein paar Jahren. Dann brauch man eben eine neue Person. Ist eben nicht so als laufen uns die Leute hier alle paar Monate weg. Nix desto trotz haben wir eben dann doch mal Leute, wo das gar nicht passt. Und da das zuletzt zweimal hintereinander aufgetreten ist, stelle ich mir eben die Frage ob man frühzeitiger abklären könnte, ob das passen könnte. Einfach weil ich weiß, dass sowas aktuell im Bewerbungsgespräch relativ milde abgeklopft wird und das wohl nicht mit den Anforderungen übereinstimmt.
  16. Ich glaube bei sowas scheitert es bei uns ein wenig an der Firmengröße. Wir reden hier von 10-15 MA an dem Standort. Da haste eher Generalisten. Das ist nix was von Anfang an gefordert ist, sondern schleift sich eher so ein mit den Aufgaben. Und es geht schon um technische Umsetzung. Problem ist da nicht, dass Kunde und Entwickler aneinander vorbeireden, sondern generell wie löse ich das, wie bilde ich das ab. Gleiche bei den externen Schnittstellen, da geht es um Bits und Bytes. Mal ein Beispiel vom letzten Mitarbeiter, wo das nix wurde. Der Kollege hat vorher tatsächlich schon mit PL/SQL gearbeitet. Zwar nicht in unserem Bereich (Lagerverwaltung/Materialfluss), sondern im ERP/Host Bereich. War auch schon einige Jahre Entwickler. In unseren System wurde er eingearbeitet, hat immer wieder kleinere Aufgaben gekriegt, natürlich nach und nach etwas größer werdend. Das erste halbwegs große dann war die Umsetzung eines Simulators für eine Fördertechnik. Schnittstelle ist extern vom Fördertechnikanbieter. Der eigentliche Prozess auf unserer Seite war quasi schon fertig und hat auch schon mit der Echtfördertechnik gearbeitet. Seine Aufgabe war nun einen Simulator zu schreiben, der quasi unsere Datenübertragung simuliert und das Verhalten der Fördertechnik. Dafür hatte er die entsprechende Schnittstellenbeschreibung, konnte den Prozess der Gegenstelle (also unsere Seite) sehen und hatte quasi Millionen von Datensätzen wie der Verlauf der Daten in echt aussieht. Als auch einen ähnlichen Simulator, den es vor Jahren mal gab für ein ähnliches Szenario. Echtablauf war quasi Fördertechnik meldet wo eine Palette/Kiste, wir haben einen Netzwerkprozess der pollt und den Baustein der SPS ausliest, die Sachen bei uns in eine Tabelle schreibt als Hexstring als gelesenen Zustand, dort steht also drin, wie es in der SPS echt aussieht. Der Fördertechnikprozess auf unserer Seite liest diesen Satz, konvertiert ihn in entsprechende Strukturen, führt damit ein paar Sachen in unseren System aus (Pathfinding, Buchungen, Validierungen etc. pp.) und schickt auf der anderen Seite generiert aus unseren Transportaufträgen Ziele in einen entsprechenden ausgehenden Satz, der dann wieder vom Netzwerkprozess an die SPS geschickt wird, der dient nur zur Übertragung und hat nur die Sachen, die geändert werden. Aufgabe also ohne den echten Netzwerkprozess die ausgehenden Daten einlesen (sind auch gespiegelt in den Gelesenen). Die Daten von unserer schreibenden Seite in die Lesende schreiben. Beachten, dass es da Möglichkeiten gab was zu escapen bzw. nicht zu senden, sprich eine Schnittmenge aus beiden Sätzen bilden. Und quasi in einer weiteren Prozessstufe dann schlicht die Palette auf das dort eingetragene Ziel zu buchen mit einen Aufruf einer Funktion in unserem System. Leicht vereinfacht und sicher gibt es da noch Details aber das wars in groben. Der Kollege konnte auch nach hundert mal erklären nicht verstehen, dass die gelesenen Sätze der Zustand in der SPS ist und die schreibenden Sätze nur Sätze sind, die dazu da sind, den Zustand in der SPS zu ändern und hat das dauernd durcheinander gebracht mit Telegrammschnittstellen, unsere Sätze und deren Sätze etc. pp. Und hat nicht verstanden, dass er erstmal die Datenübertragung von einen in den anderen Satz machen soll, sprich den Teil, den sonst der Netzwerkprozess macht. Der hat da viele Wochen dran rumgedoktert, man hat ihn wirklich immer wieder die gleichen Sachen erklärt, die Probleme, die es macht wie er es gerade probiert. Ich weiß echt nicht, was man noch machen hätte können, als ihn die Tastatur wegnehmen und das selbst tippen. Er konnte einfach die logischen Abläufe, die physisch passieren nicht in entsprechenden Code nachstellen bzw. verstehen wie das in welcher Richtung passiert. Nächste Aufgabe war dann wieder was mit einer externen Schnittstelle. Anbindung an eine Pick-By-Light Anlage, auch da ähnliche Probleme, wie man das nun aufbaut, in welcher Reihenfolge er die Sachen abarbeiten muss usw. Das waren einfach reine Logiksachen, die nix mit unseren System zutun hatten, sondern psychische Abläufe in richtiger Reihenfolge mit seiner Anwendung abzubilden.
  17. Pair Programming fände ich tatsächlich mal eine gute Idee für viele Stellen bei uns gerade für die Einarbeitung in unser System. Sowas gibt es per se bei uns nicht bzw. entsteht eher natürlich, dass jemand fragt, ob man mal mit draufguckt usw. Aber nicht wirklich als Prozess. Problem ist aber wie gesagt häufig das selbstständige Einarbeiten in andere, neue Sachen, also eher Kundenanforderungen und Schnittstellen anderer Gewerke. Und da gibt es nicht viel, was man an Einarbeit leisten kann. Klar kann ich jemand neben mich setzen, sowas umsetzen und ihn erzählen wie ich da ran gehe. Das hat an der Stelle aber wenig mit unseren System zutun, sondern dem Verständnis von der Anforderung oder externen Schnittstelle. Die Codestellen kann man dann natürlich nicht kennen, die gibt es noch nicht.
  18. Wie gesagt, so schlimm ist es nicht. Mal geht einer, dann sucht man wen Neuen. Wir haben keinen großen Personalmangel. Ist eben nur für beide Seiten ärgerlich, wenn man Monate verschwendet und es nicht klappt. Und unser System, so hässlich es ist, ist immer noch nicht das Hauptproblem beim Einstellen neuer Leute. Wenn wir statt PL/SQL nun Java, C# oder was weiß ich was nutzen würden, dann muss der Mitarbeiter trotzdem in der Lage sein sich in eine Kundenanforderung reinzudenken und die in Code umzusetzen oder eine externe Schnittstelle anzubinden usw. Das ändern Änderungen an unseren System gefühlt gar nix. Frage mich aber auch, wie so ein Refactoring aussehen würde bei sowas. Am Ende hängen eben zig Kunden dran, die kundenspezifische Lösungen haben, die Support brauchen, wo andere Schnittstellen auch an uns dran hängen, die Erweiterungen kriegen usw. Bastelt man denen je ein neues System für Lau und steckt da jeweils ein Jahr aufwärts rein? Oder stellt man den Support und Erweiterungen komplett ein für Altkunden und lässt die je Millionen auf den Tisch legen für ein Retrofit, wenn sie eine kleinere Erweiterung wollen für ihr System, was ansonsten läuft? Wo sie keinen Mehrwert drin sehen, damit man eine schönere Codebase hat? Aber am Ende eh am Thema vorbei, weil das nicht das Problem ist, dass die Bewerber haben. Nicht dass das nicht frustrieren würde.
  19. Leider komplett unmöglich. Mal vom Aufwand, der in mehrere Jahre gehen würde, müssen natürlich auch die ganzen aktiven Kunden noch betreut werden. Nicht dass ich kein Bock hätte auf was anderes als PL/SQL im Core. An den Rändern des Systems gibt es durchaus mal entsprechende Umstellungen, wie die Webentwicklungen, die darauf aufsetzen oder im .NET Bereich. Aber das Hauptsystem wird man schwerlich ersetzen können.
  20. Bin ich voll und ganz bei dir. Das System war soweit ich weiß mal vor 30+ Jahren komplett in C und wurde irgendwann in PL/SQL überführt, wo die ganze Businesslogik liegt. Ebenfalls nicht schön geschrieben und noch sehr nach C-Manier, sprich Fehlercodes als Rückgabe, Flags etc. pp. Ist auch nix, wofür ich PL/SQL als auch nur irgendwo passend sehe, ist aber nun eine Anwendung, die so mit den Jahrzehnten gewachsen ist, die Millionen von Zeilen Code hat und bei zig Kunden in Betrieb ist und aktiv erweitert und supportet wird, also nix, was man mal eben ändern könnte. Geht letztlich um Intralogistik, sprich Lagerverwaltung, Kommissionierlösungen, Materialflussrechner usw. Wobei das in dem Bereich scheinbar gar nicht so selten genutzt wird. Hatten durchaus mit einigen anderen Gewerken zutun, die auch so gut wie alles in der Oracle DB hatten, teilweise noch weitaus absurdere Konstruktionen. Aber wie gesagt, an PL/SQL scheitert es selten, sondern Kundenanforderungen in Code bringen, Schnittstellen von anderen verstehen und vernünftig anbinden usw.
  21. Nun selbstverständlich kann man an allen Ecken was besser machen. Die meisten Bewerber kriegen es aber hin, also wird das nicht unmöglich sein. Hauptproblem sehe ich dann eher die Anforderungen klar zu kommunizieren und die passenden Bewerber raus zu filtern. Und genau wegen diesen Fehler, der logischerweise an uns liegt, stelle ich diese Frage ja. Frischer Neuling ist nun auch hart gesagt, wir reden da schon davon, dass die Leute eine Einarbeitung gekriegt haben, in unseren System an vielen Stellen kleinere Aufgaben hatten. Irgendwann vor Ende der Probezeit muss man jemanden aber auch mal eine größere Aufgabe geben, wenn nicht dann, wann sonst? Und das sind meist schon leichtere Sachen oder Sachen die schon einmal ähnlich existiert haben, wo man Beispiele hat usw. Irgendwann muss der Mitarbeiter eben mit Kundenanforderungen und Schnittstellenbeschreibungen von anderen Gewerken arbeiten. Da geht es eben um die eigene Einarbeitung in Probleme und diese abbilden können. Hast du dafür konkrete Ideen? Die erste größere Aufgabe gibt es bei uns i.d.R. einige Zeit vor Ende der Probezeit, denn dann muss man auch spätestens wissen, ob man mit dem Mitarbeiter was anfangen kann. Unsere Einarbeitung ist sicher nicht perfekt, vor einigen Jahren als ich angefangen habe, gab es überhaupt keine, wir sind also diesbezüglich sicher noch am Anfang. Nix desto trotz kommen 80% hier gut klar, die keine andere Einarbeitung kriegen als die anderen und auch vor den Einarbeitungen haben Leute ins System gefunden. Probleme sind aber wie gesagt aktuell weniger die Einarbeitung in unser System, sondern sich selbst in neue Sachen rein arbeiten können. Sachen die für jeden, der sie auf den Tisch kriegen würde neu sind, wo 90% der Arbeit nix mit unserem System zutun hat, sondern mit den Anforderungen des Kunden oder Schnittstellen eines anderen Gewerks. Gerade was sowas angeht haben wir relativ geringe Anforderungen. Wir haben z.B. auch Quereinsteiger an Bord oder eben Leute wie mich, die nur eine schulische Ausbildung haben und gut die Hälfte ist direkt nach der Ausbildung oder dem Studium hier her. Mal davon ab, dass die exp alleine auch nicht viel gesagt hat in der Vergangenheit. Hatten hier schon promovierte Leute, die seit Jahrzehnten in dem Bereich sind, die keinen Anschluss gefunden haben und Fachfremde Leute, die richtig fix mit der Arbeit warm geworden sind.
  22. Realität ist eben, dass es hier hin und wieder genau am logischen Verständnis mangelt. Sowohl die jeweiligen Probleme in Code zu bringen oder Code von anderen zu verstehen, einen Bug zu finden oder ein Problem auch nur einzugrenzen oder ein Aufgabe anhand einer Doku/API vernünftig umzusetzen. Oder sich an Beispielen orientieren, welche die Leute kriegen. Es gibt ja durchaus genug Arbeitsplätze, wo man quasi nur mit einem sehr starr geführten Framework hier und da ein wenig Code in ein paar Controller Methoden schreibt, ein wenig Ein- und Ausgabe und das wars, auch dafür brauch es Personal, ist aber eben nicht was wir suchen. Das können aber natürlich auch Leute sein, die seit Jahren programmieren und das was sie da gemacht haben wundervoll gemacht haben, was so auch im Arbeitszeugnis steht. Das heißt aber nicht, dass die Person sich z.B. schnell in neue Sachen einarbeiten kann, was bei uns durchaus wichtig ist. Kundenspezifische Projekte, verschiedenste externe Systeme die angebunden werden. Frameworks werden bei uns nur in wenigen Bereichen überhaupt genutzt. Mal ab von .NET in der Dialogentwicklung. Die Technologien sind für viele durchaus mal neu, sprich da machen genaue Abfragen nicht immer Sinn. Wir haben quasi einen Desktop und einen Webbereich und ergänzend dazu kommt eigentlich immer die PL/SQL Entwicklung, wo die Businesslogik abgebildet ist. Das haben viele nicht gemacht ist aber vom Sprachumfang relativ simpel. Daran scheitert es meist auch nicht. Sondern dass die Leute nach der Einarbeitung und eine Zeit lang kleinere Aufgaben und Bugfixes mit ihrer ersten etwas größeren Aufgabe komplett überfordert sind und auch nicht den Anschein machen, dass sie sich jemals in sowas rein arbeiten könnten.
  23. Moin, mich würde mal interessieren was bei euren Jobwechseln so die größten Veränderungen waren. Seid ihr seit jeher in Unternehmen der gleichen Branche? Oder habt ihr da auch größere Sprünge gemacht und auf angeeignetes Branchenwissen für die neue Stelle verzichtet. Ggf. weil euch ein anderer Bereich interessiert hat? Oder weil ihr das einfach für Beiwerk haltet, dass man mit der Einarbeitung eh draufkriegt? Ebenso interessiert mich, in wie weit ihr euren Tech-Stack beim Wechsel geändert habt? Gerade wenn ihr mal was gemacht habt, was nicht gefragt ist und euch eine große Auswahl an Jobs bietet. Immer in der gleichen Sprache geblieben und ggf. nur ein anderes Framework als Fokus? Ein Wechsel in Sprachen mit halbwegs ähnlichen Aufbau ala C# <-> Java. Oder auch mal was komplett unterschiedliches? Quasi von einer stark OOP dominierenden Sprache zu was komplett Prozedurales oder zu was Funktionalen oder eben in die jeweils andere Richtung? Und wie gut war euer Wissen dann in diesen Bereichen? Etwas, dass ihr ggf. mal hier und da im Job zu ein paar Prozent gemacht habt aber mehr machen wolltet? Etwas dass ihr nur ein wenig nebenbei privat gemacht habt? Und wie habt ihr das im Vorstellungsgespräch verkauft? Ggf. auch ein Wechsel der eher weitsichtiger betrachtet wurde und gar finanziell ein Rückschritt war, um in einen Bereich zu wechseln der gefragter ist und mehr Möglichkeiten bietet in Zukunft?
  24. Moin, wollte mal fragen welche Aufgaben ihr bei Einstellungstests so kennengelernt habt, wie das bei euch im Betrieb gehandhabt wird und was ihr persönlich für sinnvoll haltet für den Bereich Softwareentwicklung. Bei uns gab es sowas früher gar nicht, mit der Folge, dass man natürlich auch Leute an Bord holt, die zwar gut reden konnten, wo es da dann aber auch aufgehört hat und man die Zeit von beiden Seiten verschwendet hat. Mittlerweile machen wir da zwar ein wenig was aber ich denke immer noch zu lasch. Eher generische Aufgaben mit ein paar Loops und etwas String- und Array-Manipulation. International und bei großen Konzernen haben sich ja scheinbar so Sachen in der Form von Leetcode Aufgaben etabliert. Häufig irgendwelche Algorithmen mit Graphen, Rekursion usw. Auf der einen Seite denke ich, dass es ein wenig Wahnsinn ist, dass sich Bewerber da auf etwas vorbereiten müssen und in was einarbeiten müssen, dass ggf. kaum Anwendung findet im Job später. Sowas muss man ggf. auch mal machen und verstehen aber 90% der Arbeit ist bei uns eher Branchenabläufe im Code abbilden und da sind selten komplizierte Algorithmen notwendig. Auf der anderen Seite sind das wohl Sachen, die so viel logisches Denken erfordern, dass man dann davon ausgehen kann, dass es bei simpleren Sachen keinerlei Probleme gibt. Realistische Aufgaben sind denke ich schwer, da sie Branchenwissen erfordern. Klar könnte man die irgendwie anonymisieren und auf was anderes ummünzen, wobei das von der Qualität und Sinnhaftigkeit ggf. ähnlich gut ist wie automatisch übersetzte Bedienungsanleitungen von Elektrogeräten oder dem Bewerber ggf. tatsächlich mit etwas Branchenspezifisches konfrontieren und ihn Fragen stellen lassen bzw. die Abläufe erklären. Was haltet ihr da für am sinnvollsten um abzuklopfen, dass der Bewerber genug logisches Verständnis mitbringt und dass es am Ende nicht an das Programmierung scheitert? Was für Aufgaben? Welcher Umfang? Lieber branchenspezifisch oder generisch?
  25. Ganz ehrlich, mich stören, viele, viele Sachen. Aber das sind vor allem Abläufe und technische Sachen. Die Tätigkeit als Softwareentwickler macht mir super Spaß. Dass ich hier eher Generalist bin gefällt mir auch sehr gut. Da kommt keine Langeweile auf. Geht eben von Projektleitung über DBA Tätigkeiten, Webentwicklung, Prozessentwicklung und Anbindungen verschiedenster Fördertechniken und anderen Geräten über die Betreuung und den Support und Störungsanalysen in unserem System, Fremdsystemen, bis hin zum Netzwerk runter. Stören tut mich dann eher, dass man zu wenig Zeit in Weiterentwicklung, Verbesserung von Abläufen und co. steckt. Das ist dann teilweise frustrierend, wenn Sachen die man angehen sollte ewig aufgeschoben werden. Gehalt ist natürlich bei weiten nicht so hoch wie bei einigen hier. Am Ende habe ich aber auch nur eine schulische Ausbildung, keine Betriebliche, nicht studiert etc. Mir hat man damals eher gesagt, dass ich damit nie einen Job finden werde, von daher hätte es sicher auch schlechter kommen können. Mal davon ab, dass es hier auch nicht so teuer ist und ich nicht unbedingt jemand bin der groß Geld raushaut.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...