Sinnvolle Aufgaben für Einstellungstests (Softwareentwicklung)

[Brapchu]

vor 27 Minuten schrieb Velicity:

Dafür muss der Entwickler trotzdem die Sprache des Kunden sprechen können.

Im Idealfall hat der Entwickler überhaupt nicht mit dem Kunden gesprochen sondern der Vertrieb/ Support oder das PM und das dann die Kundenwünsche für den Entwickler "Übersetzt".

[Velicity]

vor 8 Minuten schrieb treffnix:

Aber ihr habt doch, ähnlich wie wir hier auch, einen großen Monolithen, der bei zig Kunden im Einsatz ist?

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.

[Velicity]

vor 33 Minuten schrieb Brapchu:

Im Idealfall hat der Entwickler überhaupt nicht mit dem Kunden gesprochen sondern der Vertrieb/ Support oder das PM und das dann die Kundenwünsche für den Entwickler "Übersetzt".

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.

Bearbeitet 12. April 2022 von Velicity

[allesweg]

Keiner hat die Verantwortung für das Gesamtprodukt und jeder macht irgendwie alles unkoordiniert. Kann man so machen.

[Kwaiken]

vor 37 Minuten schrieb allesweg:

Keiner hat die Verantwortung für das Gesamtprodukt und jeder macht irgendwie alles unkoordiniert. Kann man so machen.

Glaube, dass das alles nicht state of the art ist weiß @Velicity ebenso gut wie wir wissen, dass wir für seine Firma nur arbeiten würden wenn wir sonst am Hungertuch nagen müssten und in Nordkorea keine Arbeitsstelle mehr frei ist.

Hilft ihm aber nicht und das weiß er wahrscheinlich auch. Ob er bei derzeitigen Arbeitnehmer-Markt fähige und willige Arbeitnehmer findet, die nicht nach kürzester Zeit das Weite suchen und wo anders hingehen, wage ich zwar ebenfalls zu bezweifeln, aber vielleicht kann ich aus dem Nähkästchen plaudern, was bei uns sehr gut für Engineering/Support/etc. funktioniert.

1. Ehrlichkeit (!) ist das A und O. Der Bewerber muss wissen was auf ihn zukommen. Ross und Reiter im VG klipp und klar benennen: was erwartet ihn, wie läuft die Einarbeitung, wie sieht die Arbeitsumgebung aus, was erwartet Ihr von ihm zu welchem Zeitpunkt.
2.  Gebt ihm eine zu der Stelle passende Aufgabe zum offline lösen ohne fixe Zeitbegrenzung. Zu erstellen sind: PAP, Pflichtenheft, oder was auch immer Ihr an Papierkram in Verwendung habt, dokumentierter Code, den man jemandem zur Wartung geben könnte und eine kleine Präsentation des Lösungsansatzes und eine kurze Codebesprechung.

Wir suchen hierbei nicht nach der Lösung des Problems. Sondern zunächst ob der Bewerber eine Aufgabenstellung analytisch durchdringen, planen und systematisch umsetzen kann. Bei der Präsentation sehen wir dann meist, ob es sein Code ist oder er ihn von Stackoverflow zusammengeklaut hat.

Aber die für uns wichtigste Charaktereigenschaft wird jedoch erst zu Tage gefördert, wenn der Bewerber über seinen Code/seine Lösung spricht. Wir suchen Menschen, die sich begeistern lassen und Spaß am lösen von "IT Puzzles" haben. Der Typ Mensch, der beim Abendessen aufschreckt weil er plötzlich eine Lösung für ein Problem gefunden hat. Und das merkst Du meist, wenn die Leute über ihren Code/Lösungsansatz sprechen und ihn anderen erklären sollen. 

Ich habe schon die introvertierteste Gurke im VG bei der Codebesprechung verbal förmlich explodieren sehen. Im VG hat er kaum ein Wort gesagt, bei der Codebesprechung ließ er sich dann nicht mehr bremsen ("We've seen enough, thank you! Fantastic work! Stop! Stop!"). 

[Rabber]

vor 7 Stunden schrieb allesweg:

10-15 Entwickler sind zu wenig für EINEN lumpigen Anforderungsmanager? Janee, isklar.

Ich habe auch mal für einen Mini-Betrieb gearbeitet. In der Summe <10 Leute. Die Besetzung sah wie folgt aus:

1x Chef, 1x Sekretärin, 2x Vertrieb (darunter Junior-Chef), 2x Senior Entwickler (darunter ich), 1x HiWi-Entwickler… uuunnddd… jetzt kommt’s…. 1x Product owner. Letzt genannter nur für uns 2,25 Entwickler. Lief wunderbar.

ach ja, der Laden hatte auch nur ein Produkt und übrigens ziemlich gut bezahlt.

erstaunlich, was nicht alles geht, wenn man möchte.

und erstaunlich, was alles nicht geht, wenn man nicht will.

[allesweg]

Was ist das Ziel? Symptomreduktion oder Ursachenbehebung?

[Velicity]

vor 2 Stunden schrieb allesweg:

Was ist das Ziel? Symptomreduktion oder Ursachenbehebung?

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.

Bearbeitet 13. April 2022 von Velicity

[allesweg]

Wie viele Kurzzeit-Entwickler hattet ihr in den letzten 3 bis maximal 5 Jahren?

Wie viele Entwickler sind in diesem Zeitraum eingestellt worden, die immer noch da sind?

Haben diese Kurzzeit-Mitarbeiter euch einen Grund genannt, warum sie gekündigt haben?

 

Nein, es braucht nicht zig neue Rollen. Üblicherweise reicht genau ein Verantwortlicher mit den Aufgaben Dolmetscher "fachliche Kundenwünsche - IT", Konsolidierung und Koordination.

[Velicity]

vor 29 Minuten schrieb allesweg:

Wie viele Kurzzeit-Entwickler hattet ihr in den letzten 3 bis maximal 5 Jahren?

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.

vor 36 Minuten schrieb allesweg:

Nein, es braucht nicht zig neue Rollen. Üblicherweise reicht genau ein Verantwortlicher mit den Aufgaben Dolmetscher "fachliche Kundenwünsche - IT", Konsolidierung und Koordination.

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.

[Brapchu]

vor 25 Minuten schrieb Velicity:

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.

Okay.. und sowas fällt erst am Ende der Probezeit auf?

Und vorher wurden wundersamerweise alle eure "kleinen" Probleme zufriedenstellend erledigt?

Das ergibt irgendwie keinen Sinn.

[Whiz-zarD]

vor 1 Stunde schrieb Velicity:

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.

Ich sehe da schon ein großes Problem. Das sind alles Leute, die die Software historisch hysterisch gewachsen gesehen haben und auch dafür verantwortlich waren. Die fühlen sich da pudelwohl, denn das ist deren Baby. Wenn ihr da aber mit PL/SQL rumhühnert, gehe ich stark davon aus, dass sie sich in den 30 Jahren nicht weitergebildet haben. Die Softwareentwicklung sah vor 30 Jahren anders aus, als heute. Ich hab auch mit solchen Leuten zu tun und ich schlage oft meine Hände über den Kopf, wenn ich deren Code sehe. Es hapert schon oft an den Grundlagen und wenn ich da so mit einigen Beratern über Senior Entwickler spreche, sind sie auch oft mit solchen Menschen konfrontiert, die ihre Werkzeuge überhaupt nicht kennen und noch beratungsresistent sind. Das muss nicht alle Senior Entwickler betreffen aber heutige Entwickler haben oft ganz andere Vorstellungen über die Entwicklung selbst.

vor 8 Minuten schrieb Brapchu:

Okay.. und sowas fällt erst am Ende der Probezeit auf?

Und vorher wurden wundersamerweise alle eure "kleinen" Probleme zufriedenstellend erledigt?

Das ergibt irgendwie keinen Sinn.

Genau das habe ich mich auch gefragt. Es klingt so, als sei man der Meinung, dass man nach 6 Monaten alleine vorankommen muss und jegliche Hilfe untersagt. Bei einer hysterisch gewachsenen Software ist das aber oft schwer. Einige kommen damit besser klar, andere wieder nicht. Man darf eines nicht vergessen: Es sind auch nur Menschen. Die Frage sollte also nicht "Was sind sinnvolle Aufgaben für Einstellungstests?" lauten, sondern "Wie können wir neu Eingestellte besser unterstützen?", denn offenbar halten sie es bei euch nicht lange aus. Ihr solltet also nicht nur die Fehler bei den Bewerbern suchen, sondern auch die Fehler bei euch und da wäre Pair Programming schon mal ein Anfang, um sie zu begleiten. Evtl. sogar noch ein paar interne, fachbezogene Schulungsangebote machen. Offenbar haben sie ja Probleme, den Ablauf der Software zu verstehen. Und ja, neue Mitarbeiter ist ein Invest, der nicht nach exakt 6 Monaten vorbei ist. Wir planen minimum 6 Monate ein, bis ein neuer Entwickler einigermaßen mit unserem Code zurecht kommt.

Bearbeitet 13. April 2022 von Whiz-zarD

[Velicity]

vor 34 Minuten schrieb Brapchu:

Okay.. und sowas fällt erst am Ende der Probezeit auf?

Und vorher wurden wundersamerweise alle eure "kleinen" Probleme zufriedenstellend erledigt?

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.

vor 16 Minuten schrieb Whiz-zarD:

Ich sehe da schon ein großes Problem. Das sind alles Leute, die die Software historisch hysterisch gewachsen gesehen haben und auch dafür verantwortlich waren. Die fühlen sich da pudelwohl, denn das ist deren Baby. Wenn ihr da aber mit PL/SQL rumhühnert, gehe ich stark davon aus, dass sie sich in den 30 Jahren nicht weitergebildet haben.

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.

vor 45 Minuten schrieb Whiz-zarD:

sondern "Wie können wir neu Eingestellte besser unterstützen?", denn offenbar halten sie es bei euch nicht lange aus.

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.

[allesweg]

Dann nochmals mit konkreten Zahlen:

Wie viele der in den letzten 5 Jahren eingestellten Entwickler sind über 12 Monate geblieben?

Wie viele der in den letzten 5 Jahren eingestellten Entwickler haben von sich aus innerhalb der ersten 12 Monate das Unternehmen wieder verlassen?

Haben die Entwickler, welche gekündigt haben, euch einen Grund genannt, warum sie gekündigt haben?

Wie hat sich in den letzten 5 Jahren die Anzahl der Entwickler verändert?

[Velicity]

Steht letztlich in den Text oben aber wenn es dir zu lang ist:

vor 5 Minuten schrieb allesweg:

Wie viele der in den letzten 5 Jahren eingestellten Entwickler sind über 12 Monate geblieben?

Zwei.

vor 5 Minuten schrieb allesweg:

Wie viele der in den letzten 5 Jahren eingestellten Entwickler haben von sich aus innerhalb der ersten 12 Monate das Unternehmen wieder verlassen?

Keiner.

vor 7 Minuten schrieb allesweg:

Haben die Entwickler, welche gekündigt haben, euch einen Grund genannt, warum sie gekündigt haben?

Waren nur welche, die länger dabei waren. Rente und keine Lust mehr auf Reisetätigkeit, weil Nachwuchs bekommen.

vor 8 Minuten schrieb allesweg:

Wie hat sich in den letzten 5 Jahren die Anzahl der Entwickler verändert?

Aktuell einer weniger.

[Rabber]

Wenn ich Deine Anforderungen so lese, muss ich immer an einen ehemaligen Kollegen denken: heute 50+, bald 20 Jahre im selben Unternehmen und dort bestens vernetzt. Ganze Teilbereiche gehen auf sein Konto. Heute noch fast identisch entwickelt wie 2000 und 2010. technisch war der wirklich mal fit. Ist leider nur stehen geblieben, was die Technik betrifft. nun ja, ich schweife ab.

diesem Kollegen hat man über die Jahre viele junge Kollegen zur Seite gestellt, um ihm zu helfen, Ihn vertreten zu können usw. Alle sind daran gescheitert. Der Großteil davon hat mittlerweile wieder gekündigt.

Natürlich waren alle potentiellen Kollegen für ihn zu blöd, konnten ihr Handwerk nicht, haben sogar einfachste Aufgaben und Zusammenhänge nicht verstanden etc. Deine Kritik könnte 1:1 von ihm kommen.

komisch war nur, dass ich und andere Mitarbeiter/Teamleiter durchweg gute Erfahrungen mit denselben Personen gemacht haben. Die waren clever, engagiert und haben in adäquater Zeit solide Ergebnisse erzielt. Nur in Horsts Power-System (Namen geändert), da wurden sie alle zu idioten. Komisch, komisch, komisch.

übrigens: ich und ein anderer Senior Entwickler haben auch einmal die Ehre gehabt in Horsts power System hantieren zu dürfen. … muss man schön mögen, seine Art zu entwickeln. Zig tausend Zeilen umfassende PL/SQL-Funktionen waren da übrigens auch der heisse scheiss, um das Bild abzurunden. 😂

Wie gesagt: komisch, komisch, komisch.

Bearbeitet 13. April 2022 von Rabber

[allesweg]

Wenn die beiden >12-Monate-Entwickler immer noch da sind und bei der um 1 gesunkenen Gesamtmannschaftsstärke die beiden Probezeitler noch nicht berücksichtigt sind, sehe ich da kein Problem.

Kein MA ist im ersten Jahr geflüchtet, die Personalstärke ist nahezu konstant und Weggänge nur aus persönlichen Gründen.

 

Oder sind die MA doch mittlerweile geflüchtet und von den Probezeitlern bleibt nur einer und es sind somit -2 MA, was bei den 10-15 MA am Standort (oder doch nur ein bald-Rentner, zwei Langjährige und zwei neuere macht 5 Entwickler) doch relativ viele sind?

 

Bonusfrage: wie vielen Entwicklern wurde in den letzten 5 Jahren gekündigt und wie viele Wochen/Monate waren diese jeweils dabei?

[Velicity]

vor 13 Stunden schrieb Rabber:

Wenn ich Deine Anforderungen so lese, muss ich immer an einen ehemaligen Kollegen denken [..] ich und ein anderer Senior Entwickler haben auch einmal die Ehre gehabt in Horsts power System hantieren zu dürfen. … muss man schön mögen, seine Art zu entwickeln. Zig tausend Zeilen umfassende PL/SQL-Funktionen waren da übrigens auch der heisse scheiss, um das Bild abzurunden.

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.

vor 13 Stunden schrieb allesweg:

Wenn die beiden >12-Monate-Entwickler immer noch da sind

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).

vor 13 Stunden schrieb allesweg:

und bei der um 1 gesunkenen Gesamtmannschaftsstärke die beiden Probezeitler noch nicht berücksichtigt sind

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.

vor 13 Stunden schrieb allesweg:

Bonusfrage: wie vielen Entwicklern wurde in den letzten 5 Jahren gekündigt und wie viele Wochen/Monate waren diese jeweils dabei?

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.

[Brapchu]

vor 36 Minuten schrieb Velicity:

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.

Okay jetzt mal ganz ehrlich: Wenn nach eurer Probezeit 3/4 Entwickler als "nicht Ausreichend" angesehen werden dann könnte das Problem eventuell tatsächlich bei eurer Einarbeitung oder euren Ansprüchen liegen.. oder nicht?

[allesweg]

vor 27 Minuten schrieb Velicity:

Die sind eben nur nach deinen 12 Monaten gegangen (worden).

ihr braucht also teilweise >12 Monate, um festzustellen, dass jemand nix taugt?

vor 27 Minuten schrieb Velicity:

einem nach mehreren Jahren

Ja wie? Doch nur einer? Oder musstet ihr mehreren kündigen?

Nein, Renteneintritt ist keine Kündigung!

Ja, der eine hat innerlich selbst gekündigt und hat seine Kündigung provoziert. Wenn ihr ordentlich gekündigt habt, hatte er so sogar noch Anspruch auf ALG und erhielt keine Sperre wie bei einer verhaltensbedingten fristlosen Kündigung üblich.

 

 

Du schreibst viel, sagst aber viel Irrelevantes dabei.

[Velicity]

vor 48 Minuten schrieb allesweg:

ihr braucht also teilweise >12 Monate, um festzustellen, dass jemand nix taugt?

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.

vor 48 Minuten schrieb allesweg:

Ja wie? Doch nur einer? Oder musstet ihr mehreren kündigen?

Drei, wie gesagt. Den Kollegen der immer fehlte und den Leuten am Ende der Probezeit, wie auch oben unter deiner Bonus-Frage angeführt.

vor 52 Minuten schrieb Brapchu:

Okay jetzt mal ganz ehrlich: Wenn nach eurer Probezeit 3/4 Entwickler als "nicht Ausreichend" angesehen werden dann könnte das Problem eventuell tatsächlich bei eurer Einarbeitung oder euren Ansprüchen liegen.. oder nicht?

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.

vor 48 Minuten schrieb allesweg:

Du schreibst viel, sagst aber viel Irrelevantes dabei.

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ß.

Bearbeitet 14. April 2022 von Velicity

[Bitschnipser]

vor 58 Minuten schrieb Velicity:

dass man den Mitarbeitern beim Bewerbungsgespräch so gut wie gar nicht auf den Zahl fühlt

Tut man ja anscheinend in den 6 Monaten Probezeit auch nicht.

 

vor 58 Minuten schrieb Velicity:

Er soll ein paar verdammte Loops schreiben und Daten von ein paar Feldern in ein paar andere packen.

Die Programmlogik mag für dich einfach sein, weil du dir das seit Jahren antust damit seit Jahren arbeitest. Jemand der nicht aus der Logistik kommt scheint sich damit sichtlich schwer zu tun. Und dann noch Programmierlogik in der Logistik, die noch ein paar Ebenen Abstraktion hinzufügt. Mir hats schon gegraust als du was geschrieben hast von Feld A empfängt und B sendet und muss umgekehrt befüttert werden und was weiß ich noch alles.

Bearbeitet 14. April 2022 von Bitschnipser

[kylt]

Am 14.4.2022 um 11:55 schrieb Velicity:

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.

- Ihr schickt, ernsthaft Leute alleine zu Kunden, die

* kein Wissen von proprietären, neuen System / Schnittstellen haben ( also dafür dezentrale Einarbeitungszeit aufbringen müssen)

* selbstständig jede Schnittstelle / API nach eigenem Gusto neu Entwickeln dürfen (und jeder potentiell das Rad neu erfindet)

* vermutlich auch keine Verpflichtung zur Dokumentation haben ( und damit eine Wartung, wie du selbst sag, unmöglich wird)

"[...] und nicht mehr Betreuung kostet, als er Arbeit fertigbringt. [...]"

Es wirkt schon ein bisschen so, dass was du vermutlich als "effektive Zeit beim Kunden programmieren" definierst, genau anders herum von außen wahrgenommen wird. 🙈

=====================================

BTT: 

Aus der Erfahrung im Consulting kann ich dir sagen, dass jede Maßnahme, den perfekten Bewerber vorzuselektieren dir keine Verbesserung garantiert. Wenn Ihr tatsächlich faire Aufgaben gibt und offen auf die Bewerber zugeht, gibt es immer jene, die es trotzdem durchs Prüfungsraster schaffen.

Spätestens beim nächsten Bewerber, der Durchfällt, obwohl du aktiv "viel Zeit" in das Bewerbungsverfahren gesteckt hast, wird Ernüchterung bringen. - Dafür ist die Probezeit ja auch da. 

Wenn du schon etwas an Bewerbungsphasen und Positionen drehen kannst, dann würde ich vielleicht über eine neue Position nachdenken. Das etablierte Stammpersonal nur noch an neuen Dingen schrauben zu lassen und für die Kleinigkeiten einen "Support-Dude" zu suchen. Dann hat derjenige nicht so spannende, neue Aufgaben - muss aber z.B. evtl. nicht Reisen? - Dann würde Anspruch und Bewerbungsverfahren ja schon gut zusammen passen, richtig? 

[allesweg]

@kylt neeneeneee. Er kann doch nix am Verfahren drehen sondern nur den Einzelpunkt "Einstellungstest für Entwickler-Kandidaten" schärfen. Sowas Weitreichendes wie neue Rollen ist undenkbar.

[skylake]

Ich sehe - wie die anderen - die Probleme wesentlich tiefliegender als vom TE beschrieben. Die Einstellungsaufgaben sind da weniger das Problem.

Wenn du unbedingt Knobelaufgaben für den Test haben möchtest, dann kauf dir den Klassiker "Cracking the Coding Interview", nehm zufallsbasiert ein paar härtere davon raus und werf diese dem Kandidaten vor die Füße.
Hier der Link: https://www.thalia.de/shop/home/artikeldetails/A1037393743 (p.s: ob das so sinnvoll ist, sei mal dahingestellt)

Das wird allerdings nicht euer grundlegendes Problem beheben. Vllt. sollte das Unternehmen darüber nachdenken:
1. Neue Mitarbeiter umfänglich, systematisch an das System heranzuführen. Hierfür kann man sich zur Not auch externer Hilfe bedienen, wenn die eigene Expertise in dem Feld nicht vorhanden ist.
2. Das was @allesweg sagt umsetzen (Rollen).
3. Vllt. überdenken, ob ein neuer Mitarbeiter ab 6 Monaten mehr Umsatz reinholen muss als er kostet, bei einer Codebasis, wie von dir beschrieben.