Saheeda

vor 2 Stunden schrieb Maniska:

Ansonsten weniger Mimimi im Anschreiben, ein bisschen mehr Selbstbewusstsein ausstrahlen. Der Bürokaufmann war keine falsche Entscheidung die du nur aus Pflichtbewusstsein durchgezogen hast.

Inhaltlich finde ich den Punkt gar nicht so schlecht, nur an der Formulierung müsste man arbeiten.

Was ich daraus lese: Der TO hat gemerkt, dass die Ausbildung die falsche Entscheidung war. Statt jetzt aber mittendrin abzubrechen hat er (oder sie) sich gesagt "Arschbacken zusammenkneifen und durch". Genau das ist doch die Skepsis bei krummen Lebensläufen: "Wird derjenige  es diesmal durchziehen?", "Wird sich die Investition in die Ausbildung rentieren?".

Ich stimme Maniska aber insofern zu: Weniger Mimimi. Erzähl, was du gemacht hast, womit du dich beschäftigst, was dich begeistert. Wenn du n Mini-ITX zusammengeschraubt hast, erzähl das. Wenns dir Spaß macht, an irgendwelchen technischen/logischen Problemen zu schrauben, erzähl das. Wenn du dir (rudimentäre) Skript-Kenntnisse angeeignet hast, erzähl das.

Von Excel würde ich glaube erst anfangen, wenn mir sonst nichts Besseres einfällt.

Ich hatte damals keine. Mein Chef grinste mich bei der Frage an und meinte nur "Wir hatten 3 Jahre Zeit, uns kennen zu lernen, ich denke, das passt."

Am 23.1.2018 um 13:32 schrieb jk86:

Programmiert ihr komplette Webseiten/Programme selbst oder einzelne Module, die vom Team dann zu einem großen Ganzen zusammengesetzt werden?

Wie unterscheiden sich die verschiedenen Lehrjahre programmiertechnisch voneinander?

Im 1. Lehrjahr haben wir vor allem Übungsaufgaben gemacht, um das erkennen/analysieren von Problemen und deren Zerteilung zu üben. Die Programmieraufgaben gingen mehr in Richtung "Entwirf einen Algorithmus für Problem xy" oder "Implementiere Algorithmus xy".

Gegen Ende des 1. Lehrjahrs wurden wir in die firmeneigenen Frameworks eingearbeitet. Das fing bei  "Bau ne einfache Bücherverwaltung" an und wurde mit der Zeit immer komplexer (Vernünftiges Fehlerhandling, externe APIs/Urls abfragen, Benachrichtigungen erzeugen, etc.)

Im 2. Lehrjahr wurden wir stückchenweise in reale Projekte integriert (aufgrund der Projektgrößen waren dies nur Teilmodule). Die Aufgaben waren quer beet: XLS auslesen und importieren, Datenbankmigration, GUI nach Vorgaben umsetzen.

Im 3. hatte ich die erste eigene (kleine) Anwendung (von Datenbank bis hin zu GUI und Kommunikation mit nem anderen System war da fast alles drin). Mein Ausbilder stand mir währenddessen noch bei der Konzeption/größeren technischen Problemen zur Seite.

Gelernt habe ich primär Java und n bisschen JavaScript.

vor 3 Stunden schrieb jk86:

Dokus schreiben wird irgendwie immer als Strafarbeit angesehen, aber es ist enorm wichtig und daher sinnvoll, das mal gemacht zu haben.

Ich geh noch n Schritt weiter: Wer den Code schreibt, muss ihn (bzw die Anwendung) auch dokumentieren. Wenn ich von unseren Projekten ausgehe, steckt im Code oft viel implizites Wissen.

Doku ist nicht nur "was" macht der Code (das sehe ich), sondern vor allem "warum". Es geht um den größeren Zusammenhang, Querverweise auf ähnliche Konstruktionen (und den Unterschied dazu), Querverweise aufs Konzept oder andere Quellen, Hinweise zur Benutzung, etc.

@Crash2001

Ich gebe dir Recht, dass man das bloße Aufsetzen einer VM (und bisschen damit rumspielen) auch gut allein zuhause machen kann.

Was aber finde ich schwer umsetzbar ist, sind Best-Practices und diverse Tipps und Tricks, die man erst mit der Erfahrung (durch ältere Kollegen) lernt.

Beispiel (ich bin AE, deswegen fällt mir so ein Beispiel einfacher):

Reines Java oder JEE kann ich daheim lernen. Was ich aber durch meinen Ausbilder bzw. das Arbeiten damit in der Firma gelernt habe, war die praktische Anwendung von z.B. Design Patterns. Oder z.B. eigene Frameworks zu bauen, die stabil sind und nicht bei der ersten komischen Eingabe abrauchen (Und auch benutzbar sind).

Nicht zu vergessen der ganze Bereich Clean-Code.

Ich glaube, solche Dinge sind nur sehr schwer daheim im eigenen Kämmerchen erlernbar. Da ist das Wissen und die Erfahrung älterer Kollegen einfach unglaublich hilfreich und wertvoll.

Ich hab damals auch den kompletten Zeitraum angegeben. Zur Zeitpunkt der Einreichung konnte ich ja noch nicht wissen, wann ich effektiv dafür eingeplant werde.

Im 3. Lehrjahr sind ja die meisten bereits fest ins Tagesgeschäft eingebunden, ergo entscheiden da noch andere Faktoren mit, wann man wie viel Zeit in die Projektarbeit investieren kann.

vor 2 Stunden schrieb Velicity:

Wenn das nach einen halben Jahr noch nicht läuft, dann wird das auch in 20 Jahren nicht laufen. Es geht um die Herangehensweise. Ich habe heute noch mal mit ganz alten Projekten, Schnittstellen und Lösungen zutun, die weit weg von unseren aktuellen Core sind, von denen ich keine Ahnung hab. Trotzdem kann ich, wenn es deshalb beim Kunden steht, in 10-15 Minuten nachvollziehen was schief läuft und dafür sorgen, dass der Kunde weiterarbeiten kann.

Geht ja nur drum bei einem Problem oder generell im System zu verstehen, was die einzelnen Komponenten sind, wie die miteinander kommunizieren etc. pp. Sprich kapieren was für Schichten gibt es da, in welcher liegt das Problem und das immer weiter eingrenzen. Man merkt meiner Meinung nach schon deutlich unter diesen 6 Monaten, ob das was werden kann oder nicht. Wird aber meist trotzdem bis ans Ende der Probezeit gezogen. Ich hätte die Leute persönlich wohl schon nach der halben Zeit aussortiert.

Für mich klingt das nach einem der Hauptprobleme für miesen Code. Wenn man immer nur "schnell-schnell" arbeiten soll und damit alles nur oberflächlich versteht, ist es fast schon vorprogrammiert, dass die eigene Lösung nur Gefrickel ist oder beim nächsten Husten ganz schnell andere Teile des Systems ins Wanken bringt.

Ich halte es für unmöglich, ein fremdes System in 15 Minuten soweit zu verstehen, dass man eine stabile Lösung einbauen kann.

Also ich sehe es als Teil der Professionalität, zu wissen, wie man sich bei offiziellen Anlässen kleidet.

Ich verkaufe in dem Moment nicht nur mich/meine Leistung, sondern repräsentiere auch meinen Arbeitgeber. Bei Kunden kann ich auch nicht in Jogginghose auftreten.

Dafür Punkte abzuziehen finde ich zwar auch etwas übertrieben, aber das liegt halt im Ermessen der IHK und wenn mans weiß, kann man sich entsprechend vorbereiten.

War bei mir (als FIAE) ähnlich.

Hast du denn die Möglichkeit, dir auf Arbeit ne Art Laborumgebung aufzubauen? Dann könntest du dich mit euren Programmen und Systemen vertraut machen, ohne Angst zu haben, was reales kaputt zu machen.

Ich hatte so gut wie keine Ahnung vom Programmieren und habe vor meiner Ausbildung n Praktikum absolviert.

Ich hab in der Zeit vor allem Aufgaben bekommen, die meine Selbstständigkeit und mein logisches Denken prüfen sollten (und nebenbei hab ich eben auch sehr viel übers Programmieren gelernt). Keine Vorkenntnisse zu haben ist vollkommen ok (und manchen Ausbildern sogar lieber, da dir weniger Mist abgewöhnt werden muss), solange du das "gewisse Etwas" hast. Dinge wie Selbstständigkeit, eine schnelle Auffassungsgabe, logisches Denken und grundlegende Anstandsregeln sind viel wichtiger.

IMHO klingt die dritte Person (also "Der Entwickler hat... gemacht") hier total falsch.

Was spricht denn gegen das vollkommen neutrale "Es wurde xy gemacht"?

Das Thema hatten wir tatsächlich vor nicht allzu langer Zeit bereits:

Ich hatte im Januar meine mündliche Prüfung bei der IHK Dresden.

"Meine" Prüfer waren sehr entspannt und locker drauf. Nach der Präsentation wollte ich kurz raus gehen, die Prüfer baten mich aber drin zu bleiben. Sie stellten mir ein paar allgemeine Fragen (Woher kamen die Zahlen aus der Rentabilitätsrechnung? Ist das Gewinn oder Umsatz? Was für Tests kennen Sie? Was ist OOP?) und schickten mich dann für vl 10 Minuten raus. Die Bewertung war wesentlich besser, als ich mich selbst eingeschätzt hatte (92 Punkte).

Ich muss aber dazu sagen, dass ich recht gut vorbereitet war und damit der erste Eindruck der Prüfer von mir bereits positiv war:

Ich hatte n Kostüm an, war ~ 30 min vor Termin da und hab Berichtsheft, Einladung und Ausweis direkt bereit gelegt. Danach hab ich alles aufgebaut und nochmal kurz getestet. Als dann auch der vorsitzende Prüfer eintrudelte, konnte es sofort los gehen.

Wenn du es dir finanziell leisten kannst, wäre ein Praktikum vielleicht eine gute Idee. Du lernst den echten Berufsalltag als FISI kennen und kannst dir das Jahr mit etwas Glück sogar anrechnen lassen (dann wäre die Ausbildung nur noch 2 Jahre lang statt 3).

Ich hab die Ausbildung mit fast 0 Vorkenntnisse in Programmieren angefangen und habe um ein halbes Jahr verkürzen können.

Es ist also definitiv machbar. Den Lehrstoff selbst würde ich als nicht besonders schwer einschätzen, sofern man sich für die Thematik interessiert. Aber das ist fast überall so, ohne eigene (intrinsische) Motivation fällt jedes Thema schwer.

Ausbildung in Teilzeit heißt doch auch insgesamt eine länger Ausbildung, oder? Ob du eine Chance hast, kommt auf den Arbeitgeber an. Bei uns z.B. gibt es sehr viele verschiedene Arbeitszeitmodelle und Lebensläufe, da könnte ich mir theoretisch auch einen Teilzeitazubi vorstellen.

Dein Engagement in allen Ehren, aber im Interesse deiner eigenen (psychischen) Gesundheit solltest du lernen abzuschalten und auch einfach mal Nein zu sagen.

@LetaleDosis

Zitat

Als Entwickler hat man selten Mitspracherechte für Workshoptermine, vor allem wenn das Produkt eigentlich schon lange fertig ist. 

Erlebe ich anders. Ist ein Produkt noch in der Entwicklung (unabhängig davon, ob der geplante Release bereits überschritten wurde oder nicht), sprechen die PMs vorher mit uns ab, welche Features wir bis wann präsentieren können (und ggf. werden Features auch erst mal komplett deaktiviert, wenn sie noch buggy sind).

(Und ja, wir mussten auch schon Termine komplett verschieben, weil zum Stichtag noch größere Probleme bestanden.)

Selbst bei bereits releasten Produkten werden wir informiert, dass eine Demo geplant ist und werden gefragt, ob wir vorher noch was dran machen wollen.

Die Firma schießt sich doch selbst ins Knie, wenn sie einem (wichtigen) Kunden ein halbfertiges Produkt präsentiert.

Nimms mir nicht übel, aber je mehr ich von dir lese, desto mehr hab ich den Eindruck, dass du in einem ziemlichen Saftladen arbeitest.

Mach dich nicht verrückt. Du scheinst dich ja vernünftigt vorzubereiten.

Die Prüfer sind auch nur Menschen und wollen dir nichts böses. Letzten Endes gehts doch nur darum zu demonstrieren, dass du verstanden hast, was du tust und in der Ausbildung nicht drei Jahre lang nur Kaffee gekocht hast.

Sei einfach pünktlich, hab alles dabei (Berichtsheft, Ausweis, etc.. Steht in der Einladung alles drin) und zeig dich von deiner besten Seite.

Lass dir auf jeden Fall vor Praktikumsbeginn bereits den Ausbildungsvertrag geben. Ich war vor ein paar Jahren in einer ähnlichen Situation, dass mir ein Ausbildungsplatz versprochen wurde und ich bis dahin aushilfsweise dort arbeiten konnte.

Ich wurde ewig hingehalten ("kriegst du nächste Woche, muss nur noch x gemacht werden") und aus dem Ausbildungsplatz wurde am Ende dann doch nichts.

Hallo,

wenn wir in unseren Anwendungen Filter brauchen (d.h. der Nutzer hat in der Oberfläche die Auswahl zwischen verschiedenen Optionen, die er beliebig kombinieren kann),

haben wir bisher immer die CriteriaApi benutzt, um das umzusetzen, ähnlich wie in diesem Blogbeitrag: http://www.mscharhag.com/java/specification-pattern-in-java-jpa

Zurzeit beschäftige ich mich jetzt mit Neo4j (Graphendatenbank) und finde kein so richtiges Äquivalent zur CriteriaApi.

Gibt es hierfür überhaupt ein Äquivalent? Wenn nein: Wie kann man über Cypher sowas umsetzen?

Für jede mögliche Kombination von Filterfeldern eine komplette Query schreiben, geht definitiv nicht...

@MarcoDrost

Du wirst lachen, ich habe tatsächlich schon Ratgeber gesehen, die empfehlen nur die (für die Stelle) wichtigsten beruflichen Positionen aufzulisten und sowas wie Schulabschluss oder Ausbildung ganz rauszulassen.

@MarcoDrost

Hat es denn nach >10 Jahren  wirklich noch Relevanz, ob jemand jetzt Abitur hat oder "nur" 10. Klasse? Solange die Arbeitszeugnisse in Ordnung sind, sollte das doch nun wirklich vollkommen egal sein.

A und B sind zwei komplett verschiedene Klassen. Dass ihre Attribute (zwei Stück, beide Strings) gleich sind, heißt nicht, dass sie ineinander konvertierbar sind. Du kannst nur innerhalb einer Vererbungshierarchie fehlerfrei casten, ansonsten wird bereits der Compiler sagen, dass die Typen nicht kompatible sind. A muss also von B erben (oder anders herum).

Darf ich ansonsten fragen, was du generell vor hast? Explizites Casten ist oft ein Hinweis auf Designfehler.

1600 halte ich für nen schlechten Scherz. Was bleibt da übrig? 1000€ netto?