Exam practice
Exam #1 2025 practical task
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.
2024-12-05
Restaurant Booking System - Razor Pages Web App
Objective: Create a web application for managing restaurant bookings.
Several restaurants (capacity, location), tables (seat amount), clients (name, email, phone), bookings (number of guests)...
Requirements:
- Implement CRUD operations for restaurants and reservations.
- Allow customers to book a table for a specified date and time.
- Include logic to check the availability of tables based on capacity.
- Provide functionality for customers to view their bookings.
- Search functionality - name & availability & capacity
Generally speaking - these are only broad guidelines. Please write a solution that you would like to present to the world as your best effort in programming and app-designing (UX is the key).
Use nullable references, and turn all the warnings into errors!
2024-11-29
Recipes - Razor Pages Web App
Create a simple application for a recipe book. Recipes, ingredients, amounts of ingredients in recipe. Implement recalculation of amount for servings needed (ie if recipe is for 5 people - how much of everything you need for 2 people). Provide search functionality - recipe name, description, ingredients.
Generally speaking - these are only broad guidelines. Please write a solution that you would like to present to the world as your best effort in programming and app-designing (UX is the key).
Use nullable references, and turn all the warnings into errors!