Java Guild course · Resources

Workspace · resources

Solirius Java Guild Tech Test — Resources

Curated 2026-08-30. Every URL below was checked and returned 200.

Knowledge

Testing

• JUnit 5 User Guide
The primary source. Use for: @Test, @DisplayName, @Nested, assertThrows, @TempDir, parameterised tests. Read § Assertions before writing a single test in this project.
• @TempDir javadoc
Use for: testing the save/load persistence without leaving libraryState.txt files scattered around the repo. This is the single most useful annotation for the Intermediate persistence requirement.
• Book: _Working Effectively with Legacy Code_ — Michael Feathers
(summary link; the book itself is worth owning). Use for: the idea of a characterisation test — a test that pins down what code currently does so you can change it safely. This tech test is a legacy-code exercise wearing a greenfield README.
• Martin Fowler — "Self Testing Code"
Use for: the one-paragraph argument for why the tests are the deliverable, not an accessory to it.

Java language & library

• java.util.Optional javadoc (Java 11)
Read the class-level text, especially the API Note. Use for: defending Optional<Book> searchBook(String) over returning null, and for knowing the documented limits (not for fields, not for parameters).
• java.lang.Object javadoc — equals / hashCode contracts (Java 11)
Use for: quoting the five-clause equals contract and the hashCode consistency rule verbatim in an interview.
• java.util.Scanner javadoc (Java 11)
Use for: why nextInt() throws InputMismatchException, and what hasNextInt() does instead. The starter's menu loop dies on any non-numeric keypress.
• Oracle Java Tutorial — "Unchecked Exceptions: The Controversy"
Use for: the checked-vs-unchecked decision on the three domain exceptions. Oracle's own guidance, so it is quotable at people who disagree.
• JEP 395: Records
Use for: knowing precisely what you are giving up by honouring the pom's Java 11 target — records landed in 16. Being able to say that is worth more than using them.
• [Book: _Effective Java_ (3rd ed.) — Joshua Bloch]
Not linkable, but the canonical citations for this test are Items 10–11 (equals/hashCode), 17 (minimise mutability), 55 (return Optional), 70–73 (exception design). Name the item number in interview and you sound read.

Design & OO

• Martin Fowler — "Tell Don't Ask"
Use for: why library.borrowBook(title) beats library.searchBook(t).borrowBook().
• Robert C. Martin — "The Single Responsibility Principle"
Use for: the argument that Library should not also be a file format. Read the actual post — SRP is about reasons to change, not "one job", and most candidates get this wrong in interview.
• Martin Fowler — "Inversion of Control Containers and the Dependency Injection Pattern"
Use for: constructor injection without a framework, which is all this test needs.
• Yegor Bugayenko — "Why NULL is Bad"
Opinionated, and useful precisely for that — a sharper set of arguments than "null is bad" for defending the Optional change.
• Martin Fowler — "TwoHardThings"
Use for: naming. viewAvailableBooks returning a List is a naming smell worth discussing.

Build & style

• Maven Compiler Plugin — setting release
Use for: the one-line pom fix that silences the -source 11 warning and is actually more correct than source+target.
• Checkstyle — Sun Code Conventions style
and the full check reference. Use for: understanding why the starter code has final parameters and javadoc on every member — it was written to pass sun_checks.xml, which is Checkstyle's default when no configLocation is set. Match it or your report goes noisy.
• Oracle — Code Conventions for the Java Programming Language
The document sun_checks.xml encodes. Historical, but this is where the rules the pom will judge you by actually come from.
• Google Java Style Guide
Use for: a modern counterpoint. Worth knowing so you can say "the project uses Sun conventions, so I matched them" rather than "I used my usual style".

Git & submission

• Chris Beams — "How to Write a Git Commit Message"
The seven rules. Use for: every commit in the submission. This is the single highest-leverage read in this list relative to its length.
• Conventional Commits 1.0.0
Use for: the type(scope): subject convention. Adopt deliberately or not at all — and be ready to say which and why.
• git archive documentation
Use for: knowing what it does not do — it does not include .git, which matters for how you package the submission.

The company

• Solirius Consulting
Use for: knowing who is reading this. Public-sector-heavy UK consultancy — which is a real argument for conservative, readable, well-documented code over cleverness.

Wisdom (Communities)

• r/javahelp
Moderated, code-review friendly, low tolerance for homework dumps — so post the design question, not the assignment. Use for: "is Optional overkill here?"
• Code Review Stack Exchange
The right venue for posting a finished, working submission for critique. Strict rules: the code must already work. Do not post before you submit — assume anything public is discoverable by the assessor. Use it after.
• London Java Community
Tom is London-based. Use for: real practitioners to ask "how would you package a tech-test submission?" and for interview practice with people who hire.

Gaps

• No public marking scheme for the Solirius Java Guild test. The evaluation
criteria in the README are all we have. Everything in this course about what scores well is inference from the criteria plus the shape of the starter repo — clearly reasoned, but not authoritative. Treated as inference throughout.
• No known past-candidate write-ups. If Tom finds one, add it here.