Digital Surgery Android Tech Test

Thank you for taking the time to complete this exercise 🙌
We’d like you to build a small Android app that consumes a public API, persists some data locally, and presents it in a clean, user-friendly way.

We are not looking for a pixel-perfect production app, but we are interested in how you structure code, reason about architecture, and (nowadays) how you use AI tools responsibly.

---

Overview

Create an Android application with two screens:

1. A Procedure list page (home screen).
2. A Favourite procedures page.

The app should:

• Fetch procedures from our API.
• Display them in a list with some metadata.
• Allow the user to mark procedures as favourites.
• Persist favourites locally in a database.
• Show procedure details in a bottom sheet style view.

You’re welcome to use any modern Android tools you’re comfortable with.

---

Screens & Requirements

1. Procedure List Page (Home)

This should be the home page of the app and show a list of procedure cards/cells, each with:

• A thumbnail image
• The procedure title
• The phase count
• A favourite button toggle

Behaviour:

• Tapping a procedure should show a dismissible bottom sheet (or similar) with detailed information:
  • Card image at the top
  • A favourite button toggle
  • Title of the procedure
  • Total duration in minutes
  • Creation date in dd/MM/yyyy format
  • A horizontal list of phases of the procedure, each with:
    • Thumbnail image
    • Phase name

You are free to decide how you structure the layout and navigation, as long as the behaviour is clear.

---

2. Favourite Procedures Page

Any time a user toggles the favourite button for a procedure, that procedure should be persisted in a local database.

This screen should:

• Display only those procedures marked as favourite (if any).
• Allow tapping a favourite procedure to show the same procedure details view (or an equivalent UX).
• Show a Snackbar (or similar) each time a procedure’s favourite state changes, notifying the user of the action (e.g. “Added to favourites”, “Removed from favourites”).

Use whatever local persistence layer you prefer.

---

API Endpoints

The API is available at:

• Procedures list:
  https://staging.touchsurgery.com/api/v3/procedures

• Procedure details:
  https://staging.touchsurgery.com/api/v3/procedures/$PROCEDURE_ID

Example:
https://staging.touchsurgery.com/api/v3/procedures/procedure-TSC_CemCup

You are free to structure your networking layer as you see fit.

---

Time & Scope

We don’t want this to consume an entire week of your free time.

• We expect you to spend a few hours, not days.
• We’re not looking for pixel-perfect UI or every possible edge case.
• Focus on:
  • Clear architecture
  • Clean, idiomatic Kotlin
  • Testability
  • Reasonable error handling and UX

If you have to choose, we prefer good structure + good tests over “complete but messy”.

---

Use of AI Tools

We know and expect that engineers today use AI tools like GitHub Copilot, Gemini, Claude, etc.

You are allowed to use AI tools for this exercise, with these expectations:

1. You remain responsible for the code.

   • Review and understand all generated code.
   • Don’t include code you wouldn’t be comfortable debugging.

2. Please add a short section to your README with:

   • Where AI helped you.
   • What you validated or changed manually after AI suggestions.
   • Anything the AI produced that you decided not to use and why.

3. Do not paste any sensitive or private information into AI tools.

We’re not trying to catch you “using AI”; we want to see how you collaborate with it and how much you understand the code that ends up in the repo.

---

Architecture & Explanation

Please include a short README or section in the main README that explains:

• Which architecture pattern you chose (e.g. MVVM, MVI, etc.) and why.
• How you structured your modules / layers (e.g. data, domain, ui).
• How you handle:
  • Asynchronous work (Coroutines / Flows / Rx)
  • Navigation
  • State management (e.g. StateFlow, Compose state)
• What you would improve or add if you had more time.

We don’t need an essay – a few clear paragraphs are enough.

---

Automated Tests

Please:

• Write your code in a testable way.
• Include some representative unit tests:
  • For example: view models, use cases, or repository logic.
• UI tests are a plus, but not mandatory.

We don’t expect 100% coverage for this exercise.
We mainly want to see:

• How you think about testing
• How you structure code to make testing easier

---

Technologies & Techniques

You’ll be joining a team with an existing codebase and stack. We’re interested in how well you can work with modern Android tooling.

Technologies we care about include (but are not limited to):

• Kotlin
• Coroutines & Flow
• Jetpack Compose
• Room
• Dependency Injection (Dagger/Hilt)
• Retrofit / OkHttp
• MVVM
• Unit testing (JUnit, MockK/Mockito, etc.)
• UI testing (Espresso / Compose testing)

In the Touch Surgery app:

• All new development is done with Coroutines and Jetpack Compose.
• We still have legacy code using RxJava and XML-based views.

For this exercise, please use whichever you think will give you the cleanest, most maintainable result.

We do not expect you to know everything from day one, but for senior roles we do expect solid familiarity with most of this stack.

---

Bonus (Optional)

These are nice-to-haves, not requirements:

• A way to search/filter procedures in the list.
• The capability to work offline (e.g. showing cached data when offline).
• Thoughtful handling of:
  • Error states (network errors, empty states)
  • Loading states
  • Configuration changes / process death

---

If anything is unclear or you hit issues with the API, please feel free to mention it in your README – part of real development is dealing with imperfect environments 🙂