Whiz-zarD

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.

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

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

Zumal ich auch oft LeetCode in einer produktiven Software nicht sehen möchte, denn bei LeetCode geht es oft darum, den kürzesten Code zu schreiben und nicht leicht verständlich und wartbaren Code. Auch sieht der reelle Alltag eines Entwicklers doch anders aus. Ja, es sind gute Übungen, die man so mal nebenbei machen kann aber ich würde denen jetzt kein so hohen Stellenwert geben. Ich hab auch so ein Kollege, der die tollsten Hacks und Tricks drauf hat und recht exotische Patterns kennt aber was bringt nachher so ein Code, wenn ihn keiner versteht?
Daher bin ich auch der Meinung von @KeeperOfCoffee. Stellt den Bewerbern ein paar Fragen zu den Frameworks, die sie in ihrem CV angegeben haben.

Und das bekommt man mit einem Einstellungstest wie gelöst?
Vielleicht solltet ihr euch Fragen, ob ihr evtl. nicht am "Not invented here"-Syndrom leidet. Wenn ihr schon sagt, dass bei euch kaum Frameworks zum Einsatz kommen, klingt es schon sehr danach, als hättet ihr euch eine eigene Welt aufgebaut, anstatt auf gängige Standards zu setzen. Bei PL/SQL schlackern mir dann echt die Ohren. Ich hab auch viel mit PL/SQL zu tun und ich fluche über die Sprache wie ein Rohrspatz, weil die Sprache so inkonsequent ist. Dass dann bei größeren Aufgaben, Überforderungen auftreten, ist dann auch normal.

Und das bekommt man mit einem Einstellungstest wie gelöst?
Vielleicht solltet ihr euch Fragen, ob ihr evtl. nicht am "Not invented here"-Syndrom leidet. Wenn ihr schon sagt, dass bei euch kaum Frameworks zum Einsatz kommen, klingt es schon sehr danach, als hättet ihr euch eine eigene Welt aufgebaut, anstatt auf gängige Standards zu setzen. Bei PL/SQL schlackern mir dann echt die Ohren. Ich hab auch viel mit PL/SQL zu tun und ich fluche über die Sprache wie ein Rohrspatz, weil die Sprache so inkonsequent ist. Dass dann bei größeren Aufgaben, Überforderungen auftreten, ist dann auch normal.

Zumal ich auch oft LeetCode in einer produktiven Software nicht sehen möchte, denn bei LeetCode geht es oft darum, den kürzesten Code zu schreiben und nicht leicht verständlich und wartbaren Code. Auch sieht der reelle Alltag eines Entwicklers doch anders aus. Ja, es sind gute Übungen, die man so mal nebenbei machen kann aber ich würde denen jetzt kein so hohen Stellenwert geben. Ich hab auch so ein Kollege, der die tollsten Hacks und Tricks drauf hat und recht exotische Patterns kennt aber was bringt nachher so ein Code, wenn ihn keiner versteht?
Daher bin ich auch der Meinung von @KeeperOfCoffee. Stellt den Bewerbern ein paar Fragen zu den Frameworks, die sie in ihrem CV angegeben haben.

Zumal ich auch oft LeetCode in einer produktiven Software nicht sehen möchte, denn bei LeetCode geht es oft darum, den kürzesten Code zu schreiben und nicht leicht verständlich und wartbaren Code. Auch sieht der reelle Alltag eines Entwicklers doch anders aus. Ja, es sind gute Übungen, die man so mal nebenbei machen kann aber ich würde denen jetzt kein so hohen Stellenwert geben. Ich hab auch so ein Kollege, der die tollsten Hacks und Tricks drauf hat und recht exotische Patterns kennt aber was bringt nachher so ein Code, wenn ihn keiner versteht?
Daher bin ich auch der Meinung von @KeeperOfCoffee. Stellt den Bewerbern ein paar Fragen zu den Frameworks, die sie in ihrem CV angegeben haben.

Zumal ich auch oft LeetCode in einer produktiven Software nicht sehen möchte, denn bei LeetCode geht es oft darum, den kürzesten Code zu schreiben und nicht leicht verständlich und wartbaren Code. Auch sieht der reelle Alltag eines Entwicklers doch anders aus. Ja, es sind gute Übungen, die man so mal nebenbei machen kann aber ich würde denen jetzt kein so hohen Stellenwert geben. Ich hab auch so ein Kollege, der die tollsten Hacks und Tricks drauf hat und recht exotische Patterns kennt aber was bringt nachher so ein Code, wenn ihn keiner versteht?
Daher bin ich auch der Meinung von @KeeperOfCoffee. Stellt den Bewerbern ein paar Fragen zu den Frameworks, die sie in ihrem CV angegeben haben.

Ich finde es etwas ... seltsam logisches Verständnis abzufragen. Wenn jemand mehrere Jahre Entwicklung macht, sollte man von logischem Verständnis ausgehen...anonsten hat man den Job nicht lange. Es macht in DE weniger Sinn LeetCode abzufragen, da die meisten Bewerber hier diese Katas nicht lernen bzw. üben. Das wäre für den dt. Markt unüblich. Viele Unternehmen finden zu wenig Leute bzw. haben zu großen Bedarf, als dass sie 80% der Leute aussortieren weil diese nicht auf LeetCode Aufgaben vorbereitet sind.
Es ergibt mehr Sinn auf die eigesetzten Technologien einzugehen. Wenn in den CV steht, dass man an einem Projekt mit Framework XY gearbeitet hat, dann sollte man eine typische Frage stellen, die jemand beantworten kann, wenn Erfahrung mit XY da ist. Man sollte so überprüfen, ob man im CV dick aufgetragen hat, oder ob es den Tatsachen entspricht. Wenn drin steht, dass man mit Azure gearbeitet hat, dann sollte man nicht an üblichen Fragen zu Azure scheitern usw. Es geht dabei weniger um logisches Denken, als um fachliche Kompetenz mit Technologie X. Hierbei muss man nicht die Doku 1:1 widergeben, sondern durch freies Sprechen Wissen verständlich vermitteln können.
Es können auch Fragen drankommen wie z.B. welche Vorteile hat Design Pattern X gegenüber Design Pattern Y wenn Technologie Z im Projekttyp A eingesetzt wird. Das betrifft nur begrenzt logisches Denken... man muss wissen was Technologie Z ist, was die Design Patterns grob machen...und dann entweder Wissen oder durch Logik herausfinden, welches Pattern vermutlich für Aufgabe A besser geeignet ist. Kann auch eine Fangfrage sein, weil Y üblicherweise bei A eingesetzt wird...mit Ausnahmen etc.
Kurz: Man spricht Fragen an, die sich auf die Projekte aus der Vergangenheit beziehen...und die jeder Entwickler, der an solchen Projekten gearbeitet hat, normalerweise beantworten kann.
Dies sollte nicht per schriftlichen Test geprüft werden, sondern einfach in einem netten Gespräch zwischen Bewerber und einem Vorgesetzten für das entsprechende Team (bzw. kann man langjährige Entwickler hinzuziehen).
Edit: Ausnahmen hier sind evtl. Embedded Programming, Kryptographie etc. ... dass sind aber Spezailfälle
 

Ich vermute, dass nur sehr wenige Firmen sowas haben. Wir kalkulieren auch minimum 6 Monate ein, bis ein neuer Mitarbeiter produktiv ist. Mache dir da mal keinen Stress.

Ich rate Anfängern immer erst dazu, die grafische Oberfläche wegzulassen, da es hier sehr komplex werden kann und in den letzen zehn Jahren ist es gefühlt nicht einfacher geworden, bei all den ganzen Techniken und Frameworks, die entstanden sind. Anfängerfreundlich ist da kaum etwas, auch wenn es immer so getan wird.
Auch wenn es nicht so fancy und hip aussieht, rate ich Anfängern immer erstmal zu Konsolenausgaben. Da kann man sich auf das wesentliche konzentrieren. Also auf die Programmlogik selbst und muss sich nicht damit rumquälen, z.B. herauszufinden, wie man HTML-Elemente nun mittig positioniert.
Viel wichtiger finde ich, dass man erstmal die Konzepte der gewählten Programmiersprache versteht, das Datenmodell gut designt und Prinzipien, wie z.B. EVA, DRY, KISS oder SOLID versteht.
Wenn die Programmlogik gut ausgearbeitet ist, kann man im Idealfall immer noch eine grafische Oberfläche dafür basteln, ohne die Logik anpassen zu müssen. Also schnapp dir eine Sprache deiner Wahl und versuche damit die Programmlogik umzusetzen.

Ich frage mich, was soll eigentich Programmieren in der Berufsschule bringen?
Ein FISI wird es mehr mit Skripten zutun haben. Also Bash bzw. Powershell und ähnliches. Powershell ist zwar objektorientiert aber lernt man Powershell wirklich, wenn man Java lernt? Auch brauchen FISI kein allzu tiefes Verständnis über die internen Abläufe einer Programmiersprache. 
Ein FIAE lernt programmieren im Betrieb. In der Berufsschule brauch er also keinen Grundlagenkurs über Objektorientierung. Zumal die Schulen eh nicht die Grundlagen lehren, sondern hauptsächlich nur sowas, wie: "Wir basteln uns in Java nun ein Button und mittels Mausklick soll der Button 2 + 2 rechnen". Auch werden keine Algorithmen und Datenstrukturen in Schulen durchgenommen. Also sowas wie:  "Wie funktioniert ein Array? Eine Liste? Ein binärer Suchbaum? etc." Ich denke, für die meisten ist gar nicht klar, dass weder Polymorphie noch Vererbung das Hauptargument für Objektorientierung ist, sondern die Umkehr der Abhängigkeit. Die Objektorientierung hat lediglich Polymorphie und Vererbung vereinfacht. Wird aber schon lange, mit einigen Kniffen, z.B. in C praktiziert.
So, wie es jetzt läuft, ist es für beide Parteien nur Zeitverschwendung.
Das höre ich immer wieder aber die Meinung teile ich nicht. Die Syntax wirkt für mich sehr inkonsequent. Es gibt auch keine Datenkapselung. Es gibt nur: "Hey, benutz doch bitte nicht die Variablen, die mit einem Unterstrich anfangen.". Auch die Type Hints sind nur ein Nice-To-Have und werden nicht mal überprüft. Im Zweifel sind sie sogar falsch. Man ist also auf Gedeih und Verderb auf die Dokumentation angewiesen, um herauszufinden, welche Parameter eine Methode/Funktion verlangt und was man bekommt. Das Prinzip der Multiparadigmen macht die Sache dann auch nicht einfacher. Mal sind es Funktionen, mal sind es Methoden an Klassen.

Nein, UML wird nicht dazu genutzt, wozu es gedacht war. UML wird, wenn überhaupt, als nachträgliche Dokumentation genutzt, weil es einfach zu schwerfällig und unflexibel ist, um damit wirklich eine Software zu modellieren.
Ich persönlich kenne auch keine einzige Firma, die wirklich mit UML Software modelliert. Dazu auch? Inzwischen beherrscht jede IDE automatische Codevervollständigung, sodass das Schreiben von Code schneller von statten geht, als die Modellierung mittels UML.
Eine Software liegt unter ständigen Wandel. Kramst du dann ständig die Diagramme aus, um erstmal dort Anpassungen am Modell zu machen, bevor du dann den Code anpasst?
Man sollte sich nicht zu sehr auf UML versteifen. Ja, beim Brainstorming können Diagramme und andere Grafiken helfen aber macht es so leichtgewichtig, wie es geht und fangt nicht an zu diskutieren welche Pfeilart beim Klassendiagramm nun die richtige sei. Diskutiert über das fachliche und haltet euch nicht mit UML-Firlefanz auf.
Man sollte aber überholte Dinge gerne mal hinterfragen.
Genauso, wie ich jedes Mal das ER-Modell hinterfrage. Wieso fängt jeder mit einem ER-Modell an? Damit stellt man die Persistenz in den Vordergrund, obwohl die Geschäftslogik im Vordergrund stehen sollte. Also das, womit man sein Geld verdient. Die Persistenz ist nur ein Detail und ob ich da jetzt eine relationale Datenbank oder was völlig anderes nehme sollte egal sein. Zumal relationale Datenbanken und Objektorientierung auch nicht mal wirklich zusammenpassen. Dafür braucht man wieder einen umständlichen O/R-Mapper, den man z.B. bei dokumentenbasierten Datenbanken gar nicht braucht und somit auch das ER-Modell überflüssig macht.

MVPs sind aber eher die, die viel für die Community machen. Also die, die Vorträge halten, Fachartikel schreiben, etc. Ein Freelancer, der "nur" ein "Experte" (Experte in was?) ist, wird kein MVP.
Die Welt der Softwareentwicklung hat sich seit den 90ern stark geändert und ist wesentlich komplexer geworden. Einfach ein Java-Buch zu lesen wird nichts bringen, um eine qualitativ gute Software zu entwickeln. Da braucht man schon mehr, als nur Java-Kenntnisse. Das fängt schon damit an, dass viele heutzutage eine Web-Applikation haben möchten. Da kommst du mit Java alleine nicht mehr so weit. Schon gar nicht nebenbei als kleines Projekt.

Wenn ich diesen Quatsch lese, muss ich an Postal denken.
 

Und das sind Aufgaben für eine Einstellung?🤨 Kein Wunder, dass alle über den Fachkräftmangel jammern...

Nein, UML wird nicht dazu genutzt, wozu es gedacht war. UML wird, wenn überhaupt, als nachträgliche Dokumentation genutzt, weil es einfach zu schwerfällig und unflexibel ist, um damit wirklich eine Software zu modellieren.
Ich persönlich kenne auch keine einzige Firma, die wirklich mit UML Software modelliert. Dazu auch? Inzwischen beherrscht jede IDE automatische Codevervollständigung, sodass das Schreiben von Code schneller von statten geht, als die Modellierung mittels UML.
Eine Software liegt unter ständigen Wandel. Kramst du dann ständig die Diagramme aus, um erstmal dort Anpassungen am Modell zu machen, bevor du dann den Code anpasst?
Man sollte sich nicht zu sehr auf UML versteifen. Ja, beim Brainstorming können Diagramme und andere Grafiken helfen aber macht es so leichtgewichtig, wie es geht und fangt nicht an zu diskutieren welche Pfeilart beim Klassendiagramm nun die richtige sei. Diskutiert über das fachliche und haltet euch nicht mit UML-Firlefanz auf.
Man sollte aber überholte Dinge gerne mal hinterfragen.
Genauso, wie ich jedes Mal das ER-Modell hinterfrage. Wieso fängt jeder mit einem ER-Modell an? Damit stellt man die Persistenz in den Vordergrund, obwohl die Geschäftslogik im Vordergrund stehen sollte. Also das, womit man sein Geld verdient. Die Persistenz ist nur ein Detail und ob ich da jetzt eine relationale Datenbank oder was völlig anderes nehme sollte egal sein. Zumal relationale Datenbanken und Objektorientierung auch nicht mal wirklich zusammenpassen. Dafür braucht man wieder einen umständlichen O/R-Mapper, den man z.B. bei dokumentenbasierten Datenbanken gar nicht braucht und somit auch das ER-Modell überflüssig macht.

Wenn ich diesen Quatsch lese, muss ich an Postal denken.
 

Und das sind Aufgaben für eine Einstellung?🤨 Kein Wunder, dass alle über den Fachkräftmangel jammern...

Es gibt keine spezielle Zwischenprüfung für "Verkürzer".
Jedes halbe Jahr gibt es eine Zwischen- und eine Abschlussprüfung statt, da es auch Azubis gibt, die im Februar anfangen und nicht im August. Außerdem gibt es noch diejenigen, die bei der Abschlussprüfung durchgefallen sind, die nach 6 Monaten die Prüfung wiederholen können.

Und das sind Aufgaben für eine Einstellung?🤨 Kein Wunder, dass alle über den Fachkräftmangel jammern...

Und das sind Aufgaben für eine Einstellung?🤨 Kein Wunder, dass alle über den Fachkräftmangel jammern...

Wenn ich diesen Quatsch lese, muss ich an Postal denken.
 

"Ich denke, dass ich jetzt gehe"