Exam 2025-2026 Fall
Dates:
- 2025-12-12 hw defence - (preregistration!)
- 2025-12-19 exam and hw defence - last lecture session (preregistration!)
- 2026-01-09 exam and hw defence (preregistration!)
- 2026-01-16 exam and hw defence (preregistration!)
- 2026-01-23 exam
Preregistration is in taltech moodle. Moodle link and key are under communication info.
You can only attend exam when HW is defended!
Exam starts at 9:00 wih theory (pen and paper). After theory is handed in - random practical task is given out.
During practical task implementation - you can be physically whereever (school, home, etc).
Be back to school latest at 18:00 - you must be ready to present your progress with practical task (it should at least compile and run...).
HW defence is from 10:00 - 20:00. After that - when there is nobody currently waiting for exam defence and teachers are still in school.
HW defence is usually divided into 2 (9-13, 16-19) or 3 blocks - 10-13, 14-17, 17-20. You can only choose one day/block.
You must be there at the beginnning of the time period and wait for your turn.
Exam practical part guidelines
Development Approach: MVP First
Read this section carefully. It may save your grade.
Eight hours is not enough time to build everything described below to perfection. That's intentional. We're testing your ability to prioritize and deliver working software under constraints—a core professional skill.
The Golden Rule
A working app with half the features beats a broken app with all the features.
At any point during the exam, you should be able to stop and submit something functional. If you spend 7 hours on a perfect domain model and run out of time before building any UI, you fail. If you build basic CRUD that works and runs out of time, you pass.
Priority Tiers
Structure your work in this order:
Tier 1 — Minimum Viable Product (Hours 1-3) Get these working first. No excuses.
- Database schema and migrations that run cleanly
- Basic CRUD
- Relationships working
- Simple list/detail views
- Application runs without errors
If you only complete Tier 1, you pass - grade 1.
Tier 2 — Core Features (Hours 3-5) The headline functionality.
- Simple search
- Basic business rules
- Form validation
Tier 1 + Tier 2 = solid grade 2-3 territory.
Tier 3 — Full Requirements (Hours 5-7) Complete the specification.
- Advanced filtering combinations
- Full-text search across all fields
- All business rules
- All validation rules
Tier 1 + Tier 2 + Tier 3 = grade 4-5 territory.
Tier 4 — Polish (Hour 7-8) Only if everything else works.
- Toast notifications
- Loading indicators
- Keyboard navigation
- Edge case handling refinements
- Code cleanup and documentation
Grade 5+ territory.
Development Rhythm
-
Commit working code frequently. Every 30-45 minutes, you should have something that compiles and runs.
-
Vertical slices over horizontal layers. Don't build all entities, then all repositories, then all services, then all pages. Build one complete feature end-to-end, then the next.
-
Stub what you skip. If you're not implementing a feature, leave a placeholder—an empty page that says "Not implemented" is better than a broken link or crash.
-
Test as you go. Five minutes of manual testing after each feature saves an hour of debugging at the end.
-
Don't gold-plate early features. Basic scaling that works is better than perfect scaling on an app that doesn't run. You can refine business logic after core CRUD exists.
What We Actually Evaluate
A submission with:
- Working CRUD
- Basic business rules
- Runs without exceptions
...scores higher than a submission with:
- Sophisticated domain model
- Elegant architecture
- Perfect validation rules
- But crashes on startup or has no working UI
Ship software. Not code.
Technical Requirements
- Clean separation between UI, business logic, and data access
- Async/await for all data operations
- Data Annotations for simple field validation
- FluentValidation (or equivalent) for complex business rules
- Proper database indexes for search performance
- Log all queries in development—verify no N+1 problems
- User-friendly error messages; log technical details server-side
UX Requirements
- Mobile-first responsive design
- Confirmation dialogs for destructive actions
- Toast notifications for feedback
- Inline form validation errors
- Loading indicators for async operations
- Full keyboard navigation support
- Accessible allergen indicators (not color-only)
- Dark/Light mode toggle
Evaluation Criteria
| Aspect | Weight |
|---|---|
| Functionality completeness | 30% |
| Code quality and architecture | 25% |
| Validation and error handling | 20% |
| UX and responsive design | 15% |
| Edge case handling | 10% |
Deliverables
- Git repository with complete source code
- Working migrations (must run on empty database)
- Seed data - enough for testing and filtering. Should hit pagination limits.
- README: setup instructions, assumptions made, known limitations, features you're proud of
Design the domain model yourself. Build incrementally. Ship something that works.