Interesse an Nebenläufigkeit positiv in einer FIAE Ausbildungsbewerbung vermitteln?

[Legislaturperiode]

Hallo.

ich stehe aktuell in einer kleinen Zwickmühle: Einerseits finde ich nebenläufige Programmierung sehr interessant, anderseits weiß ich sehr wenig darüber.  Ich würde mein Interesse allerdings trotzdem gern in meiner Bewerbung unterbringen - ich vermute viele Unternehmen beschäftigen sich aktuell sehr intensiv mit Nebenläufigkeit.

Kleine Anmerkung dazu vorweg: Das ist natürlich nur mein aktuelles Verständnis von den den relevanten Themen rund um Nebenläufigkeit. D.h. falls ihr Fehler dazu entdeckt, freue ich mich über einen Hinweis dazu!

Was ich darüber weiß:

• Unterschied von Nebenläufigkeit zu Parallelisierung (Nebenläufigkeit bezeichnet sowohl die Ausführung mehrerer Threads auf einem, wie auf mehreren CPU kernen, Parallelität setzt zwingend mehrere CPU Kerne zur Ausführung voraus)
• getName() o.ä. Methoden, die für OOP typisch sind, sind schwer zu parallelisieren, weil das Ergebnis stark vom zeitlichen Kontext abhängt (Wurde das objekt bereits erzeugt? Wurde dem Objekt bereits ein wert hinzugefügt bzw. wurde der Wert bereits aktualisiert?). D.h. wenn zwei parallelisierte Threads gleichzeitig  ein Objekt lesen/verändern kann das Ergebnis unerwünscht sein, auch wenn der Code in einem single threaded Programm korrekt wäre.
• funktionale Sprachen sind von natur aus leichter zu parallelisieren, weil sie größtenteils seiteneffektfrei sind, d.h. sie liefern immer denselben wert zurück, unabhängig vom ausführungszeitpunkt.

Was ich nicht darüber weiß:

• Wie man nebenläufig programmiert (ich hab bisher immer nur darüber gelesen, allerdings noch nie wirklich nebenläufig programmiert)
• Wie man nebenläufig und gleichzeitig objektorientiert programmieren kann. (= stabiles, sicheres objektorientiertes, nebenläufiges Design)
• irgendwelche sonstigen theoretischen Dinge

Was möchte ich mit dieser Aussage dem Personaler/fachlichen Chef mitteilen?

• Ich hab mich damit beschäftigt und hab ernsthaftes Interesse daran
• Ich möchte damit nicht aussagen, dass ich "weiß, wie Nebenläufigkeit funktioniert" o.ä. Das tue ich nicht.

D.h. ich weiß generell sehr wenig darüber, finde es aber extrem interessant. Nun ist meine Frage, sollte ich basierend auf dem obigen Wissen, mein nebenläufiges Interesse in folgendem Absatz unterbringen? Wenn nein, kann ich ihn so verbessern, dass man mich und mein Interesse nicht falsch versteht?

Quote

Aktuell besuche ich das technische Gymnasium der $schule in $stadt –
Dort erlernen wir mithilfe von UML Grundlagen des objektorientierten Designs, welches
wir anschließend in C# implementieren. Zusätzlich beschäftigen wir uns mit dem Design
von Datenbanken.

Weiterhin finde ich Themen wie informationstechnische Qualitätssicherung, verschiedene
Programmierparadigmen (insbesondere funktionale), die Funktionsweise von
Kommunikationsprotokollen sowie nebenläufige Programmierung interessant. Darüber hinaus höre ich regelmäßig mehrere
Podcasts zum Thema Softwareentwicklung (SoftwareArchitekTOUR, innoQ und
Software Engineering Radio).

 

Bearbeitet 28. August 2016 von Legislaturperiode

[Whiz-zarD]

Warum sollte man sowas nicht erwähnen? Das zeigt, dass du dich intensiver mit den Themen beschäftigst und da es um ein Ausbildungsplatz gehen soll, kann man sowieso nicht erwarten, dass du schon alles kennst.

Die Nebenläufigkeit und die Parallelisierung sind auch ein sehr komplexe Themen. Siehe z.B. das Philosophenproblem (mal unter Wikipedia suchen). 

[Legislaturperiode]

Naja, ich möchte halt vermeiden dass das einen falschen Eindruck hinterlässt. In der Art "Der hat das sicherlich nur irgendwo in wikipedia gelesen und das kopiert, ohne es zu verstehen."

[Whiz-zarD]

Naja, was will man auch erwarten? Du bist kein ausgebildeter fachinformatiker, sondern die Firmen soll dich ausbilden. Wenn du schon alles weißt, bräuchtest du ja keine Ausbildung mehr.

Außerdem muss man sich ja aus der Menge herausstechen. Da könnten solche Fachbegriffe schon hilfreich sein.

[Chief Wiggum]

Die Gefahr bei einer solchen Aktion ist, dass im Vorstellungsgespräch fachlich nachgefragt werden kann.

Somit sollte man Sachen, von denen man keine Ahnung hat, in der Bewerbung NICHT erwähnen.

[Legislaturperiode]

@Chief Wiggum Mir, ist durchaus klar, dass da nachgefragt werden kann. Dann kann ich ja das erzählen, was ich dazu weiß, d.h. das empfinde ich nicht als schlimm.

Aber ich hab eben ein wenig Angst, dass sie dann enttäuscht sind, dass ich eben doch nur sehr wenig dazu weiß.

[Chief Wiggum]

Lass es weg. Du bewirbst dich um einen Ausbildungsplatz. Da werden keine Vorkenntnisse verlangt und erwartet - ausser den PC einschalten zu können ohne dass in der Kaffeeküche nebenan die Maschine explodiert.

[Nopp]

vor 37 Minuten schrieb Chief Wiggum:

Lass es weg. Du bewirbst dich um einen Ausbildungsplatz. Da werden keine Vorkenntnisse verlangt und erwartet -

Jo, sieht man ja bei den ganzen offenen Stellen...

Ist heutzutage oft eher andersrum. Leider.

[Chief Wiggum]

vor 3 Stunden schrieb Nopp:

Ist heutzutage oft eher andersrum. Leider.

Dann möchte man mich gerne als Ausnahme bezeichnen. Für mich als Ausbilder im Fisi-Bereich ist es echt schwer, in den ersten Wochen und Monaten das "Vorwissen" vom Azubi abzuprüfen und sicherzugehen, dass ich ihm ohne Gefahren einen Admin-Zugang gewähren kann - und sei es nur ein globaler lokal Admin auf allen Systemen ohne Dom-Admin-Rechte.

Auch wenn ich nicht programmieren kann: ist es bei euch in der AE-Welt nicht genauso? Oder seid ihr so schräg und freut euch über Spaghetticode vom Azubi, hauptsache das Programm funktioniert?

[JimTheLion]

vor 5 Stunden schrieb Legislaturperiode:

Naja, ich möchte halt vermeiden dass das einen falschen Eindruck hinterlässt. In der Art "Der hat das sicherlich nur irgendwo in wikipedia gelesen und das kopiert, ohne es zu verstehen."

Das ist ein Eindruck, der sich für mich durch alle deine Threads zieht.

Jedes mal irgendwelche anderen Technologien für die du dich sehr interessierst. Was ist mit dem Interesse an Kryptografie passiert? Dein Wissen darüber könntest du im Gespräch einfacher nachweisen.

vor 6 Stunden schrieb Legislaturperiode:

Ich würde mein Interesse allerdings trotzdem gern in meiner Bewerbung unterbringen - ich vermute viele Unternehmen beschäftigen sich aktuell sehr intensiv mit Nebenläufigkeit.

Woher kommt die Vermutung?

Ich denke, der Personalabteilung würde der Satz den du im Anschreiben unterbringen nichts sagen; der Geschäftsführer interessiert sich nicht für Implementationsblabla und der Ausbilder bleibt unbeeindruckt weil er weiß, dass da nicht viel hinter stecken wird.

[Chief Wiggum]

vor 10 Minuten schrieb PVoss:

Ich denke, der Personalabteilung würde der Satz den du im Anschreiben unterbringen nichts sagen

Zustimmung. In unserer Personalabteilung sitzen auch nur (aus IT-Sicht) Anwender, schlimmstenfalls DAUs.

[Legislaturperiode]

43 minutes ago, PVoss said:

Das ist ein Eindruck, der sich für mich durch alle deine Threads zieht.

Kannst du das etwas näher beschreiben? Hm, ich möchte ja gar nicht vermitteln dass ich viel weiß, sondern eben nur dass ich es interessant finde.

43 minutes ago, PVoss said:

Jedes mal irgendwelche anderen Technologien für die du dich sehr interessierst. Was ist mit dem Interesse an Kryptografie passiert? Dein Wissen darüber könntest du im Gespräch einfacher nachweisen.

Hm. Naja, mein Interesse kommt eben meist daher, dass ich Dinge verstehen zu versuche, die bisher noch nicht verstehe. Mein Interesse an Kryptographie ist natürlich immer noch da - da gibts btw. auch noch dinge die ich super interessant finde, aber noch nicht verstehe, bspw. hashing und symmetrische Kryptographie wie AES. Warum ich mich aber aktuell  mit Nebenläufigkeit statt Kryptographie beschäftigt habe, wenn ich beides nicht verstehe und beides interessant finde, lässt sich vermutlich durch meinen Eindruck des größeren Nutzens in der Softwareentwicklung erklären.

Zumindest ist das so mein Verständnis. => Auch hier freue ich mich über Korrekturen.

43 minutes ago, PVoss said:

Woher kommt die Vermutung?

Quelle ist diese SoftwareArchitekTOUR Folge    , in der die Aussage getätigt wurde, dass Prozessorkerne generell nicht wirklich schneller werden, sondern dass sich vielmehr die Anzahl der Kerne pro Prozessor erhöhen. Da mehrere Prozessorkerne selbst im PC Bereich schon recht "standart" sind, kann man durch eine parallelisierte Ausführung (auf mehreren Kernen) idealerweise dadurch schon performantere Systeme bauen, wie mit einer nicht-parallelisierten Ausführung - schließlich bleiben bei einer nicht-parallelisierten Ausführung alle anderen Kerne ungenutzt.
 

43 minutes ago, PVoss said:

Ich denke, der Personalabteilung würde der Satz den du im Anschreiben unterbringen nichts sagen; der Geschäftsführer interessiert sich nicht für Implementationsblabla und der Ausbilder bleibt unbeeindruckt weil er weiß, dass da nicht viel hinter stecken wird.

Hm, danke, das ist tatsächlich ein ziemlich gutes Argument.

 

Bearbeitet 28. August 2016 von Legislaturperiode

[Whiz-zarD]

vor 33 Minuten schrieb Legislaturperiode:

Quelle ist diese SoftwareArchitekTOUR Folge    , in der die Aussage getätigt wurde, dass Prozessorkerne generell nicht wirklich schneller werden, sondern dass sich vielmehr die Anzahl der Kerne pro Prozessor erhöhen. Da mehrere Prozessorkerne selbst im PC Bereich schon recht "standart" sind, kann man durch eine parallelisierte Ausführung (auf mehreren Kernen) idealerweise dadurch schon performantere Systeme bauen, wie mit einer nicht-parallelisierten Ausführung - schließlich bleiben bei einer nicht-parallelisierten Ausführung alle anderen Kerne ungenutzt.

Nicht immer ist eine Parallelisierung sinnvoll.
Eine Parallelisierung ist nur dann sinnvoll, wenn man auch wirklich eine Berechnung parallelisieren kann und diese auch von der Parallelisierung profitiert. Etwas zu parallelisieren, nur damit die Berechnung 2 Sekunden dauert, anstatt 5, ist einfach unnütz. Du wirst selbst heute noch sehr wenig mit Parallisierung zu tun haben. Eher mit Nebenläufigkeiten, um Daten asychron zu berechnen/zu laden. Parallelisierung wird oftmals erst zum Thema, wenn es Performanceprobleme gibt.

vor 1 Stunde schrieb Chief Wiggum:

Auch wenn ich nicht programmieren kann: ist es bei euch in der AE-Welt nicht genauso? Oder seid ihr so schräg und freut euch über Spaghetticode vom Azubi, hauptsache das Programm funktioniert?

Ehrlich gesagt, würde ich mich schon freuen, wenn ich sogar von Entwicklern mit mehrjähriger Erfahrung kein Spaghetticode mehr ansehen muss. Es ist einfach traurig, dass selbst viele Freiberufler und Consulting Agenturen noch nie etwas von Clean Code oder SOLID gehört haben.

Aber zum Thema: Warum sollte man es nicht erwähnen, dass man sich mit Themen wie Nebenläufigkeit schon mal auseinandergesetzt hat? Man erwartet ja kaum in Vorstellungsgesprächen, dass er alles ins Detail kennt. Selbst die Stichworte, die der TE aufgeschrieben hat, ist mehr als so manch ein Diplominformatiker weiß. Beim Vorstellungsgespräch kann man ja mit offenen Karten spielen und sagen, dass man sich bis jetzt nur in der Theorie damit auseinandergesetzt hat. Wenn ich einen Azubi einstellen würde, würde ich es auch nicht mal verlangen, dass er weiß wie man so etwas programmiert. 

[Legislaturperiode]

43 minutes ago, Whiz-zarD said:

Du wirst selbst heute noch sehr wenig mit Parallisierung zu tun haben. Eher mit Nebenläufigkeiten, um Daten asychron zu berechnen/zu laden. Parallelisierung wird oftmals erst zum Thema, wenn es Performanceprobleme gibt.

Das finde ich erstaunlich (wobei ich ehrlich gesagt keine Ahnung davon habe, welche Art von Softwareentwicklung aktuell den Markt dominiert). Gerade solche Anforderungen wie die von größeren Webshops hätte ich als ideal zum parallellisieren eingeschätzt. Immerhin verstehe ich den aktuellen Stand so, dass dort eine thread-basierte(s) Architektur/Design quasi standart ist. Ansonsten könnte man ja gar nicht alle Nutzer gleich bedienen (bzw. ihm irgendein Ergebnis zurückliefern, damit er weiß ob die Webseite gerade etwas berechnet, oder "kaputt" ist.) und müsste alle Nutzer sequentiell abarbeiten.

Das eignet sich doch ideal zum parallelisieren, oder? Speziell wenn die Anforderungen größer sind, hätte ich erwartet dass Parallellisierung da quasi Standart ist. (weil ein Kern zu langsam ist, um ein paar Millionen Anfragen zu irgendwas zeitnah zu verarbeiten)

Warum werde ich aktuell sehr wenig mit Parallellisierung zu tun haben?

Bearbeitet 28. August 2016 von Legislaturperiode

[Whiz-zarD]

vor 7 Minuten schrieb Legislaturperiode:

Gerade solche Anforderungen wie die von größeren Webshops hätte ich als ideal zum parallellisieren eingeschätzt. Immerhin verstehe ich den aktuellen Stand so, dass dort eine thread-basierte(s) Architektur/Design quasi standart ist. Ansonsten könnte man ja gar nicht alle Nutzer gleich bedienen (bzw. ihm irgendein Ergebnis zurückliefern, damit er weiß ob die Webseite gerade etwas berechnet, oder "kaputt" ist.) und müsste alle Nutzer sequentiell abarbeiten.

Das eignet sich doch ideal zum parallelisieren, oder? Speziell wenn die Anforderungen größer sind, hätte ich erwartet dass Parallellisierung da quasi Standart ist. (weil ein Kern zu langsam ist, um ein paar Millionen Anfragen zeitnah zu beantworten)

Anstatt einen Monolithen zu bauen wird heutzutage die Microservice-Architektur bevorzugt. Man startet also nicht einzelne Threads, sondern ganze Prozesse, die untereinander mit einem Messagebroker kommunizieren. Die Microservice-Architektur lässt sich auch einfacher skalieren, da die Microservices auf unterschiedliche Server gehostet werden können und für jeden Microservice kann dann eine geeignete Persistenzschicht gewählt werden.

vor 13 Minuten schrieb Legislaturperiode:

Warum werde ich aktuell sehr wenig mit Parallellisierung zu tun haben?

Weil das vielfach einfach nicht nötig tut und over-engineering wäre. So lange es auch auf andere Wege funktioniert, die einfacher zu händeln sind, würde ich nicht auf eine Parallisierung setzen. Nicht überall ist eine Parallisierung schneller, da eine Parallisierung auch mehr Overhead bedeutet. In einigen Fällen ist eine Parallisierung sogar auch langsamer als eine sequentielle Abarbeitung. Besonders wenn die Threads miteinander kommunizieren und aufeinander warten müssen.

[arlegermi]

vor 9 Stunden schrieb Legislaturperiode:

Gerade solche Anforderungen wie die von größeren Webshops hätte ich als ideal zum parallellisieren eingeschätzt. Immerhin verstehe ich den aktuellen Stand so, dass dort eine thread-basierte(s) Architektur/Design quasi standart ist

Das ist schon richtig. Das Ding ist nur, dass du als (z.B.) Webentwickler damit nichts zu tun haben wirst. Die gesamte Parallelisierung wird dir vom Server / Framework abgenommen. Klar, du startest mal einen neuen Thread oder Task und lässt den parallel laufen - mit der zugrundeliegenden Technik hast du aber nichts zu schaffen. Korrekten (!) multithreaded Code zu schreiben, ist schwierig und aufwendig zu testen. Daher verlässt man sich normalerweise auf die Arbeit von Experten, die einem eine zugängliche API bereitstellen (in der .NET-Welt sind das bspw. async/await, Task.Run oder Thread.Start - und selbst da kann man genug verkehrt machen, wenn man nicht aufpasst).

Ich würde dir auch empfehlen, solche Sachen aus der Bewerbung rauszulassen. Im besten Fall nimmt dein Gegenüber das nicht für bare Münze und denkt sich seinen Teil, im schlimmsten Fall hält man dich für naiv und eine Buzzword-Schleuder.

[Crash2001]

vor 11 Stunden schrieb Legislaturperiode:

[...]Hm, ich möchte ja gar nicht vermitteln dass ich viel weiß, sondern eben nur dass ich es interessant finde.[...]

Etwas interessant finden und darauf hinzuarbeiten,, die entsprechende Technik einmal produktiv einzusetzen später ist aber ein himmelweiter Unterschied. Du findest vielleicht auch Musik von $Interpret interessant, oder $Computerspiel. Deshalb muss es aber lange nicht relevant sein für die Ausbildung. Genauso kann es auch sein, dass du es total uninteressant findest, wenn du das Prinzip dahinter verstanden hast.

Es werden auch längst nicht alle Firmen parallelisierte Prozesse oder Nebenläufigkeit unbedingt in ihren Programmen verwenden. Es lohnt halt oftmals einfach nicht, diesen Zusatzaufwand (man braucht z.B. zusätzliche Schnittstellen und Sicherungsmechanismen, um die Datenintegrität sicherzustellen, damit nicht bereits berechnete Werte einfach wieder überschrieben werden von anderen parallel laufenden Prozessen, man braucht eine Speicherverwaltung, usw.)
Bei kleinen Klitschen kann man manchmal sogar froh sein, wenn überhaupt richtig objektorientiert programmiert wird, und man keinen Spaghetticode schreiben soll, oder man unsaubere Programmierung (Mißbrauch von Klassen z.B.) beigebracht bekommt.

Zudem lernt man erst einmal die Grundlagen der Programmierung und steigt nicht direkt mit Sonderfällen damit ein, die komplexer zu programmieren sind.
Meist steigt man auch nicht einmal direkt mit objektorientierter Programmierung ein, sondern erst einmal mit den Grundlagen wie if-Abfragen, Schleifen, Datentypen, Variablen, globalen Variablen, Funktionen usw. und geht dann über ins objektorientierte Programmieren mit Klassen und Methoden usw. Die Parallelisierung würde dann also erst danach kommen.

Parallelisierung hat Nachteile, wenn Ergebnisse auf den Rückgabewert des vorherigen Prozesses warten müssen, so dass sich lange nicht alles auch sinnvoll parallelisieren lässt.
Was bringt es dir, wenn Prozess 1 auf CPU 1 läuft, Prozess 2 gestartet wird, jedoch auf den Rückgabewert von Prozess 1 warten muss, um loslaufen zu können? Da kann es genausogut auch nach Ablauf des Prozesses 1 auf CPU 1 weiterberechnet werden.
Das Gleiche dürfte auch für Nebenläufigkeit gelten.
Kann man ein Programm SINNVOLL in mehrere Threads zerlegen, bringt der Overhead keinen wirklichen Vorteil in der Laufzeit, oder kann man dadurch viel Zeit sparen (jede Menge kleine Jobs, die unabhängig voneinander laufen können)?

[mqr]

Hallo Community,

Meiner Ansicht nach ist der Begriff "Nebenläufigkeit" eh sehr schwer von einer alternierenden Arbeitsweise abzugrenzen und als Modewort für Rechenstandart anzusehen, da sich Berechnungen oft in einer Abhängigkeit voneinander bewegen. Ob nun echte Parallelisierung oder nicht, der Grafikprozessor nimmt dem Hauptprozessor auch parallel Arbeit ab. Zwei Computer sind hingegen keine Parallelisierung. Mit solchen Fragen sollte man sich bei sogenannten Supercomputern auseinandersetzen, die mit PETAFLOPS arbeiten und die amerikanische Wetterlage mit der Europäischen zusammenrechnen um die Geschwindigkeit des Golfstroms zu ermitteln.

So mein Verständnis zu der Einlassung. Evt. viel Lärm um nichts!

Grüße

Micha

[Legislaturperiode]

2 hours ago, mqr said:

Zwei Computer sind hingegen keine Parallelisierung.

Warum? Die Probleme (z.B. Verhinderung von Race conditions) müssten doch dieselben bzw. ähnlich sein, oder? Zumindest, wenn man einen gemeinsamen Datenbereich verwendet, wie eine Datenbank o.ä..

 

2 hours ago, mqr said:

Meiner Ansicht nach ist der Begriff "Nebenläufigkeit" eh sehr schwer von einer alternierenden Arbeitsweise abzugrenzen

Was meinst du damit?

----------------------------------------------------------------------------------------------------------

Hm, offensichtlich hab ich die Bedeutung von Nebenläufigem Programmieren total falsch eingeschätzt - gut, dass ich nachgefragt hab. Da zudem die grundsätzliche Aussage - dass ich an moderen Technologien in der Softwareentwicklung interessiert bin - durch mein Verweis auf das aktive Hören von Softwareentwicklungs-Podcasts schon gegeben ist, werd ichs rauslassen.

Vielen Dank für die Diskussion!

[Whiz-zarD]

vor 2 Stunden schrieb mqr:

Zwei Computer sind hingegen keine Parallelisierung.

Warum nicht?
Ob ich jetzt mehrere Threads auf einer Maschine oder mehrere Prozesse auf mehreren Maschinen starte, spielt für die Parallelität keine Rolle. Fakt ist, es wird parallel etwas verarbeitet.

[Crash2001]

@zwei Computer sind keine Parallelisierung:

Natürlich nicht. Eine Parallelisierung wäre es erst dann, wenn sie ein Cluster bilden und/oder zur Lastverteilung Aufgaben verteilt berechnen.
Wobei es selbst dann noch nicht zwingend eine Parallelisierung sein muss.

[mqr]

Nunja, ich habe mich nicht mit diesen grundlegenden Fragen beschäftigt. Von daher ist meine Ansicht von Parallelisierung zu reden und dann an Bits parallel bis zur Busbreite berechnet zu denken (synchron), zu naiv. Ich hätte gedacht Parallelität müsste separate Werte mit anderen Algorithmen beinhalten, die ein gemeinsames Ergebnis erreichen wollen. Mehrere Prozesse laufen doch auf jeder zeitgleich eingeschalteten Maschine???

Ich sollte mir noch einmal die Definitionen anschauen.

Grüße

Micha

[KeeperOfCoffee]

Wenn du genauso viel Zeit in Bewerbungen investieren würdest wie in "Themen die du interessant findest" hättest du wohl schon einen Haufen Bewerbungsgespräche.

Ernsthaft...eine Ausbildung ist da um Wissen zu vermitteln. Kein AG kann dir garantieren Techniken einzusetzen "die du interessant findest". Genaugenommen wird es deinem Chef egal sein, Hauptsache das Produkt x ist zum dd.MM.yyyy brauchbar.

Es ist schön wenn du mal später mit was arbeitest, was dir Spaß macht, so sollte es im Idealfall sein, aber du machst ne Ausbildung ...

Du sollst alles lernen was für diesen Beruf erstmal relevant ist, egal ob es dich interessiert oder nicht. Die meisten Ausbilder sind froh Leute zu haben, die sich für das Zeug interessieren, welches in der Firma angewandt wird. Vermeintliche "Alleswisser" die alles ewig lange in Frage stellen, sind da oft nicht gern gesehen. 

Wenn Ausbilder deine Bewerbung sehen, denken sie sich wahrscheinlich oft "aha schön, dass ihn das interessiert ... machen wir aber leider nicht". Mal ganz davon abgesehen: Gehe nicht davon aus, als Azubi gleich an/mit den spannendsten Themen zu arbeiten. Das erste Jahr bekommst du in der AE erstmal kleinere Aufgaben und guckst anderen über die Schulter. Das Tempo wird dann je nach deiner Eignung angezogen.

Und zum Schluss: Du schindest mehr Eindruck, wenn du dich über die Technik die der AG einsetzt informierst, als random irgendwas zu lernen. Ein AG ist 10x mehr happy wenn du dich über sein Zeug und den Techniken die dahinter stecken informierst, als über etwas was du auf heise gelesen hast. 

Bearbeitet 29. August 2016 von KeeperOfCoffee