Detailed explanation
Serialization in Java is the process of converting an object's state into a byte stream so it can be stored in a file or transmitted over a network. Deserialization reconstructs objects from that stream. Java's built-in object serialization normally requires the class to implement java.io.Serializable, a marker interface with no methods. This interface signals that instances may participate in the serialization mechanism; it does not automatically make their contents safe to store or transmit.
ObjectOutputStream.writeObject() writes an object and recursively processes the objects reachable through its serializable instance fields. This forms an object graph, rather than just a collection of primitive values. The stream records class information, field values, and references, preserving shared references and handling circular links. By default, non-static, non-transient fields are included. Static fields belong to the class, not an individual object's state, while transient fields are deliberately excluded. If a non-transient referenced object is not serializable, writing typically fails with NotSerializableException. In the example, User is serializable and String supports serialization; however, new User() leaves name null unless it is initialized.
ObjectInputStream.readObject() reads the stream and returns the reconstructed object, which usually needs a cast to its expected type. During ordinary Serializable deserialization, constructors and field initializers of serializable classes are not executed; instead, the accessible no-argument constructor of the first non-serializable superclass runs. Classes should explicitly declare a private static final long serialVersionUID to identify their serialization version. A mismatch between the stream's version and the local class version causes InvalidClassException. Keeping the same identifier does not make every class change compatible.
Interviewers usually expect you to explain these mechanics, not just repeat the definition. Mention try-with-resources for closing streams, transient for excluding fields from default serialization, and custom readObject/writeObject methods when special handling is required. Also distinguish serialization from encryption: serialized data can expose sensitive information. Deserializing untrusted data is dangerous because reconstruction can invoke class-specific behaviour; avoid it where possible, and use restrictive deserialization filters when native serialization is necessary. For public APIs and long-lived interchange, explicitly designed formats such as JSON or Protocol Buffers are often preferable.
Key points to remember
- Serializable is a marker interface enabling Java's built-in object serialization.
- ObjectOutputStream writes objects; ObjectInputStream reconstructs them.
- Default serialization includes non-static, non-transient fields and their reachable object graph.
- serialVersionUID participates in version compatibility checks during deserialization.
- Serialization is not encryption, and untrusted native deserialization creates security risks.
Common mistakes candidates make
- Assuming that implementing Serializable makes every referenced object serializable.
- Claiming that all constructors run normally during Serializable deserialization.
- Treating transient as a complete security measure or serialized bytes as encrypted data.
Likely follow-up questions
What happens to transient fields after deserialization?
Transient fields declared in a Serializable class normally have their type's default value, such as null, 0, or false. Their field initializers do not run during ordinary deserialization, although custom readObject logic can restore them.
Why should serialVersionUID be declared explicitly?
Without an explicit declaration, Java computes a default value from class details, so some code changes can unexpectedly change it. An explicit value gives you deliberate version control, but you must still evaluate whether class changes are compatible.
How is Externalizable different from Serializable?
Externalizable extends Serializable and requires writeExternal and readExternal methods, giving the class explicit control over its serialized contents. Unlike ordinary Serializable deserialization, reconstruction invokes the Externalizable class's public no-argument constructor.
Interview tip: Start with the definition, walk through writeObject and readObject, then mention object graphs, transient fields, version compatibility, and security.