Examen Eindgesprek

Het Eindgesprek: Tips & Vragen

Het eindgesprek is de afronding van je examen. De assessoren gebruiken dit gesprek om vast te stellen of je over de juiste competenties beschikt.

Authenticiteit

Tijdens het eindgesprek wordt vooralkritisch gekeken naar de authenticiteit.authenticiteit. DatDe houdtassessoren in dat er wordt bepaaldbepalen of alhet hetopgeleverde werk echtdaadwerkelijk door jou zelfjouzelf is gemaakt.gemaakt en of je de gemaakte keuzes kunt onderbouwen.

VerbeterpuntenKansen bij onvolkomenheden

AlsMochten er tijdens het nakijkenbeoordelen van je portfolio kleine zaken onjuist zijn of missenontbreken, kandan wordt hier ooktijdens het gesprek naar worden gevraagd. HetDit zouis kunnenjouw kans om mondeling aan te tonen dat jij alsnog kan aantonen dat iets wel voldoet en je zoude daarmeestof beheerst, wat je score omhoog kunnen halen. Ditpositief kan maarbeïnvloeden. opLet enkeleop: puntendoor omdatde beperkte tijd kunnen niet alle 8acht werkprocessen uitgebreid besprokenbehandeld kunnenworden; worden.focus je dus op de kern.

BeperkteFocus tijdvan het gesprek

JeIn kuntprincipe overalkan vragenelke overonderdeel krijgen.van Meestalje wordenexamen maarbevraagd eenworden. paarVanwege werkprocessen bevraagd. Dat omdat er maarde beperkte tijd is.(meestal 20-30 minuten) maken de assessoren vaak een selectie van een aantal werkprocessen waar zij meer over willen weten.

Zorg ervoor dat je jouw portfolio kandirect presenterenkunt presenteren. Bereid je extra goed voor op onderdelen waarvan je zelf al vermoedt dat ze minder sterk zijn. Zorg dat je applicatie werkend klaarstaat en als je al vermoed dat er zaken ontbreken, probeer je daar dan op voor te bereiden. Je code werkt dus en alle documentendocumentatie hebdirect jeoproepbaar bij de hand!
is.

---

Checklist voor het gesprek

• Laptop opgeladen,volledig opgeladen en lader mee?binnen handbereik?
• Systeemvrije dag? (Windows) Windows/Software-updates gedraaid?vooraf uitgevoerd?)
• SoftwareLokale werktserver allemaalen tools operationeel? (XAMPP, VSC,VS Code, Git, etc.)
• Portfolio staatlokaal klaarbeschikbaar? (dusVoorkom nietvertraging ergens eerst moetendoor downloaden en/of unzippen)?
• AllesWerking getest?van de applicatie gecontroleerd in de examensituatie?
• ...en vergeetVergeet je IDgeldig identiteitsbewijs niet!

---

Vragen die je kankunt verwachten

MaarHoewel let op, alles kan gevraagd worden, zeker als er zaken in je portfolio niet duidelijk zijn. Maar hieronder zie je een aantalde vragen variëren per project, zijn dit de meest voorkomende onderwerpen die regelmatigde gesteldassessoren worden.behandelen:

Algemeen

• Wie waren allede betrokkenenbelanghebbenden van(stakeholders) bij dit project?
• Hoe verliep het contact met de samenwerking?
  opdrachtgever en/of collega's?
• Ben je tevreden met de kwaliteit van het eindproduct? Wat zou een 'versie 2.0' bevatten?
• HoeWat langwas, bentechnisch je in totaal bezig geweest metgezien, het project?
meest
• Welkuitdagende onderdeel was het meeste werk?onderdeel?
• Wat is de belangrijkste les die je tijdens dit examen hebt geleerd?
• WelkeWelk tipadvies zou je een student geven aandie anderevolgend studenten diejaar dit examen moeten doen?
• Wat vond je het lastigste om te doen en waarom?doet?

Planning & Organisatie

• Wie is je opdrachtgever?
• In hoeverre kloptekwam jouwde planning?realiteit Zouovereen met je achterafinitiële gezienplanning?
de
• Welke onvoorziene omstandigheden dwongen je om je planning andersaan hebbente gemaakt?passen?
• StaanJe er dingengaf in de planning die je niet of anders hebt uitgevoerd? Waarom?
• Heb je dingen uitgevoerd die niet in de planning staan? Waarom?
• In de planning staataan dat je "abc" gingop doen,een kanbepaalde dag zou afronden; kun je laten zien hoe dat latenis zien?verlopen?

Ontwerp & Voorbereiding

• Op welke punten benwijkt jehet eindproduct af van jehet technisch ontwerp afgeweken en zo ja, waarom?
• Zou je achteraf gezien een ander ontwerp hebben gemaakt?
• Is het nuttig om een ontwerp te maken?
• Waarom heb je onderwerpspecifiek "abc"voor wel/nietdeze opgenomendatabase-structuur in(ERD) gekozen?
• Hoe heeft het ontwerp je ontwerp?
geholpen
• Wattijdens isde het belangrijkste onderdeel van het ontwerp?realisatiefase?

Realisatie (Code & Techniek)

• KanKun je de werking van User Story X demonstreren in de applicatie?
• Kun je de code van je belangrijkste algoritme of functie toelichten?
• Stel dat ik de functionele eis "..." toevoeg, waar in de code zou je dit dan implementeren?
• Hoe heb je de veiligheid van de gegevens gewaarborgd? (SQL-injection / XSS)
• Volgens welke code-conventies of standaarden heb je geschreven?
• Kun je de tabelrelaties in je database laten zien via PHPMyAdmin?

Testen & Kwaliteit

• Kun je Test X uit je testrapport nu 'live' uitvoeren?
• Wat was de meest kritieke bug die je tijdens het testen vond en hoe heb je deze opgelost?

Communicatie & Reflectie

• Hoe heb je de gemaakte afspraken met de opdrachtgever vastgelegd?
• Hoe heb je bepaald welk technisch niveau je presentatie moest hebben voor de doelgroep?
• Welke feedback kreeg je tijdens je voortgangsgesprekken en hoe is dit verwerkt in de code?
• Als je naar je eigen proces kijkt, wat zijn dan je drie belangrijkste verbeterpunten voor een volgend project?

Gids: De Code Walkthrough

Als de assessor vraagt: "Laat de code van je inlogsysteem eens zien", is het verleidelijk om simpelweg door de file te scrollen. Doe dit niet. Volg de 'Happy Path' methode.

1. Volg de 'Happy Path'

Leg je code uit aan de hand van een gebruikersactie. Begin niet bij regel 1, maar vertel een verhaal:

• Input: "De gebruiker vult het formulier in op login.php."
• Verwerking: "Zodra er op verzenden wordt geklikt, vang ik de data op en controleer ik eerst met htmlspecialchars() of er geen schadelijke scripts in staan."
• Database: "Daarna gebruik ik een Prepared Statement om de gebruiker op te zoeken in de database. Dit voorkomt SQL-injection."
• Resultaat: "Als het wachtwoord klopt via password_verify(), maak ik een $_SESSION aan en stuur ik de gebruiker naar het dashboard."

2. Benoem je 'Best Practices'

Assessoren 'vinken' begrippen af in hun hoofd. Zorg dat je deze termen letterlijk noemt terwijl je de code aanwijst:

• Don't Repeat Yourself (DRY): "Zoals je hier ziet, gebruik ik include 'header.php', zodat ik de navigatiebalk maar op één plek hoef te onderhouden."
• Separation of Concerns: "Ik heb mijn database-connectie in een apart bestand (db.php) gezet, zodat mijn logica gescheiden blijft van mijn configuratie."
• Datatypen & Validatie: "Bij het invoeren van een kilometerstand (of ticket-ID) controleer ik eerst of het wel echt een int (integer) is."

3. Wees eerlijk over fouten of 'TODO's'

Als een assessor een stukje code aanwijst dat niet perfect is, raak dan niet in paniek. Gebruik het als een kans om je reflectievermogen te tonen:

"Klopt, op deze plek is de validatie nog beperkt. Als ik meer tijd had gehad, had ik hier een Regex-controle toegevoegd om te checken of het kenteken wel aan het Nederlandse formaat voldoet. Dat staat ook in mijn verbeterpunten beschreven."

Presentatie-hacks:

• Zoom in: Gebruik CTRL + in VS Code zodat de assessoren je code goed kunnen lezen op afstand of op een kleiner scherm.
• Dark Mode: Zorg dat je editor een prettig contrast heeft.
• Tabbladen: Zet de belangrijkste bestanden (bijv. db.php, index.php en je CSS) alvast open in je editor voordat je de kamer binnenstapt.

---

Met deze voorbereiding en de checklists hierboven straal je zelfverzekerdheid uit. Je laat zien dat je niet alleen een 'coder' bent, maar een beginnend professional die begrijpt wat hij bouwt en waarom.

Gids: Het ERD Presenteren

De assessor wil niet horen welke tabelnamen je hebt, maar waarom de relaties tussen die tabellen essentieel zijn voor de werking van de applicatie.

1. De "Single Point of Truth"

Begin met de kern: de gebruikers. Leg uit hoe de verschillende entiteiten met elkaar verbonden zijn:

• De Entiteiten: "Ik heb gekozen voor drie kerntabellen: Users, Tickets (of Meldingen) en Categories."
• De Relatie (1-op-N): "De belangrijkste relatie is die tussen de gebruiker en het ticket. Dit is een één-op-veel relatie: één gebruiker kan meerdere meldingen maken, maar een melding hoort altijd bij één specifieke gebruiker."
• Foreign Keys: "Om dit technisch te realiseren, sla ik het user_id op als Foreign Key in de ticket-tabel. Hiermee waarborg ik de data-integriteit."

2. Normalisatie en Efficiëntie

Laat zien dat je hebt nagedacht over een schone database:

"Ik heb de categorieën (Hardware/Software) in een aparte tabel gezet in plaats van als tekst in de ticket-tabel. Hierdoor is mijn database genormaliseerd. Als we later een categorienaam willen aanpassen, hoeft dat maar op één plek in de database en verandert het automatisch voor alle gekoppelde tickets."

3. Voorbereiding op "Stel dat..." vragen

Assessoren testen je ontwerp vaak door een wijziging voor te stellen:

• Vraag: "Stel dat een ticket door meerdere monteurs tegelijk opgepakt moet worden?"
• Jouw antwoord: "In mijn huidige ontwerp is dat een 1-op-N relatie (één monteur per ticket). Om dat mogelijk te maken, zou ik een koppeltabel moeten toevoegen om er een N-op-M relatie (veel-op-veel) van te maken."

Presentatie-hacks voor je ERD:

• Pointer: Gebruik je muis (of een laserpointer) om de lijnen tussen de tabellen aan te wijzen terwijl je de relatie benoemt.
• PK/FK: Wijs expliciet de Primary Key (het gouden sleuteltje) en de Foreign Key aan.
• Legenda: Zorg dat je ERD duidelijk de datatypen laat zien (bijv. INT, VARCHAR(255), DATETIME).

---

Laatste tip: Oefen deze uitleg één keer hardop. Als je de termen Primary Key, Foreign Key en Eén-op-veel relatie vloeiend gebruikt, heb je de helft van de punten voor je database-ontwerp al binnen.

De 5 Meest Gemaakte Fouten

(en hoe ze te voorkomen)

Veel studenten gaan de mist in op zaken die niets met hun code te maken hebben, maar alles met hun houding en voorbereiding.

1. "Ik weet het niet" (Zonder vervolg)

Het is oké om een technisch detail even niet te weten, maar "Ik weet het niet" is een dooddoener.

• De Oplossing: Zeg: "Ik weet de exacte PHP-functie hiervoor niet uit mijn hoofd, maar ik kan je wel de logica uitleggen van hoe ik het heb opgelost..." of "Dat onderdeel heb ik opgezocht in de documentatie van PHP.net."

2. "Het werkte gisteren nog..."

De grootste nachtmerrie van elke student: een demo die crasht. Vaak komt dit door onverwachte updates of een vergeten database-import.

• De Oplossing: Test je applicatie 15 minuten voor het gesprek op de locatie zelf. Maak een back-up van je database (SQL-export) en zet je code eventueel ook op een USB-stick als extra veiligheid.

3. Te passief afwachten

Studenten die alleen "Ja" of "Nee" antwoorden, dwingen de assessor om te blijven 'trekken'. Dit wekt de indruk dat je niet trots bent op je werk.

• De Oplossing: Neem het initiatief. Als een assessor vraagt naar je inlogscherm, vertel dan ook direct waarom je voor die specifieke beveiliging hebt gekozen. Laat zien dat je de expert bent van jouw eigen project.

4. Code laten zien die je niet begrijpt

Als je een stuk code van StackOverflow of AI hebt gebruikt zonder het te begrijpen, val je door de mand zodra de assessor vraagt: "Wat gebeurt er op regel 42?".

• De Oplossing: Gebruik alleen code die je kunt uitleggen. Heb je hulp gehad? Zorg dan dat je elk onderdeel van die code hebt uitgeplozen en kunt verantwoorden.

5. Geen bewijs van testen

Beweren dat je applicatie "bugvrij" is zonder dat je kunt laten zien hoe je dat hebt getest, is ongeloofwaardig.

• De Oplossing: Houd je testrapport bij de hand. Wijs een fout aan die je tijdens het bouwen vond en laat zien hoe je die hebt opgelost. Assessoren houden van studenten die kritisch zijn op hun eigen werk.

---

De "Gouden Regel" voor je gesprek:

"Don't just show, tell why." (Laat niet alleen zien wat je hebt gemaakt?gemaakt,

Kanmaar jevertel uservooral story X laten zien?

Kan je de code van user story X laten zien?

Welke code vondwaarom je het lastigstezo omhebt tegedaan.)

maken,

Je kanhebt nu de projectbriefing, de technische handleidingen, de code-walkthrough gids en de ERD-presentatie. Je bent er helemaal klaar voor. Veel succes met je dat laten zien en uitleggen?

Stel je zou de kleur van ... willen veranderen, waar in de code doe je dat dan?

Kan je jouw database laten zien?

Kan je laten zien waar je commentaar in de code hebt toegevoegd?

Heb je volgens een standaard geprogrammeerd, welke?

Kan je een oude versie van de code laten zien?

Testen

• Kan je test X uitvoeren en laten zien dat het klopt wat je in het testrapport hebt beschreven?
• Welke bevinding is het belangrijkst en waarom?

Verbeterpunten

• Kan je laten zien wat je precies bedoeld met verbeterpunt X?
• Welk verbeterpunt vind jij de belangrijkste en waarom?

Overleggen

• Kun je meer informatie geven over het filmpje?
• Hoe vaak hadden jullie overleg?
• Met wie waren jullie in overleg?
• Wat was jou rol in het overleg?
• Hoe heb jij afspraken vastgelegd en kan je dat laten zien?
• Hoe kan je aantonen dat je ook echt de afspraken bent nagekomen?
• Had je achteraf gezien meer of juist minder overleggen willen hebben, leg uit?

Presenteren

• Kan je vertellen waar en voor wie de presentatie werd gehouden?
• Hoe had jij van tevoren bedacht welk niveau en welk details jouw presentatie moest zijn?
• Kreeg je onverwachte vragen of feedback? Licht toe?
• Wat zou je een volgende keer anders doen als je weer een presentatie moest houden?

Reflectie

• Kun je meer vertellen over de feedback die je kreeg (wanneer was dat, was dat eenmalig, wie gaf je de feedback, hoe kwam het over en hoe regeerde je)?
• Wat heb jij veranderd naar aanleiding van de feedback? Kan je een voorbeeld geven van die verandering?
• Wat zijn de drie belangrijkste verbeterpunten?
• Wat is het nut van het maken een reflectie?

examen!