Interview Questions tutorials

Interview question lists are usually a definition and a move on. These articles answer the question, then answer the follow-up, because the follow-up is where an interview actually goes.

Coverage is core Java: the language and its object model, collections and their performance characteristics, string handling and immutability, exceptions, and concurrency. Each answer says what the interviewer is checking for, which is often narrower than the question implies.

The material overlaps heavily with the Java and algorithms sections. The difference is framing — these are written to be recalled under pressure and defended, rather than read once.

Concurrency questions get the most space, because they are where interviews separate recall from understanding. Explaining what volatile does is a definition; explaining what it does not do — that it publishes visibility but provides no atomicity — is the answer that holds up. The same applies to the difference between synchronized and a ReentrantLock, and to why a double-checked lock was broken before Java 5.

Collections questions get similar treatment. The expected answer to how a HashMap works is not a definition but a mechanism: buckets, hash distribution, collision handling, resize behaviour, and what changes when keys have a poor hash.

One caveat worth stating: an interview answer and a production decision are not always the same thing. Where the expected answer differs from what you would actually build, the article says both, because being able to name the gap is usually a better signal than either answer alone.

Structure matters more than speed. Restate the problem before writing anything, then ask about the constraints that change the answer: input size, whether the data fits in memory, whether duplicates or empty input are possible. State a working brute-force solution and its cost, then improve it deliberately and say what the improvement trades away. An interviewer who cannot follow the reasoning cannot give credit for it, so narrating the approach is part of the answer rather than a distraction from it. The same habit applies to system design questions, where there is no single correct answer and the reasoning is the entire assessment.

These are written as explanations rather than as answer keys. An interview answer that recites a definition is worth very little; one that names the failure mode the feature prevents, and what it costs, is worth a great deal. So each entry tries to give you the sentence you would actually say out loud, plus the follow-up question it invites.

The overlap with the rest of the site is deliberate. Collections, concurrency and the memory model are the three areas that come up most often, and each has a full treatment elsewhere; the material here is the compressed version, organised by what gets asked rather than by how the API is structured. Where a topic has a longer article it is linked, and that longer article is the one to read first if the subject is new to you.

One caveat on how to use this section. Reading a compressed answer is enough to recognise a topic; it is not enough to defend one. If an area is genuinely new, the full article is the one to work through, and the compressed version is what to reread the morning of the interview. The order matters, and doing it the other way round produces an answer that sounds confident and falls apart on the second question.