Myth — "Factory Must Be Used Everywhere"

No — you use the factory for things a test might override, which means all components, transaction items, and sequences, but a purely internal object that no test would ever override gains nothing from the factory and only pays its cost. The factory's entire purpose is substitutability: type_id::create routes construction through the factory so a test can register an override and substitute a derived type from above without editing the environment. That capability is exactly what you want for components, so a test can swap in an error-injecting driver or an extended monitor; for transaction items, so a test can inject a faulty item; and for sequences, so behavior is overridable. For those, the factory is non-negotiable, and new is a mistake because it silently bypasses the factory and breaks overrides — a high-cost, confusing error. But the factory is not free: it requires the type to be registered and performs a lookup on every create. For an object that is purely internal to a component, fully type-controlled, and never a candidate for override — a small bookkeeping struct, a local helper, a transient calculation object — the factory adds the registration burden and a per-construction lookup and buys nothing, since there is nothing to override. If that object is also created at high rate in a hot path, the lookup is wasted cost. So the line is overridability: use the factory wherever a test might substitute the type, and a plain new is appropriate for genuinely internal, non-overridable helpers. The understanding to convey is that the factory is for overridable things and that forcing it everywhere, including on internal hot-path helpers, is overhead without benefit — which shows you know why the factory exists, not just the rule.

Yes — new is acceptable for a genuinely local, non-overridable object whose type you fully control, while it is a mistake for components and transaction items, where it silently breaks factory overrides. The reflexive teaching is never use new, always type_id::create, and that is correct as a default for the overridable architecture: a component or item built with new bypasses the factory, so any test override of it is silently ignored, and the classic symptom is a registered override that does nothing — a high-cost, hard-to-find bug. So for components, items, and sequences, you always use the factory. But new is not universally wrong. When you construct an object that is purely internal to your component, that no test would ever want to override, and whose type is fixed and under your control — a private data structure, a temporary helper, a local container element — there is nothing for the factory to override, so the factory adds only its registration requirement and per-construction lookup with no benefit. There, new is not just acceptable but clearer and slightly faster, and if the object is created at high rate in a hot loop, avoiding the factory lookup is a legitimate performance choice. The discipline is to base the decision on overridability and cost: factory where a test might override, new where the type is internal and fixed. Stating new is always wrong is the overcorrection; the calibrated position is that new is wrong specifically where it breaks overrides and fine where there are no overrides to break. The understanding to convey is the conditions under which new is acceptable and the high-cost case where it is not, which shows you understand the trade-off rather than reciting an absolute.

The factory's cost is a registration requirement on the class and a type lookup on every type_id::create call, and it matters when objects are created at high rate in a hot path, where the per-construction lookup accumulates. Using the factory requires that the class be registered with the uvm_component_utils or uvm_object_utils macro so it has a type_id the factory knows, and each create performs a lookup to resolve the type — checking for any registered override and returning the right type. For the things you create occasionally — components built once at build time, or even transaction items at typical transaction rates — this cost is negligible and entirely worth the overridability it buys. Where it can matter is a genuinely hot path: an object constructed thousands or millions of times across a run, like a helper created per transaction in a scoreboard or a temporary built inside a tight loop. There the factory lookup, multiplied by the construction rate, becomes a measurable cost, and if that object is internal and never overridden, the cost buys nothing. That is the case where a plain new, or reusing a pooled instance, is the right optimization, as the performance checklist notes. The practical guidance is that you do not micro-optimize by default — you use the factory for the overridable architecture and let its cost be paid where it earns overridability — but where profiling shows construction in a hot path dominating, and the object is internal and non-overridable, dropping to new is justified. The understanding to convey is that the factory cost is registration plus a per-create lookup, negligible for normal construction but real in a hot path, and that it is a profiling-guided trade-off, not a reason to avoid the factory for the architecture where overridability matters.

Because it shows you learned the rule use type_id::create without learning the reason it exists, so you apply it as a ritual rather than for its purpose, which an interviewer reads as cargo-cult understanding. The factory has a specific purpose — to make types overridable from a test — and the right use of it follows from that purpose: you use it where a test might substitute a type, and you understand that where nothing will ever be overridden, it buys nothing. An engineer who understands this uses the factory deliberately for components, items, and sequences and can explain why, and recognizes that an internal, fixed-type helper does not need it. An engineer who has only absorbed always use the factory applies it to everything, including objects no test would override, because they are following a rule rather than reasoning from the rule's purpose — and when asked why, they cannot give a reason beyond that is what you are supposed to do. That inability to justify the boundary is the tell. It is the same pattern as any cargo-cult practice: the form is copied without the function, so it is applied uniformly rather than where it matters, and it cannot adapt to a case the rule did not explicitly cover. Demonstrating understanding means explaining the overridability purpose, where it applies, and where it does not, including the hot-path cost case — which shows you reason from the mechanism's purpose. The understanding to convey is that reflexive uniform application signals rule-following without comprehension, while deliberate application with a justified boundary signals real understanding of why the factory exists, which is the distinction the interview is probing.

You decide by asking whether a test might ever want to override its type, and secondarily what its construction cost is: if a test might substitute it, use the factory; if it is internal and fixed and especially if it is hot, a plain new is appropriate. The primary question is overridability. A type is a factory candidate if substituting it is a meaningful test capability — components, because tests specialize environments by swapping a driver or monitor; transaction items, because tests inject error or extended variants; sequences, because tests override behavior. For all of these the answer is yes, use the factory, and the cost of getting it wrong with new — a silently broken override — makes the factory non-negotiable there. A type is not a factory candidate if it is purely internal to a component, its type is fixed and under your control, and no test would have any reason to replace it — a private helper, a bookkeeping struct, a local container element. For those, the factory adds registration and a lookup with no overridability benefit. The secondary question is cost: if such an internal object is created at high rate in a hot path, avoiding the factory lookup with new or a pool is a justified optimization; if it is created rarely, the factory's cost is negligible and using it for uniformity does little harm either way, so the overridability test dominates. So the decision rule is overridability first — factory if a test might override, new if it is internal and fixed — with hot-path cost reinforcing new for internal objects. The understanding to convey is the overridability-and-cost decision rule, which shows you place each object deliberately rather than applying the factory or new reflexively.