Dici,
I know that the code will compile and work as expected.
... ma come hai imparato, non sarà ... perché non hai confermato che la versione corretta è disponibile in fase di compilazione, sui computer di compilazione .
Però non è questo il punto. Il punto e la causa principale della tua non assunzione, è che non sei riuscito a comunicare con l'intervistatore. Non hai comunicato un requisito o una dipendenza per il codice che stavi scrivendo. Personalmente, ritengo che una grande assunzione (la gestione delle dipendenze può essere un grosso problema che implica analisi statiche, revisioni del codice, formazione degli sviluppatori, build, installazione / distribuzione, legale, SLA, ecc.)
Quindi ora lo sai, e sapere è metà della battaglia. Ma questo non aiuta davvero. Quello che fa è un grande consiglio che ho ricevuto durante le interviste:
For every line you write on the whiteboard, say something relevant.
Inizia con questi mentre stai scrivendo ogni riga:
- "Sto pensando che ..."
- "Questo ha senso perché ..."
- "Ciò presuppone che ..."
Nel tuo scenario, avrei detto qualcosa sulla falsariga di:
"I'm thinking that a simple list of strings should suffice, so I'll just pull one out of Guava."
... o anche
"Is it safe to assume that the Guava libraries are available?"
Come punto di interesse, scrivo .NET / C # e ho chiesto in un'intervista a Microsoft se si poteva supporre che potessi usare LINQ. La risposta era no.