Add Home

Home.md

@@ -0,0 +1,857 @@
+# TECHNICAL CASE STUDY  
+## WorkspaceHub — Coworking Reservation & Operations Platform
+
+**Expected Duration:** 7–10 Days  
+**Delivery Method:** Private Git Repository  
+**Application Type:** Fullstack Web Application
+
+---
+
+## CONFIDENTIALITY AND REPOSITORY POLICY
+
+This technical case study and all materials supplied as part of the recruitment process are intended solely for evaluation purposes.
+
+The completed project must be stored in a **private repository**. The candidate may use a platform of their choice, including GitHub, GitLab, Bitbucket, or another Git hosting service, provided that the repository is not publicly accessible.
+
+The repository must be shared only with the people specified during the recruitment process.
+
+Publishing the source code, screenshots, project documents, or case-study details publicly during the evaluation process is not permitted.
+
+---
+
+# 1. PROJECT OVERVIEW
+
+WorkspaceHub is a web-based coworking reservation and operations platform.
+
+The platform allows individual users to discover coworking locations, inspect available workspace resources, and create reservations.
+
+Coworking locations are managed by designated **Managers**, while platform-wide administration and operational visibility are provided through an **Admin Dashboard**.
+
+The objective of this case study is not simply to implement CRUD screens.
+
+The application should demonstrate the candidate's ability to design and implement a maintainable end-to-end system containing:
+
+- a modern frontend application,
+- a backend API,
+- authentication and authorization,
+- relational data persistence,
+- business rules,
+- reservation and availability logic,
+- resource management,
+- administrative dashboards,
+- operational resource visibility,
+- appropriate error handling,
+- and maintainable software architecture.
+
+The system should be usable from end to end.
+
+---
+
+# 2. TECHNOLOGY REQUIREMENTS
+
+The candidate may choose one technology from each category.
+
+### Frontend
+
+- React
+- Next.js
+
+### Backend
+
+- NestJS
+- Java Spring Boot
+
+### Database
+
+- PostgreSQL
+- MariaDB
+
+Alternative core frameworks or databases should not be substituted.
+
+Libraries, ORMs, component libraries, state-management solutions, authentication libraries, build tools, and other supporting technologies may be selected by the candidate.
+
+---
+
+# 3. PROJECT STRUCTURE
+
+The entire project must be delivered through **one Git repository**.
+
+Frontend and backend applications must exist as separate top-level parts of the same repository.
+
+Any additional project components such as scripts, documentation, Docker configuration, database migrations, or infrastructure configuration should also remain within the same repository.
+
+The project should be reproducible by another developer using the instructions provided in the repository.
+
+A live deployment is **not required**.
+
+---
+
+# 4. USER ROLES
+
+WorkspaceHub must support three primary roles.
+
+## 4.1 Customer
+
+Customers are individual users looking for coworking resources.
+
+A Customer should be able to:
+
+- register and authenticate,
+- browse available coworking locations,
+- inspect location and resource information,
+- search or filter suitable workspaces,
+- check availability,
+- create reservations,
+- view their existing and previous reservations,
+- cancel reservations where allowed.
+
+A Customer must not be able to access another customer's private reservation information or management functionality.
+
+---
+
+## 4.2 Manager
+
+Managers operate coworking locations assigned to them by an Administrator.
+
+Managers should be able to manage operational information related to their assigned location or locations, including:
+
+- coworking location information,
+- working/opening hours,
+- reservable resources,
+- resource availability,
+- maintenance or temporary blocking periods,
+- reservations,
+- resource usage information.
+
+A Manager must only be able to manage and observe locations assigned to that Manager.
+
+Managers do not onboard themselves onto the platform.
+
+Location and Manager assignments are controlled administratively.
+
+---
+
+## 4.3 Administrator
+
+Administrators operate WorkspaceHub at platform level.
+
+An Administrator should have access to global management functionality including:
+
+- coworking locations,
+- Managers,
+- Customers,
+- resources,
+- reservations,
+- resource operational information,
+- platform-wide resource utilization information.
+
+Administrative authorization must be enforced by the backend and must not depend solely on hiding frontend controls.
+
+---
+
+# 5. COWORKING LOCATIONS
+
+WorkspaceHub supports multiple coworking locations.
+
+Each location should contain enough information for Customers to understand the workspace and determine whether it is suitable for their reservation.
+
+Locations should also define operational information such as opening hours and available workspace resources.
+
+The exact persistence model and data organization are left to the candidate.
+
+Administrators assign Managers to locations.
+
+Managers may then manage the locations for which they are responsible.
+
+---
+
+# 6. RESERVABLE RESOURCES
+
+The application must support **at least three distinct workspace resource types**.
+
+The mandatory baseline should include the following concepts.
+
+## 6.1 Hot Desk
+
+Hot Desks represent a shared-capacity workspace.
+
+Reservations are primarily **daily**.
+
+Unlike an exclusive room, multiple Customers may reserve Hot Desk capacity for the same date as long as sufficient capacity remains.
+
+For example:
+
+```text
+Hot Desk Area
+
+Total Capacity: 20
+
+Already Reserved: 15
+New Request: 3
+
+Result:
+Reservation can be accepted.
+```
+
+However:
+
+```text
+Total Capacity: 20
+
+Already Reserved: 18
+New Request: 4
+
+Result:
+Reservation must be rejected.
+```
+
+The system must correctly calculate remaining capacity.
+
+---
+
+## 6.2 Meeting Room
+
+Meeting Rooms represent exclusive resources.
+
+Reservations are based on a **time interval**.
+
+Two reservations for the same Meeting Room must not overlap.
+
+For example:
+
+```text
+Existing Reservation
+10:00 – 11:00
+
+Requested Reservation
+10:30 – 11:30
+
+Result:
+Reservation must not be accepted.
+```
+
+Adjacent reservations that do not overlap may be accepted where other business rules allow them.
+
+---
+
+## 6.3 Private Office
+
+Private Offices represent another exclusive workspace resource.
+
+A Private Office should primarily support **daily reservation** rather than hourly Meeting Room-style usage.
+
+A Private Office that has already been reserved for a date must not be simultaneously allocated to another Customer for the same period.
+
+---
+
+Candidates may introduce additional resource types if their implementation supports them appropriately.
+
+Adding additional resource types is not required for completion of the case study.
+
+---
+
+# 7. RESOURCE STATUS AND AVAILABILITY
+
+Resources must have an operational state.
+
+At minimum, the system should distinguish between resources that are:
+
+- active,
+- inactive,
+- under maintenance.
+
+A resource that is inactive or unavailable due to maintenance must not accept reservations that conflict with its unavailable period.
+
+Managers must also be able to define temporary blocking or maintenance periods.
+
+For example:
+
+```text
+Meeting Room A
+
+Blocked Period:
+18 September
+13:00 – 17:00
+
+Reason:
+Maintenance
+```
+
+A Customer attempting to reserve that resource during the blocked period should not be allowed to complete the reservation.
+
+Availability therefore depends on more than whether an existing reservation is present.
+
+Depending on the resource type, the application may need to consider:
+
+- location opening hours,
+- resource operational status,
+- maintenance/blocking periods,
+- existing reservations,
+- resource capacity,
+- requested number of users,
+- requested date or time interval.
+
+How this logic is structured internally is left to the candidate.
+
+---
+
+# 8. CUSTOMER RESERVATION FLOW
+
+The application should provide a complete Customer booking experience.
+
+A typical flow may include:
+
+```text
+Register / Login
+        ↓
+Browse Coworking Locations
+        ↓
+Search / Filter
+        ↓
+View Location
+        ↓
+Select Resource
+        ↓
+Select Date / Time / Capacity
+        ↓
+Check Availability
+        ↓
+Review Reservation
+        ↓
+Create Reservation
+        ↓
+Reservation Confirmation
+        ↓
+My Reservations
+```
+
+The exact screen structure and navigation are left to the candidate.
+
+No predefined UI design or wireframe will be supplied.
+
+The resulting application should nevertheless provide a clear and usable experience.
+
+---
+
+# 9. SEARCH AND DISCOVERY
+
+Customers must be able to browse available coworking locations and resources.
+
+The application should provide meaningful filtering or search capabilities appropriate to the domain.
+
+Examples may include criteria such as:
+
+- location,
+- date,
+- resource type,
+- requested capacity,
+- availability.
+
+Candidates may introduce additional filters where appropriate.
+
+Search and filtering should operate against application data rather than being implemented only as static frontend behavior.
+
+---
+
+# 10. RESERVATION BUSINESS LOGIC
+
+Reservation creation is one of the primary parts of this case study.
+
+The backend must validate whether a requested reservation can actually be made.
+
+Frontend validation alone is insufficient.
+
+A reservation should only be accepted when all relevant business requirements are satisfied.
+
+This includes correctly handling the difference between:
+
+- capacity-based resources,
+- exclusive hourly resources,
+- exclusive daily resources.
+
+The application must prevent invalid or conflicting reservations.
+
+Reservation logic should also appropriately account for resource availability and location operating conditions.
+
+The candidate may define reasonable additional reservation and cancellation rules.
+
+Such decisions should be documented briefly in the project documentation.
+
+---
+
+# 11. RESERVATION LIFECYCLE
+
+Reservations should have a meaningful lifecycle rather than existing only as static records.
+
+The candidate should define appropriate reservation states and rules for transitions between those states.
+
+At minimum, the system must support the concepts required to distinguish active reservations from cancelled reservations.
+
+Other lifecycle concepts may be introduced where they improve the implementation.
+
+Invalid state transitions should be prevented.
+
+The candidate is expected to make reasonable business decisions and document important assumptions.
+
+---
+
+# 12. PRICING
+
+Each reservable resource should have pricing appropriate to its reservation model.
+
+For example:
+
+- Hot Desk pricing may depend on days and number of people.
+- Meeting Room pricing may depend on reserved time.
+- Private Office pricing may depend on the number of reserved days.
+
+The backend must calculate the authoritative reservation price.
+
+The application must not rely on a total price supplied by the frontend.
+
+For example:
+
+```text
+Meeting Room
+Price: 20 / hour
+
+Reservation:
+09:00 – 11:30
+
+Calculated Duration:
+2.5 hours
+
+Calculated Total:
+50
+```
+
+No real payment-provider integration is required.
+
+Payment processing is outside the mandatory scope.
+
+---
+
+# 13. MANAGER OPERATIONS
+
+Managers must be able to operate the coworking locations assigned to them.
+
+The management interface should allow a Manager to perform the essential operations required to keep a location functioning.
+
+This includes resource configuration, operational status management, reservations, availability, and temporary resource restrictions.
+
+The Manager should also have visibility into how resources in their assigned locations are currently being used.
+
+Manager data must be restricted to the Manager's assigned locations.
+
+---
+
+# 14. ADMIN DASHBOARD
+
+WorkspaceHub must contain an administrative dashboard.
+
+The dashboard should provide both management capabilities and useful operational information.
+
+It should not simply be a collection of unrelated CRUD forms.
+
+The Administrator should be able to gain a meaningful overview of the current state of the WorkspaceHub platform.
+
+---
+
+# 15. RESOURCE OPERATIONAL VISIBILITY
+
+An important objective of the Admin Dashboard is to provide visibility into coworking resource usage.
+
+This refers to **business/resource monitoring**, not DevOps infrastructure monitoring.
+
+The dashboard should allow an Administrator to understand information such as:
+
+- overall resource availability,
+- active/inactive/maintenance resources,
+- currently occupied resources,
+- remaining Hot Desk capacity,
+- current and upcoming reservations,
+- resource utilization,
+- location-level resource usage,
+- maintenance and blocked resources.
+
+For example:
+
+```text
+RESOURCE OVERVIEW
+
+Total Resources       42
+Active                36
+Maintenance            4
+Inactive               2
+
+Meeting Rooms Occupied
+7 / 12
+
+Hot Desk Utilization
+68%
+```
+
+The exact visualization is left to the candidate.
+
+---
+
+# 16. RESOURCE UTILIZATION
+
+The Admin Dashboard should provide basic utilization information calculated from actual system data.
+
+The purpose is to demonstrate that the candidate can transform transactional application data into useful operational information.
+
+Examples could include:
+
+```text
+Most Utilized Resources
+
+Meeting Room A       82%
+Hot Desk Area        71%
+Private Office B     58%
+```
+
+or aggregated information such as:
+
+```text
+Location A
+Resource Utilization: 74%
+
+Location B
+Resource Utilization: 51%
+```
+
+The candidate should determine a reasonable definition of utilization for the different resource types.
+
+The implementation and calculation strategy should be documented where the chosen behavior is not immediately obvious.
+
+---
+
+# 17. MANUAL DATA REFRESH
+
+Resource monitoring information must be refreshable without requiring the Administrator or Manager to reload the entire browser page.
+
+At least one clear manual refresh mechanism must be available for operational dashboard information.
+
+For example:
+
+```text
+Resource Overview                         [Refresh]
+
+Active      Occupied      Maintenance
+  32           14              3
+```
+
+Activating the refresh action should request current data from the backend and update the relevant interface.
+
+Appropriate user feedback should be provided while refreshing or when a refresh fails.
+
+Automatic real-time updates are **not mandatory**.
+
+---
+
+# 18. AUTHENTICATION AND AUTHORIZATION
+
+The application must implement authentication.
+
+Authentication must be backed by the server.
+
+Credentials must be handled securely and passwords must not be stored in plain text.
+
+Authorization rules must also be enforced server-side.
+
+Examples include:
+
+- Customers cannot access other Customers' reservations.
+- Managers cannot manage locations assigned to another Manager.
+- Customers cannot access Manager or Admin operations.
+- Managers cannot gain platform-wide administrative access.
+- Administrator functionality must require appropriate authorization.
+
+The exact authentication mechanism is left to the candidate.
+
+---
+
+# 19. DATA PERSISTENCE AND MODELLING
+
+All important application information must be persisted using either PostgreSQL or MariaDB.
+
+The candidate is responsible for designing an appropriate relational data model based on the requirements in this document.
+
+The data model should correctly support:
+
+- user roles and ownership,
+- coworking locations,
+- resources,
+- availability,
+- reservations,
+- pricing,
+- maintenance/blocking,
+- resource usage information.
+
+No predefined database schema is provided.
+
+Database structure, relationships, constraints, indexing decisions, and persistence approach form part of the technical assessment.
+
+The project should contain a practical method for initializing the database and providing enough sample data to demonstrate the application.
+
+---
+
+# 20. BACKEND ENGINEERING EXPECTATIONS
+
+The backend should be structured as maintainable application code rather than a collection of tightly coupled handlers.
+
+The project must demonstrate:
+
+- Object-Oriented Programming principles,
+- SOLID principles,
+- appropriate separation of responsibilities,
+- reusable business logic,
+- input validation,
+- predictable error handling,
+- authorization enforcement,
+- maintainable configuration management.
+
+Business logic such as reservation validation, availability, pricing, and authorization should not be duplicated unnecessarily.
+
+Environment-specific configuration and sensitive values should not be hardcoded directly into source code.
+
+Candidates are free to determine the internal architecture.
+
+---
+
+# 21. FRONTEND ENGINEERING EXPECTATIONS
+
+The frontend must provide a usable end-to-end interface for the required roles.
+
+The implementation should demonstrate appropriate handling of:
+
+- navigation,
+- authentication state,
+- authorization-aware screens,
+- forms,
+- validation feedback,
+- server errors,
+- loading states,
+- empty states,
+- manual data refresh,
+- data tables or suitable administrative views,
+- Customer reservation interactions.
+
+The frontend must interact with the implemented backend rather than relying on hardcoded application data for the primary workflows.
+
+Frontend structure, component organization, styling approach, data-fetching approach, and state-management strategy are left to the candidate.
+
+---
+
+# 22. ERROR HANDLING
+
+The system should handle predictable failure cases cleanly.
+
+Examples include:
+
+- invalid login information,
+- inaccessible resources,
+- invalid reservation requests,
+- unavailable resources,
+- reservation conflicts,
+- insufficient resource capacity,
+- invalid user input,
+- unauthorized operations,
+- backend or network errors.
+
+Errors should produce meaningful application behavior rather than unhandled exceptions or broken screens.
+
+Technical details that should not be exposed to end users should remain appropriately protected.
+
+---
+
+# 23. CODE QUALITY
+
+Code quality is an important part of the evaluation.
+
+Candidates are expected to produce code that another developer could reasonably understand and continue developing.
+
+Attention should be given to:
+
+- meaningful naming,
+- manageable class/function/component sizes,
+- separation of responsibilities,
+- avoiding unnecessary duplication,
+- appropriate abstractions,
+- consistent coding conventions,
+- dependency management,
+- project organization,
+- maintainability.
+
+Completing more features does not compensate for an unnecessarily difficult-to-maintain implementation.
+
+---
+
+# 24. AI TOOL USAGE
+
+Use of AI-assisted development tools is **fully permitted**.
+
+Candidates may use tools such as coding assistants, large language models, IDE assistants, or other AI-based development services.
+
+AI usage does not negatively affect the evaluation.
+
+However, candidates must include a short section in the project documentation explaining:
+
+- which AI tools were used,
+- approximately what they were used for.
+
+A short explanation is sufficient.
+
+For example:
+
+```text
+AI Usage
+
+GitHub Copilot:
+Used for code completion and repetitive DTO/component generation.
+
+ChatGPT:
+Used to discuss reservation conflict edge cases and improve README wording.
+```
+
+Candidates should be prepared to explain the submitted implementation and technical decisions regardless of whether AI tools were used.
+
+---
+
+# 25. README REQUIREMENTS
+
+A `README.md` must be included in the repository.
+
+It should provide sufficient information for another developer to understand, install, and run the application.
+
+At minimum, documentation should explain:
+
+- project purpose,
+- technology choices,
+- prerequisites,
+- environment configuration,
+- database setup,
+- frontend startup,
+- backend startup,
+- how to access/test the required roles,
+- important business assumptions,
+- significant architectural decisions,
+- known limitations,
+- AI tools used during development.
+
+Setup instructions should be reproducible.
+
+---
+
+# 26. OPTIONAL IMPROVEMENTS
+
+Candidates are welcome to extend the project beyond the mandatory requirements.
+
+Additional functionality or engineering improvements may be considered positively when they are relevant, correctly implemented, and do not reduce the quality of the mandatory functionality.
+
+Examples of possible areas include:
+
+- automated tests,
+- Docker / Docker Compose,
+- API documentation,
+- live deployment,
+- automated dashboard updates,
+- WebSocket or Server-Sent Events,
+- more advanced search/filtering,
+- pagination,
+- additional resource types,
+- richer reservation workflows,
+- audit/activity tracking,
+- notification mechanisms,
+- caching,
+- CI/CD,
+- DevOps observability,
+- other technically justified improvements.
+
+This list is not a required implementation checklist.
+
+Candidates are free to select improvements that they believe provide meaningful value.
+
+---
+
+# 27. OUT OF SCOPE
+
+To keep the assignment appropriate for the expected timeframe, the following are not required:
+
+- real payment-provider integration,
+- mobile applications,
+- microservice architecture,
+- Kubernetes,
+- external identity providers,
+- production monitoring infrastructure,
+- real-time communication infrastructure,
+- complex geographic/map functionality,
+- production cloud deployment.
+
+Candidates may implement additional functionality voluntarily where appropriate.
+
+---
+
+# 28. DELIVERY REQUIREMENTS
+
+The completed work must be submitted through a **private Git repository** on a Git platform selected by the candidate.
+
+The repository must contain the complete frontend and backend source code.
+
+The repository should preserve meaningful development history through Git commits.
+
+Before submission, access to the private repository must be granted to the reviewers specified during the recruitment process.
+
+The final submission must:
+
+1. contain the complete application,
+2. contain the required README documentation,
+3. include all configuration examples necessary to run the project without exposing secrets,
+4. include a method to initialize required database structures and sample data,
+5. allow the reviewer to run and evaluate the primary application flows.
+
+---
+
+# 29. EVALUATION FOCUS
+
+The case study will be evaluated as an **overall Fullstack engineering exercise**.
+
+Evaluation will consider the quality of the complete solution, including:
+
+- functional completeness,
+- frontend implementation,
+- backend implementation,
+- relational data modelling,
+- reservation and availability logic,
+- authentication and authorization,
+- resource management,
+- Admin/Manager operational dashboards,
+- business-rule correctness,
+- architecture,
+- OOP and SOLID application,
+- code quality,
+- error handling,
+- maintainability,
+- usability,
+- documentation,
+- Git usage,
+- technical decisions.
+
+The case study intentionally leaves certain implementation details undefined.
+
+Candidates are expected to make reasonable engineering decisions where requirements do not specify an exact implementation and to briefly document significant assumptions.
+
+The ability to explain these decisions during a technical discussion is considered part of the exercise.
+
+---
+
+# 30. COMPLETION EXPECTATION
+
+The priority is a **working, maintainable end-to-end application**.
+
+Candidates should prioritize completing the core WorkspaceHub workflow before implementing optional enhancements.
+
+A smaller solution whose mandatory functionality is reliable and well structured is preferable to a larger solution containing many incomplete or unstable features.
+
+The expected result should allow a reviewer to experience the application from multiple roles, create and manage coworking resources, make valid reservations, observe resource utilization, and verify that the required business constraints are enforced.