Abstraction is deciding what to leave out. You name an operation by its intent and hide the steps behind that name. A caller writes save(order) and never learns whether that is a SQL insert, a file write or an HTTP call.
Four techniques do this. Interfaces state a contract with no implementation. Abstract classes fix a shape and leave gaps for subclasses. Ordinary methods give one name to a block of steps. Access modifiers back all of this up by keeping the internals out of reach.
A wrong abstraction costs more than none. If the contract you picked does not match how callers use the thing, every caller writes a workaround. Flags and special cases follow. Duplicated code is easier to fix later than a bad abstraction everyone depends on.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
How is abstraction different from encapsulation, given they both hide things?A strong answer separates choosing what callers see from guarding an object's state, and notes that access modifiers serve both.
How does an abstract class differ from an interface, and when do you reach for each?A strong answer weighs instance fields and constructors, which only abstract classes have, against implementing many interfaces but extending one class.
How can you tell an abstraction is wrong, and how do you get out once many callers depend on it?Look for boolean flags, type checks and callers working around the contract. A good fix inlines the code back, then extracts a better fit.
What is a leaky abstraction, and where could save(order) leak?A strong answer says hidden details still reach the caller, like timeouts, latency or partial failure when save is really a network call.
If callers only see save(order), how does that help you test the code that calls it?Point to a fake or in-memory version of the same contract, so tests of the caller run without a real database.
What you can say
Abstraction is deciding what to leave out, so you name an operation by what it's for and hide the steps behind that name.
A caller writes save(order) and never needs to know whether that's a SQL insert, a file write or an HTTP call.
The two main tools are interfaces, which state a contract with no implementation, and abstract classes, which fix a shape and leave gaps for subclasses.
Plain methods count too because they give one name to a block of steps, and access modifiers back it all up by keeping the internals out of reach.
The catch is that a wrong abstraction costs more than none, because if the contract doesn't fit how callers use it, they all write workarounds and flags pile up.
So I'd rather live with some duplicated code for a while than lock everyone into a bad abstraction that's hard to undo.
Weak answers to avoid
Confuses abstraction with encapsulationHiding fields is encapsulation. Abstraction is choosing what a caller sees, so lead with the contract and treat access modifiers as the backup.
Says abstraction just means abstract classesThat's one tool. Interfaces, plain methods and access modifiers all hide detail too, and naming only one sounds memorized.
Treats more abstraction as always betterA layer that doesn't fit its callers leads to flags and workarounds. Say when you'd keep duplicated code rather than extract too early.
Only gives a car or coffee machine analogyAn analogy shows the idea but not the skill. Tie it to code, like a method whose callers don't know which storage sits behind it.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
