IT-Berufe-Podcast

In der dreizehnten Episode meines Anwendungsentwickler-Podcasts beende ich meine Liste der häufigen Fragen rund um die Programmierung im Fachgespräch.

Objektorientierung

Was bedeutet das Schlüsselwort this?

Zeiger auf das aktuelle Objekt.

Was bedeutet static?

Statische Attribute oder Methoden können ohne eine Instanz ihrer Klasse verwendet werden.

Was sind Vor-/Nachteile static?

Statische Methoden sind gut testbar, da sie keinen Objektzustand verwenden. Sie können aber z.B. nicht überschrieben werden.

Was ist ein Konstruktor?

Ein Konstruktor ist eine besondere Methode, die eine Objektinstanz erzeugt.

Welche Parameter sollte ein Konstruktor haben?

Ein Konstruktor sollte alle Parameter bekommen, die nötig sind, um ein Objekt in einem gültigen Zustand zu erzeugen.

Was sind Enumerations?

Enumerations sind Datentypen mit einer endlichen Menge an erlaubten Werten.

Welche Vorteile bieten Listen gegenüber Arrays?

Sie sind redimensionierbar. Sie sind evtl. schneller.

Fehlerbehandlung

Was sind Exceptions?

Eine Exception beschreibt eine Fehlersituation in einem Programm. Sie kann in anderen Teilen des Programms behandelt werden.

Welche zwei Typen von Exceptions gibt es in Java?

Checked (müssen gefangen werden) und unchecked Exceptions.

Was bedeuten die Schlüsselwörter try, catch, throw und throws?

try/catch: umschließen potentiell fehlerhaften Code, throw wirft eine Exception, throws kennzeichnet eine Methode als potentiell fehlerhaft.

Tiefergehendes

Was ist Refactoring?

Die semantikinvariante Modifikation von Quelltext.

Was ist Typinferenz?

Durch Typinferenz kann der Compiler den Datentyp einer Variablen ableiten, ohne dass er explizit angegeben werden muss.

Was sind generische Klassen?

Generische Klassen (Generic) stellen allgemeingültige Algorithmen für unterschiedliche Datentypen bereit.

Was sind Ko- und Kontravarianz?

Bei einer Vererbungsbeziehung kann eine Methode in der Subklasse überschrieben werden und dabei ihre Parametertypen anhand deren Vererbungsbeziehungen verändern. Wenn diese Veränderung in die gleiche Richtung geht wie die Vererbungsbeziehung der Methode, spricht man von Kovarianz. Wenn sie gegenläufig ist, spricht man von Kontravarianz.

Beliebtes Beispiel in Java: Listen sind nicht kovariant, d.h. List erbt nicht von List.

Literaturempfehlungen

*(direkt beim Rheinwerk-Verlag bestellen*)

Das passende Kapitel im OpenBook: 9 Grundlagen der Programmierung - Rheinwerk Computing :: IT-Handbuch für Fachinformatiker

*(direkt beim Rheinwerk-Verlag bestellen*)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Aufzählungstyp – Wikipedia

Ausnahmebehandlung – Wikipedia

Refactoring – Wikipedia

Typinferenz – Wikipedia

Generischer Typ – Wikipedia

Kovarianz und Kontravarianz – Wikipedia Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden!

In der zwölften Episode meines Anwendungsentwickler-Podcasts schließe ich meine Reihe zu häufigen Fragen im Fachgespräch rund um die Programmierung mit einigen allgemeinen Fragen ab. Da die Liste der Fragen recht lang ist, habe ich die Beantwortung auf zwei Episoden aufgeteilt. Der Rest folgt also in der nächsten Woche.

Programmierung allgemein

Was ist ein Algorithmus?

Eine Beschreibung zur Lösung eines Problems.

Welche drei grundlegenden Bausteine von Algorithmen gibt es?

Sequenz, Verzweigung und Wiederholung.

Was ist Rekursion?

Eine Funktion, die sich selbst aufruft.

Was sind Vor-/Nachteile von Rekursion?

Vorteil: Kurze Funktionen, nah an der Definition. Nachteil: Stack kann überlaufen.

Muss man Rekursion einsetzen?

Nein, man kann jedes Problem auch iterativ lösen.

Welche zwei grundlegenden Formen von Schleifen gibt es?

Kopfgesteuert/abweisend und fußgesteuert/akzeptierend.

Welche anderen Formen von Schleifen gibt es noch?

Zählerschleife (for), foreach.

Welche drei grundlegenden Datenstrukturen gibt es?

Variable, Array und Struct/Objekt/Record.

Was ist der Unterschied zwischen call by value und call by reference?

By value verändert die ursprüngliche Variable nicht, by reference schon.

Eigenschaften von Programmiersprachen

Was sind Sourcecode, Bytecode und Maschinencode?

Sourcecode schreibt der Mensch, Maschinencode führt der Computer aus, Bytecode ist ein Zwischending für die Ausführung durch eine virtuelle Maschine (z.B. bei Java und .NET).

Was sind Compiler und Interpreter?

Compiler übersetzt Quelltext in Byte- oder Maschinencode. Interpreter führt den Quelltext direkt aus.

Was bedeuten statische und dynamische Typisierung?

Bei der statischen Typisierung stehen Datentypen bereits zur Compilezeit fest.

Was bedeuten starke und schwache Typisierung?

Starke Typisierung lässt keine implizite Typumwandlung zu.

Was ist ein Cast?

Eine explizite Typumwandlung.

Literaturempfehlungen

*(direkt beim Rheinwerk-Verlag bestellen*)

*(direkt beim Rheinwerk-Verlag bestellen*)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Rekursion – Wikipedia

Statische Typisierung – Wikipedia

Starke Typisierung – Wikipedia

Typumwandlung – Wikipedia Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden!

In der elften Episode meines Anwendungsentwickler-Podcasts gehe ich sinnvolle Inhalte der Projektpräsentation durch.

Wichtige allgemeine Hinweise

Die Projektpräsentation sollte im Großen und Ganzen die Inhalte der Projektdokumentation verkürzt darstellen. Meist haben nicht alle Mitglieder des Prüfungsausschusses die Dokumentation gelesen, also sollte die Präsentation ohne dieses Hintergrundwissen verständlich sein. Du kannst davon ausgehen, dass im Prüfungsausschuss erfahrene Softwareentwickler sitzen, musst also keine allgemein bekannten Begriffe erläutern (z.B. GUI, ERM usw.). Aber die Feinheiten deiner Branche, deines Ausbildungsbetriebes und insb. deines Projektumfelds wird niemand kennen.

Da die 15 Minuten - die du übrigens unbedingt einhalten musst - recht knapp bemessen sind, sollten die wichtigsten und interessantesten Inhalte der Dokumentation gezeigt werden. Das sind hauptsächlich die angewendeten Methoden, z.B. in Form von UML-Diagrammen, und nicht langweilige Textwüsten. Super ist eine Live-Demo deiner Anwendung, wobei du sicher sein solltest, dass diese wie erwartet funktioniert. Ich würde daher eher zu Screenshots oder einem Screencast raten.

Alle Inhalte müssen gut lesbar sein. Ich empfehle mind. (!) Schriftgröße 24. Achte insb. auf Grafiken und Quelltexte, die genauso groß sein sollten.

Nutze woimmer es geht besser Grafiken/Diagramme anstatt Text zur Visualisierung deiner Arbeit. Die hast du ohnehin (hoffentlich) für die Dokumentation erstellt.

Zeige interessante Inhalte und Beispiele und keine langweiligen Trivialitäten. Beispiel: Als Quelltextausschnitt nicht die Getter/Setter deiner Klasse zeigen, sondern den selbst entwickelten Algorithmus.

Die Corporate Identity (Logo, Fußzeile usw.) mag deinem Ausbildungsbetrieb heilig sein, aber wenn du große Grafiken oder Quelltext zeigen willst und durch das Logo nur noch die halbe Folie an Platz zur Verfügung steht, würde ich zu Gunsten der Lesbarkeit auf die CI verzichten. Denke daran: Es ist deine (!) Abschlussprüfung und keine Werbeveranstaltung deines Ausbildungsbetriebs.

Die vorgebene Zeit von 15 Minuten muss unbedingt eingehalten werden.

Daher muss eine bewusste Auswahl der Inhalte getroffen werden.

Das bedeutet, dass man nur die absoluten Highlights seines Projekts zeigen sollte.

Wo immer es geht, mit Grafiken arbeiten und nicht mit Text. Gerade die wichtige Methodik lässt sich sehr gut visualisieren (UML, ERM usw.).

Auf jeden Fall muss sowohl die Technik, als auch die Wirtschaftlichkeit gezeigt werden.

Wichtige Eckpunkte, die aus der Präsentation hervorgehen müssen: verwendete Programmiersprache und Datenbank sowie ggfs. Frameworks.

Fokus auf die eigenen Inhalte legen.

Nicht auf ein funktionierendes Internet verlassen!

Zwischenfragen nicht zulassen!

Konkrete Inhalte

Klassischer Aufbau: Einleitung, Hauptteil, Schluss.

Einleitung stellt Prüfling, Betrieb und Thema vor.

Hauptteil zeigt die Highlights aus den einzelnen Projektphasen.

Schluss gibt einen Rück- und Ausblick.

Einleitung

Titelfolie mit Projektbezeichnung, Daten des Auszubildenden und des Ausbildungsbetriebs.

Agenda zeigt geplanten Ablauf der 15 Minuten.

Kurze (!) Vorstellung des Prüflings und des Unternehmen.

Das Projekt und die Aufgaben des Prüflings müssen verständlich erklärt werden, auch für Mitglieder des Prüfungsausschusses, die die Projektdokumentation nicht gelesen haben.

Insb. das Projektziel und die Begründung für die Durchführung müssen ersichtlich werden.

Kurze (!) Beschreibung der Ausgangssituation (Ausbildungsbetrieb, Problemstellung, Ist-Analyse).

Viele Prüflinge nutzen diesen Teil als viel zu lange Werbeveranstaltung für das Ausbildungsunternehmen. Es interessiert niemanden, wie viele Standorte und tolle Produkte dein Unternehmen hat. Du sollst dein Projekt und deine eigene Arbeit vorstellen. Eine Folie zum Unternehmen und maximal ein paar Sätze dazu reichen.

Hauptteil

Übliche Grafiken zur Erklärung bestimmter Sachverhalte.

ERM, Tabellenmodell für die Datenbank.

GUI-Mockup, Screenshot für die Oberfläche.

Use-Case-/Aktivitätsdiagramm, EPK oder Flussplan für die Anforderungen.

Klassen-/Komponentendiagramm für die Architektur der Anwendung.

Deplomentdiagramm für die physikalische Verteilung der Anwendung.

Klassen-/Sequenz-/Zustandsdiagramm für die Implementierung.

Visuelle Amortisationsrechnung bei der Wirtschaftlichkeitsbetrachtung.

Der Aufbau des Hauptteils sollte dem Ablauf des Projekts folgen (Projektphasen).

Projektplanung

Projektziel (Soll-Konzept, Qualitätskriterien).

Hierbei besonders auf den Kontext und das Ziel des Projekts eingehen, das man ohne Vorkenntnisse verstehen sollte. Ich habe schon Präsentationen gesehen, bei denen ich bis zum Ende nicht wusste, was eigentlich genau umgesetzt wurde und warum das sinnvoll war.

Projektbegründung: Projektkosten und Wirtschaftlichkeitsbetrachtung (Amortisationsrechnung, gerne grafisch), ggfs. Nutzwertanalyse.

Projektphasen mit Angabe der geplanten Stunden

Vorstellung des Entwicklungsprozesses

Wirtschaftlichkeit: Kosten- und Amortisationsrechnung; ggfs. Nutzwertanalyse

Die Wirtschaftlichkeit ist ein absoluter Pflichtteil in jeder Präsentation, auch wenn die meisten Entwickler sich lieber mit der Technik auseinandersetzen.

Analyse

Vorgehen beschreiben

Use Cases zeigen

Lastenheft

Entwurf

Programmablauf: EPK, Aktivitätsdiagramm, Flussplan

GUI: MockUps der Oberflächen, Konzept der Dialoge

Datenbank: ERM, Tabellenmodell

Architektur der Anwendung (Einbindung in und Interaktion mit anderen Systemen): Komponentendiagramm, Verteilungsdiagramm

Wie komplex ist die Aufgabenstellung? Welche Komponenten wurden umgesetzt?

Entscheidung für Programmiersprache, Datenbank, Frameworks usw. begründen, z.B. mit einer Nutzwertanalyse

Implementierung (z.B. ERM, UML, (kurze) Quelltexte, Screenshots).

Es ist erstaunlich, dass es immer wieder Präsentationen gibt, aus denen die verwendete Programmiersprache und/oder Frameworks usw. nicht hervorgehen.

Auch die Qualitätssicherung ist ein zentraler Punkt. Hast du getestet? Wie? Gab es Code-Reviews? Wer hat das Programm abgenommen?

interessante Quelltexte, Screenshots zeigen

Endergebnis zeigen: Screenshots, Live-Demo (besser als Video aufzeichnen)

Beispiele für aufgetretene Probleme und deine Lösungen dafür.

Bitte keine Trivialitäten wie "ich habe bei der for-Schleife einen Off-by-one-Error gehabt".

Test/Abname

Testplan, Unit-Tests, Testprotokolle zeigen

Dokumentation

Benutzerdokumentation vorstellen

Entwicklerdokumentation zeigen

Schluss

Fazit: Zielerreichung, Akzeptanz beim Kunden

Hier kannst du gerne noch kurz (!) deine Erfahrungen unterbringen und ggfs. zeigen, dass das Projekt fortgeführt oder erweitert wird.

Lessons Learned: Was hat der Prüfling aus dem Projekt gelernt?

Ausblick: Wird das Projekt weitergeführt und wenn ja wie?

Obligatorische Schlussfolie mit Name, Logo usw.

Bewertungsschema der IHK

Die IHK bewertet die Präsentation nicht allein, sondern im Zusammenhang mit dem anschließenden Fachgespräch. Es gibt also immer nur eine Note für den gesamten Prüfungstag. Dennoch kann eine gute Präsentation natürlich die Gesamtnote verbessern bzw. eine schlechte das ansonsten gute Fachgespräch abwerten.

Das folgene Bewertungsschema wird von mehreren IHKen verwendet. Allerdings kann jede IHK eigene Vorgaben machen. Bitte suche daher auf der Website der für dich zuständigen IHK nach den konkreten Vorgaben für deine Prüfung.

Fachkenntnisse (20%)

Die musst du also zeigen! Das bedeutet: Methoden, Kosten, Grafiken, spannende Inhalte.

Rhetorik (10%)

Ich gehe davon aus, dass du die Präsentation so lange übst, bis du sie perfekt auswendig kannst und exakt auf 15 Minuten kommst. Dann sollte der Vortrag locker und professionell möglich sein.

Medieneinsatz (10%)

Wie man mit PowerPoint umgeht, solltest du nach drei Jahren Ausbildung wissen. Sinnvolle Animationen sind zur Unterstützung der Verständlichkeit Pflicht.

Begrüßung und Einstieg in die Präsentation (10%)

Siehe oben: Mache direkt dein Thema deutlich und zeige, was deine Leistung ist. Verschwende keine wertvolle Zeit mit der Historie oder dem Organigramm deines Ausbildungsbetriebs.

Ergebnis des Fachgesprächs (50%)

Foliendesign

Zum Thema Foliendesign ist eine allgemeine Empfehlung schwierig. Viele Prüfungsausschüsse werden wohl den "klassischen" Aufbau der Folien erwarten, also...

Kopf-/Fußzeile mit Unternehmenslogo, Datum, Titel etc.

Folien sollten der Corporate Identity des Ausbildungsbetriebs folgen

ständig sichtbares Inhaltsverzeichnis (als "Fortschrittsbalken")

Stichpunkte als Bullet Points auf den Folien

nicht zu viel Text auf den Folien

Methoden grafisch dargestellt

Ich persönlich vertrete jedoch einen anderen Ansatz, den du dir hier im Detail anschauen kannst: Ideen für moderne Projektpräsentationen.

Literaturempfehlungen

*

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Die 11 häufigsten Fehler in der Projektpräsentation

Ideen für moderne Projektpräsentationen

Weitere Infos zur ProjektpräsentationDu suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.Jetzt anmelden!

In der zehnten Episode meines Anwendungsentwickler-Podcasts beende ich meine Reihe zu häufigen Fragen im Fachgespräch rund um die Objektorientierung mit dem Thema Polymorphie.

Inhalt

Polymorphie (oder auch Polymorphismus) heißt Vielgestaltigkeit.

Polymorphie ist ein Konzept der Objektorientierung, das zwei konkrete Ausprägungen hat:

Variablen können unterschiedliche Datentypen annehmen. Überall wo eine Basisklasse oder ein Interface erwartet wird (Variablen, Parameter usw.), kann auch eine Subklasse bzw. eine implementierende Klasse verwendet werden.

Bei Methoden wird erst zur Laufzeit entschieden, an welchem Datentyp diese aufgerufen werden (dynamisches Binden). Da der konkrete Datentyp zur Laufzeit vom deklarierten Datentyp abweichen kann, ruft die Laufzeitumgebung dynamisch die Methode des konkreten Datentyps auf. Wenn eine mehrstufige Vererbungshierarchie vorliegt, wird die Methode aufgerufen, die in der Hierarchie am weitesten unten liegt.

Beispiel 1: Das Interface Waschbar definiert die Methode wasche(). Die Klasse Reinigung definiert die Methode reinige(Waschbar zuWaschendesObjekt), die die Methode wasche() aufruft. Die Klassen Auto und Hund implementieren Waschbar und können nun beide von der Reinigung gewaschen werden.

Beispiel 2: Die Klasse Tier definiert die Methode gibLaut(). Die Klassen Hund und Katze erben von Tier und implementieren gibLaut() (einmal als "Wuff" und einmal als "Miau"). Die Klasse Labrador erbt von Hund und implementiert gibLaut() nicht erneut. Wenn nun ein Herrchen seinem Tier sagt, es soll Laut geben, dann wird das Tier - je nachdem um welches konkrete Tier es sich handelt - entweder "Wuff" oder "Miau" sagen. Ein Labrador wird "Wuff" sagen, da er die Methode von Hund erbt.

Weiterführende Diskussion

Was ist ein Interface?

Ein Sprachkonstrukt, dass in vielen objektorientierten Sprachen verfügbar ist und quasi eine abstrakte Klasse mit ausschließlich abstrakten Methoden darstellt.

Was ist der Unterschied zwischen einem Interface und einer abstrakten Basisklasse?

In den meisten Sprachen kann man nur von einer Klasse erben, aber mehrere Interfaces implementieren. Abstrakte Basisklassen können zusätzlich zu abstrakten Methoden auch noch Attribute oder implementierte Methoden enthalten.

Wann nutzt man ein Interfaces bzw. eine abstrakte Basisklasse?

Eine abstrakte Klasse sollte verwendet werden, wenn die Implementierung von Methoden wiederverwendet werden kann/soll.

Ein Interface sollte verwendet werden, wenn komplett unterschiedliche Implementierungen (z.B. Sortieralgorithmen) oder sogar unterschiedliche Konzepte (Auto und Hund sind Waschbar) abgebildet werden sollen.

Was ist parametrische Polymorphie (auch Generics)?

Generische Klassen stellen allgemeingültige Algorithmen für mehrere Datentypen bereit. Ein gutes Beispiel sind Listen (List in Java), die nach der Parametrisierung (z.B. List) nur noch (typsicher) mit einem Datentyp arbeiten können.

Tipps für die Programmierpraxis

Immer gegen Abstraktionen, nie gegen Implementierungen programmieren! (Dependency Inversion Principle)

Interfaces den Vorzug geben, da Vererbung eine sehr starke Beziehung ist, die schwer aufzulösen ist.

Häufiges Muster: Abstrakte Klasse, die ein Interface implementiert, vereint die Vorteile beider Konzepte.

Wenn man in einer objektorientierten Sprache switch benutzt, hat man meist etwas falsch gemacht und sollte stattdessen besser Polymorphie einsetzen. (Replace Conditional with Polymorphism)

Literaturempfehlungen

Wie immer der Klassiker für alles rund um Java:

*(direkt beim Rheinwerk-Verlag bestellen*)

Ein sehr gutes Buch rund um die Objektorientierung und gerade auch Polymorphie. Verständlich geschrieben und mit vielen Praxisbeispielen angereichert. Auch wenn der Fokus auf Ruby liegt, empfehle ich das Buch allen Einsteigern in die Objektorientierung.

*

Das Standardwerk rund um das Thema Refactoring. Ein konkretes Refactoring wird oben bereits erwähnt: Replace Conditional with Polymorphism. Viele weitere werden mit Schritt-für-Schritt-Anleitungen in diesem Buch beschrieben.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Anwendungsentwickler-Podcast #2: Häufige Fragen im Fachgespräch – Objektorientierung

Anwendungsentwickler-Podcast #6: Häufige Fragen im Fachgespräch – Kapselung

Anwendungsentwickler-Podcast #8: Häufige Fragen im Fachgespräch – Vererbung

Rheinwerk Computing :: Java ist auch eine Insel – 5.11 Dynamisches Binden

Polymorphism (The Java Tutorials > Learning the Java Language > Interfaces and Inheritance)

Polymorphismus (C#-Programmierhandbuch)

Polymorphie (Programmierung) – Wikipedia

The Dependency Inversion Principle

Why should I prefer composition over inheritance? - Programmers Stack Exchange

Gute Erklärung zu Dependency Injection | Fachinformatiker Anwendungsentwicklung

Replace Conditional with Polymorphism Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden!

In der neunten Episode meines Anwendungsentwickler-Podcasts gebe ich Beispiele für die 17 häufigsten Fehler in der Projektdokumentation und zeige wie man sie vermeiden kann.

Inhalt

Formelle Fehler (leicht/schnell zu korrigieren)

Es sind Rechtschreib-, Interpunktions- und Grammatikfehler vorhanden.

Lasst eure Dokumentation von jemandem (am besten von mehreren Personen) korrekturlesen!

Es sind Rechenfehler vorhanden.

Kontrolliert unbedingt sämtliche Berechnungen (insb. Kosten, Amortisation) auf Fehler.

Es sind keine Quellenangaben vorhanden.

Was ihr euch nicht selbst ausgedacht habt, muss mit Quellen versehen werden.

Die mögliche Seitenzahl wird nicht komplett ausgenutzt.

Nutzt alle erlaubten Seiten bis aufs Letzte aus. Es wäre ärgerlich, wenn ihr eine schlechte Note bekommt, obwohl ihr noch mehr Inhalte hättet zeigen können.

Seiten werden mit uninteressanten Inhalten aufgefüllt.

Packt nur interessante Inhalte (z.B. Quelltexte, Screenshots, Dokumentation) in die Dokumentation und nicht seitenweise langweilige Inhalte.

Verweise auf Artefakte fehlen.

Alle Artefakte (Bilder, Tabellen, Code usw.) müssen im Text referenziert werden.

Fehler in der Nutzwertanalyse.

Achtet auf die formelle Korrektheit der Nutzwertanalyse. Erläutert die Kriterien, die Bewertungsskale und die konkrete Bewertung.

Fachliche Fehler (schwierig/aufwändig zu korrigieren)

Der Wirtschaftlichkeitsteil fehlt.

Eine wirtschaftliche Betrachtung des Projekts ist Pflicht!

Der Technikteil fehlt.

Die Technik sollte den Großteil der Dokumentation füllen.

Die Dokumentation fehlt.

Benutzer- und Entwicklerdokumentation sind absolutes Pflichtprogramm in der Projektdokumentation.

Es sind keine Quelltextbeispiele vorhanden.

Prüfer wollen euren (interessanten!) Quelltext sehen.

Es sind nur langweilige Quelltextbeispiele vorhanden.

Bitte keine Getter/Setter und Klassendefinitionen, sondern spannende Algorithmen zeigen.

Getroffenen Entscheidungen werden nicht begründet.

Insb. die zentralen Entscheidungen (Programmiersprache, Entwicklungsprozess, Datenbank usw.) müssen nachvollziehbar begründet werden.

Es ist kein methodisches Vorgehen erkennbar.

Wir programmieren nicht einfach drauflos, sondern folgen einem definierten Plan und wenden etablierte Methoden (z.B. UML, ERM) an.

Triviale Inhalte werden detailliert ausgeführt.

Bitte nicht eine einfache Berechnung auf drei Seiten bis ins letzte Detail auseinandernehmen, sondern auf einer abstrakteren Ebene euer Projekt und dessen Komponenten schildern.

Das Ziel des Projekts wird nicht deutlich.

Was hat der Prüfling eigentlich selbst gemacht? Warum ist das sinnvoll?

Die notwendige technische Tiefe wird nicht erreicht.

Ist der Umfang des Projekts für ein Abschlussprojekt nach drei Jahren Ausbildung angemessen oder wird nur eine triviale Aufgabe gelöst?

Meine Vorlage für die Projektdokumentation könnt ihr als Grundlage für eure Dokumentation oder als Vergleichsdokument verwenden, um eure Dokumentation auf die obigen Fehler zu prüfen.

Literaturempfehlungen

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Vorlage für die Projektdokumentation

Das komplette Regelwerk der deutschen Rechtschreibung

DIN-konformes Literaturverzeichnis mit LaTeX

Nutzwertanalyse – Wikipedia

Weitere Infos zur ProjektdokumentationDu suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.Jetzt anmelden!

In der achten Episode meines Anwendungsentwickler-Podcasts setze ich meine Reihe der häufigsten Prüfungsfragen im Fachgespräch fort. Das Thema ist dieses Mal die zweite "Säule" der Objektorientierung, die Vererbung.

Beantwortung der Frage im Fachgespräch

Klassen können Attribute und Methoden von anderen Klassen übernehmen, indem sie von ihnen erben.

Die vererbende Klasse heißt Basisklasse (auch Eltern- oder Superklasse) und die erbende Klasse Subklasse (auch Kind- oder abgeleitete Klasse).

Um von einer Klasse zu erben, schreibt man in Java extends und den Namen des Basisklasse hinter die Klassendefinition. In C# wird anstatt extends einfach der Doppelpunkt : verwendet.

Alle Attribute und Methoden der Basisklasse können automatisch in der Subklasse verwendet werden, sofern sie für diese sichtbar sind. Der Sichtbarkeitsmodifizierer protected erlaubt der Klasse selbst und allen Subklassen den Zugriff auf die mit ihm ausgezeichneten Member.

Eine Klasse kann mit abstract als nicht instantiierbar gekennzeichnet werden. Dann können ihre Attribute und Methoden nur über Objekte ihrer Subklassen aufgerufen werden.

Auch eine Methode kann als abstract gekennzeichnet werden. Sie wird dann in der Basisklasse nicht implementiert und muss in den Subklassen implementiert werden. Sobald mind. eine Methode abstrakt ist, muss auch die gesamte Klasse abstrakt sein.

Methoden können in Subklassen überschrieben werden. Das bedeutet, dass in der Subklasse eine Methode mit derselben Signatur (Methodenname und Parameter) wie in der Basisklasse implementiert wird. Beim Aufruf der Methode an einem Objekt der Subklasse wird nun deren Implementierung verwendet anstatt der der Basisklasse.

Java erlaubt standardmäßig das Überschreiben von Methoden, während C# es standardmäßig verbietet. In Java kann man Methoden mit final als nicht überschreibbar kennzeichnen und in C# mit virtual als überschreibbar.

Auch Klassen können als nicht überschreibbar gekennzeichnet werden, was bedeutet, dass man von ihnen nicht erben kann. In Java wird hierfür final verwendet und in C# sealed.

Mit super kann innerhalb der Subklasse auf Member der Basisklasse zugegriffen werden.

In den meisten neueren Programmiersprachen ist es nur möglich, von einer einzigen Klasse zu erben, da die Mehrfachvererbung (die z.B. in C++ erlaubt ist) zu Problemen führen kann (z.B. dem Diamantenproblem).

In Java erben alle Klassen automatisch von Object.

Weiterführende Diskussion

Legt euch ein interessantes Beispiel (bitte nicht das alte Auto/Fahrzeug) für die Vererbung für die Prüfung zurecht.

Was ist die Methodensignatur? (Methodenname und Reihenfolge und Typ der Parameter)

Was ist der Unterschied zwischen dem Überladen und dem Überschreiben von Methoden? (Überschreiben: gleiche Signatur in Subklasse, Überladen: gleicher Name in derselben Klasse)

Was passiert, wenn ich eine private Methode "überschreibe"? (sie wird in der Subklasse "maskiert")

Design Pattern "Template Method" (verwendet final und abstract)

Tipps für die Entwicklerpraxis

Viele Entwurfsmuster verwenden Vererbung.

Vererbung nicht im Sinne der "ist-ein"-Beziehung verstehen, sondern zur reinen Wiederverwendung.

Beim Einsatz von Vererbung immer das Liskov Substitution Principle einhalten. Gegenbeispiel: Ein Quadrat ist kein Rechteck.

"Favor composition over inheritance."

Literaturempfehlungen

*(direkt beim Rheinwerk-Verlag bestellen*)

Das passende Kapitel im OpenBook: 5.8 Vererbung - Rheinwerk Computing :: Java ist auch eine Insel

*

*

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Anwendungsentwickler-Podcast #2: Häufige Fragen im Fachgespräch – Objektorientierung

Anwendungsentwickler-Podcast #6: Häufige Fragen im Fachgespräch – Kapselung

Inheritance (The Java Tutorials > Learning the Java Language > Interfaces and Inheritance)

Rheinwerk Computing :: Java ist auch eine Insel – 5.8 Vererbung

Overriding and Hiding Methods (The Java Tutorials > Learning the Java Language > Interfaces and Inheritance)

Can we override private method in Java - Example program | Java67

The Liskov Substitution Principle

Multiple inheritance: The diamond problem - Wikipedia, the free encyclopedia

Software design pattern - Wikipedia, the free encyclopedia

Template method pattern - Wikipedia, the free encyclopedia Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden!

In der siebten Episode meines Anwendungsentwickler-Podcasts geht es um häufige (aber vermeidbare) Fehler in der Projektpräsentation. Ich gebe 11 Praxisbeispiele für Fehler in der Projektpräsentation und wie Prüflinge es besser machen können.

TL;DR

Aus meinen Erfahrungen als Prüfer zeige ich dir elf häufige Fehler bei der Projektpräsentation und wie du sie vermeidest. Damit dein Projekt auch ohne Vorwissen verständlich wird, gehören die technische Umsetzung und die wirtschaftlichen Ergebnisse in deinen Vortrag, wobei deine Eigenleistung klar erkennbar sein muss. Halte die Unternehmensvorstellung kurz und stelle fachliche Inhalte mit passenden Diagrammen dar. Durch wiederholtes Üben unter Prüfungsbedingungen bereitest du dich darauf vor, verständlich zu sprechen und die vorgesehenen 15 Minuten einzuhalten.

Kapitelmarken

[00:00:00] Einstieg zur Projektpräsentation

[00:00:35] Anlass und Überblick über die elf häufigsten Fehler

[00:01:55] Fehler 1: Das Ausbildungsunternehmen zu ausführlich vorstellen

[00:03:45] Fehler 2: Fachbegriffe verwenden, die du kaum erklären kannst

[00:05:52] Fehler 3: Zu viel Text auf den Folien

[00:07:38] Fehler 4: Den Vortrag zu wenig üben

[00:09:03] Fehler 5: Die vorgesehenen 15 Minuten verfehlen

[00:10:56] Fehler 6: Wichtige Angaben zum Projekt auslassen

[00:12:35] Fehler 7: Die Wirtschaftlichkeit auslassen

[00:14:16] Fehler 8: Die technische Umsetzung kaum zeigen

[00:15:38] Fehler 9: Das methodische Vorgehen auslassen

[00:17:10] Fehler 10: Das gesamte Projekt bleibt unklar

[00:18:25] Fehler 11: Der eigene Anteil bleibt unklar

[00:20:20] Abschluss und Wünsche für die Prüfung

[00:20:50] Shownotes und weiterführende Links

[00:21:03] Feedback und Fragen zum Podcast

Inhalt

Die Vorstellung des Ausbildungsunternehmens ist zu lang und umfangreich.

Es werden Fachbegriffe verwendet, ohne sie zu kennen.

Praxisbeispiel: "XP" -> "Programmieren ohne Regeln".

Prüfling weist in Präsentation explizit auf MVC hin und kann Fragen dazu im Fachgespräch nicht beantworten.

Es wird zu viel Text auf die Folien geschrieben.

Anstatt aussagekräftige Diagramme oder andere Visualisierungen zu nutzen.

Der Vortrag wurde nicht perfekt eingeübt.

Folienübergänge sind stockend oder es werden Inhalte vergessen und später ergänzt.

Bei so einer wichtigen (und auch noch sehr kurzen) Präsentation ist mehrfaches Üben Pflicht.

Die Zeitvorgabe von 15 Minuten wird nicht eingehalten.

Abweichung von 3 Minuten sind schon 20% der Gesamtzeit.

Zu kurz: Verfügbare Möglichkeiten nicht ausgenutzt. Meist fehlen wichtige Inhalte.

Zu lang: Priorisierung des Prüflings mangelhaft. Häufig viel uninteressantes "Gelaber".

Wichtige Informationen zum Projekt werden nicht erwähnt.

Zum Beispiel die verwendete Programmiersprache.

Nicht alle Prüfer im Ausschuss kennen die Dokumentation!

Es wird keine Wirtschaftlichkeitsbetrachtung vorgestellt.

Sie ist ein wichtiger Bestandteil jeder Projektpräsentation!

Es werden keine technischen Details gezeigt.

Wird anscheinend in einigen Unternehmen so gelehrt. Stimmt aber überhaupt nicht.

Es werden keine angewendeten Methoden gezeigt.

Der Prüfling muss zeigen, dass er methodisch vorgegangen ist und nicht einfach "irgendwie" entwickelt hat.

Das Projektziel wird nicht deutlich.

Das zentrale Thema des Projekts wird nicht klar herausgestellt. Was wurde eigentlich umgesetzt?

Der Eigenanteil des Prüflings wird nicht deutlich.

Hat der Prüfling überhaupt etwas Anspruchsvolles umgesetzt?

Ich kann nur allen Prüflingen empfehlen, sich einmal näher mit "Presentation Zen" auseinanderzusetzen. Hier ist ein tolles (und kurzes) Video von Garr Reynolds zum Thema:

Ein schönes Beispiel für eine in Anlehnung an Presentation Zen gestaltete Projektpräsentation gibt es hier:

Literaturempfehlungen

Nachfolgend einige sehr gute Literaturempfehlungen zur Präsentationsgestaltung. Ich habe alle Bücher selbst gelesen und kann sie absolut empfehlen. "Presentation Zen" ist mehr eine allgemeine Einführung ins Thema als eine Sammlung konkreter Tipps. Die anderen Bücher enthalten aber von der Farbgestaltung und Typographie über das Layout bis hin zum Einsatz von Bildern direkt umsetzbare Hinweise zur besseren Foliengestaltung.

*

*

*

*

*

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Mein Vortrag zum Thema "Tod durch PowerPoint" (mit Handout zum Thema Präsentationsgestaltung)

Projektpräsentation von Gerda Feldhaus (mit 100% bewertet) (als positives Beispiel)

Abschlusspräsentation im Stil von Presentation Zen (Diskussion bei fachinformatiker.de)

Weitere Infos zur ProjektpräsentationDu suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.Jetzt anmelden!

Zusammenfassung

Elf häufige Fehler bei der Projektpräsentation

Aus meinen Erfahrungen als Prüfer gebe ich dir Hinweise, wie du als IT-Azubi deine Projektpräsentation vorbereitest. Die Beispiele stammen aus Prüfungen zum/zur Fachinformatiker:in; die Aufnahme entstand im April 2015 und bezieht sich auf einen Vortrag von 15 Minuten.

1. Das Ausbildungsunternehmen zu ausführlich vorstellen

Für das Unternehmen empfehle ich dir ein bis zwei Folien, auf denen du das Umfeld deines Projekts beschreibst. Eine ausführliche Unternehmensgeschichte oder sämtliche Standorte nehmen Zeit in Anspruch, die du für deine eigene Arbeit brauchst. Bei einer Unternehmensvorstellung von drei Minuten ist bereits ein Fünftel deiner Vortragszeit vergangen.

2. Fachbegriffe verwenden, die du kaum erklären kannst

Wenn du einen Fachbegriff erwähnst, solltest du ihn verstehen und Fragen dazu beantworten können. Mit den Begriffen aus deinem Vortrag beeinflusst du, welche Themen die Prüfer:innen im Fachgespräch aufgreifen.

In einer meiner Prüfungen kündigte ein:e Prüfungsteilnehmer:in ausdrücklich Fragen zum verwendeten MVC-Muster an, konnte anschließend aber kaum mehr als die Abkürzung erklären. Bei einem anderen Projekt wurde Extreme Programming als regelloses Programmieren beschrieben. Zu diesem Konzept gehören festgelegte Praktiken und Werte, mit denen du dich vor einer solchen Aussage beschäftigen musst.

3. Zu viel Text auf die Folien schreiben

Durch passende Diagramme kannst du fachliche Zusammenhänge anschaulich zeigen. Für eine Datenbank eignet sich beispielsweise ein ER-Modell; Klassen und ihre Beziehungen lassen sich in einem Klassendiagramm darstellen. Auch ein Use-Case-Diagramm kann Inhalte deines Projekts verständlich machen.

Beschränke den Text auf deinen Folien, damit die Prüfer:innen deinem Vortrag folgen können. Umfangreiche Texte vorzulesen beansprucht einen großen Teil der verfügbaren Zeit. Wähle Grafiken passend zum Inhalt und halte die Folien frei von überflüssigen Animationen.

4. Den Vortrag zu wenig üben

Ich empfehle dir, deinen Vortrag zehn bis zwanzig Mal laut zu halten. Stell dich dafür mit einem Presenter in einen Raum und arbeite möglichst mit einem Beamer, damit du unter ähnlichen Bedingungen wie in der Prüfung übst.

Dabei kannst du prüfen, ob die Grafiken lesbar sind und die Folienübergänge passen. Wenn du den Ablauf gut kennst, sinkt das Risiko, durch Nervosität den Faden zu verlieren. Miss beim Üben auch die Zeit.

5. Die vorgesehenen 15 Minuten verfehlen

Richte deine Inhalte auf die vorgegebene Dauer aus. Schon drei Minuten Abweichung entsprechen bei diesem Zeitrahmen 20 Prozent.

Wenn dein Vortrag deutlich früher endet, bleibt Zeit für bewertbare Inhalte unbesetzt. Du könntest darin beispielsweise ein relevantes Quelltextbeispiel erläutern. Bei einem zu langen Vortrag stellt sich die Frage, ob du deine Inhalte angemessen gewichtet hast. Durch wiederholte Probeläufe findest du heraus, welche Inhalte in die 15 Minuten passen.

6. Wichtige Angaben zum Projekt auslassen

Gehe davon aus, dass einzelne Prüfer:innen deine Dokumentation noch nicht gelesen haben. In vielen Prüfungsausschüssen wird das Lesen der Dokumentationen aufgeteilt, sodass dein Vortrag eigenständig verständlich sein muss.

Beschreibe das Problem, das du bearbeitet hast, und erläutere dein Ergebnis. Zur technischen Einordnung gehören die verwendete Programmiersprache sowie die Architektur und gegebenenfalls eingesetzte Frameworks. Die Prüfer:innen bringen technisches Fachwissen mit, brauchen aber die konkreten Angaben zu deinem Projekt.

7. Die Wirtschaftlichkeit auslassen

Als Fachinformatiker:in arbeitest du in einem Beruf mit wirtschaftlichem Bezug. Zeige deshalb, welche Kosten dein Projekt verursacht hat und wie du diese berechnet hast. Erläutere auch die erwarteten Einsparungen und wann sich die Kosten dadurch ausgleichen.

Dafür können zwei bis drei Folien ausreichen. Deine Berechnungen müssen nachvollziehbar machen, weshalb sich das Projekt für das Unternehmen lohnt.

8. Die technische Umsetzung kaum zeigen

Zur Prüfung in der Anwendungsentwicklung gehört, dass du deine technische Arbeit sichtbar machst. Beschreibe, wie die Software aufgebaut ist und wie du sie umgesetzt hast.

Mit UML-Diagrammen oder einem ER-Modell kannst du passende Ausschnitte zeigen. Auch Ablaufdiagramme kommen dafür infrage. Die Prüfer:innen sollen erkennen können, welche technischen Aufgaben du bearbeitet hast.

9. Das methodische Vorgehen auslassen

Zeige anhand deines Projekts, wie du Software systematisch entwickelst und dabei Qualität sicherst. Dazu gehören beispielsweise dein Projektplan und die Analysephase.

Für die fachlichen Schritte kannst du eine objektorientierte Analyse erläutern oder zeigen, wie du beim Datenbankentwurf normalisiert hast. Mit einem passenden Diagramm wird sichtbar, dass du Methoden aus der Ausbildung auf ein Praxisprojekt übertragen kannst.

10....

In der sechsten Episode meines Anwendungsentwickler-Podcasts setze ich meine Reihe über häufige Fragen im Fachgespräch fort. Dieses Mal geht es um die Kapselung im Rahmen der Objektorientierung.

Beantwortung der Frage im Fachgespräch

Objekte bilden Dinge der realen Welt ab. Sie haben Eigenschaften und Funktionen. Beispiel: Person mit Eigenschaft Geburtstag und Funktion gruesse().

In der Objektorientierung nennt man die Eigenschaften Attribute und die Funktionen Methoden.

Klassen sind Baupläne für Objekte. Sie definieren, welche Attribute und Methoden jede Instanz der Klasse - das Objekt - hat. Die konkreten Ausprägungen der Werte der Attribute - der Zustand des Objekts - kann (muss aber nicht) bei jedem Objekt unterschiedlich sein.

Objekte müssen zu jeder Zeit in einem gültigen Zustand sein, d.h. die Attribute müssen gültige Werte haben.

Jedes Objekt ist dafür verantwortlich, seinen gültigen Zustand beizubehalten. Daher muss es den Zugriff auf seine Attribute einschränken können.

Außerdem sollte ein Objekt nicht nach außen hin preisgeben, wie es funktioniert, sondern nur, was es macht.

Dieses Prinzip wird auch Geheimnisprinzip genannt.

Um den Zugriff auf Attribute und Methoden zu steuern, können Sichtbarkeitsmodifizierer verwendet werden.

private = nur die Klasse selbst hat Zugriff, protected = die Klasse selbst und von ihr abgeleitete Klassen haben Zugriff, public = alle haben Zugriff.

Der Zugriff auf Attribute von außen sollte ausschließlich über spezielle Methoden - Getter und Setter - möglich sein.

Setter erlauben die Prüfung der zu setzenden Werte und sorgen damit dafür, dass das Objekt immer in einem gültigen Zustand ist. Beispiel: Geburtsdatum wird vor dem Setzen auf ein gültiges Datum ab 01.01.1900 geprüft.

Getter erlauben die Berechnung von Werten, anstatt sie in Attributen abzulegen. Beispiel: Alter einer Person wird zur Laufzeit anhand des Attributs Geburtsdatum ermittelt.

Tiefergehende Diskussion

In Java gibt es noch den Sichtbarkeitsmodifizierer package-private (kein expliziter Modifizierer angegeben) = nur die Klasse selbst und Klassen im gleichen Package haben Zugriff.

Objekte kapseln Attribute und die zugehörigen Methoden, d.h. die Methoden sollten die Attribute verwenden.

Optimalerweise verwenden alle Methoden einer Klasse alle Attribute der Klasse. Man spricht dann von einer hohen Kohäsion.

Dieses Prinzip wird auch Single Responsibility Principle genannt: "There should never be more than one reason for a class to change."

Im Vergleich zur prozeduralen Programmierung hat die Kapselung von Attributen und den zugehörigen Methoden den Vorteil der besseren Wiederverwendbarkeit. Eine Klasse kann als Ganzes (wie eine Kapsel) verwendet werden.

Tipps für die Entwicklerpraxis

Daumenregel: Alle Attribute private machen.

Auch wenn es ggfs. nicht nötig ist, die Sichtbarkeitsmodifizierer immer explizit angeben, damit der Code leichter zu verstehen ist.

Getter und Setter erst einführen, wenn sie wirklich benötigt werden (YAGNI).

Getter und Setter können von der meisten IDEs generiert werden.

In C# werden anstatt Gettern und Settern Eigenschaften (Properties) verwendet.

Literaturempfehlungen

*(direkt beim Rheinwerk-Verlag bestellen*)

Das passende Kapitel im OpenBook: 9 Grundlagen der Programmierung - Rheinwerk Computing :: IT-Handbuch für Fachinformatiker

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Anwendungsentwickler-Podcast #2: Häufige Fragen im Fachgespräch – Objektorientierung

You Aren't Gonna Need It

Cohesion metrics

SRP: The Single Responsibility Principle

Datenkapselung (Programmierung)

Eigenschaften (C#-Programmierhandbuch)

Create Getters and Setters - Eclipse Platform Weitere Infos zum FachgesprächDu suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.Jetzt anmelden!

In der fünften Episode meines Anwendungsentwickler-Podcasts geht es um die Bewerbung nach der Ausbildung. Einige Azubis wechseln nach der Ausbildung aus verschiedenen Gründen den Arbeitgeber und brauchen vielleicht ein paar Tipps für die Inhalte der Bewerbung.

Stellensuche

Persönliche Kontakte - z.B. bei lokalen User Groups (siehe Softwareentwickler-Stammtisch).

Lokale Tageszeitungen - für den lokalen Mittelstand häufig immer noch am wichtigsten.

Job-Boards wie monster.de.

Soziale Netzwerke wie Xing.

Überregionale Zeitungen mit Stellenanzeigen.

Fachzeitschriften wie c't und iX.

Inhalte der Bewerbung

Anschreiben

Maximal eine Seite lang.

Speziell zugeschnitten auf das Unternehmen: Was könnt ihr eurem neuen Arbeitgeber bieten?

Keine allgemeinen Floskeln, sondern konkreten Bezug zu den Anforderungen.

Keine Massenabfertigung mit falschen Ansprechpartnern usw.

Am besten vorher Telefonkontakt suchen und direkt den richtigen Ansprechpartner adressieren.

Auf spezielle Anforderungen des Unternehmens (z.B. frühesten Eintrittstermin oder Gehaltsvorstellung) eingehen.

Lebenslauf

Bild nicht vergessen (wichtig für den ersten Eindruck).

Die Grundschulbildung interessiert niemanden (mehr).

Praxis auflisten (z.B. Open Source, Vorträge, Artikel).

Hobbys: Können positiv und negativ bewertet werden (z.B. Fußball => Teamfähigkeit aber auch Verletzungsgefahr, Lesen => Weiterbildung aber auch Klischee).

Resume

Verantwortlichkeiten und insb. Ergebnisse auflisten.

Konkrete Projekte/Technologien erwähnen.

Es sollte eine Verbesserung im Laufe der Zeit erkennbar sein.

IHK-Zeugnis

Sollte heutzutage schon eine (sehr) gute Abschlussnote enthalten.

Arbeitszeugnisse

Wichtiger als IHK-Zeugnis.

Zertifikate

Wenn vorhanden, unbedingt anfügen.

Weisen eigenen Lernwillen nach, weniger technische Skills.

Machen evtl. den Unterschied bei ansonsten gleichen Qualifikationen.

Tipps zur Bewerbung

Jemanden korrekturlesen lassen. Fehler eliminieren.

Sämtliche Kontaktdaten müssen auf allen Seiten direkt sichtbar sein.

Keine Lücken im Lebenslauf entstehen lassen. Das wirkt sofort suspekt.

Ein einziges PDF-Dokument erstellen! Nicht zerstückeln oder Word-/JPG-Dateien verschicken.

Nicht zu große Dateien versenden, aber auch keine unleserlich komprimierten.

Eingescannte Dokumente optimieren (z.B. begradigen, Tonwertkorrektur, schwarze Bereiche entfernen).

Seriöse E-Mail-Adresse verwenden.

Außergewöhnliche Designs sind ansprechend, aber nicht jeder beherrscht das.

Eigenen Online-Auftritt prüfen und ggfs. optimieren.

Evtl. auf eigene Website/Github/Xing verweisen, wenn dort interessante Inhalte geboten werden.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

How to Prepare Your Resume (Your Resume Stinks!)

Bewerbungsanschreiben Muster: Die besten Tipps & Beispiele

Bewerbungsmappen-Check: Das muss in die Bewerbung

Bewerbung: Alle Tipps zur perfekten Bewerbung

10 Tipps für Ihre XING-Profiloptimierung

Die Sache mit dem Arbeitszeugnis

LaTeX und der Lebenslauf mit moderncv

Bewerbungsvorlagen

In der vierten Episode meines Anwendungsentwickler-Podcasts geht es um die optimale Vorbereitung auf die schriftliche Abschlussprüfung der IHK.

Während der Ausbildung

Möglichst früh anfangen zu lernen. Die Inhalte sollen ja dauerhaft hängen bleiben und nicht nach der Prüfung wieder verschwunden sein.

Regelmäßig Lernzielkontrollen mit der/dem Ausbilder/in durchführen. Sie/er sollte am besten bewerten können, ob das Wissen in der notwendigen Tiefe vorhanden ist.

Zusätzlich bei allen Fragen die/den Ausbilder/in ansprechen. Ihr/sein Feedback und die Erklärungen helfen am besten beim Verständnis.

Andere Kollegen oder Mitazubis (am besten aus höheren Jahrgängen) können die Inhalte noch einmal anders formulieren oder erklären. Das hilft beim Verständnis.

Wenn all das nicht möglich ist, helfen Foren wie fachinformatiker.de.

Wenn auch das nicht hilft, könnt ihr gerne auch mir Fragen stellen, die ich dann im Podcast beantworte.

Inhalte

In GH1 sind klassischerweise UML, Algorithmen, SQL, Datenbankmodellierung und Projektmanagement vertreten.

UML: Use Case-, Klassen-, Aktivitäts-, Sequenz-, Zustandsdiagramme

DB: ERM, Tabellenmodell

Algorithmen: Struktogramme, Pseudocode

In GH2 kann so ziemlich alles drankommen, was irgendetwas mit IT zu tun hat. Häufig Englisch, Rechnungswesen, Projektmanagement, Verkabelung, Hype-Themen (Cloud usw.)

Im WiSo-Teil wiederholen sich häufig die Fragen der letzten Jahre. Zusätzlich können aktuelle Entwicklung im Bereich Arbeitsrecht usw. dazukommen.

Richtig üben

Von Anfang an unter Zeitdruck üben und versuchen, die Prüfungen in 90 bzw. 60 Minuten zu lösen.

Schnell entscheiden, welche Frage gestrichen werden soll.

Kurz und prägnant antworten.

Syntax bei Diagrammen exakt einhalten und nicht einfach runtermalen (Zeitverbrauch ist sonst nicht aussagekräftig).

Den Wirtschaftsteil nicht vergessen!

Tipps

Textaufgaben streichen. Sie dauern lange und man weiß häufig nicht genau, was als Antwort erwartet wird.

Kurz fassen, nicht schwafeln. Viel Inhalt in kurze Sätze packen.

Bei Algorithmen nie Struktogramme zeichnen, sondern immer Pseudocode verwenden. Diagramme dauern länger und sind nur umständlich zu korrigieren.

Diagramme ggfs. detaillierter als nötig zeichnen, da die Punktevergabe nicht immer durch die IHK vorgegeben ist und so evtl. noch zusätzlich Punkte herausgeholt werden können.

Bei SQL zuerst alle Tabellen und Spalten in der richtigen Reihenfolge aufschreiben. Das gibt meist schon einen Großteil der Punkte.

Bei SQL die JOIN-Syntax verwenden und nicht WHERE, da erstere leichter ergänzt und korrigiert werden kann.

Keine Angst vor Hype-Themen. Sie dienen meist nur als Aufhänger für althergebrachte Aufgaben wie Rechnungswesen.

Literaturempfehlungen

Am besten lernt man mit den alten Abschlussprüfungen. Die gibt es für 12 Euro beim U-Form-Verlag. Achtung: Sie enthalten keine Lösungen (außer für WiSo).

Sehr gut sind auch die Prüfungstrainer*, die neben den Aufgaben auch die Lösungen und vor allem Erklärungen dazu enthalten.

*

Beides zusammen gibt es auch im All Inclusive PLUS Paket Abschlussprüfung*.

*

Die wichtigsten Fakten und alle Lerninhalte für die Prüfung stehen im IT-Handbuch*. Es war bis vor Kurzem sogar noch als Hilfsmittel in der Abschlussprüfung zugelassen. Was dort nicht drin steht, gibt es nicht in der Prüfung ;-)

*

Das Standardwerk zur Begleitung der Ausbildung, das ich meinen Azubis empfehle, ist das Handbuch für Fachinformatiker*. Mit über 1.000 Seiten ist es aber weniger für das schnelle Lernen, sondern mehr als Begleitlektüre für die gesamte Ausbildung gedacht. Also (wie oben erwähnt) früh anfangen!

*(direkt beim Rheinwerk-Verlag bestellen*)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

fachinformatiker.de - Forum für IT-Berufe

Weitere Hilfen zur IHK-PrüfungDu suchst noch mehr Tipps rund um die Vorbereitung auf die schriftliche IHK-Prüfung? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die schriftliche IHK-Prüfung.Und kennst du schon meine Übungsaufgaben für die Abschlussprüfung? Unter dieperfekteihkpruefung.de kannst du sie herunterladen.