Updated: 30 Sep 2026, 21:25
Assessment Logic and Generative AI Use Policy
Table of contents
Assessment Logic
DEUTSCH
Scroll down for a German translation of the assessment logic.
Note: section “Vertical Feature and Portfolio Ownership” exisits only in English.
Assessment consists of four elements:
| Assessment type | Examination | Individual Points | Team Points | Totals |
|---|---|---|---|---|
| Gate to examination | Assignment | n/a | n/a | n/a |
| Examination | Submission | 30 | 25 | 55 |
| Examination | Oral Examination | 30 | 5 | 35 |
| Examination | Refined Submission | – | 10 | 10 |
| Totals | 60 | 40 | 100 |
Rubric: Assignment (ungraded gate to examination)
| Category | Criteria |
|---|---|
| Team Composition | Team name and list of contributors Team repository that examiner can “git pull” (cannot be changed later) Meta-goals per contributor: target grade and personal goals |
| Value Proposition | Target user with a plausible problem and team’s (app-based) solution proposal App must implement a two-sided platform |
| Target Scope | Visual scoping of Web App, primarily via scribbles of UI screens |
Notes
Achievement of “Value Proposition” and “Target Scope” criteria may be assessed via an in-class peer review format. If so, the Lecturer decides “pass / rework / fail” informed by this review. Rework due date is announced by Lecturer.
Students must pass the mandatory Assignment (“Studienleistung”) to be eligible for subsequent examination.
Mandatory Requirements and Prohibited Technology
Mandatory Requirements are checked with Submission.
Prohibited Technology is checked with Refined Submission.
- Accidental inclusion at Submission (which might be noticed by Lecturer) may be remedied penalty-free until Refined Submission.
- If minor JavaScript / TypeScript use is detected: 0 Points for Refined Submission.
- In all other cases of Prohibited Technology use: 0 Points for Refined Submission + 0 Team Points for Submission.
- The Team is fully accountable for not including any Prohibited Technology, also if Lecturer doesn’t catch it with Submission, but notices it in Refined Submission.
| Mandatory Requirement | Prohibited Technology |
|---|---|
| Written in Python | Any (even minor) use of JavaScript / TypeScript; exception: JS functionality bundled with Bootstrap |
| Use of Flask | Replacing Flask with another web app framework, e.g., FastAPI |
| Use of Jinja2 | Replacing Jinja2 with another templating engine, e.g., Mako |
| App handles multiple HTTP requests with varied business logic (no content website) | – |
| SQLite, with exactly one database file checked into repository | Any other database technology (including NoSQL databases), or remote hosting of database |
| User roles, including authorization flow(s) | – |
| Useful “headless” REST API; min. 1 of which delivers a JSON file | – |
| Must be executable natively on a current Windows or MacOS system | Packaging any part of your App in a Docker container, a Virtual Machine, or similar |
Vertical Feature and Portfolio Ownership
Every Student must own at least one vertical feature (= covers all areas from front-end to business logic to data handling). Distributing work like “Student A = Data Model”, “Student B = Front-end”, “Student C = Back-end” is not allowed.
In addition, Students must distribute all cross-cutting concerns within their team, according to the Portfolios listed below.
The Portfolios indicate task accountability, which means here: coordination and final coherence. This does not remove responsibility from the other team members. Every Student must contribute to discovery, implementation, review, documentation, integration, and submission through their own vertical feature(s) and team participation.
| Task | Detailed accountability | Portfolio | Team of 3 |
|---|---|---|---|
| Discovery Process | |||
| Plan discovery activities | Ensure that research questions, target participants, methods, etc. are appropriate for identifying the problem to be solved. | A | A |
| Maintain discovery evidence | Ensure that interview notes, observations, and other findings are recorded accurately and that evidence is distinguished from assumptions. | A | A |
| Identify discovery gaps | Identify unsupported claims, weak evidence, and questions that require further investigation. | A | A |
| App Scope | |||
| Synthesize discovery findings | Ensure that research findings are translated into a coherent understanding of the target users, their problem, and the proposed product response. | B | B |
| Maintain the value proposition | Ensure that the value proposition remains specific, evidence-based, and consistent with the implemented product. | B | B |
| Control project scope | Ensure that the team prioritizes the central workflow, removes unnecessary features, and avoids risks. | B | B |
| Maintain feedback response | Ensure that feedback (e.g., from reviews) is evaluated, accepted or rejected with reasons, and reflected in project decisions. | B | B |
| User Experience | |||
| Maintain the central user journey | Ensure that the team’s vertical features combine into an understandable and coherent human-facing workflow. | C | C |
| Integrate navigation and page structure | Ensure consistent navigation, information hierarchy, shared templates, headings, and page-level structure. | C | C |
| Integrate forms and feedback | Ensure consistent form behavior, incl. labels, validation messages, confirmation feedback, empty states, error presentation, etc. | C | C |
| Maintain UI terminology | Ensure that user-facing terminology is consistent across pages (app + documentation) and aligned with the product concepts. | C | C |
| Product Rules | |||
| Identify shared product rules | Ensure that important rules are explicit, e.g., authorization, access, ownership, matching, conflicts, state transitions, … | D | B |
| Integrate domain behavior | Ensure that vertical features do not implement contradictory or duplicated product rules. | D | B |
| Align HTML and API behavior | Ensure that human-facing and machine-facing operations enforce the same underlying product rules. | D | B |
| API | |||
| Define the API purpose | Ensure that each API operation serves a plausible machine-facing use case. | A | A |
| Integrate API behavior | Ensure consistent representations, status codes, authentication and error responses across API operations. | A | A |
| Verify API readiness | Ensure that the final API operations can be demonstrated and that documented success and failure examples work in the submitted version. | A | A |
| Data Integration | |||
| Integrate the data model | Ensure that tables, entities, relationships, cardinalities, optionality, and naming form one coherent relational model. | B | A |
| Coordinate data constraints | Ensure that primary keys, foreign keys, uniqueness constraints, and other database protections support the product rules. | B | A |
| Review schema changes | Ensure that changes introduced by individual verticals do not create duplicated concepts or contradictory relationships. | B | A |
| Verify database readiness | Ensure that database initialization works and that the final data-model documentation matches the implementation. | B | A |
| Design + Code Coherence | |||
| Enforce software-design boundaries | Ensure that the project follows any mandatory structure(s) and requirements. | C | C |
| Integrate cross-cutting code conventions | Ensure consistent authentication conventions, authorization invocation, error handling, shared types, etc. | C | C |
| Monitor code integration | Ensure that branches are integrated regularly, merge problems are surfaced, and the main branch remains runnable. | C | C |
| Documentation Quality | |||
| Maintain documentation structure | Ensure that required Markdown pages are present, navigable, and consistently organized | D | B |
| Coordinate documentation quality | Ensure consistent terminology, readable Markdown, correct diagrams, valid code references, and accurate descriptions. | D | B |
| Review design decisions | Ensure that design decision structure follows the mandatory template, and that there is concrete evidence of how regarded options were evaluated. | D | B |
| Verify contribution documentation | Ensure that every student’s contribution page covers all mandatory sections, and that every claim is backed up by adequate proof (e.g., a git commit). | D | B |
| Repository Delivery | |||
| Coordinate release identification | Ensure that the submission commit contains the latest integrated work of the team, including documentation. | D | C |
| Verify readme instructions | Ensure that another person can clone the repository, install dependencies, initialize the database, and run the submitted application using the documented steps. | D | C |
Rubric: Submission
| Category | Individual | Team | Points + Criteria |
|---|---|---|---|
| Vertical Feature Ownership | 20 | – | - Proof of vertical feature(s) ownership, primarily through exemplary git commit traces - Step-by-step walkthrough of owned vertical feature(s) that examiner can follow in app - Owned vertical feature(s) essential to Value Proposition - Contributed substantially to app source code |
| Design and Portfolio Ownership | 10 | – | - At least 2 relevant Design Decisions in the mandatory format, with proof of regarded options (tangible self-created artifacts like repo branches, not list of links or similar) - Proof of continuous portfolio ownership, primarily through work diary, git commit traces, and other useful artifacts |
| Product Discovery | – | 10 | - Evidence folder with “raw material” aimed to (1) define design challenge, (2) understand target user(s) with their core problem(s), (3) propose solution elements, and (4) test ideas - Value Proposition: what is the problem? Who has it? How to solve it with an App? - Happy Path derived from Value Proposition (clear priorities) |
| Product Delivery | – | 15 | - After “git clone”: within 10 min, examiner can reproduce App Happy Path locally by following README.md instructions - App fulfils all Mandatory Requirements - Data Model visualized and described, must match implementation |
| Totals | 30 | 25 | 55 |
Rubric: Oral Examination
| Category | Individual | Team | Points + Criteria |
|---|---|---|---|
| Outlook | – | 5 | Planned refinements from Submission date to Refined Submission, with reasoning how they are aligned with Value Proposition |
| Design Insight | 10 | – | - When asked, able to logically / reasonably explain particular decision(s) in own area of responsibility - Shows overall intimacy with problem space, target user, proposed solution |
| Code Insight | 20 | – | Demonstrates technical mastery; signals: (1) easily navigates in codebase; (2) answers are convincing (not wrong/ reasonable) and to-the-point; (3) can assess consequences of proposed changes |
| Communication | 5 | – | - Manages to answer posed questions within time budget - Shows conversational ability under pressure - remains calm/ professional in examination setting - Overall effective communication style (clear statements, correct terms, eye contact, …) |
| Totals | 35 | 5 | 40 |
Rubric: Refined Submission
| Category | Individual | Team | Points + Criteria |
|---|---|---|---|
| Refinement | – | 5 | - Implementation of refinements since Submission clearly documented - It is easy for examiner to see how App is faithful to Value Proposition |
| Submission Usability | – | 5 | - No part of the Final Submission contains inconsistencies - Clutter-free git repository (e.g., no venv/ folder) |
| Totals | – | 10 |
Generative AI Use Policy
Principle
The goal of this Module is to assess your understanding and ability to create, not the output quality of a tool. You must maintain human agency over every line of code and every sentence that you submit.
Permitted Tools
You are allowed to use Generative AI for assistance. You are fully responsible for any result that you submit, you must understand and be able to explain it. Permitted tools:
- Chat-based interfaces (e.g., ChatGPT, Perplexity), e.g., for brainstorming, to learn about concepts and technologies, to explain encountered errors.
- IDE code completion (e.g., Copilot within Visual Studio Code) for small snippets or boilerplate code.
Prohibited Tools
The use of Agentic AI is PROHIBITED. This includes any AI-based tool that plans and executes several steps autonomously, modifies files, manages repositories, generates code structure, etc. without step-by-step intervention by you. This includes the creation of git commits (and commit messages) on your behalf.
Exemplary tools that are forbidden include, but are not limited to: Aider, Antigravity, Claude Code, Codex, Copilot Chat Agents, Cursor, OpenClaw, OpenCode, Replit.
Disclosure
You must maintain a comprehensive AI Directory, as per FB1 Regulations on Generative AI Use. “Catch-all” disclosure (like “AI Tool used for bugfixing”) is generally not sufficient.
Again, any use of Agentic AI is prohibited.
Verification and Sanctions
Your ability explain the artifacts you created (code and documentation) is a crucial verification mechanism.
- Oral Examination: Your individual grade depends on your ability to explain your own results.
- Undisclosed Tool Use: If detected at any point, (e.g., Oral Examination), your Individual Points are capped at 10.
- Forbidden Tool Use: If detected at any point, you will fail the Module for Misconduct (“Täuschung”).
DEUTSCH
(DE) Prüfungslogik
Die Prüfung erfolgt in vier Teilen:
| Art | Name | Individuell | Team | Gesamt |
|---|---|---|---|---|
| Zulassung zur Prüfung | Studienleistung | n/a | n/a | n/a |
| Prüfung (schriftlich) | Submission | 30 | 25 | 55 |
| Prüfung (mündlich) | Oral Examination | 30 | 5 | 35 |
| Prüfung (schriftlich) | Refined Submission | – | 10 | 10 |
| Gesamt | 60 | 40 | 100 |
Mandatory Requirements und Forbidden Technology
Die Mandatory Requirements (DE: verbindliche Anforderungen) werden mit der Submission überprüft.
Prohibited Technology (DE: unerlaubte Technologien) wird mit der Refined Submission überprüft.
- Eine versehentliche Verwendung bei der Submission, die möglicherweise von der Lehrperson bemerkt wird, kann bis zur Refined Submission schadensfrei entfernt werden.
- Bei geringfügiger Nutzung von JavaScript / TypeScript: 0 Punkte für Refined Submission.
- In allen anderen Fällen von Prohibited Technology: 0 Punkte für Refined Submission + 0 Team-Punkte für Submission.
- Das Team ist vollständig dafür verantwortlich, keine Prohibited Technology zu verwenden, auch wenn die Lehrperson dies bei der Submission nicht bemerkt, sondern erst bei der Refined Submission feststellt.
| Mandatory Requirement | Forbidden Technology |
|---|---|
| In Python geschrieben | Jegliche, auch geringfügige Nutzung von JavaScript / TypeScript; Ausnahme: mit Bootstrap gebündelte JS-Funktionalität |
| Verwendung von Flask | Ersetzen von Flask durch ein anderes Web-App-Framework, z.B. FastAPI |
| Verwendung von Jinja2 | Ersetzen von Jinja2 durch eine andere Template-Engine, z.B. Mako |
| App verarbeitet mehrere HTTP-Requests mit unterschiedlicher Geschäftslogik (keine reine Content-Website) | – |
| SQLite, mit genau einer Datenbankdatei, die ins Repository eingecheckt ist | Jede andere Datenbanktechnologie (einschließlich NoSQL-Datenbanken) oder Remote-Hosting der Datenbank |
| Benutzerrollen, einschließlich Autorisierungs-Flow(s) | – |
| Sinnvolle “headless” REST-API; min. 1 Endpunkt liefert eine JSON-Datei aus | – |
| Muss nativ auf einem aktuellen Windows- oder macOS-System ausführbar sein | Packaging irgendeines Teils der App in einem Docker-Container, einer virtuellen Maschine oder Ähnlichem |
Bewertungsraster: Studienleistung (unbenotete Prüfungsvoraussetzung)
| Kategorie | Kriterien |
|---|---|
| Team Composition | - Teamname und Auflistung der Mitglieder - Team-Repository, das Prüfer*in per “git pull” abrufen kann (kann später nicht mehr geändert werden) - Meta-Ziele je Mitglied: angestrebte Note und persönliche Ziele |
| Value Proposition | - Zielnutzende mit nachvollziehbarem Problem und dazu passender App-basierter Lösungsidee des Teams - Team muss eine zweiseitige Plattform implementieren |
| Target Scope | Visuelles Scoping der Web-App, insbesondere durch Skizzen von UI-Screens |
Hinweise
Die Erfüllung von “Value Proposition” und “Target Scope” können per Peer-Review in der Übung bewertet werden. In diesem Fall entscheidet die Lehrperson auf dieser Grundlage über “bestanden / zu überarbeiten / nicht bestanden”. Die Frist zur Überarbeitung wird von der Lehrperson bekanntgegeben.
Studierende müssen die verpflichtende Studienleistung bestehen, um zur anschließenden Prüfung zugelassen zu werden.
Bewertungsraster: Submission
| Kategorie | Individuell | Team | Kriterien |
|---|---|---|---|
| Verantwortung für vertikale Features | 20 | – | - Nachweis der Verantwortung für min. 1 vertikales Feature, v.a. anhand exemplarischer Git-Commit-Verläufe - Schritt-für-Schritt-Anleitung der eigenen vertikalen Features, die Prüfer*in in der App nachvollziehen kann - Eigene vertikale Features sind wesentlich für die Value Proposition - Wesentlicher Beitrag zum Quellcode der App |
| Verantwortung für Design und Portfolio | 10 | – | - Mindestens 2 relevante Design Decisions im verpflichtenden Format, mit Nachweis der betrachteten Optionen (greifbare, selbst erstellte Artefakte wie Repository-Branches, keine Linklisten o.Ä.) - Durchgängige Verantwortung für das zugeteilte Portfolio, Nachweis mittels “Tagebuch”, Git-Commits und weiteren hilfreichen Artefakten |
| Product Discovery | – | 10 | - Nachweis-Ordner mit „Rohmaterial“, das darauf abzielt, (1) die Design Challenge zu definieren, (2) die Zielnutzer*innen mit ihren Kernproblemen zu verstehen, (3) Lösungselemente vorzuschlagen und (4) Ideen zu testen - Value Proposition: Was ist das Problem? Wer hat es? Wie kann es mit einer App gelöst werden? - Happy Path, abgeleitet aus der Value Proposition (klare Prioritäten) |
| Product Delivery | – | 15 | - Nach “git clone” kann Prüfer*in innerhalb von 10 Minuten den Happy Path der App lokal nachbilden, indem er/sie den Anweisungen in der README.md folgt - App erfüllt alle Mandatory Requirements - Datenmodell visualisiert und beschrieben, muss mit der Implementierung übereinstimmen |
| Gesamt | 30 | 25 | 55 |
Bewertungsraster: Oral Examination
| Kategorie | Team | Individuell | Kriterien |
|---|---|---|---|
| Ausblick | 5 | – | - Geplante Verbesserungen / Verfeinerungen von der First Submission bis zur Final Submission, mit Begründung, wie sie sich aus (1) der Value Proposition und (2) dem aktuellen Stand der App heraus ableiten |
| Design-Verständnis | – | 10 | - Kann auf Nachfrage bestimmte Entscheidung(en) im eigenen Verantwortungsbereich logisch / nachvollziehbar erklären - Zeigt insgesamt Vertrautheit mit dem Problemraum, den Zielnutzer*innen und der vorgeschlagenen Lösung |
| Code-Verständnis | – | 15 | - Durchdringt die App technisch; Anzeichen: (1) findet sich leicht im Code-Repository zurecht; (2) Antworten sind überzeugend (nicht falsch / nachvollziehbar) und auf den Punkt; (3) kann die Folgen vorgeschlagener Änderungen einschätzen |
| Kommunikation | – | 5 | - Beantwortet gestellte Fragen innerhalb des Zeitbudgets - Zeigt Gesprächsfähigkeit unter Druck - bleibt in der Prüfungssituation ruhig / professionell - Insgesamt effektiver Kommunikationsstil (klare Aussagen, korrekte Begriffe, Blickkontakt, …) |
| Gesamt | 5 | 30 | 35 |
Bewertungsraster: Refined Submission
| Kategorie | Team | Individuell | Kriterien |
|---|---|---|---|
| Konsistenz | 10 | – | - Umsetzung von Verbesserungen / Verfeinerungen seit der First Submission reflektiert - Für Prüfer*in ist leicht erkennbar, wie die App an der Value Proposition ausgerichtet ist - Kein Teil der Final Submission enthält Inkonsistenzen |
| Nutzbarkeit der Abgabe | 5 | – | - Git-Repository ohne unnötige Artefakte (z.B. kein venv/-Ordner) - Dokumentation auf öffentlich zugänglicher Website und automatisch aus .md-Dateien erstellt (z.B. über GitHub Pages) - Nach “git pull” kann Prüfer*in die funktionsfähige App leicht ausführen, indem er/sie den Anweisungen in der README.md folgt |
| Gesamt | 15 | – |
(DE) Richtlinie zur Nutzung Generativer KI
Grundsatz
Die Bewertung zielt auf Ihr Verständnis und Ihre Fähigkeit zum Erstellen eigener Ergebnisse, nicht auf die Ausgabequalität eines Tools. Jede Codezeile und jeder Satz in der Dokumentation muss von Ihnen vollumfänglich verstanden und verantwortet werden - Sie haben Human Agency, nicht das KI-Tool.
Erlaubte Tools
Sie dürfen generative KI zur Unterstützung verwenden. Sie sind vollständig für jedes Ergebnis verantwortlich, das Sie einreichen; Sie müssen es verstehen und erklären können. Erlaubte Tools sind:
- Chatbasierte Oberflächen (wie ChatGPT, Perplexity), z.B. für Brainstorming, zum Erfragen von Konzepten und Technologien oder zum Erklären aufgetretener Fehler.
- IDE-Codevervollständigung (z.B. Copilot in Visual Studio Code) für kleine Code-Snippets oder Boilerplate-Code.
Verbotene Tools
Die Nutzung agentischer KI ist VERBOTEN. Dazu zählt jedes KI-basierte Tool, das mehrere Schritte autonom plant und ausführt, Dateien verändert, Repositories verwaltet, Code-Strukturen erzeugt usw., ohne dass Sie Schritt für Schritt eingreifen. Dies umfasst auch das Erstellen von Git-Commits und Commit-Nachrichten in Ihrem Namen.
Beispielhafte Tools, die verboten sind, umfassen unter anderem: Aider, Antigravity, Claude Code, Codex, Copilot Chat Agents, Cursor, OpenClaw, OpenCode, Pi, Replit.
Offenlegung
Sie müssen ein umfassendes KI-Verzeichnis gemäß FB1 Regulations on Generative AI Use führen. Eine pauschale Beschreibung wie “KI-Tool für Bugfixing verwendet” ist in der Regel nicht ausreichend.
Nochmals: Jede Nutzung agentischer KI ist verboten.
Überprüfung und Konsequenzen
Ihre Fähigkeit, die von Ihnen erstellten Artefakte (Code und Dokumentation) zu erklären, ist der zentrale Überprüfungsmechanismus.
- Oral Examination: Ihre individuelle Bewertung hängt davon ab, wie gut Sie Ihre eigenen Ergebnisse erklären können.
- Nicht offengelegte Tool-Nutzung: Wird diese zu irgendeinem Zeitpunkt festgestellt, z.B. in der Oral Examination, werden Ihre individuellen Punkte auf 10 begrenzt.
- Nutzung verbotener Tools: Wird diese zu irgendeinem Zeitpunkt festgestellt, bestehen Sie das Modul wegen Täuschung / Fehlverhalten nicht.
Oral Examination Q&A Simulation
Ziel: Simulation der mündlichen Prüfungssituation. Die Studierenden üben zu erklären, warum sie bestimmte Designentscheidungen getroffen haben und wie ihr Code funktioniert.
Dauer: 90 Minuten
Gruppengröße: Dreiergruppen (3 Studierende)
Rollen:
- Candidate: Die Person, die ihren konkreten Beitrag erläutert.
- Examiner: Stellt Fragen auf Grundlage des Fragenkatalogs.
- Observer: Macht sich Notizen für die Feedback-Runde und achtet auf die Zeit.
Ablauf
| Zeit | Inhalt | Hinweis |
|---|---|---|
| 0:00 - 0:05 | Intro | - Format vorstellen und Fragen klären. - Dreiergruppen bilden (aus verschiedenen Teams). |
| 0:05 - 0:25 | Vorbereitungsphase | - Gegenseitig Zugriff auf Git-Repo inkl. Doku geben. - 10 min je Repo: Basierend auf der dokumentierten “Individual Contribution” versuchen, sich in den relevanten Repo-Teil (Code + Doku) einzufinden. |
| 0:25 - 0:45 | RUNDE 1 | Candidate: Student*in A |
| 2 min | Kontext | Student*in A fasst kurz den eigenen Beitrag im Projekt zusammen |
| 10 min | Q&A | Student*in B (Examiner) stellt 1-2 Fragen zu Design-Verständnis und 1-2 Fragen zu Code-Verständnis; 10 min gesamt = 4x 2:30 min: - 30s Frage - 60s Antwort - 30s ggf. Feedback/Nachfrage - 30s ggf. präzisierte Antwort |
| 3 min | Feedback | Student*in C (Observer) gibt strukturiertes Feedback: - Was war überzeugend? - Was war offensichtlich am schwierigsten? - Wie war das Zeitmanagement? |
| 5 min | Rollenwechsel | - A → Observer, B → Candidate, C → Examiner - Kurze Vorbereitung auf nächste Runde |
| 0:45 - 1:05 | RUNDE 2 | Candidate: Student*in B |
| 1:05 - 1:20 | RUNDE 3 | Candidate: Student*in C |
| 1:20 - 1:30 | Debriefing im Plenum |
Fragenkatalog
Anleitung:
- Als Examiner wählst Du 1-2 Fragen aus Kategorie 1 (Designverständnis) und 1-2 Fragen aus Kategorie 2 (Codeverständnis).
- Stelle keine allgemeinen Fragen. Nutze den konkreten Kontext der jeweiligen App, sweit es Dir möglich ist.
- Stelle anspruchsvolle, aber faire Fragen - keine “gemeinenen” Fragen.
Kategorie 1: Designverständnis
Fokus: Begründung von Entscheidungen / Alternativen
- In Deiner Doku hast du [Option A] und [Option B] in [Design Decision] betrachtet. Du hast dich für [Option A] entschieden. Was war der konkrete Nachteil von [Option B], der diese Option für dieses Projekt untragbar gemacht hat?
- Du hast entschieden, [Design Decision] so zu lösen: [Entscheidung]. Was war der eine ausschlaggebene Grund, dass Du so entschieden hast?
- Zeige mir den Git-Branch oder das Artefakt, in dem Du das alternative Design getestet hast. Welche Daten oder Beobachtungen aus diesem Test haben dazu geführt, dass du es verworfen hast?
Fokus: Problemraum / Nutzerempathie
- Du hast [Zielnutzer*in] als primäre Zielgruppe auf der Angebotsseite genannt. Wie adressiert Deine App direkt einen Schmerzpunkt dieser Nutzergruppe – und nicht nur einer allgemeinenen Nutzerin?
- Wenn Du ein Feature aus dem aktuellen Umfang entfernen müsstest, um die User Experience für die Nachfrageseite zu verbessern: Welches wäre das und warum?
- Beschreibe ein Szenario, in dem Dein aktueller UI-Flow eine*n Erstnutzer*in verwirren könnte. Wie hast Du dieses Risiko im Design reduziert?
Fokus: Systemarchitektur / Ablauf
- Wie spiegelt Dein Datenbankschema die Business-Logik von [konkretes Feature der App] wider? Führe mich durch die Beziehungen.
- Wenn diese App morgen auf 10.000 Nutzer*innen skalieren müsste: Welcher Teil Deines aktuellen Designs würde zuerst scheitern, und wie würdest Du ihn neu gestalten?“
Kategorie 2: Codeverständnis
Fokus: Navigation / Struktur
- Öffne Deine
app.py(oder die zentrale Routen-Datei). Zeige auf die Zeile, in der die Anfrage für [konkrete Seite] verarbeitet wird. Führe mich durch den Ablauf: Wie gelangen die Daten aus der SQLite-Datenbank in das Jinja2-Template? Benenne die konkreten Funktionen oder Methoden, die beteiligt sind. - Ich sehe, dass Du [Library/Modul] importiert hast. Warum hast du diese spezifische Library gewählt? Welche konkrete Funktionalität hat sie bereitgestellt, die wesentlich war?
- Schau in Deine Git-Historie. Identifiziere einen Commit, in dem Du ein wichtiges Problem gelöst hast. Worum ging es dabei und wie bist Du vorgegangen?
Fokus: Logik / Implementierungsdetails
- Schau Dir diese konkrete Funktion an: [auf eine komplexe Abfrage oder Schleife zeigen]. Erkläre, was passiert, wenn die Eingabedaten fehlerhaft oder leer sind. Wie behandelt Dein Code diesen Fall?
- Du hast hier ein [konkretes Pattern, z.B. Decorator, Mixin, Factory] verwendet. Warum war dieses Pattern notwendig? Wie würde der Code aussehen, wenn Du ihn ohne dieses Pattern geschrieben hättest?
- Erkläre den Unterschied zwischen Deiner Umsetzung von [Feature X der App] und [Feature Y der App]. Unterscheiden sich die Implementierungsstrategien? Wenn ja, wieso? Wenn nein, wieso nicht?
Fokus: Was wäre-wenn-Fragen
- Wenn ich Dich bitten würde, ein neues Feld zur Tabelle [Tabellenname] hinzuzufügen: Was müsstest Du genau im Python-Code ändern? Führe mich in einer logischen Reihenfolge durch.
- Angenommen, wir möchten die Nutzer-Authentifizierung ändern. Welche Teile Deiner aktuellen Codebasis wären am stärksten betroffen? Schätze den Aufwand ein: niedrig, mittel oder hoch – und begründe warum.
- Du hast erwähnt, dass Du auf [konkreter Codebeitrag] besonders stolz bist. Wenn Du diesen Code heute mit Deinem jetzigen Wissen neu schreiben müsstest: Was würdest Du ändern, um besser zu machen? Definiere zunächst “besser”.
Copyright © 2026 Prof. Dr. Alexander Eck. All rights reserved.