The Interview Viva

Mutability makes equality hazardous in hashed collections — a real point — but plenty of mutable types define equals sensibly. Note that title and author here are already final; only the borrowed flag moves.

List.contains, indexOf and remove(Object) all use equals. This is exactly backwards.

Right, and the honest answer names the consequence: two Book objects with identical title and author are currently unequal, so assertEquals on books compares references and any future remove would fail. Whether to add it is a judgement call — but not noticing is not.

Javac emits no such warning. Some static analysers do; the compiler does not.

Both halves, and give both. The build constraint is decisive on its own — javac --release 11 rejects records outright — and even on Java 21 the mutable isBorrowed flag makes Book a poor record. Mentioning that you checked the compiler target is the detail that lands.

Records can override toString freely. Not a limitation.

Too strong, and it is a claim you would have to defend. Records model immutable values well, whatever layer they sit in.

Nothing about records affects the hand-written text format, and they serialise normally besides.

That is what happens when the calls are sequential. Interleave them and both threads can read isBorrowed == false before either writes.

That is raised by structural modification during iteration, not by mutating a field on a book already in the list.

Separate threads are the cause of the problem, not a defence against it. The shared Book is the contended state.

Correct, and it is a check-then-act race on a non-volatile field. The right follow-up is scope: “the brief describes a single-user console app, so I didn’t build for concurrency — but if this became a service I’d need to make borrow atomic, and I’d note the flag isn’t even safely published across threads.” Knowing it and consciously descoping it is the answer.

Excluding them removes the most valuable scenarios — the crashes are precisely the behaviour you set out to change, so they are the hunks that make the final diff persuasive.

This is the answer, and it distinguishes the two kinds of test cleanly. A characterisation test asserts what is; the unit tests assert what should be. Conceding the premise here would be conceding you do not know what a golden master is for.

It is not a temporary compromise. Approving current behaviour, including bad behaviour, is the technique working exactly as intended.

The baseline was taken several commits before the fix, which is the point — and if it had been fixed in the same commit there would be no diff to show.

A strong second, and worth naming — it also loses the whole session’s work, since state is only saved on a clean exit. But it announces itself, so it gets fixed.

The most conspicuous defect and the one you fixed first, but it is a design flaw. It confuses maintainers; it does not lose anybody’s data.

The best answer, because the reasoning is about severity rather than about which bug is most obvious. Silent data corruption outranks a crash: the crash is found in minutes, the corruption is found months later, if ever. Saying so shows you rank defects the way someone who has run software in production does.

Not a bug at all — it was the hint that told you where to start. Calling it the worst bug would be misreading the exercise.

Two things in one sentence: the technical reason, and the fact that you documented it rather than smuggling it. The second half is what turns a deviation into evidence of judgement.

The brief also says “visibility at candidate discretion”, which invites judgement — but answering a request for justification with “none is required” is exactly the wrong instinct to display.

No such convention exists, and appealing to fashion rather than reasoning is a weak move in front of anyone senior.

Untrue — both would compile against a boolean-returning method. Inventing a technical necessity that does not exist is the worst option here.

A count tells you how many are out but not which, so you can never model a loan, a due date or a borrower. It defers the modelling rather than doing it.

This is roughly what the current code allows, and the reason the bug exists: searchBook returns the first match, so the others are unreachable.

Better, and a reasonable intermediate step — but it still leaves Book carrying a borrowed flag, so a Book is still simultaneously a description and a physical object.

The real answer, and the vocabulary matters: Book becomes an immutable description (title, author), Copy carries the borrowable state. The current model conflates them, which is why a title can only ever be lent once. Add that you would not have built this for the test, because the brief does not ask for it.

Overclaiming, and easily checked. The Book tests went green the moment they were written, because Book already worked.

The honest and the strongest answer — and being able to draw the line is itself the evidence. Point at the commits: the golden master and unit tests characterise, the exception and persistence commits each began with a failing test.

Underclaiming, and untrue. The three domain exceptions did not exist in any code path, and were driven by a test that failed with “expected AlreadyBorrowedException but was IOException”.

A golden master is generated from existing behaviour, so it is green on arrival by construction. Calling it a failing test to someone who knows the technique is the worst available answer.