Master the React.createElement interview answer: explain JSX, React element objects, and what ReactDOM does in under 30 seconds.
Most candidates who stumble on React.createElement interview questions already know JSX. That's the irony. They've written hundreds of components, they understand props, they know what a hook does — but when an interviewer asks "what does React.createElement actually return?" the answer goes fuzzy in about ten seconds. This guide fixes that with a clean 30-second answer first, then exactly as much supporting depth as you need to defend it under follow-up.
Give the 30-Second Answer First, Not the Lecture
The answer that sounds confident without sounding rehearsed
Here is the answer that works in a React.createElement interview. Say something close to this:
"JSX is syntactic sugar that Babel compiles to React.createElement calls before React ever runs. React.createElement takes a type — either a string like 'div' or a function or class component — plus a props object and any children, and it returns a plain JavaScript object called a React element. That object describes what should be on screen. React's reconciler reads those objects and decides what to create, update, or remove in the actual DOM. So React.createElement builds the description; ReactDOM handles the page."
That's under 60 seconds. It names JSX, the transform, the returned object, and the render path without getting tangled in internals. The interviewer now has a complete mental model and a clear starting point for follow-up.
What makes a short answer feel wrong
The structural mistake most candidates make is treating the question as an invitation to explain React's history. They start with "so JSX was introduced because writing React.createElement by hand was verbose" — and by the time they get to what the function actually returns, the interviewer has already made a judgment. The other failure mode is jumping straight to fiber or virtual DOM, which sounds impressive but skips the basic definition the question was asking for.
The real job is to name three things in one tight pass: JSX compiles to createElement, createElement returns a plain element object, and React uses that object to update the DOM. Everything else is follow-up territory.
What this looks like in practice
Imagine a 60-second mock interview moment. The interviewer asks: "Can you explain what React.createElement does?" The candidate answers with the paragraph above — type, props, children, plain object, reconciler. The interviewer follows up: "So is JSX a component?"
The candidate doesn't flinch: "No — JSX is syntax. It compiles to a createElement call. A component is the function or class that JSX might reference as the type argument, but they're different layers."
That follow-up answer takes five seconds because the original answer already established the vocabulary. The React documentation on JSX transformation and the React elements spec both treat this distinction as foundational — and interviewers who know their React do too.
Show the JSX-to-React.createElement Step Without Turning It Into a Compiler Tour
JSX is the shortcut, not the thing React understands
The common confusion is that JSX feels like React — it's in every React file, it looks like the UI, it is where you spend most of your time. But JSX is a compile-time transform. By the time React's runtime executes, every JSX expression has already been converted to a React.createElement call by Babel or the TypeScript compiler. React never sees JSX. It only sees function calls.
That distinction — JSX to React.createElement — is the core of the answer, and saying it clearly is what separates a candidate who uses React from one who understands it.
What this looks like in practice
Take this JSX:
Babel compiles that to:
The first argument is the type — the string `"button"` because this is a native HTML tag. The second argument is the props object. The third argument is the child — the text string "Submit." If there were multiple children, they'd be additional arguments or an array in props.children. The Babel REPL lets you paste JSX and see the compiled output in real time — it's the fastest way to make this transformation feel concrete rather than theoretical.
Why this matters in an interview
If you can trace that transform cleanly, you stop sounding like someone who memorized a definition and start sounding like someone who understands the flow. The interviewer's follow-up questions — "what if the type is a component?" or "where do children end up?" — are all answered by the same mental model you just demonstrated. You don't need to memorize new answers; you just extend the same trace.
Describe the React Element Object Before You Call It Anything Else
The plain-object mental model that interviewers are really testing
React.createElement returns a React element object — a plain JavaScript object, not a DOM node, not a component instance, not anything exotic. That object has a predictable shape: a `type` field, a `props` field that includes children, a `key`, and a `ref`. When you `console.log` a React element in a live app, that's exactly what you see.
This is what interviewers are actually probing when they ask about createElement. They want to know whether you understand that React operates on a description of the UI — the element object — rather than on the DOM directly.
What this looks like in practice
Run this in a React sandbox:
The output looks roughly like:
In an interview answer, the fields that matter are `type`, `props`, and `children` (which lives inside props). The `$$typeof` symbol is a security mechanism React uses to distinguish elements from other objects — worth mentioning if the interviewer pushes on internals, but not worth leading with. The React source-level documentation on elements describes this structure precisely.
The easiest mistake to make here
Candidates blur three distinct things: the React element object (a plain JS object describing what to render), the DOM element (a browser node that exists after React renders), and a component instance (what React creates internally when it processes a class component). These are three separate layers. Saying "createElement returns a DOM element" is wrong. Saying "createElement returns a component" is also wrong. The safe answer is always: it returns a plain object that describes what should be rendered.
Draw the Line Between React Element, React Component, and DOM Element
Why this mix-up keeps happening
When you write `<MyButton onClick={fn} />`, you're simultaneously looking at JSX syntax, referencing a component, and producing an element — all in one line. Those layers collapse visually, so it's easy to collapse them mentally too. The confusion isn't careless; it's structural. The code looks like one thing but represents three.
What this looks like in practice
Native tag example:
Function component example:
In both cases, `el` is a plain object. The DOM element doesn't exist yet. MyButton hasn't run yet. React element vs component is a question of what the `type` field holds — a string for native tags, a function or class for components — and the DOM element is downstream of the entire render process, not part of createElement at all. The React documentation on components and elements draws this distinction explicitly.
The one-sentence distinction worth memorizing
A component is a function or class. An element is the plain object React.createElement returns. A DOM element is the browser node React eventually creates. These are three different things at three different layers.
Explain What Happens When React.createElement Gets a Function or Class
The part most candidates hand-wave away
When the type argument is a function component or class component, React.createElement does not call that function or instantiate that class. It records the reference. The element object it returns has `type: MyButton` — the function itself — sitting in the type field. React's reconciler reads that later, during the render phase, and decides what to do with it.
What this looks like in practice
Function component path:
Class component path:
React calls the function or instantiates the class during reconciliation — not during createElement. This is why you can create elements without mounting them, pass them as props, or store them in state without triggering any rendering logic.
The interview-safe follow-up answer
If the interviewer asks whether function and class components are treated the same at the element level: yes, at the createElement level they are identical — both produce an element object with the component reference as the type. The difference only appears when React processes that element: function components are called, class components are instantiated and their `render` method is called. That distinction belongs to React's reconciler, not to createElement itself.
Separate React.createElement from ReactDOM.createRoot Before You Say Something Sloppy
Two different jobs people keep merging into one
Both APIs are involved in getting UI onto the page, which is why candidates conflate them. But they do completely different work. React.createElement builds a description — a plain element object that exists entirely in JavaScript. ReactDOM.createRoot attaches React to a real DOM container and gives you a root you can render into. One is about description; the other is about mounting.
What this looks like in practice
createElement runs first and produces the element object. createRoot runs second and connects React to the actual DOM node. root.render() takes the element object and kicks off reconciliation. These are sequential, and they are separate. The React 18 createRoot documentation covers the current API — if you're referencing the old `ReactDOM.render`, update your mental model, because interviewers working with React 18 will notice.
The line that keeps you out of trouble
"React.createElement builds the element object that describes the UI. ReactDOM.createRoot mounts React into a DOM container. They're different APIs doing different jobs — one is pure JavaScript, the other touches the browser."
Answer the Follow-Ups Interviewers Actually Throw at You
Is JSX a component?
No — and this is a trap worth knowing about. JSX is syntax. It compiles to React.createElement. A component is the function or class that JSX might reference as the type argument. You can write JSX that returns a native tag (`<div>`) and there's no component involved at all. Conflating JSX with components suggests you haven't separated the layers, which is exactly what this line of questioning is designed to test.
What is an element instance?
This phrasing is slightly sloppy, and interviewers sometimes use it deliberately to see how you respond. A React element is a plain object — it's not instantiated, it doesn't have methods, it doesn't hold state. The phrase "element instance" is usually fishing for clarification: do you know that elements are immutable descriptions, not live objects? The safe answer is to gently clarify: "A React element is a plain object, not an instance — it's a description of what to render. Component instances are what React creates internally when processing class components."
What changes if the child is a component instead of a DOM tag?
The type field in the element object changes from a string to a function or class reference. That's the mechanical answer. The behavioral consequence is that React's reconciler now needs to call or instantiate that type to get the next layer of elements — it recurses down the tree until everything resolves to native tags. This is why React can compose components: each one returns more elements, and React keeps unwrapping until it has a tree of strings it can hand to the DOM renderer.
Lock In the Answer So You Don't Blur It Under Pressure
The mistake that sounds almost right
The two most common almost-right answers are: "JSX is the component" and "createElement returns a DOM node." Both are wrong in a way that sounds plausible if you're not listening carefully — which is exactly why interviewers press on them. If you say either of those things, the follow-up will be immediate and uncomfortable.
What this looks like in practice
Before any React.createElement interview, rehearse three lines out loud:
- JSX line: "JSX is syntax sugar — Babel compiles it to React.createElement before React runs."
- Element object line: "React.createElement returns a plain JavaScript object with type, props, and children — not a DOM node."
- Render line: "React's reconciler reads those objects and ReactDOM handles the actual DOM updates."
Say those three lines in sequence until they come out without hesitation. That's the full answer. Everything else in this guide is follow-up ammunition.
How to self-check your answer in ten seconds
After you rehearse, ask yourself four questions: Did I name JSX as syntax, not a runtime thing? Did I say createElement returns a plain object, not a DOM node? Did I separate the component (function or class) from the element (the object)? Did I put DOM manipulation in ReactDOM, not in createElement? If you can answer yes to all four, the answer is interview-safe. If any of those distinctions blurred while you were talking, that's the one to drill.
FAQ
Q: What is React.createElement in plain English, and how do I explain it in under 30 seconds in an interview?
React.createElement is a function that takes a type (a tag name or component), a props object, and children, and returns a plain JavaScript object describing what should appear on screen. In an interview: "JSX compiles to React.createElement, which returns a plain object — the element — that React uses to figure out what to render to the DOM."
Q: When JSX is compiled, what exactly does React.createElement produce?
It produces a plain JavaScript object with at minimum a `type` field, a `props` field (which includes children), a `key`, and a `ref`. This object is sometimes called a React element. It is not a DOM node and it is not a component instance — it is a lightweight description of what should be on screen.
Q: What is the difference between a React element, a React component, and a DOM element?
A React component is a function or class that returns elements. A React element is the plain object that React.createElement returns — a description of what to render. A DOM element is the actual browser node that exists after React processes those descriptions and commits to the page. Three different layers, three different things.
Q: What happens when React.createElement receives a function component versus a class component?
In both cases, createElement records the reference in the element's `type` field and returns the element object — it does not call the function or instantiate the class. React's reconciler does that later during the render phase: function components are called, class components are instantiated and their render method is invoked.
Q: Why does understanding React.createElement matter if I mostly write JSX?
Because every JSX expression you write is React.createElement in disguise. When something breaks — a key warning, an unexpected re-render, a prop that didn't arrive — the mental model that helps you debug is the one where you can see what the createElement call looks like and what the element object contains. JSX fluency without createElement understanding is fluency without a foundation.
Q: What follow-up questions do interviewers usually ask after the basic definition?
The most common follow-ups: "Is JSX a component?" (no — it's syntax), "What does the returned object look like?" (type, props, children), "What's the difference between an element and a component?" (object vs function/class), and "What does ReactDOM.createRoot do differently?" (mounts React to the DOM, doesn't build elements). Knowing those four covers the vast majority of React.createElement interview follow-ups.
Q: How do I avoid the common mistake of saying JSX or a component is the same as an element?
Keep the three-layer model active: syntax (JSX), description (element object), browser node (DOM element). When you're about to say "JSX is" or "a component is," pause and ask which layer you're actually talking about. JSX is compile-time syntax. A component is a function or class. An element is the plain object createElement returns. If those three definitions are sharp, the conflation doesn't happen.
How Verve AI Can Help You Prepare for Your Interview With React.createElement
The hardest part of a React.createElement interview isn't knowing the definition — it's delivering it cleanly under live pressure without blurring the layers. That's a performance skill, not a memorization skill, and it only develops through repetition against real follow-up questions.
Verve AI Interview Copilot is built for exactly that gap. It listens in real-time as you talk through your answer and responds to what you actually said — not a canned prompt. If you blur element and component in your answer, Verve AI Interview Copilot catches it. If your JSX explanation drifts into runtime territory, the follow-up question it generates reflects that specific mistake. Verve AI Interview Copilot stays invisible while you practice, so the friction of the drill stays low and the feedback stays sharp. For a concept like React.createElement — where the answer is short but the follow-up tree is wide — that kind of responsive practice is what closes the gap between knowing the material and sounding like you own it.
Conclusion
You don't need to sound like a React runtime engineer to pass a React.createElement interview. You need to sound precise enough to separate four things without wobbling: JSX is compile-time syntax, React.createElement returns a plain element object, a component is the function or class that object might reference, and the DOM element only exists after React renders. That's the whole answer. Everything in this guide is either the answer itself or ammunition for the follow-ups.
Rehearse the three-line version out loud right now — JSX line, element object line, render line — and then test it against the follow-up questions in Section 7. If you can answer "is JSX a component?" and "what does the element object look like?" without pausing, you're ready.
Morgan Kim
Interview Guidance
