Use ng generate component to explain what Angular CLI creates, how standalone mode changes the files, and the follow-up interview questions.
Most Angular candidates know the command. The freeze happens a few seconds later, when the interviewer asks "and what exactly does it create?" or "how does that change if your project uses standalone components?" — and the answer that felt solid in practice suddenly sounds like a glossary entry being read aloud. `ng generate component` is the right starting point, but the interview isn't testing whether you can type the command. It's testing whether you understand what the CLI is doing for you and what it's leaving for you to figure out yourself.
This guide gives you the exact mental model: what gets generated, how standalone mode changes the story, what you still have to wire manually, and how to answer the follow-ups before they're asked.
Say What the Command Does Before You Start Listing Files
The instinct under interview pressure is to reach for specifics immediately — file names, flags, folder structure. That instinct is understandable but backwards. Interviewers are not looking for a directory listing. They want to know whether you have a working mental model of Angular CLI component generation and where it fits in the development workflow.
The One-Sentence Answer Interviewers Want
Here is the sentence worth memorising: `ng generate component` scaffolds a reusable Angular component by creating the TypeScript class, HTML template, stylesheet, and optional spec file, then wires the component into the nearest NgModule — or marks it as standalone — depending on your project configuration.
That sentence does three things at once: it names the command's purpose (scaffold), it names the artifacts (class, template, styles, spec), and it signals that you know the context matters (module-based vs. standalone). A candidate who opens with that sentence has already answered 80% of what the interviewer actually wants to know. Everything else is elaboration.
Why People Overcomplicate a Simple Command
There is a reasonable instinct behind over-listing: you want to sound thorough. The problem is that leading with `--skip-tests` and `--inline-style` and `--change-detection` before you have explained what the command fundamentally does sounds like you memorised a man page rather than used the tool. Interviewers who have run Angular interviews repeatedly have heard that pattern, and it reads as shallow rather than deep. The flags are real and worth knowing, but they are detail on top of a foundation — and if you lead with detail, you signal that you do not have the foundation.
The stronger move is to state the plain-English purpose first, then offer to go deeper on flags or configuration if the interviewer wants it. That is what a working developer actually does when explaining a tool to a colleague.
What This Looks Like in Practice
Say you are building a product grid and you need a card component that will render for each item. You run:
Angular CLI creates a `product-card/` folder inside your current directory with four files: `product-card.component.ts`, `product-card.component.html`, `product-card.component.css`, and `product-card.component.spec.ts`. In a module-based project, it also updates the nearest `NgModule` to add `ProductCardComponent` to the `declarations` array. That is the scaffolding job done. What you have now is a reusable UI building block with its own encapsulated template and styles — not just a file, but a component that Angular knows about.
The Angular CLI documentation lists every generated artifact and every supported flag, and it is worth reading once so you are not guessing at what the defaults actually are.
Remember the Shorthand and the Flags That Actually Matter
The Shorthand People Use Without Thinking
`ng g c` is the shorthand everyone uses in real projects. In an interview, mentioning it is worth one sentence: "In practice I use `ng g c` — same command, just faster to type." That is it. Do not spend more than a breath on it. The shorthand matters because Angular projects generate a lot of components, and typing the full command for every one of them would be genuinely slower. It does not matter because it sounds clever to say in an interview.
Same output, same behavior. The ng g c shorthand is standard across every Angular team I have worked on, and any interviewer who knows Angular will recognise it immediately.
The Flags Worth Naming Out Loud
Three flags are worth knowing and being able to explain clearly:
`--skip-tests` omits the `.spec.ts` file. Use this when you are generating a throwaway UI component during a spike or when your project uses a testing setup that does not rely on the default Jasmine/Karma spec files. Generating specs you will never use adds noise.
`--inline-style` removes the separate `.css` file and puts the styles directly in the `@Component` decorator's `styles` array. This makes sense for small, self-contained components where the styling is trivial and a separate file would be overhead without benefit.
`--inline-template` does the same for the HTML, embedding it in the `template` property rather than a separate `.html` file. This is useful for components with minimal markup — a loading spinner, a simple badge — where the template is two or three lines and a separate file is more ceremony than substance.
What This Looks Like in Practice
For a modal component that is a real feature with its own styles and template logic, you want separate files:
For a tiny confirmation badge that will live inside a table row and has four lines of markup and one CSS rule, inline makes sense:
The Angular CLI generate options reference documents every flag and its default value. The defaults exist for a reason — they are what most production Angular teams actually want most of the time.
Know What Angular CLI Creates in Standalone and Module-Based Projects
Module-Based Projects Still Teach the Old Mental Model
In a module-based Angular project, `ng generate component` does something beyond creating files: it automatically adds the new component to the `declarations` array of the nearest `NgModule`. This matters for two reasons. First, Angular's component system requires that every component belong to exactly one module before it can be used anywhere. Second, if you want to use the component in a different module, you have to `export` it from its own module and `import` that module wherever you need it. Interviewers ask about declarations, exports, and imports because those concepts reveal whether a candidate understands Angular's dependency resolution system — not just its file structure.
If you can explain that a `declarations` array tells Angular which components, directives, and pipes belong to a module, and that `exports` controls what is visible outside that module, you are demonstrating component system knowledge, not just CLI knowledge.
Standalone Changes the Wiring, Not the Job
Standalone component generation, introduced as stable in Angular 15 and now the default in Angular 17+, changes one structural thing: the component is no longer declared in an NgModule. Instead, it manages its own imports directly. The scaffolding job is identical — you still get the TypeScript class, template, styles, and spec file. But the generated component now has `standalone: true` in its `@Component` decorator, and its `imports` array is where you list the other components, directives, and pipes it depends on.
In an Angular 17+ project with standalone defaults, you do not need the flag — standalone is already the default. The key interview point is this: standalone removes the NgModule from the picture, but it does not remove the need to understand what the component depends on. You just declare those dependencies on the component itself instead of on a module.
What This Looks Like in Practice
Module-based output (Angular 14 and earlier defaults):
Standalone output (Angular 17+ defaults):
No module file is touched. The Angular documentation on standalone components explains what moves into the component's own `imports` array and why — worth reading before any interview at a team that has migrated to Angular 15+.
Separate What the CLI Gives You From What You Still Have to Wire
The Generated Pieces Are Only Half the Story
The Angular component files the CLI creates — the TypeScript class, the HTML template, the stylesheet, and the spec — are scaffolding. They give you a valid, compilable component. They do not give you a component that does anything, renders anywhere, or communicates with anything. Generation and integration are two separate jobs, and conflating them is the most common gap in junior Angular interview answers.
A generated component with no parent template referencing its selector, no route pointing to it, and no data flowing into it is a file that compiles and does nothing. The CLI's job ends at the folder. Your job starts there.
The Missing Wiring Is Where Real Angular Knowledge Shows Up
To actually use a generated component, you need to do at least one of the following: add its selector to a parent template, add it to a route configuration, or import it into a parent standalone component. Beyond that, real components need data. That means understanding `@Input()` for passing data down, `@Output()` with `EventEmitter` for sending actions up, and the component's selector as the bridge between the template world and the class world.
The `@Component` decorator's `selector` property is what you use in parent templates. If your selector is `app-product-card`, then `<app-product-card></app-product-card>` is how the parent renders it. That connection — between the decorator metadata and the template syntax — is what interviewers are probing when they ask follow-up questions about how you would actually use the component you just generated.
What This Looks Like in Practice
Start with the generated component:
Now wire it. Add an `@Input()` for the widget title and an `@Output()` for a refresh action:
In the parent template:
The Angular documentation on component inputs and outputs covers this precisely. The CLI gave you the shell. The `@Input()`, `@Output()`, and the parent template reference are what make it a working piece of the application.
Use the Generated Component Like a Real Feature Team Would
A Card, Modal, or Widget Is the Right Kind of Example
Abstract examples do not land well in interviews. What lands is a specific, recognisable UI pattern that the interviewer has almost certainly built themselves. A product card, a modal dialog, and a dashboard widget are all good choices because they are genuinely reusable — the same component renders in multiple places with different data each time. That reusability is the whole point of component-based architecture, and naming it explicitly shows you understand why Angular's component system is designed the way it is.
Data Flows Through the Component, Not Around It
Component communication is the mechanism that makes a generated component useful rather than decorative. The component receives data through `@Input()` properties — the parent controls what data it provides, the component controls how it renders that data. The component sends actions back through `@Output()` event emitters — the component decides when to emit, the parent decides what to do with the event. This separation of concerns is not just a pattern; it is what keeps Angular applications testable and maintainable as they grow.
A component that reaches outside itself to pull data from a service or mutates global state directly is harder to reuse, harder to test, and harder to reason about. A component that declares its inputs and outputs explicitly is a contract — you know exactly what it needs and exactly what it can tell you.
What This Looks Like in Practice
Take a modal dialog component. After generating it with `ng g c modal`, you wire it like this:
The parent template renders it conditionally:
Now you can explain this in plain English in an interview: "The modal receives its title as an input from the parent, and it emits a `closed` event when the user dismisses it. The parent decides whether to show it based on local state. The modal itself does not know or care about what triggered it — it just renders what it receives and emits when it's done." That is a working developer's explanation, not a textbook definition.
Answer the Follow-Ups Before the Interviewer Asks Them
Declarations Versus Imports Is the Real Trap
In module-based Angular, `declarations` is where you register a component so the module knows it exists. `exports` is how you make it available to other modules. `imports` on the module is how you bring in other modules' exported components. These three concepts form the core of Angular's component visibility system — and interviewers ask about them because a candidate who cannot explain the difference between declaring a component and importing a module has a gap in their mental model that will cause real bugs in a real project.
In standalone Angular, the `imports` array moves to the component itself. You import `CommonModule`, `ReactiveFormsModule`, or other standalone components directly into the component that needs them. The concept is the same — explicit dependency declaration — but the location changes.
Lifecycle Hooks, Routing, and Dependency Injection Are Fair Follow-Ups
A strong candidate can connect the generated component to three adjacent topics without losing the thread. Lifecycle hooks — particularly `ngOnInit` for data fetching and `ngOnDestroy` for cleanup — are almost always relevant because generated components frequently need to do something when they first render. Lazy-loaded routes are relevant because Angular's router is where many generated components actually live, and understanding that a component can be a route target changes how you think about its structure. Dependency injection is relevant because most real components need a service — and the service is injected through the constructor, not generated by the CLI.
None of these topics require a deep dive to mention credibly. "I'd typically inject a service in the constructor for data fetching and use `ngOnInit` to trigger the first load" is one sentence that signals genuine familiarity.
What This Looks Like in Practice
Here are three follow-up questions that separate candidates who understand component generation from those who just know the command:
"If you generate a component in a feature module, what do you need to do to use it in a different module?" — A strong answer explains that the component must be added to the feature module's `exports` array, and the feature module itself must be imported into the module where the component will be used.
"You generated a component that needs data from an API. Walk me through how you'd connect it." — A strong answer mentions injecting a service, calling the service in `ngOnInit`, and binding the result to a template variable. A weak answer stops at "I'd use a service."
"What happens if you forget to add a generated component to its module's declarations?" — A strong answer names the specific error: Angular throws a template parse error saying the component is not a known element. That specificity shows the candidate has actually hit this error in a real project.
The Angular documentation on NgModules and the routing guide are the primary sources for follow-up depth.
Make Your Answer Sound Like Someone Who Has Actually Used Angular
The Weak Answer Sounds Like a Glossary Entry
The weak version of this interview answer lists file names in order, maybe mentions the shorthand, and stops. It sounds like someone who read the Angular CLI documentation the night before and is reciting it back. It does not explain why the command exists, what problem it solves, or how the generated component fits into a working application. Angular component structure is not just about what files exist — it is about how those files relate to the rest of the app.
The Strong Answer Sounds Like a Working Developer
The strong version names the command, describes the generated artifacts in plain English, mentions the standalone vs. module-based difference without being asked, and anchors the whole thing in a concrete use case. It sounds like someone who has typed this command two hundred times and knows exactly what comes out the other side.
What This Looks Like in Practice
Weak answer: "ng generate component creates four files: the component TypeScript file, an HTML template, a CSS file, and a spec file. You can also use ng g c as a shorthand."
Strong answer: "ng generate component scaffolds a new Angular component — it creates the TypeScript class, HTML template, stylesheet, and spec file, and in a module-based project it automatically adds the component to the nearest NgModule's declarations. In Angular 17+ with standalone defaults, it skips the module and marks the component as standalone instead, so you manage its dependencies through the component's own imports array. I'd typically use this when I need a reusable piece of UI — a product card, a modal, a dashboard widget. The CLI gives you the shell; you still need to wire up the selector in a parent template, add inputs and outputs for data flow, and hook into lifecycle methods if the component needs to fetch data. The shorthand is ng g c, which is what I use in practice."
That answer takes about 30 seconds to say out loud. It covers the command, the artifacts, the module vs. standalone distinction, a real use case, and the gap between scaffolding and integration. Practice saying it once. Then practice saying it again with the standalone difference explained more explicitly — because that is the follow-up that trips up candidates who learned Angular before version 15.
FAQ
Q: What does ng generate component do in Angular, in one interview-ready sentence?
`ng generate component` scaffolds a reusable Angular component by creating the TypeScript class, HTML template, stylesheet, and optional spec file, then either registers the component in the nearest NgModule or marks it as standalone depending on your project configuration. That sentence covers the command's purpose, the generated artifacts, and the context-dependency that separates a strong answer from a basic one.
Q: What files and folder structure does Angular CLI create when you run it?
Running `ng generate component my-component` creates a `my-component/` folder containing four files: `my-component.component.ts` (the class and decorator), `my-component.component.html` (the template), `my-component.component.css` (the styles), and `my-component.component.spec.ts` (the Jasmine test file). In a module-based project, the CLI also updates the nearest `NgModule` to add the component to its `declarations` array — no manual edit required.
Q: What is the shorthand version of the command and when is it acceptable to use?
`ng g c` is the standard shorthand and it is acceptable to use everywhere — in development, in CI scripts, and in interviews when you mention it. It produces identical output to the full command. Every Angular developer uses it; there is no context where the full command is required.
Q: How do standalone components change the way component generation is explained in interviews?
Standalone components remove the NgModule from the picture. The generated files are the same, but the component's `@Component` decorator includes `standalone: true`, and its `imports` array is where you declare dependencies instead of in a module. In Angular 17+, standalone is the default, so you do not need the `--standalone` flag. In an interview, mentioning this distinction signals that you are current with Angular's direction and understand why the change was made.
Q: What does the command generate automatically versus what the developer still needs to wire up manually?
The CLI generates the component files and handles module registration automatically. What it does not do: add the component's selector to any parent template, configure a route to point to it, define `@Input()` and `@Output()` properties, inject services, or implement lifecycle hooks. Generation is scaffolding. Integration — making the component actually render and communicate with the rest of the app — is the developer's job.
Q: How would you use a generated component in a real feature, such as a card, modal, or dashboard widget?
Generate the component, then add `@Input()` properties for any data the component needs to render and `@Output()` event emitters for any actions it needs to report back to its parent. In the parent template, use the component's selector with property bindings for inputs and event bindings for outputs. For a modal, that means the parent controls visibility and passes a title as an input; the modal emits a `closed` event when dismissed. The parent handles the event and updates its own state.
Q: What follow-up questions should an interviewer ask to confirm the candidate truly understands component generation?
Three questions expose genuine understanding versus surface familiarity: "What do you need to do to use a component generated in one module from a different module?" (tests knowledge of exports and imports), "Walk me through connecting a generated component to an API" (tests lifecycle hooks and service injection), and "What error do you get if you forget to add a generated component to its module's declarations?" (tests whether the candidate has actually hit this in practice — the answer is a template parse error saying the element is not known).
How Verve AI Can Help You Prepare for Your Interview With ng generate component
The hardest part of answering a technical question in a live interview is not knowing the answer — it is knowing the answer and still losing the thread when the follow-up diverges from what you rehearsed. You planned to explain module-based projects, the interviewer asks about standalone. You practiced the file structure, they ask what error you get when you forget to declare the component. That gap between preparation and live performance is exactly what Verve AI Interview Copilot is built to close.
Verve AI Interview Copilot listens in real-time to the actual conversation happening in your interview — on Zoom, Google Meet, or Teams — and surfaces relevant talking points as the question unfolds. It does not give you a script to memorise. It responds to what is actually being asked, including the follow-up you did not see coming. For a question like `ng generate component`, that means it can surface the standalone vs. module distinction when the interviewer pivots there, or prompt you to mention `@Input()` and `@Output()` when the conversation moves toward component integration.
The desktop app stays invisible during screen share at the OS level — the interviewer cannot see it even if they ask you to share your screen. Setup takes a few minutes: sign in, select your role and stack, join the call. If you want to go deeper, you can upload your resume, load Angular-specific Q&A pairs, or add context about the company — but none of that is required to start. Verve AI Interview Copilot is the difference between preparing for the question you expect and being ready for the one that actually comes.
Conclusion
You came into this article knowing the command. You leave it with the sentence that opens the answer cleanly, the file structure that backs it up, the standalone vs. module distinction that separates strong answers from basic ones, and the follow-up questions that test whether you actually understand what the CLI generated versus what the app runtime needs.
Now do one thing: say the strong answer out loud. Not in your head — out loud, at interview pace. Then say it again with the standalone explanation added in. That second pass is where most candidates still stumble, and it is exactly what the interviewer is listening for.
James Miller
Career Coach
