PUBLIC_DOCS/caseStudy1
1
0
Wiki
Page: TECHNICAL CASE STUDY
Pages
TECHNICAL CASE STUDY
2 TECHNICAL CASE STUDY
squarefox edited this page 2026-09-10 23:59:00 +00:00
Table of Contents

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:

Hot Desk Area

Total Capacity: 20

Already Reserved: 15
New Request: 3

Result:
Reservation can be accepted.

However:

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:

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:

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:

Register / Login
        v
Browse Coworking Locations
        v
Search / Filter
        v
View Location
        v
Select Resource
        v
Select Date / Time / Capacity
        v
Check Availability
        v
Review Reservation
        v
Create Reservation
        v
Reservation Confirmation
        v
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:

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:

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:

Most Utilized Resources

Meeting Room A       82%
Hot Desk Area        71%
Private Office B     58%

or aggregated information such as:

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:

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:

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.