Mission

**Submit the Solirius Java Guild "Library Management System" tech test as a piece

of work that reads like a professional engineer's, and then defend every decision

in it out loud in an interview.**

The concrete goal

Tom has been sent java-guild-candidate-test-intermediate — a Maven project from

Solirius Consulting containing a working but flawed Library Management System

and a README asking for it to be extended at Intermediate level.

The success condition is not "makes the menu work". It is:

Produce a submission whose commit history, tests, design and README together

demonstrate that the candidate saw what was wrong with the starter code, fixed

it deliberately, and can say why.

Why this test is not what it looks like

The README reads like a blank-page exercise ("Create a simplified Library

Management System"). It is not. The repository already contains a complete

implementation. That changes the task entirely:

There is an exceptions/ package containing three exception classes —

AlreadyBorrowedException, BookNotFoundException, NotBorrowedException —

and not one of them is referenced anywhere in the code. The Intermediate

requirement asks you to handle exactly those three scenarios. They have been

left on the table for you.

Library.borrowBook throws IOException for a domain failure, and it

reports "Book not found" for a book that is found and merely already

borrowed. The library lies.

mvn test reports No tests to run. The Graduate requirement — unit tests

for Book and Library — is entirely unmet.

The pom.xml declares mockito-core and sqlite-jdbc, neither of which

is used by any code in the repo, and configures checkstyle. That is a

statement about what a good answer contains.

Reading a codebase for what it is asking for is the actual skill under test.

What "done" looks like

Tom can, cold:

1. Walk a stranger through the starter code and name every defect in it, with the

failure mode, before running anything.

2. Drive each fix test-first — writing a test that fails for the right reason,

then the code that makes it pass.

3. Justify each design decision with a named principle and the concrete cost of

the alternative — not just "SOLID".

4. Produce a git history a reviewer can read top to bottom and understand the

work without opening the diff.

5. Package and send the submission so that an assessor can build, run and read it

with zero friction.

6. Answer, without hesitating: *checked or unchecked? Why Optional? Why not a

record? Where does persistence belong? What would you do next?*

Non-goals

Building a "real" library system. Scope discipline is being marked; gold-plating

reads as poor judgement.

Frameworks. No Spring, no DI container. The pom has JUnit, Mockito and SQLite

and nothing else, and that is the whole permitted palette.

Java 21 language features. The pom pins the compiler to Java 11 — no

records, no sealed types, no switch expressions. Working elegantly inside a

stated constraint is worth more than ignoring it.

Status

Mission set: 2026-08-30
Submission deadline: not yet recorded — tell me when you know it.
Starter repo: ~/Desktop/java-guild-candidate-test-intermediate-main