commit ef0d3abae8ba43e6c3d7a69c3cbc5a9d4704e543 Author: squarefox Date: Thu Sep 10 23:53:53 2026 +0000 Add Home diff --git a/Home.md b/Home.md new file mode 100644 index 0000000..2dc9e93 --- /dev/null +++ b/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.