You say,
I know that the code will compile and work as expected.
... but as you've learned, it won't... because you didn't confirm that the correct version is available at build time, on the build machine(s).
That's not the point though. The point, and the root cause of your not getting hired, is that you failed to communicate with the interviewer. You didn't communicate a requirement or dependency for the code you were writing. Personally, I would consider that a large assumption (dependency management can be a pretty big deal that involves static analysis, code reviews, dev training, build, the installer/deployment, legal, SLAs, etc).
So now you know, and knowing is half the battle. But that doesn't really help. What does is a big tip that I got when doing interviews:
For every line you write on the whiteboard, say something relevant.
Start with these as you're writing each line:
- "I'm thinking that ..."
- "This makes sense because... "
- "This assumes that... "
In your scenario, I would have said something along the lines of:
"I'm thinking that a simple list of strings should suffice, so I'll just pull one out of Guava."
... or even
"Is it safe to assume that the Guava libraries are available?"
As a point of interest, I write .NET/C# and I asked in an interview at Microsoft if it was safe to assume that I could use LINQ. The answer was no.