What bindings do v-model and ngModel sugar, and why?
If you know two-way binding is property binding plus an event.
v-model sugars value and input; ngModel sugars [value] and (ngModelChange). This enforces one-way data flow for predictable state.
What's really being asked
This question probes whether you understand that two-way binding directives are compiler sugar rather than runtime magic. Interviewers want to see that you can decompose v-model and ngModel into their constituent one-way property binding and event binding parts, and that you grasp why unidirectional data flow is the bedrock of maintainable component architectures. Senior candidates should connect this pattern to framework-agnostic principles like the single source of truth and explicit change notification.
The full answer
First, the mechanical decomposition. In Vue, v-model on a native input roughly expands to binding the value attribute and listening for the input event. In Angular, the banana-in-a-box syntax [(ngModel)] is shorthand for a property binding [ngModel] paired with an event binding (ngModelChange). Second, the directionality. Props down means the parent passes state to the child via inputs; events up means the child notifies the parent of changes through outputs, letting the parent mutate the canonical state. Third, the architectural rationale. This pattern prevents hidden side effects, makes data flow traceable, and allows child components to remain presentational and reusable across different parent contexts. Fourth, the custom component angle. Both frameworks let you define custom v-model or ControlValueAccessor implementations, which still obey the same two-part contract: accept a value, emit a change event.
The mistakes people make
A red flag is describing the syntax as true bidirectional data flow where the child mutates the parent object directly. Another mistake is conflating ngModel with reactive forms or failing to name the specific event that carries the change. Some candidates say it is just for convenience without explaining why the underlying one-way flow matters, which signals shallow familiarity. Claiming that two-way binding breaks unidirectional data flow is also incorrect; the syntax preserves it by design.
What usually comes next
An interviewer might ask how to implement a custom v-model in Vue using modelValue and update:modelValue, or how Angular ControlValueAccessor bridges template-driven and reactive forms. They could also ask how this pattern compares to React controlled components, or when you should avoid two-way binding in favor of explicit one-way plus callback props.
A concrete example
Imagine a numeric stepper component. With props down, the parent passes count={5} into the stepper. When the user clicks plus, the stepper does not increment its own copy; instead it emits an onChange event with the new value. The parent receives the event, updates its own state, and the new count flows back down. This loop keeps the parent as the single source of truth and makes the stepper trivial to test in isolation because it has no internal state to manage.
Interview question
Which best explains why two-way binding syntax in Vue and Angular is considered syntactic sugar rather than true bidirectional flow?
- a.It expands into a one-way property binding plus an event binding so the parent can update its own state.Correct
- b.It creates a dedicated two-way reactive tunnel that bypasses normal props and events.
- c.It relies on framework-level watchers to detect changes and silently update the parent property.
- d.It allows the child component to directly mutate the parent's bound property without an explicit event.
Why? this is the answer
v-model sugars value and input while ngModel sugars a property binding and ngModelChange, preserving unidirectional data flow by requiring the parent to handle the event and mutate canonical state. The first option is wrong because the child never directly mutates the parent; it only emits a change notification.
Just read this? Test yourself on what you have been reading.
Read the original → angular.dev
- #vue
- #angular
- #data-binding
- #components
- #frontend-architecture
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on vue — each one lists the topics its interview covers.
See open roles