Learn how to answer the clone object in C interview question in plain English: shallow copy vs deep copy, struct ownership, memcpy limits, and a worked.
Most C interview questions about "cloning an object" trip up candidates who know the answer but can't say it in C terms. A clone object in C interview question is really asking: can you copy a struct and guarantee that every heap-owned field gets its own independent allocation? Not whether you know what a copy constructor does in C++. Not whether you can recite the definition of a deep copy. Whether you understand who owns what, and what happens when two variables pretend to share the same memory.
That distinction — ownership, not syntax — is the entire answer. Everything else is mechanics.
What Interviewers Mean by "Clone Object in C Interview"
What this question is really testing
The interviewer is not testing your knowledge of object-oriented vocabulary. C has no objects in the formal sense, no constructors, no destructors, and no automatic copy semantics. What the question probes is whether you understand data ownership: who allocates a piece of memory, who is responsible for copying it when a struct is duplicated, and who frees it when the lifetime ends.
A candidate who answers with "you just assign the struct" has revealed something: they haven't thought about what happens when that struct contains a pointer to heap-allocated memory. After the assignment, both the original and the copy hold a pointer to the same address. They look like two independent objects. They aren't. They are two variables sharing one allocation, and the first `free()` call turns the second into a crash waiting to happen.
The ownership rule is the answer: when you clone a struct in C, every field that represents owned heap memory must be separately allocated and separately copied. Value fields copy trivially. Pointer fields that own memory do not.
What this looks like in practice
Consider a struct like this:
The `id` and `score_count` fields are plain integers. Copying them is safe and complete — the copy holds its own value. The `name` and `scores` fields are pointers. After a simple struct assignment, the copy's `name` pointer and the original's `name` pointer point at the same block of memory. Mutate one, and you've mutated both. Free one, and you've invalidated the other.
Cloning this struct correctly means: allocate a new `Person`, copy `id` and `score_count` directly, then `malloc` a new buffer for `name`, copy the string contents into it, do the same for `scores`, and only then hand back the new struct. That sequence — copy values, then allocate and copy owned buffers — is the deep copy. Everything else is a shallow copy with a time-bomb inside it.
Why C Has No Copy Constructor, but Still Needs Copying Rules
The C++ habit that misleads people
C++ gives you a copy constructor and a copy assignment operator. When you write `Person b = a;` in C++, the compiler can invoke your custom copy constructor, which knows how to allocate fresh memory for each owned member. The language hides the allocation logic inside a function that runs automatically.
C does not do this. When you write `Person b = a;` in C, you get a memberwise copy of bytes. The language does not know that `name` represents owned memory. It copies the pointer value — the address — and moves on. The result is two structs that look identical and are partially broken.
This is not a deficiency in C. It is a design choice. C trusts you to know what your data means. The flip side of that trust is that you are responsible for writing the copying logic yourself, explicitly, every time.
What this looks like in practice
In a well-structured C codebase, copying is expressed through explicit helper functions. You will see names like `copy_person()`, `clone_node()`, or `person_dup()`. These are not language features — they are conventions that make the ownership rules visible. When a function is named `clone_node`, a reader knows immediately that it allocates memory and that the caller is responsible for freeing the result.
In an interview, this is exactly the vocabulary to use. Don't say "I'd use the copy constructor." Say "I'd write a `clone_person()` function that allocates a new struct, copies the plain fields, and then separately allocates and copies each owned buffer." That answer demonstrates that you understand what C actually does, not what you wish it did.
Shallow Copy vs Deep Copy in C Structs Is Where Most Candidates Get Burned
Why a shallow copy looks correct until it explodes
A struct assignment in C is a shallow copy. So is `memcpy` applied to the whole struct. Both operations copy every byte of the source struct into the destination. For a struct with no pointer fields — or pointer fields that don't represent ownership — that is completely correct and entirely safe.
The seductive part is that a shallow copy compiles cleanly, runs without errors, and produces a destination struct that looks exactly right. Print the fields, and they match. The bug is invisible until something changes.
What changes is ownership. The source and the clone now hold the same pointer value for every heap-owned field. They are aliases — two names for the same memory. The moment either one is freed, the other is holding a dangling pointer. The moment either one's `name` is `free()`d and reallocated, the other is pointing at garbage.
What this looks like in practice
Take the `Person` struct from Section 1. A shallow copy looks like this:
Or equivalently:
Both produce a `clone` where `clone.name == original.name`. They point at the same address. Now consider what happens at cleanup:
The second `free()` is a double free. On most implementations this corrupts the allocator's internal state or crashes the process. The crash may not appear at the `free()` call itself — it may surface several operations later, in an allocation that has nothing to do with `Person`. That delayed failure is what makes this bug genuinely dangerous in production code and what makes it a reliable signal in interviews: candidates who haven't been burned by it tend to underestimate it.
The debugging clue interviewers want you to notice
The symptom chain is: shallow copy creates aliasing, aliasing means two owners for one allocation, one owner frees the memory, the second owner now holds a dangling pointer, and the crash appears when the dangling pointer is used or freed. The crash looks random because it is temporally separated from the bug.
If you can describe that chain in an interview — aliasing leads to double free leads to delayed crash — you have demonstrated exactly the kind of ownership reasoning the question is designed to surface.
A Safe Deep-Copy Function for a C Struct with Pointers
Copy the easy fields first, then the owned pointers
The order of operations matters for both correctness and cleanup. Copy the plain value fields first, because they cannot fail. Then handle each owned pointer field in sequence, because each allocation can fail and you need to know what has already been allocated when you roll back.
For the `Person` struct, the plain fields are `id` and `score_count`. Copy those immediately. Then allocate a new buffer for `name`, copy the string. Then allocate a new buffer for `scores`, copy the array. If any allocation fails, free everything already allocated and return `NULL`.
What this looks like in practice
Notice the initialization of `dst->name = NULL` and `dst->scores = NULL` before the allocations. That is not cosmetic. It makes the cleanup path safe: if the second `malloc` fails, `free(dst->name)` is either a valid free or a no-op on `NULL`, and the function can return cleanly without leaking the first allocation.
Why failure handling matters here
Most interview answers go hand-wavy at exactly this point. A candidate will describe the allocation logic correctly and then say "and if malloc fails, handle the error." That is not an answer — it is a placeholder for an answer.
The real answer is: when the second allocation fails, you must free everything the function has already allocated before returning `NULL`. In the example above, that means freeing `dst->name` and then `dst` itself. If you had initialized `dst->name` to an unspecified value rather than `NULL`, the cleanup `free(dst->name)` could free garbage. The `NULL` initialization is not defensive programming — it is the mechanism that makes the cleanup path correct.
A candidate who explains that rollback logic in an interview has demonstrated that they think about allocation as a transaction, not just a sequence of calls.
When memcpy Is Fine, and When It Quietly Breaks Ownership
The one case where `memcpy` is actually acceptable
`memcpy` is the right tool for copying plain-old-data structs — structs where every field is a value type and no field represents ownership of heap memory. If your struct is:
then `memcpy(&dst, &src, sizeof(Circle))` is perfectly correct. There are no owned pointers. The copy is complete. Every field in `dst` is an independent value. `memcpy` is fast, explicit, and appropriate here.
What this looks like in practice
The boundary is ownership semantics, not the presence of pointers. A struct can contain a pointer that it does not own — for example, a pointer to a statically allocated string or a reference to an object managed by another part of the program. In that case, copying the pointer is correct: both the source and the copy should point at the same thing, because neither owns it.
The problem is when a pointer represents ownership — when the struct is responsible for freeing that memory. `memcpy` has no way to know the difference. It copies the address. If the address represents owned memory, you now have two owners. If it represents a shared reference, the copy is correct.
The rule for interviews: `memcpy` copies representation, not semantics. For plain-old-data structs with no ownership, representation and semantics are the same. For structs with owned heap memory, they diverge, and `memcpy` alone is not enough.
How to Answer Cloning in One or Two Interview Sentences
Say the ownership rule before you say the technique
The instinct under interview pressure is to reach for the technique first: "I'd use memcpy" or "I'd write a deep-copy function." Resist that. Start with the ownership rule, because that is what the question is actually testing. The technique follows naturally from the rule.
The structure of a strong answer: state what "clone" means in C terms, name the distinction between shallow and deep copy, and then describe the technique. That order signals that you understand the why, not just the how.
What this looks like in practice
A tight two-sentence answer that works in most C interviews:
"In C, cloning a struct means making a fully independent copy — so I'd allocate a new struct, copy all the plain value fields directly, and then for each pointer field that represents owned heap memory, I'd allocate a fresh buffer and copy the contents. A shallow copy like struct assignment or memcpy only duplicates the pointer addresses, which creates aliasing and leads to double-free bugs when either copy is freed."
That answer names ownership, distinguishes shallow from deep copy, and flags the failure mode. It does not use C++ terminology. It does not drift into abstract theory. It gives the interviewer exactly the signal they are looking for: this candidate understands memory boundaries.
Common Cloning Bugs: Double Free, Aliasing, and Dangling Pointers
Why these bugs are really the same ownership mistake
Double free, aliasing, and dangling pointers look like three separate problems. They are one problem expressed at three different points in the program's lifetime. The root cause is always the same: two variables claiming ownership of the same allocation.
Aliasing is the state — two pointers hold the same address. A double free is what happens when both owners try to release that address. A dangling pointer is what the surviving owner holds after the first free. These are not independent failure modes. They are the same failure mode at different stages of execution.
What this looks like in practice
A shallow clone creates aliasing at the moment of copy. The bug is latent — the program runs correctly until one of the owners is freed or until one owner modifies the shared buffer. Consider:
The `printf` may print garbage, may crash, or may appear to work depending on whether the allocator has reused that memory. The second `free_person(b)` is a double free. Neither failure is obvious at the point of the shallow clone — they appear later, which is why this class of bug is difficult to track down without understanding the ownership split that caused it.
The debugging signal interviewers want to hear: if a crash appears in a `free()` call and there is no obvious bad pointer nearby, look for a shallow copy earlier in the call chain. That is where the ownership split happened.
How This Maps to C++ Copy Constructor, clone(), and Copy Assignment
The translation layer interviewers like to hear
If the interviewer shifts from C to C++, the mental model does not change — only the syntax does. In C++, the same ownership rules that you express through an explicit `clone_person()` function are expressed through a copy constructor and a copy assignment operator. The copy constructor is called when an object is initialized from another object of the same type. The copy assignment operator handles `a = b` after both objects exist.
Both must perform the same deep-copy logic: allocate new buffers for owned members, copy the contents, and ensure the destructor frees only what the object itself allocated. The Rule of Three (and in modern C++, the Rule of Five) codifies exactly this: if you need a custom destructor, you almost certainly need a custom copy constructor and copy assignment operator too, because the same ownership semantics that require careful destruction require careful copying.
What this looks like in practice
A polymorphic `clone()` method — common in class hierarchies — is the same idea taken one step further. Because copy constructors are not virtual, a base-class pointer cannot invoke a derived-class copy constructor directly. A virtual `clone()` method solves this by delegating the copy to the derived class, which knows its own layout and owned members.
In an interview, connecting the C `clone_person()` function to the C++ copy constructor and then to a virtual `clone()` method demonstrates that you understand the underlying ownership model, not just the language features that implement it. The mental model is portable. The syntax is not.
FAQ
Q: In a C interview, what does 'clone an object' actually mean when C has no objects or copy constructors?
It means making a fully independent copy of a struct, where every heap-owned field gets its own allocation. C has no automatic copy semantics, so the interviewer is checking whether you can reason about ownership manually — who allocates, who copies the contents, and who frees the result.
Q: How do you deep-copy a struct that contains pointers to heap-allocated memory?
Allocate a new destination struct, copy all plain value fields directly, then for each pointer field that represents owned memory: `malloc` a new buffer of the appropriate size, copy the contents (using `strcpy` for strings or `memcpy` for arrays), and assign the new pointer to the destination field. Handle allocation failure by freeing everything already allocated before returning `NULL`.
Q: What is the difference between a shallow copy and a deep copy in C?
A shallow copy duplicates every byte of the struct, including pointer values — so source and copy share the same heap addresses. A deep copy allocates independent storage for every owned pointer field and copies the data into that new storage. For structs with no owned heap memory, shallow and deep copy are equivalent. For structs with owned pointers, a shallow copy creates aliasing that leads to double-free and dangling-pointer bugs.
Q: How do you avoid double-free, aliasing, or dangling-pointer bugs when cloning?
Ensure that every owned pointer in the clone points to freshly allocated memory, not to the source's memory. Initialize pointer fields to `NULL` before allocating so that cleanup code can safely call `free()` on any partially-initialized struct without freeing garbage. Never share ownership of a heap allocation between two structs unless you are using a reference-counting scheme that tracks it explicitly.
Q: How would you explain cloning in one or two interview sentences?
"In C, cloning a struct means making a fully independent copy — allocate a new struct, copy plain value fields directly, and for each owned pointer field allocate a fresh buffer and copy the contents. A shallow copy like struct assignment only duplicates pointer addresses, which creates aliasing and leads to double-free bugs when either copy is freed."
Q: When is a simple memcpy acceptable, and when is it unsafe?
`memcpy` is acceptable for plain-old-data structs where no field represents ownership of heap memory. It is unsafe when the struct contains owned pointer fields, because `memcpy` copies addresses, not the data those addresses point to. After a `memcpy` of a struct with owned pointers, source and copy share the same heap allocations — a shallow copy with aliasing built in.
Q: How would you clone a linked-list node or small object graph in C?
Each node must be cloned individually. Allocate a new node, copy its value fields, and then recursively clone the `next` pointer (for a singly-linked list) or both `prev` and `next` pointers (for a doubly-linked list). For graphs with shared references — where two nodes point to the same child — you need a visited map (typically a hash table or array indexed by original pointer) to detect already-cloned nodes and wire up the clone's pointers to the already-cloned versions rather than cloning the same node twice.
How Verve AI Can Help You Prepare for Your Software Engineer Job Interview
Memory ownership questions like clone object in C interview are exactly the kind where knowing the answer is not the same as being able to say it clearly under pressure. The moment an interviewer follows up with "what happens if the second malloc fails?" or "how does this relate to the copy constructor?", a rehearsed definition falls apart — and a real answer has to come from understanding the mechanism, not recalling a script.
Verve AI Interview Copilot is built for that live moment. During your actual interview on Zoom, Google Meet, or Teams, it follows the conversation in real time and helps you structure an answer as the question unfolds — so when the follow-up diverges from what you prepared, you have something to work with. On the desktop app, Verve AI Interview Copilot stays invisible during screen share, so it is present without being visible to the interviewer. If you want to rehearse the ownership explanation and the deep-copy walkthrough before the real thing, the separate Mock Interviews feature lets you run the format in advance and see where your answer goes vague. The live Copilot and the mock practice are distinct tools — one for the day of, one for the days before.
Conclusion
Cloning in C is not language magic. It is ownership-safe copying: allocate a new struct, copy the plain fields, and give every owned pointer its own independent allocation. That is the entire answer, and it is the answer the interviewer is looking for.
Before your interview, say the one-sentence version out loud: "In C, cloning means allocating a new struct and deep-copying every owned pointer field so the clone has no shared memory with the source." Then, if the interviewer pushes, walk through the `clone_person()` example — the value fields, the `NULL` initialization, the two `malloc` calls, and the rollback on failure. Those two moves together — the sentence and the walkthrough — cover everything the question is designed to test.
James Miller
Career Coach
