10 Fragen im Fachgespräch für Anwendungsentwickler
DAS WICHTIGSTE IN KÜRZE
- Das Fachgespräch folgt direkt auf deine Projektpräsentation und dauert in der Regel maximal 15 Minuten. Präsentation und Fachgespräch zusammen sind auf 30 Minuten begrenzt.
- Präsentation und Fachgespräch machen zusammen 50 % der Bewertung des Prüfungsbereichs „Entwicklung und Umsetzung von Anwendungen“ aus – die andere Hälfte ist die betriebliche Projektarbeit inklusive Dokumentation.
- Gefragt wird zu Vorgehensweise, Wirtschaftlichkeit, Qualitätssicherung, Datenschutz, Datensicherung, IT-Sicherheit, Frameworks und Programmiersprachen – meist ausgehend von deiner Dokumentation.
- Die häufigste Punktequelle: Fachbegriffe, die du in der Doku verwendest, aber nicht an einem eigenen Beispiel erklären kannst.
- Beste Vorbereitung: mit dem Ausbilder üben, mit anderen Azubis üben, KI zur Simulation nutzen – und mindestens einmal unter echten Zeitbedingungen durchspielen.
10 FRAGEN AUS DEM FACHGESPRÄCH FÜR ANWENDUNGSENTWICKLER
WAS IST DAS FACHGESPRÄCH – UND WIE LÄUFT ES AB?
WER SITZT DIR GEGENÜBER?
WIE LANGE DAUERT DAS FACHGESPRÄCH?
WORAUF ACHTEN DIE PRÜFER BEI DER BEWERTUNG?
Bewertungsdimension | Was das konkret heißt |
Fachliche Tiefe | Du erklärst Begriffe nicht nur, du ordnest sie ein und kennst Alternativen. |
Projektbezug | Zu jeder Theorie folgt ein Beispiel aus deinem eigenen Projekt. |
Begründungskompetenz | Du erklärst nicht nur was du gemacht hast, sondern warum – inklusive verworfener Alternativen. |
Wirtschaftliches Denken | Kosten, Nutzen, Aufwand und Verhältnismäßigkeit tauchen in deinen Antworten auf. |
Souveränität | Du bleibst bei Rückfragen ruhig, gibst Wissenslücken offen zu und rechtfertigst dich nicht. |
DAS WICHTIGSTE IN KÜRZE
Die folgenden zehn Fragen tauchen in Prüfungsprotokollen und Erfahrungsberichten immer wieder auf. Formuliere deine Antworten nicht auswendig – bereite stattdessen zu jeder Frage ein konkretes Beispiel aus deinem Projekt vor. Genau das unterscheidet eine 2 von einer 4.
FRAGE 1: „ERKLÄR UNS BITTE DAS MVC-MODELL.“
Eine Klassikerfrage – besonders wenn du eine Webanwendung entwickelt hast und der Begriff MVC in deiner Dokumentation auftaucht. Den Prüfern geht es nicht darum, ob du die drei Buchstaben kennst. Sie wollen sehen, dass du das Prinzip der Trennung von Zuständigkeiten (Separation of Concerns) verstanden hast.
Das wollen die Prüfer hören:
- Was Model, View und Controller jeweils verantworten – und wie sie zusammenspielen.
- Warum die Trennung sinnvoll ist: Wartbarkeit, Testbarkeit, Wiederverwendbarkeit, Arbeitsteilung im Team.
- Wo genau du MVC in deinem Projekt eingesetzt hast – welche Klasse war Model, welche View?
Antwort-Einstieg: „MVC trennt die Anwendung in drei Verantwortungsbereiche. In meinem Projekt war das Model die Klasse Ticket zusammen mit dem Repository für den Datenbankzugriff, der Controller hat die Anfragen entgegengenommen und validiert, und die View war das Blade-Template für die Ticketübersicht. Der Vorteil war konkret: Als sich das Layout geändert hat, musste ich nur die View anfassen – die Geschäftslogik blieb unberührt.“
No-Gos: Definitionen aufsagen, ohne ein Beispiel zu nennen. Oder die drei Schichten benennen, aber nicht erklären können, wie sie zusammenarbeiten. Das wirkt auswendig gelernt – und Prüfer erkennen das sofort an der ersten Rückfrage.
Wenn du nicht weiterkommst: Denk an dein eigenes Projekt zurück. Wo hast du MVC eingesetzt? Was war bei dir das Model, was die View? Dein Projekt ist immer der sichere Anker.
FRAGE 2: „WAS SIND DIE VIER SÄULEN DER OBJEKTORIENTIERUNG?“
Fragen zu Klassen und Objekten kommen in fast jedem Fachgespräch für Anwendungsentwickler vor. Die vier Säulen sind Kapselung, Vererbung, Polymorphie und Abstraktion.
Das wollen die Prüfer hören: Nicht nur die Definitionen, sondern den Nutzen. Warum kapselst du Attribute? Was gewinnst du durch Vererbung – und wo wird sie zum Problem? Beginne mit dem Prinzip, das du am sichersten beherrschst und für das du einen echten Anwendungsfall im Projekt nennen kannst. Du musst nicht zu jeder Säule ein Projektbeispiel haben, aber erklären können musst du alle vier.
Antwort-Einstieg: „Am deutlichsten war bei mir die Kapselung: Die Klasse Benutzer hat das Passwort-Attribut privat gehalten, gesetzt wurde es nur über eine Methode, die direkt hasht. So kann kein anderer Programmteil versehentlich ein Klartextpasswort schreiben. Die anderen drei Säulen sind …“
No-Gos: Polymorphie und Vererbung in einen Topf werfen. Oder Abstraktion nur als „man lässt Details weg“ beschreiben, ohne den Bezug zu abstrakten Klassen und Interfaces herzustellen.
FRAGE 3: „WAS SIND VOR- UND NACHTEILE VON NOSQL-DATENBANKEN GEGENÜBER RELATIONALEN DATENBANKEN?“
Diese Frage kommt fast immer, wenn du irgendeine Datenbank eingesetzt hast – egal welche. Die Prüfer wollen wissen, ob du eine bewusste Entscheidung getroffen hast oder einfach das genommen hast, was im Betrieb schon lief.
Vorteile von NoSQL | Nachteile von NoSQL |
Hohe Skalierbarkeit, gut für sehr große Datenmengen | Kein einheitlicher Abfragestandard wie SQL |
Flexibles Schema – neue Datenfelder ohne Migration | Eingeschränkte Transaktionssicherheit (ACID) |
Gut für unstrukturierte Daten, z. B. JSON-Dokumente | Datenredundanz durch Mehrfachspeicherung |
Horizontale Verteilung über mehrere Knoten | Konsistenz oft nur „eventually“ garantiert |
So punktest du: Nenne mindestens drei Vor- und drei Nachteile und begründe, warum du dich in deinem Projekt so entschieden hast. Auch „Wir haben MySQL genommen, weil die Daten stark relational verknüpft waren und wir Transaktionssicherheit bei der Buchung gebraucht haben“ ist eine sehr gute Antwort.
No-Gos: NoSQL pauschal als „moderner“ und relationale Datenbanken als „veraltet“ darstellen. Und: Nicht erklären können, wofür das Akronym ACID steht, wenn du es selbst ins Spiel bringst.
FRAGE 4: „WARUM WURDE DIE SOFTWARE SELBST PROGRAMMIERT UND KEINE FERTIGE LÖSUNG EINGEKAUFT?“
Diese Frage hat zwei Seiten. Erstens wollen die Prüfer wissen, ob du wirtschaftlich denken kannst: Hast du überhaupt geprüft, ob es eine Fertiglösung gibt?
Zweitens setzen sie dich bewusst leicht unter Druck – die Frage klingt oft so, als wäre die Eigenentwicklung von vornherein falsch gewesen. Bleib ruhig, das ist Teil der Prüfung.
Das wollen die Prüfer hören:
- Welche konkreten Fertiglösungen du dir angeschaut hast – mit Namen.
- Warum sie nicht gepasst haben: Lizenzkosten, Anpassungsaufwand, fehlende Schnittstellen, zu hohe Komplexität für den tatsächlichen Bedarf.
- Den konkreten Mehrwert der Eigenentwicklung für den Betrieb – idealerweise mit einer Zahl aus deiner Wirtschaftlichkeitsbetrachtung (Amortisationsdauer, eingesparte Arbeitszeit).
Antwort-Einstieg: „Wir haben uns im Vorfeld verschiedene Lösungen angeschaut …“ – und dann erklärst du, warum die Eigenentwicklung am Ende die sinnvollere Wahl war, zum Beispiel weil Datenschutzanforderungen, IT-Sicherheit oder unternehmensspezifische Prozesse abgedeckt werden mussten.
No-Gos:
„Wir haben keine Fertiglösung gesucht.“ – Für Prüfer das klare Signal, dass kein wirtschaftliches Denken stattgefunden hat.
- Defensiv antworten, als müsstest du dich für einen Fehler rechtfertigen. Du begründest eine Entscheidung, du entschuldigst dich nicht.
- Behaupten, es gäbe am Markt gar keine Fertiglösung – das ist bei den meisten Projekten unglaubwürdig, und es wird nachgehakt.
- Rein technisch argumentieren. Die Frage zielt bewusst auf Kosten, Nutzen und Verhältnismäßigkeit.
FRAGE 5: „WIE WURDE IM PROJEKT GETESTET BZW. DIE QUALITÄT GESICHERT?“
Qualitätssicherung ist einer der Bereiche, in denen sich Prüflinge am leichtesten von der Masse abheben – weil so viele hier nur „Ich hab’s durchgeklickt“ sagen.
Das wollen die Prüfer hören:
- Die eingesetzten Teststufen: Unit-Tests für einzelne Funktionen, Integrationstests für das Zusammenspiel von Komponenten, manuelle Oberflächen- oder Abnahmetests.
- Die verwendeten Tools und warum: JUnit, PHPUnit, Jest, Selenium, Postman.
- Wie du mit gefundenen Fehlern umgegangen bist: Fehlerliste, Issue-Tracking, Definition of Done.
- Dass Qualitätssicherung ein kontinuierlicher Prozess ist und nicht eine Aktion am Projektende.
No-Gos: Testen und Debuggen gleichsetzen – Debugging beseitigt bekannte Fehler, Testen deckt unbekannte auf. Umfangreiche automatisierte Tests behaupten, die es nicht gab: Es wird nach Testabdeckung, Testfällen und Ergebnissen gefragt. Und Qualitätssicherung auf Testen zu reduzieren – Code-Reviews, Pair Programming, statische Codeanalyse und definierte Akzeptanzkriterien gehören ebenso dazu.
Wenn du nicht weiterkommst: Hast du einzelne Funktionen ausprobiert? Testdaten eingegeben und geschaut, was passiert? Jemanden drüberschauen lassen? Das alles ist Qualitätssicherung – du musst es nur strukturiert beschreiben.
Selbst wenn dein Testkonzept nicht perfekt war: Ehrlich sagen, was du gemacht hast und was du beim nächsten Mal anders machen würdest, ist eine starke Antwort.
FRAGE 6: „WAR DATENSCHUTZ RELEVANT? WENN JA, WIE WURDE ER GEWÄHRLEISTET?“
Diese Frage wird von erschreckend vielen Prüflingen unterschätzt oder komplett vergessen. Dabei kommt sie fast immer – Datenschutz ist gesetzlich vorgeschrieben, und die Prüfer müssen ihn abfragen.
Das wollen die Prüfer hören:
- Welche personenbezogenen Daten verarbeitet deine Anwendung?
- Wie ist der Zugriff geregelt?
- Und vor allem: mindestens eine konkrete technische Schutzmaßnahme aus deinem Projekt – Passwort-Hashing mit bcrypt oder Argon2, ein Rollen- und Rechtekonzept, Transportverschlüsselung, Pseudonymisierung, Löschkonzept, Datensparsamkeit.
No-Gos: „Das war eine interne Anwendung, also war kein Datenschutz nötig.“ Das ist falsch – auch interne Anwendungen verarbeiten regelmäßig personenbezogene Daten von Mitarbeitenden. Und: Datenschutz und IT-Sicherheit nicht verwechseln. Datenschutz ist rechtlich und schützt Personen, IT-Sicherheit ist technisch und schützt Systeme.
Wenn du nicht weiterkommst: Geh dein Projekt gedanklich durch. Gibt es einen Login? Werden Namen, E-Mail-Adressen oder andere Nutzerdaten gespeichert? Was passiert mit diesen Daten? Fang dort an – der Rest entwickelt sich im Gespräch.
FRAGE 7: „GIBT ES EIN DATENSICHERUNGSKONZEPT?“
Das wollen die Prüfer hören:
- Ob und wie Datensicherung in deinem Projekt eine Rolle gespielt hat – auch eine einfache Lösung zählt, wenn du sie konkret benennst.
- Die vier Kernfragen jedes Sicherungskonzepts: Was wird gesichert? Wie oft? Wo liegt die Sicherung? Wie wird wiederhergestellt?
- Die Sicherungsarten und ihre Vor- und Nachteile: Vollsicherung (einfach wiederherzustellen, hoher Speicherbedarf), differenzielle Sicherung (Wiederherstellung aus zwei Sätzen), inkrementelle Sicherung (sparsam, aber Wiederherstellung über die gesamte Kette).
- Die Einordnung über das Projekt hinaus: Warum ist Datensicherung für Unternehmen geschäftskritisch?
No-Gos: Sagen, Datensicherung sei „bei so einem kleinen Projekt nicht nötig“ gewesen. Datensicherung und Datenschutz verwechseln – Datensicherung schützt vor Datenverlust, Datenschutz vor unbefugtem Zugriff. Und: die Wiederherstellung vergessen. Eine Sicherung, die sich nicht zurückspielen lässt, ist wertlos, und genau da wird gerne nachgefragt.
Wenn du nicht weiterkommst: Stell dir die einfachste Frage – was würde passieren, wenn die Datenbank deines Projekts heute Nacht verloren geht? Wäre alles weg, oder gibt es eine Sicherung? Wie würdest du wiederherstellen? Diese Gedankenübung bringt dich direkt zu einer praxisnahen Antwort.
FRAGE 8: „WELCHE MASSNAHMEN WURDEN IN BEZUG AUF IT-SICHERHEIT GETROFFEN?“
Das wollen die Prüfer hören:
- Konkrete technische Maßnahmen aus deinem Projekt: Input-Validierung, Prepared Statements gegen SQL-Injection, HTTPS, sichere Session-Verwaltung, Output-Encoding.
- Die Unterscheidung der Ebenen – Anwendung, Datenbank, Netzwerk – und auf welcher du aktiv geworden bist.
- Typische Angriffsvektoren, die du kennst: SQL-Injection, Cross-Site-Scripting (XSS), Cross-Site-Request-Forgery (CSRF), unsichere Passwortspeicherung.
- Ehrlichkeit, wenn etwas im Projektzeitraum nicht umsetzbar war – plus die Aussage, was du als Nächstes angehen würdest.
No-Gos: IT-Sicherheit mit Datenschutz gleichsetzen. Sagen, es seien keine Maßnahmen nötig gewesen, weil es „nur ein internes Projekt“ war. Maßnahmen aufzählen, die du gar nicht umgesetzt hast. Und Authentifizierung und Autorisierung vergessen – wer darf was in deiner Anwendung tun, ist IT-Sicherheit in der Praxis.
Wenn du nicht weiterkommst: Geh deine Anwendung von außen nach innen durch. Was sieht ein Nutzer? Was kann er eingeben? Was passiert mit dieser Eingabe bis in die Datenbank? Allein dieser Gedankengang führt dich zu Input-Validierung und SQL-Injection-Schutz – zwei Maßnahmen, die du fast immer nennen kannst.
FRAGE 9: „WELCHE FRAMEWORKS WURDEN VERWENDET UND WARUM?“
Das wollen die Prüfer hören:
Nenne die eingesetzten Frameworks mit vollständigem Namen und erkläre kurz, wofür sie zuständig sind – Frontend, Backend, Testing, ORM. Begründe die Auswahl sachlich: Verbreitung in der Branche, Kompatibilität mit der gewählten Sprache, vorhandenes Know-how im Team, Support-Zeitraum, spezifische Funktionen, die das Projekt gebraucht hat. Geh dabei auch auf Kosten und Nutzen ein – Lizenzmodell, Einarbeitungszeit, langfristige Wartbarkeit. Stark wirkt außerdem, wenn du die Grenzen deines Frameworks kennst. Kein Werkzeug ist für alles die beste Lösung, und genau diese Einschätzung schätzen Prüfer.
No-Gos:
- „Wir haben React genommen, weil es modern ist.“ – Modern ist kein Kriterium.
- Frameworks nennen, über die du kaum etwas weißt. Wer Bootstrap erwähnt, muss erklären können, was es tut.
- Den Unterschied zwischen Framework und Bibliothek verwischen. Merksatz: Die Bibliothek rufst du auf, das Framework ruft deinen Code auf.
- Mehr Frameworks aufzählen, als du eingesetzt hast – das wirkt aufgeblasen und führt zu Folgefragen.
Wenn du nicht weiterkommst: Frag dich, was du ohne das Framework hättest von Hand programmieren müssen. Genau das ist deine Begründung.
FRAGE 10: „WELCHE PROGRAMMIERSPRACHEN WURDEN VERWENDET UND WARUM?“
Das wollen die Prüfer hören:
Alle eingesetzten Sprachen klar und vollständig – auch Auszeichnungs- und Abfragesprachen wie HTML, CSS oder SQL gehören dazu, wenn sie relevant waren. Im Idealfall hast du dazu bereits eine Auflistung in der Dokumentation. Begründe die Wahl sachlich und zeige, dass du typische Eigenschaften einordnen kannst: statisch oder dynamisch typisiert, kompiliert oder interpretiert, objektorientiert oder funktional.
Wenn die Sprachwahl vom Betrieb oder von der bestehenden Systemlandschaft vorgegeben war, sag das ruhig – das ist völlig legitim, solange du es begründen kannst („Die bestehende Backend-Landschaft war Java, eine andere Sprache hätte zusätzlichen Wartungsaufwand erzeugt“).
No-Gos: „Java, weil wir das in der Schule hatten.“ Das ist eine Erklärung, aber keine Begründung. Sprachen aufzählen, ohne ihre Rolle im Projekt zu erklären. Andere Technologien pauschal schlechtreden. Und Sprache und Framework durcheinanderbringen – Java ist eine Sprache, Spring ist ein Framework.
Dein Trainingspartner für die FIAE-Prüfung.
Mit dem Plakos Prüfungstrainer für Anwendungsentwickler übst du alle Prüfungsbereiche – von Teil 1 über Teil 2 bis WiSo. Im Plus- und Premium-Paket hilft dir zusätzlich ein KI-Lernbuddy, das Fachgespräch rund um die Uhr zu trainieren. So sitzt jede Antwort, wenn es darauf ankommt.
- Interaktive Übungsaufgaben & Lösungen
- Erklärvideos, Erfahrungsberichte & Insidertipps
- Zugang zur Plakos Lern-App
12 WEITERE FRAGEN, AUF DIE DU VORBEREITET SEIN SOLLTEST
Die zehn Fragen oben decken den Kern ab. Diese Zusatzfragen tauchen ebenfalls regelmäßig auf – geh sie einmal durch und notiere dir zu jeder einen Satz:
- Warum hast du dich für dieses Vorgehensmodell entschieden – Wasserfall, Scrum, Kanban?
- Wo lag die größte Abweichung zwischen Soll- und Ist-Zeit, und woran lag sie?
- Wie hast du die Anforderungen erhoben und mit dem Auftraggeber abgestimmt?
- Was war die größte technische Herausforderung – und wie hast du sie gelöst?
- Erkläre dein Datenbankmodell. Ist es normalisiert? Bis zu welcher Normalform?
- Was ist der Unterschied zwischen einem INNER JOIN und einem LEFT JOIN?
- Wie hast du Versionierung betrieben, und wie war dein Branching-Modell?
- Was passiert nach dem Projekt – wer wartet die Anwendung, gibt es eine Übergabe?
- Wie hast du die Benutzer geschult bzw. eine Anwenderdokumentation erstellt?
- Was ist eine REST-Schnittstelle, und welche HTTP-Methoden hast du genutzt?
- Was würdest du heute anders machen, wenn du das Projekt neu starten würdest?
- Wie sieht die Amortisationsrechnung aus – ab wann rechnet sich deine Lösung?
DIE 5 HÄUFIGSTEN FEHLER IM FACHGESPRÄCH
- Fachbegriffe in der Doku, die du nicht erklären kannst. Jeder Begriff in deiner Dokumentation ist eine Einladung zur Rückfrage. Schreib nur hinein, was du an einem Beispiel erklären kannst.
- Auswendig gelernte Definitionen. Sie halten genau eine Rückfrage lang. Danach wird es unangenehm.
- Kein Projektbezug. Theorie ohne Beispiel wird als Halbwissen bewertet – auch wenn die Theorie stimmt.
- Raten statt zugeben. „Das weiß ich nicht sicher, ich würde es so herleiten …“ bringt mehr Punkte als eine erfundene Antwort. Prüfer merken den Unterschied sofort.
- Sich rechtfertigen statt begründen. Kritische Fragen sind Methode, nicht Urteil. Wer defensiv wird, verliert Souveränitätspunkte.
SO BEREITEST DU DICH AUF DAS FACHGESPRÄCH VOR
1. MIT DEINEM AUSBILDER ÜBEN
2. MIT ANDEREN AZUBIS ÜBEN
3. KI ZUR SIMULATION NUTZEN
Lade deine Dokumentation in ein KI-Tool und lass dich in der Rolle der Prüfungskommission befragen. Kein Ersatz für echtes Training, aber eine sehr gute Ergänzung, wenn du abends allein üben willst. Fertige Prompts dafür findest du in unserem Beitrag 11 geniale KI-Prompts für die Anwendungsentwickler-Prüfungsvorbereitung.
4. PRÜFUNGSSIMULATION UNTER ZEITDRUCK
CHECKLISTE FÜR DIE LETZTEN 7 TAGE VOR DER PRÜFUNG
- Markiere jeden Fachbegriff in deiner Dokumentation und schreib dir zu jedem einen Erklärsatz plus ein Projektbeispiel auf.
- Formuliere zu den Themen Datenschutz, Datensicherung, IT-Sicherheit und Qualitätssicherung je eine konkrete Maßnahme aus deinem Projekt.
- Bereite deine Wirtschaftlichkeitsargumentation vor: eine geprüfte Alternative, ein Kostenargument, ein Nutzenargument.
- Leg dir eine ehrliche Antwort auf „Was würdest du heute anders machen?“ zurecht.
- Spiele Präsentation und Fachgespräch einmal am Stück durch – laut, mit Stoppuhr, vor Publikum.
- Präge dir deinen Satz für Wissenslücken ein: „Das kann ich nicht sicher sagen – ich würde es folgendermaßen herleiten …“
FAzit
Das Fachgespräch ist der am besten planbare Teil deiner Abschlussprüfung – weil die Fragen aus deiner eigenen Dokumentation kommen. Merk dir vor allem das eine: Verwende in Dokumentation und Präsentation nur Fachbegriffe, die du verstanden hast und mit einem Beispiel erklären kannst. Prüfer merken sofort, wenn eine Antwort heruntergerasselt wird. Dann kommen die Folgefragen – und da hört es dann auf.
Bleib fokussiert, üb regelmäßig mit anderen und zeig im Fachgespräch, dass du dein Projekt wirklich verstanden hast.
DAS KÖNNTE DICH AUCH INTERESSIEREN
