Software Engineering

Explain why using Git is better than using, for instance, Google Drive or OneDrive.

Git biedt gedetailleerd versiebeheer, maakt samenwerken via aparte branches mogelijk en bewaart volledige projectgeschiedenis, waardoor ontwikkelteams veilig en gestructureerd kunnen werken.

How does Git track changes in files, and what is the purpose of the staging area?

Git slaat bij elke commit een snapshot van versiegegevens op, en vergelijkt deze met voorgaande snapshots. De staging area laat je nauwkeurig bepalen welke wijzigingen je opneemt in de volgende commit.

What is a commit in Git, and what information does it contain?

Een commit is een permanente snapshot van de repository met metadata zoals auteur, datum/tijd en een omschrijvende commit message.

What is the difference between a branch and a commit in Git?

Een commit is een vastgelegde momentopname van alle bestanden, terwijl een branch een verwijzing is naar een reeks commits die meegroeit bij elke nieuwe commit.

What is the difference between a branch and a tag in Git?

Een branch evolueert mee met nieuwe commits, terwijl een tag een statische verwijzing is naar één specifieke commit.

What happens when you create a new branch? How does Git internally track branches?

Git maakt een nieuwe pointer aan (refs/heads/branchnaam) die verwijst naar een bestaande commit; bij elke nieuwe commit op die branch verschuift de pointer automatisch naar de nieuwe commit.

Explain the 'three trees' in Git: the working directory, the staging area and the commit history.

De working directory bevat je bewerkbare bestanden; de staging area is een tussentabel van wijzigingen klaar voor commit; de commit history bewaart alle snapshots (commits) chronologisch.

What is the difference between a local repository and a remote repository in Git?

Een local repository staat op je eigen machine en bevat al je branches en commits; een remote repository staat op een server en dient als gedeelde centrale voor samenwerking.

How can you add a new remote repository, and why might you need multiple remotes?

Met git remote add <naam> <url> voeg je een extra server toe; meerdere remotes gebruik je bijvoorbeeld voor verschillende forks, staging‐omgevingen of backup‐servers.

Explain the difference between git fetch and git pull.

git fetch haalt nieuwe commits van de remote binnen zonder ze te integreren; git pull doet een fetch én voegt de updates direct samen in je huidige branch.

Explain the difference between merging and rebasing. When should each be used?

Mergen voegt twee branches samen en bewaart de volledige geschiedenis; rebasing herschrijft commits op een nieuwe basis voor een lineaire geschiedenis. Gebruik merge voor veilige, traceerbare integratie; rebase voor een schonere, makkelijk leesbare log.

What does git reset do, and how does it differ from git revert?

git reset verplaatst de HEAD-pointer en kan staging of werkomgeving aanpassen (geschiedenis herschrijven), terwijl git revert een nieuwe commit maakt die de veranderingen van een eerdere commit ongedaan maakt.

What are the three different modes of git reset (--soft, --mixed, --hard), and how do they affect the working directory, staging area, and commit history?

--soft verplaatst alleen HEAD (staging en werkomgeving onveranderd); --mixed (standaard) reset de staging area maar behoudt werkomgeving; --hard overschrijft HEAD, staging area én werkomgeving.

Explain how git rebase lets you 'rewrite history'.

Rebase pakt commits van je branch, “plakt” ze één voor één opnieuw bovenop een andere commit en creëert zo nieuwe commit-id’s, waardoor de geschiedenis verandert.

What is git stash, and why is it useful?

git stash slaat onvoltooide wijzigingen tijdelijk op zodat je snel van branch kunt wisselen zonder commit-‘rommel’ achter te laten.

How does git stash differ from git reset and git restore when dealing with uncommitted changes?

git stash bewaart je wijzigingen in een aparte stack; git reset en git restore halen wijzigingen terug naar de laatste commit en kunnen je werk permanent laten verdwijnen.

Explain the difference between the following 'branching models': trunk-based development and feature branches.

Trunk-based development werkt continu op de hoofdbranch met korte-lived feature toggles, terwijl feature branches aparte, langere takken zijn voor elke functionaliteit die later gemerged worden.

Explain how a workflow with Pull Requests looks like.

Je maakt een feature branch, pusht deze naar de remote, opent een Pull Request waarin je veranderingen worden besproken, reviewed en tenslotte gemerged na goedkeuring.

Why is working with Pull Requests so encouraged?

Pull Requests stimuleren code‐reviews, kennisdeling, discussie over wijzigingen en kwaliteitscontrole voordat ze in de hoofdbranch terechtkomen.

Why should you use .gitignore, and how do you set it up?

.gitignore voorkomt dat tijdelijke, build- of gevoelige bestanden gecommit worden; je zet het op door per regel een wildcard of pad op te nemen in het .gitignore-bestand.

Why is it a bad practice to commit large, unrelated changes in a single commit?

Zulke commits zijn moeilijk te reviewen, te testen en te herroepen; kleinere, thematische commits verbeteren traceerbaarheid en herstelbaarheid.

What does it mean to "rewrite history" in Git, and why would you want to do it?

Geschiedenis herschrijven betekent commits wijzigen, verwijderen of herschikken (via rebase of filter-branch) bijvoorbeeld om fouten te verbergen of je log te schonen.

What are the risks of rewriting history, especially in shared repositories?

Je kunt andermans werk overschrijven, duplicaten of merge-conflicten introduceren en de geschiedenis voor anderen breken.

Explain why reverting an unwanted commit (eg, committing a password) does not make that mistake invisible.

Omdat de originele commit nog steeds in de geschiedenis staat en via Git-tools eenvoudig terug te vinden is.

What does it mean to have an Agile mindset in software development?

Een Agile mindset is iteratief, klantgericht en adaptief werken met focus op samenwerking, feedback en voortdurende verbetering.

How are Scrum, Kanban, Extreme Programming, … and other Software Methodologies different from Agile?

Agile zijn de onderliggende waarden en principes; Scrum, Kanban en XP zijn concrete frameworks of practices die deze principes implementeren.

Explain how you can work with Scrum or Kanban but still not be working in an Agile way.

Als je ceremonies en borden mechanisch volgt zonder feedback, samenwerking of flexibiliteit, volg je wel de vorm, maar niet de Agile geest.

Explain how Scrum works in broad terms.

Scrum organiseert werk in vaste sprints met rollen (Product Owner, Scrum Master, Team), ceremonies (Planning, Daily, Review, Retrospective) en een geprioriteerde backlog.

What is a Daily Standup (also called Daily Scrum), and what is discussed during it?

Een korte dagelijkse meeting waarin teamleden aangeven wat ze gedaan hebben, wat ze gaan doen en welke blokkades er zijn.

What is Sprint Planning, and how does the team determine what to work on?

De sprintplanning selecteert user stories uit de backlog op basis van prioriteit en beschikbare capaciteit, waarna het werk wordt opgesplitst en toegewezen.

What happens in a Sprint Review, and who participates?

Het team demonstreert de opgeleverde functionaliteit aan stakeholders, verzamelt feedback en evalueert voortgang. Stakeholders, Product Owner en Team zijn aanwezig.

What is a Sprint Retrospective, and why is it important?

Een reflectie-meeting na de sprint om successen en verbeterpunten te bespreken en acties af te spreken voor de volgende sprint.

What happens if a team doesn’t complete all Sprint tasks?

Onvoltooide items gaan terug naar de backlog of het volgende sprintplan; ze kunnen opnieuw ingeschat en ingepland worden.

Why should Scrum teams avoid extending the Sprint length?

Verlenging ondermijnt voorspelbaarheid, cadans en het leerproces binnen korte iteraties.

What are the three main roles in Scrum, and what are their responsibilities?

Product Owner (prioriteren en stakeholder-interface), Scrum Master (procesbewaker en obstakels wegnemen), Development Team (levert werkende software).

Explain how Kanban works in broad terms.

Kanban visualiseert werk op een bord met kolommen, beperkt werk in uitvoering (WIP-limieten) en optimaliseert flow en doorlooptijd.

Explain the steps that your code takes from being written on your own laptop to being deployed on Azure.

Code lokaal schrijven → commit en push naar Git → CI/CD‐pipeline bouwt, test en valideert → artefacten (bijv. containers) worden naar Azure Registry gepusht → Azure Deploymentservice haalt artefacten op en organiseert rollout.

How do you handle sensitive information (like credentials) within CI/CD pipelines?

Gevoelige data sla je op als beveiligde secrets of variabelen in de CI/CD-omgeving, niet in de code of in git.

Why is it beneficial to store build artifacts in a package registry before deploying them?

Het zorgt voor reproduceerbare, versieerbare builds die hergebruikt en geauditeerd kunnen worden, en versnelt de deployment.

How does CI/CD help avoid bugs from getting into production?

Door elke wijziging automatisch te bouwen en te testen (unit, integratie, statische analyse), worden fouten vroeg gedetecteerd.

How does CI/CD help prevent human error?

Automatisering van build-, test- en deploy‐stappen reduceert handmatige handelingen en daarmee de kans op vergissingen.

Describe the test pyramid. What are the key differences between the different layers?

De testpiramide bestaat uit veel unit tests (snel, geïsoleerd), minder integratietests (samenhang tussen componenten) en weinig E2E-tests (volledige gebruikersstromen, trager).

Why is it preferable to have a test pyramid instead of a test "ice cream cone"?

Een piramide garandeert snelle, betrouwbare tests eerst; een ice cream cone (meer E2E dan unit) leidt tot trage, fragiele tests en vertraging.

Explain the Test Driven Development method. How can you benefit from TDD?

Bij TDD schrijf je eerst een mislukte test, dan de code om de test te laten slagen en tenslotte refactor je; dit leidt tot beter ontwerp, minder bugs en hoge testdekking.

You encounter a bug in your code. What steps do you take to resolve your bug and ensure it does not reoccur?

Bug reproduceren → root cause analyseren → fix implementeren → nieuwe test toevoegen → code review → commit en deploy.

What is the Software Development LifeCycle (SDLC)?

De SDLC is het gestructureerde proces van planvorming tot onderhoud voor het ontwikkelen van software.

What are the main phases of the SDLC?

Planning → Analyse → Ontwerp → Implementatie → Testen → Onderhoud.

What happens in the planning phase of the SDLC?

Scope, doelen, resources, risico’s en tijdlijnen worden gedefinieerd.

What happens in the analysis phase of the SDLC?

Functionele en niet‐functionele eisen worden verzameld en gedocumenteerd.

What happens in the design phase of the SDLC?

Technische architectuur, data‐ en component‐ontwerp worden uitgewerkt.

What happens in the implementation phase of the SDLC?

Ontwikkelaars schrijven de code volgens het ontwerp en bouwen de software.

What happens in the testing phase of the SDLC?

De software wordt getest op functionaliteit, performance en beveiliging tegen de eisen.

What happens in the maintenance phase of the SDLC?

Na oplevering worden bugs verholpen, updates en verbeteringen doorgevoerd.

How is the SDLC related to Agile methodologies?

Agile doorloopt dezelfde fasen, maar in korte iteraties met continue feedback en adaptatie.

What is requirements gathering, and why is it important?

Het gestructureerd verzamelen en vastleggen van wensen en behoeften om een oplossing te bouwen die aan verwachtingen voldoet.

What are the differences between functional and non-functional requirements?

Functioneel beschrijft wat het systeem moet doen; niet-functioneel beschrijft hoe het systeem moet presteren (bv. snelheid, veiligheid).

Who are the key stakeholders involved in gathering requirements?

Klanten, eindgebruikers, Product Owner, business-analisten en technische experts.

How do you handle conflicting requirements from different stakeholders?

Prioriteren, compromis zoeken en duidelijke communicatie zodat de meest waardevolle eisen bovenaan komen te staan.

How do you ensure that stakeholders provide clear and realistic requirements?

Door gerichte vragen, voorbeelden en prototypes te gebruiken en haalbaarheid met het team te valideren.

What are the common methods for ensuring requirements are correct and complete?

Interviews, workshops, user stories, prototyping en validatiesessies met stakeholders.

What role does the product owner play in reviewing and approving requirements?

De Product Owner bewaakt de productvisie en beslist welke requirements in de backlog komen en wanneer ze worden opgepakt.

What is user story mapping, and why is it useful in Agile?

Een visuele techniek om gebruikersreizen en features te ordenen, zodat je samenhangend en incrementeel waarde kunt leveren.

What is a user story?

Een korte beschrijving van functionaliteit vanuit het perspectief van de gebruiker, meestal volgens het format “Als wil ik zodat ”.

How do user stories fit into frameworks like Scrum and Kanban?

In Scrum vormen user stories het werk dat tijdens sprints wordt ingepland; in Kanban stromen ze door het bord van to-do naar done.

How do personas help in writing more relevant user stories?

Persona’s representeren typische gebruikers met doelen en frustraties, zodat stories aansluiten bij werkelijke behoeften.

What key details should a good persona include?

Achtergrond, doelen, gedrag, frustraties en context van de gebruiker.

What are acceptance criteria, and how do you define them properly?

Duidelijke, meetbare voorwaarden die beschrijven wanneer een user story als voltooid geldt. Ze moeten specifiek en testbaar zijn.

How do you ensure that requirements are testable and verifiable?

Door acceptatiecriteria SMART (Specifiek, Meetbaar, Acceptabel, Realistisch, Tijdgebonden) te formuleren.

What happens if acceptance criteria are too vague or incomplete?

Dan ontstaan misverstanden, onvolledige implementaties en kunnen stories bij review worden afgekeurd.

Give an example of a good and a bad user story.

Goed: "Als klant wil ik mijn bestelling online kunnen volgen zodat ik weet wanneer het aankomt." en Slecht: “Voeg track & trace toe.”

What is the difference between a conceptual data model and a logical data model?

Een conceptueel model definieert de belangrijkste entiteiten en relaties zonder technische details; een logisch model voegt datatypes, attributen en normalisatie toe.

How does a domain model differ from a data model?

Een domain model beschrijft concepten en gedragingen in de bedrijfs- of probleemruimte; een data model richt zich op hoe gegevens worden gestructureerd en opgeslagen.

What is a sequence diagram, and how does it represent interactions?

Een UML-diagram dat de volgorde van berichten toont tussen objecten of componenten over tijd tijdens een use case.

What is Flyway, and why is it used in database migrations?

Flyway is een tool voor gestructureerde, versiebeheerde database-migraties via genummerde scripts, waardoor schema-wijzigingen consistent en reproduceerbaar zijn.

What are the core principles behind Flyway?

Lineaire migraties, consistente versiebeheer, checksum-controle en een schema history-tabel voor statusbewaking.

How do you apply a change to the database schema using Flyway?

Je maakt een nieuw genummerd SQL- of Java-migratiescript aan in de migratiefolder; bij uitvoeren past Flyway het script toe en registreert het in de history-tabel.

How does Flyway keep track of which migrations have been executed?

Door elk script en checksum op te slaan in de database-tabel flyway_schema_history.

What happens if you modify an already applied migration script?

Flyway detecteert een checksum mismatch en faalt, om de integriteit van de migratiehistorie te waarborgen.

Why should you be very careful with modifying the schema history table?

Handmatige aanpassingen kunnen leiden tot inconsistente migratiestatus en onvoorspelbare database-problemen.

What are Spring profiles, and why are they useful?

Spring profiles laten je verschillende configuraties definiëren en activeren per omgeving (dev, test, prod), zodat je één codebase kunt gebruiken met variabele settings.

How do you define separate configuration for a Spring profile in a Spring Boot application?

Door aparte `application-.yml` of `.properties` bestanden te maken of `@Profile` annotaties in je beans te gebruiken.

How do you activate a specific profile in application.properties or application.yml?

Stel `spring.profiles.active=` in binnen je hoofdbestand.

How can you activate a Spring profile using command-line arguments?

Start de applicatie met `--spring.profiles.active=`.

How do you set up multiple configuration files for different environments (e.g., dev, test, prod)?

Maak voor elk profiel een eigen bestand application-dev.yml, application-test.yml, application-prod.yml, en activeer het juiste profiel.

What is the default profile in Spring Boot if no profile is explicitly set?

Het default profiel.

What is Behavior-Driven Development (BDD) and what are its benefits?

BDD is een samenwerkingstechniek waarbij ontwikkelaars, testers en business gezamenlijk gedragsspecificaties schrijven, wat leidt tot betere afstemming en duidelijkere tests.

What are the key principles of BDD?

Samenwerking, duidelijke taal (Ubiquitous Language) en tests gebaseerd op acceptatiecriteria.

How does BDD differ from Test-Driven Development (TDD)?

BDD centreert zich op gedrags-eisen en samenwerking vóór het schrijven van code, terwijl TDD puur focust op het schrijven van tests voorafgaand aan code.

What are the three phases of the BDD process?

Discovery (verzamelen van features), Formulation (opstellen van scenarios in Gherkin), Automation (uitvoeren en integreren van scenarios).

How does BDD promote collaboration between developers, testers, and business stakeholders?

Door gemeenschappelijke feature- en scenario-taal te gebruiken en gezamenlijke specificatie-sessies te houden.

What is the role of Gherkin in BDD?

Gherkin is de leesbare, gestructureerde taal voor het schrijven van BDD-scenarios met sleutelwoorden als Given/When/Then.

How does Gherkin syntax structure feature files in BDD?

Feature files bevatten een Feature-beschrijving, gevolgd door Scenarios met stappen gemarkeerd door Given, When, Then, And, But.

What are the common keywords used in Gherkin scenarios?

Given, When, Then, And, But.

What is the purpose of scenario outlines in Gherkin?

Met scenario outlines kun je één scenario herhalen met meerdere datarijen (Examples-tabel).

What is the difference between scenario outlines and examples in Gherkin?

Scenario outlines definiëren de stapensjabloon; Examples levert de variaties van invoerwaarden.

What is Cucumber and how does it support BDD?

Cucumber is een testframework dat Gherkin-featurefiles kan lezen en gekoppelde stapdefinities in code uitvoert.

What are the key components of Cucumber?

Feature files, step definitions (bindings tussen Gherkin en code) en test runner.

How does Cucumber integrate with Gherkin to execute BDD scenarios?

Cucumber parsers de Gherkin-bestanden, matcht elke stap met een stapdefinitie in code en voert die uit.

What is Cypress?

Cypress is een modern end-to-end testframework voor webapplicaties met realtime reloads, debugging en eenvoudige API.

How can you integrate Cypress with Cucumber to execute BDD scenarios?

Met de cypress-cucumber-preprocessor plugin kun je Gherkin-featurefiles koppelen aan Cypress testbestanden.