Angular
Senior

The tag defines the element; The attribute configures information or behavior in its start tag. A property DOM represents the live state and may differ from the initial attribute.

id identifies an element within the document and is used for relationships, fragments and labels. class groups elements for styles or behavior.

I associate labels, group options with fieldset/legend, use types and autocomplete, explain errors and move focus when the flow requires it.

ol communicates that the order modifies the meaning; ul groups elements without semantic sequence.

A link with href changes location and preserves native actions such as opening in another tab. A button executes an action in the interface. Choosing the right element brings keyboard, role and expectations without recreating them with JavaScript.

Attributes such as required, type, min, max and pattern express constraints and allow feedback from the browser. The application can customize messages, but the server must repeat the validation because the client can modify it.

Flexbox distributes elements along an axis and allows wrapping. Grid defines a two-dimensional structure. An interface can use both at different levels.

The element can live within a stacking context that is below another. I compare ancestral contexts before uploading the number.

display:none removes box; visibility:hidden conserves its space. If you need to only visually hide and maintain readability, I use a proven visually-hidden pattern.

I reduce specificity, define tokens and layers, limit scope, document variants and test states, sizes, themes and actual content.

I identify the stacking contexts of both elements and compare their ancestors, not just their numbers. transform, opacity, isolation, and certain positioned elements create contexts that limit where a descendant competes.

A media query responds to the viewport or user preferences. A container query responds to the space available for the component. The second allows you to reuse the same piece in different layouts without knowing the page that contains it.

var has function scope and allows redeclaration. let and const have block scope and remain in the Temporal Dead Zone until initialized. const prevents reassignment of the binding, but the referenced value can still mutate.

Abstract equality does not compare the array and boolean directly. It first converts false to the number 0. It then applies ToPrimitive to the array: [].toString() produces ''. Because it is now comparing a string with a number, it converts '' to 0; the final result is 0 == 0, which is true. In contrast, [] === false is false because the types differ and no coercion occurs. I would not memorize only this result: following boolean → number, object → primitive, and string → number also explains cases such as [0] == false. In production code I use === and explicit conversions so this sequence is not hidden.

I use arrow for callbacks that need the outer this. Use normal function for dynamic methods, constructors or APIs that assign receiver.

A shallow copy creates a new object or array, but nested values are copied by reference. For example, with const original = { user: { name: 'Ana' } }; const copy = { ...original };, copy !== original, but copy.user === original.user; therefore, copy.user.name = 'Luis' also changes original.user.name. Spread, Object.assign, Array.from, and slice make shallow copies. A deep copy recursively duplicates the structure so nested objects do not share identity. structuredClone(original) works for many native data types and cycles, but it does not clone functions or DOM elements, and it does not preserve the behavior of every class instance. I do not deep-clone by default: it costs CPU and memory and can break identities the application relies on. For state updates, I prefer copying only the changed path, such as { ...state, user: { ...state.user, name: 'Luis' } }; this preserves immutability and structural sharing without duplicating the entire object graph.

A closure is a function together with references to the bindings in its lexical environment. It is determined when the function is created, not when it is invoked. For example, function makeCounter() { let count = 0; return () => ++count; } returns a function that keeps accessing count after makeCounter finishes. const a = makeCounter(); const b = makeCounter(); creates two environments: a() returns 1, then 2, while b() starts at 1. The runtime preserves only environments that remain reachable, so a closure provides private state without turning count into a global variable.

It captures the binding—the cell where the value lives—not an immutable snapshot. With let rate = 1; const price = value => value * rate; rate = 2;, price(10) returns 20 because it reads the current value of rate. Several functions can share the same binding and observe its changes. If I need to freeze a value at a point in time, I create another binding by passing the value to a factory: const withRate = rate => value => value * rate. Each call receives its own rate parameter.

var has function scope, so every callback closes over one shared i binding. When the timer runs, the loop has finished and that binding is 3: for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)); prints 3, 3, 3. With let, the specification creates a new binding for every iteration, producing 0, 1, 2. Another solution is a factory or IIFE that receives i and creates a distinct parameter for each iteration. The important point is not the timer: it is how many bindings exist and which one each function captures.

While a function is reachable, the values it needs from its environment also remain reachable. A global listener that captures a component, a timer that captures a large response, or an unbounded cache can keep that graph alive after the view is removed. Not every closure is a leak: it becomes a problem when the reference outlives the useful lifetime of the data. I remove listeners, clear timers and subscriptions, limit caches, and capture only the necessary identifier or small value. In Angular I connect cleanup to DestroyRef or takeUntilDestroyed when appropriate.

With explicit conversion, the code states its intention: Number(input.value), String(id), or Boolean(flag). Implicit coercion occurs inside an operator or context: '5' - 1 produces 4, 1 + '2' produces '12', and if ('false') enters because the string is not empty. Coercion is not automatically an error; templates, comparisons, and operators depend on it. The risk appears when it hides a contract. At external boundaries I convert, validate, and keep a stable type from that point onward.

ToPrimitive is the abstract operation that converts an object into a primitive value before another algorithm continues. If present, it calls Symbol.toPrimitive; otherwise it tries valueOf and toString in an order determined by the hint. They must return a primitive or conversion fails with a TypeError. That is why [] + 1 produces '1': the array becomes '' and + concatenates. An object can customize the result with [Symbol.toPrimitive](hint), but surprising behavior makes operators difficult to reason about; I normally prefer explicit domain methods.

When JavaScript enters a block, it creates the bindings for let, const, and class, but leaves them uninitialized until their declaration executes. That interval is the Temporal Dead Zone. Reading the binding during it throws a ReferenceError: console.log(total); let total = 1;. Even typeof total fails when total is in the TDZ, unlike a variable that does not exist. With var, the binding is initialized to undefined, so early access does not fail and can hide an ordering bug. The TDZ prevents a block-scoped variable from being used before it has the value promised by its declaration. It does not mean let and const are not hoisted: their bindings are created when entering the scope, but they are not accessible yet.

Yes, but I would deliberately use value == null only when I want to accept exactly null or undefined. The comparison is true for those two values and false for 0, false, '', and NaN; for example, if (response.middleName == null) detects that an optional field is missing without rejecting a valid empty string. This is a well-known Abstract Equality exception and should be allowed explicitly with a rule such as eqeqeq: ['error', 'always', { null: 'ignore' }]. Everywhere else I use === and !==, because == applies coercions that are difficult to read: '' == 0, '0' == false, and [] == false are all true. If the team prioritizes maximum explicitness, I write value === null || value === undefined; it communicates the same contract without relying on knowledge of the exception.

class organizes inheritance and methods with clearer syntax; the runtime resolves methods through prototypes. Knowing the model explains instanceof, shadowing and shared methods.

map creates a transformed collection and requires using the return. forEach expresses one effect per element and returns undefined.

Map accepts any key, preserves insertion order, and offers size and direct iteration. An object fits into records with string/symbol keys and JSON serialization.

push, pop, shift, unshift, splice, sort, reverse, fill and copyWithin. map, filter, slice, concat and the to* methods create another array.

Spread copies enumerable properties from the first level. Nested references remain shared and the copy does not preserve complete descriptors or internal behavior of all objects. First I define which part of the model needs a new identity.

Each operator can loop through and assign another collection. On a hot route or a large list, a single loop can reduce memory and work. I keep the chain when its clarity outweighs that measured cost.

A Promise represents a single result that may not yet be available. Starts pending and ends fulfilled with a value or rejected with an error. For example, fetch('/users') immediately returns a Promise; The object allows you to record what to do when the response or failure arrives. Promise does not contain a thread nor does it execute two results: it models the completion of an operation.

No. new Promise((resolve) => { console.log('executor'); resolve(1); }) prints executor during the current stack. What runs next as a microtask is the callback registered with then. Putting a heavy loop inside the executor blocks the interface just like any other synchronous code.

then returns a new Promise. If the callback returns 42, the new Promise satisfies 42; if fetch(...) returns, it adopts the state of that Promise; If it throws an error, it is rejected. This contract allows chaining transformations and propagating errors up to a catch.

The callback returns undefined, so the next then continues without waiting for the internal operation. On loadUser().then(user => { saveUser(user); }).then(showSuccess), showSuccess may execute before saveUser terminates. The fix is ​​return saveUser(user) or use await saveUser(user) inside a async function.

First run the synchronous stack: A and E. The microtasks are then processed in the order in which they were queued: C and D. At the end the timer task runs and B appears. The result is A, E, C, D, B. A timer with zero delay indicates a minimum delay; it doesn't jump ahead of the stack or microtasks.

await pauses the containing function async and returns control to the caller. The main thread can process other tasks. When Promise finishes, JavaScript enqueues the continuation of the function as a microtask. A heavy calculation before or after await still blocks because await does not create another thread.

Use sequence when an operation depends on the previous result, such as loading a user and then querying their permissions. For independent jobs, start both before: const userRequest = loadUser(); const settingsRequest = loadSettings(); const [user, settings] = await Promise.all([userRequest, settingsRequest]);. Thus the total time approximates the slower operation instead of adding both waits.

A Promise delivers a single result and does not incorporate cancellation. It starts when the operation that created it has already been started. A Observable can output zero, one, or multiple values; It usually starts when you subscribe, allows unsubscribe, and composes time, cancellation, and concurrency using operators. For an isolated HTTP request a Promise can be achieved; for cancelable events, streams, or flows, a Observable better expresses the contract.

A Observable describes how to produce and deliver a sequence of notifications. subscribe starts or connects that production and returns a Subscription. The observer receives next(value) while there is data and can then receive complete() or error(reason) as an exclusive end. Example: interval(1000) emits values ​​until the consumer unsubscribes; http.get() usually issues a response and completes.

A cold Observable creates one execution per subscriber. Two subscriptions to http.get('/users') usually create two requests. A hot Observable shares an external source or execution between subscribers, such as clicks or a Subject. share and shareReplay can share a cold source, but require defining replay, refCount and reset to not retain data or connections longer than expected.

unsubscribe stops delivering values ​​and executes the teardown of the producer. It cancels the job only if that teardown knows how to stop it. HttpClient may abort the request; a Observable created with new Observable should return cleanup, for example return () => clearInterval(id). A Promise converted with from(promise) will still resolve because the original Promise does not know about the subscription.

from(promise) integrates a single result into a RxJS pipeline, but does not add cancellation to Promise. firstValueFrom(source$) resolves with the first issue and unsubscribes; lastValueFrom(source$) waits for the source to complete and uses the latest one. If the source is non-emitting or incomplete, the Promise may reject or be left pending, so the conversion needs a clear completion contract.

I create const controller = new AbortController(), pass controller.signal to fetch, and call controller.abort() when the response is no longer useful. The resulting rejection represents cancellation and not a functional error. I also clear the controller by destroying the component or by starting a request that replaces the previous one.

The timer callback runs in another task, after the try block has finished. try { setTimeout(() => { throw new Error('boom'); }); } catch {} does not capture it. The callback needs to handle its error or the API needs to wrap the result in a Promise that the caller can return and wait for.

I save the identity of the current request, cancel the previous one, or compare a version before writing status. In a search engine, the query ang may answer after angular; Without that protection, the UI displays results that no longer match the input. In RxJS, switchMap expresses the policy of keeping only the most recent operation.

The browser empties the microtask queue before advancing to the next task and rendering. A chain that schedules another microtask can delay input and painting. I split the work and defer to the scheduler when I need the browser to process another task.

Promise.all rejects upon receipt of the first observable rejection, but remaining operations continue unless its API supports cancellation. I use allSettled when I need the result of each operation and AbortController when I need to stop compatible I/O.

unknown forces you to validate or narrow the type before using it. any allows invalid operations and propagates holes throughout the application.

Both describe shapes of objects. interface supports declaration merging and contract-oriented extension; type also represents unions, intersections, tuples, and computed types. The consistency of the code and the capacity needed decide the choice.

satisfies checks that the value satisfies a contract and preserves its inference. as forces an interpretation of the type and may hide an incompatibility. I use assertions only when the runtime provides a guarantee that the compiler cannot prove.

The generic must preserve a relationship between values, for example between input and output or between a key and its property. If the type parameter appears only once, perhaps a union or a specific type better communicates the contract.

No. Types disappear upon compilation and an assertion only changes what the compiler believes. I validate the JSON with a schema or type guard at the border and only then convert it to the internal model.

Compatibility depends on the form of the value. If an object has the required properties with compatible types, it can satisfy the contract even if it comes from another declaration. This facilitates composition, but requires caution with excessive properties and overly broad types.

A conditional type chooses a result according to a T extends U relationship. infer declares a type variable within the pattern: type Result<T> = T extends Promise<infer R> ? R : T extracts the resolved value of a Promise.

When one contract derives from another mechanically. type Flags<T> = { [K in keyof T]: boolean } preserves the keys and changes their values. This avoids duplicating models that later diverge.

I would migrate by supported increments, with tests, bundle budgets and observability. I prioritize security, compatibility and deprecated APIs; then I adopt new syntax.

Eliminates the need for NgModules to declare components. Modules can still bundle legacy APIs or libraries. Standalone simplifies dependencies and lazy loading.

I look for mutations that depend on ZoneJS, libraries that update fields without notifying and direct uses of external APIs. I migrate the visible state to signals, AsyncPipe or explicit flags and compare tests and metrics before removing ZoneJS.

I differentiate expensive content that does not participate in the first visual objective. I choose trigger and prefetch based on the probability of use, reserve space to avoid CLS and measure LCP, transfer and interaction in a production build.

Angular creates the environment injector with the application providers, instantiates the root component, creates its host view and executes the first render. The compiled template creates nodes, evaluates bindings, and connects listeners before subsequent changes go into change detection.

Interpolation produces text. Property binding writes a runtime property of the element or component. Attribute binding writes the attribute, for example ARIA or SVG. I choose based on the actual destination of the value, not based on a syntax preference.

The compiled template contains instructions for each binding. During change detection Angular evaluates the expression, compares the result with the previous value and writes only the destination that changed. It does not rebuild the entire HTML component.

I update supported majors and stabilize tests. Then I reduce NgModules with standalone, migrate control flow and just introduce Signals or zoneless where the state model justifies it. Each stage preserves a way of measuring and reversing.

An input expresses dependency on the parent and keeps the component reusable. A service serves state shared by distant branches or a domain. Do not hide presentation data by globalizing everything.

ng-content works for fixed slots and declarative ergonomics. TemplateRef allows you to repeat, parameterize, or choose templates at runtime.

Only inputs, outputs and slots that represent real variations of the product. If an option exposes internal details or joins invalid states, I prefer to split responsibilities or model a more precise join.

I create a directive when I need to add behavior to an existing element without imposing markup. I create a component when the unit has visual structure, state, and an API that must evolve together.

A property binding writes to the runtime property of the element or component, for example [disabled]. An attribute binding writes the attribute HTML with [attr.aria-expanded]. I use attributes for ARIA, SVG or metadata without an equivalent DOM property.

It depends on the node: in a native element it references the HTMLElement, in a component its instance, with exportAs a directive and on ng-template a TemplateRef. Its scope belongs to the view that declares it.

Declare a view recipe. Angular only creates its nodes when a directive, NgTemplateOutlet or ViewContainerRef instantiates its TemplateRef. This allows you to repeat the fragment and pass context to it.

I use ViewContainerRef.createComponent if it must be part of that view and pass bindings with inputBinding, outputBinding or twoWayBinding. For a declarative case I can use NgComponentOutlet; for lazy loading visual I prefer to evaluate @defer.

The constructor belongs to TypeScript and DI. ngOnInit belongs to the Angular loop and receives ready inputs. Avoid I/O on both if a resolver, store or resource expresses the load better.

Use AsyncPipe, signals or takeUntilDestroyed; clean external APIs with DestroyRef.onDestroy. Then I verify repeated navigation with profiler and tests.

ngAfterViewInit confirms that Angular initialized the view, but a measurement may depend on a later render. afterNextRender executes work after the next render of the tree and allows separating write and read phases.

Place the cleanup next to the resource that needs it and avoid concentrating contextless teardown on ngOnDestroy. I use it with listeners, observers and takeUntilDestroyed to bind their life to the injection context.

Angular assigns inputs, executes ngOnChanges, ngOnInit, content hooks, view hooks and completes the render. The Checked hooks run again on subsequent traversals; Init run once.

No. Render callbacks are browser dependent. I use them to measure or integrate DOM after rendering and keep the SSR path free of that API.

ngOnChanges is useful when I need to compare input changes or execute an imperative adaptation. A computed best expresses a pure derivation of signal inputs because it maintains the relationship without manual synchronization.

Moves the mutation to another task and avoids the current check, but preserves a misplaced data stream. I correct who owns the state or move the job to the appropriate hook and phase.

No. OnPush changes when Angular checks the view. Immutability makes it easier to detect changes by reference and avoids corrupt shared state.

For logging, storage, canvas, browser APIs or external integration. UI derivations belong to computed.

Code that mutates fields without issuing a supported notification, as well as dependencies on NgZone events. I would migrate state to signals or flag the view.

A signal compares the new value with the old one using Object.is by default. Mutating a property preserves the reference and does not publish another value. I create a new reference or model field as a separate signal.

computed calculates derived state and only depends on other signals. effect synchronizes the reactive graph with an external boundary such as storage, logging, or canvas. I do not copy derived state through effects.

A new reference in an input, an event handled within the view, a signal read by the changing template, AsyncPipe, setInput or markForCheck. An internal mutation of an object without notification preserves the same reference and may leave the UI old.

markForCheck schedules the view for the next tour and maintains the normal flow. detectChanges runs an immediate check of that view and its children; I reserve it for controlled integrations because it can introduce unexpected work and order.

Models an editable state that depends on another signal and needs to be readjusted when that source changes, such as a selection that must remain valid when replacing the list. Avoid an effect dedicated to copying and correcting state.

I record an interaction with Angular DevTools and the Performance panel, identify which notification marked the branch, and review references, template functions, and effects. I change a cause and measure scripting and INP again.

It is a singleton within the injector that provides it. Two injectors can create two instances. The phrase 'singleton global' omits the scope.

Allows you to inject deleted configuration, functions or interfaces into runtime. The token preserves identity and can define factory and type.

useClass asks the injector to construct another instance of the indicated class. useExisting creates an alias to a registered instance. I use aliasing when two tokens must share identity and state.

The injector that registers the provider defines its scope and lifetime. A component provider isolates instances per subtree; one route can live with the lazy feature; root shares the instance in the application.

It starts at the injector of the current context, queries the node's providers and environment, and works its way up until it finds the token. Resolution modifiers change that path; if no provider exists and is not optional, Angular throws an error.

The component provider creates an instance associated with that subtree and is destroyed with it. The route provider shares state between lazy feature components and lives with its environment injector.

It allows multiple parties to register values under the same token and for the consumer to receive an array. I use it for plugins, validators or extensible pipelines where each feature provides an implementation.

Converts the service to an application singleton. If you save screen or user state without a reset policy, you can mix navigation cycles and sessions. The scope must match the useful life of the data.

It nests life cycles and errors, complicates cancellation and creates races. A flattening operator expresses the policy and returns a single subscription.

I debounce, remove duplicates and use switchMap. unsubscribe cancels the XHR/fetch request when the backend and client allow it.

Unsubscribe stops the observation and may abort the request if the source integrates cancellation, such as HttpClient. The server may have started the job. Effects operations require idempotence or their own cancellation protocol.

You can retain the last value and keep the subscription alive longer than expected. I define buffer, refCount and reset policy according to the life cycle. I also decide how to invalidate errors and stale data.

Inside if each request can fail and the source must continue listening for lookups. Out if any error terminates or replaces the entire flow. The position determines which subscription is closed.

Stops the resource created by that subscription: removes listeners, clears timers, closes sockets or aborts compatible I/O. It must also tolerate repeated calls without producing invalid effects.

When you keep the source subscribed after the last consumer leaves or keep a heavy value without a reset policy. I configure refCount and resets depending on whether I need a persistent cache or just sharing concurrent consumers.

I choose the concurrency policy: switchMap replaces, concatMap enqueues, mergeMap allows parallelism, and exhaustMap ignores new entries while one is still active. The semantics of the business decide which loss or order is valid.

When several flows share state, you need traceability, coordinated effects or complex rules. For an isolated form, a global store increases cost without benefit.

Recalculatable derivations, unnecessarily non-serializable objects, and ephemeral DOM state. I would save the minimal source of truth.

Server state is a copy of remote data and requires stale time, caching, and invalidation. Client state is born in the interaction, for example filters or steps of a wizard. Separating them prevents a store from treating both lifecycles with the same policy.

I consider it when multiple flows write the same domain, I need event traceability, coordinated effects or shared update rules. A local form or isolated display does not justify that cost alone.

When multiple features write to the same domain, I need clear event history, coordinated effects, inspection tools, or consistent update rules. At that point a formal store reduces implicit paths.

It is a value that can be calculated from the source state, like the total of a cart. I express it with computed or a selector and don't save it separately, because two copies can diverge.

I apply a local change with an operation ID, send the request, and commit or rollback depending on the result. I resolve concurrency, duplicates and error messages without losing a later edit.

Shared domain state whose life crosses paths and requires coordination. Focus, accordion, or temporary form states remain close to the component unless another part of the application needs to control them.

No. A user controls the client. The guard improves UX and prevents accidental navigation; the API authorizes each operation.

Resolve when the view does not make sense without the data or you need consistency before activating. Component loading for streaming, skeletons or partial content.

CanMatch decides if a route configuration can participate in matching and allows another route to be tested. CanActivate acts after choosing it and decides whether to activate it. None replace server authorization.

I avoid blocking navigation for secondary or slow data. The screen can show structure, loading and partial recovery. I use resolve when the data defines whether the route makes sense or when entering without it would produce an invalid state.

Angular recognizes the path, evaluates guards and, if allowed to continue, executes resolvers before activating the component. A redirect or cancellation cuts off navigation; Errors need a navigation policy or error handler.

No. Control customer navigation and improve the experience. The API must authenticate and authorize each operation because a user can call the endpoint without going through the Router.

When the route doesn't make sense without a small, critical piece of information or I need to decide before activating it. For secondary content I prefer to load inside the view and show partial states, because a long resolve delays all navigation.

I use RouterTestingHarness with real routes, navigate a URL and check component, redirects and visible status. Isolated tests cover the logic of guards or resolvers and integration tests cover the navigation order.

I define a typed schema, components by field type, derived visibility rules and registrable validators. I separate data, layout and behavior; I test the engine with contract cases.

Issue during writeValue, forget disabled state or do not check touched. That creates loops and breaks the semantics of the form.

You must write the external value without issuing a user change, register change and touched callbacks, and honor the disabled state. You also need a clear representation for null and partial values.

I model validation as a flow that cancels the previous query upon changing the value. I apply debounce when appropriate and distinguish transport error, invalid value and pending status on the interface.

In the FormGroup that owns both controls. The validator returns an error from the group and the presentation decides in which fields to announce it without mutating foreign errors.

The control updates value and validation when it loses focus. It reduces work and requests while typing, but changes when valueChanges emits and when the UI can display the result.

I declare the type of the repeated control, for example FormArray<FormGroup<AddressControls>>. The type describes controls, while getRawValue produces the value including disabled controls.

I mark controls as touched, locate the first invalid element following the visual order, focus it, and connect the message with aria-describedby. An error summary can link each field in long forms.

In an authentication layer coordinated by interceptor, with a single renewal in flight and controlled queue. I avoid loops and clean the session if the refresh fails.

The HttpClient generic expresses the expectation, it does not validate the server. At a critical boundary I validate and transform the DTO before exposing it.

Each interceptor envelops the next. The request proceeds in the recorded order and the response returns in reverse order. Authentication, retry, cache and logging can change their behavior depending on that composition.

I relate each writing to the affected keys. I can override, update optimistically, or replace with the server's response. The policy includes rollback and avoids deleting data from unrelated domains.

HttpRequest is immutable. clone creates a request with the changes and preserves the original object so that the interceptor chain can reason without shared mutations.

The request traverses the list in the order of registration. The response returns down the chain in reverse order, as nested layers. The order affects auth, cache, retry, loaders and telemetry.

Transports local configuration within the pipeline without sending it to the server. An interceptor can read an HttpContextToken to bypass auth, activate caching, or change error handling for a specific request.

I share a single refresh operation while it is active, queue or retry the original requests after the new token and clear the state when finished. If the refresh fails, I log out only once.

DOM models the document. BOM brings together objects and APIs from the browser environment, such as history, location, and navigator.

I choose localStorage for few non-responsive preferences, sessionStorage for tab life and IndexedDB for volume, queries and asynchronous work.

A browser policy that allows the server to declare which origins can read a response. It does not protect endpoints from non-browser clients nor does it replace authorization.

Layout recalculates geometry; paint generates pixels; compositing combines layers. Changes and interleaved reads can force synchronous work.

A write invalidates styles or layout and a subsequent geometric read, such as getBoundingClientRect, forces the browser to calculate the result at that time. I group reads and writes to avoid repeating that work within a loop.

No. CORS controls which responses JavaScript can read from another origin in a browser. A server script can call the endpoint. The API still needs authentication, authorization and validation.

I use their limits and dependency inversion where they protect business rules. I avoid copying backend layers if they only add files and mappings.

When there is a stable contract and more than one real consumer, or when the limit requires ownership and own tests. Pull ahead freezes immature APIs.

Circular imports appear, coordinated changes between supposedly independent folders and shared services that know all domains. I relocate the behavior according to ownership and expose a small API per border.

It receives components, models and services from different domains until it becomes a global dependency. I separate reusable primitives from business contracts and leave each model close to the feature that owns it.

I expose a small public API and domain contracts. The consuming feature does not import internal components, private stores, or deep file paths; communicates through published services, events or models.

When you concentrate several stores or services, you translate models and offer stable use cases to the UI. If you just forward each method with the same name and type, you add navigation without reducing coupling.

In Angular I provide the service on a shared injector. The guarantee is valid within that scope; local providers or multiple applications create other instances.

You can stabilize the feature's API and hide store details. You can also hide capabilities and duplicate names. I use it when protecting a real boundary.

The consumer depends on a contract expressed by an abstract class or InjectionToken. The configuration connects that contract to an implementation. I can change the border in tests or by environment without showing details to the consumer.

A facade that only renames each method adds navigation without reducing coupling. I use it when concentrating a use case, hiding coordination between dependencies, or protecting the UI from subsystem changes.

I define a contract for the operation, register implementations using DI and select the strategy by configuration or context. The consumer knows the capacity, while each algorithm maintains its own tests and dependencies.

The interface has a single implementation, it replicates all its methods and changes along with the detail. I wait for concrete cases of variation and extract the boundary that those cases share.

I define slow interaction, reproduce with real data and record performance. I identify network, scripting, layout or memory; I change a cause and measure again.

In *ngFor yes. Modern control flow uses track. Both preserve DOM identity; an unstable key voids the benefit.

I define an interaction and a metric, reproduce with a production build and capture a profile. Then I separate network, scripting, rendering and memory. I optimize the measured neck and compare again under the same conditions.

No. OnPush may reduce view checks, but a function that occupies the main thread still blocks input and render. I split the job, reduce its complexity or move it to a Worker if the message cost allows it.

I reproduce the interaction with Performance panel and RUM, locate long tasks and separate scripting, style, layout and paint. Then I reduce work from the critical path, split CPUs or limit renders and measure again on real devices.

Virtual scroll reduces DOM nodes, but does not reduce downloaded data, expensive filters, or entire model memory. With hundreds of thousands of rows I combine server-side pagination, remote queries and an accessible visible window.

Improves HTML delivery and SEO, but adds server and hydration. TTFB or interaction can worsen if the backend and the bundle do not match.

HTML different between server and client, non-deterministic dates or random, DOM manipulated before hydrating and invalid markup.

I use SSG for stable content, SSR for request-dependent HTML, and CSR for private areas where the shell contributes little to the server. I evaluate SEO, personalization, latency, cache and operational cost per route.

The client produces a different tree than the server's HTML due to non-deterministic data, browser access, or conditional markup. I share the initial state, isolate APIs from the browser and keep the structure stable until hydrated.

The server and the client's first render generate different structures. Dates, random, locale, early access to DOM or browser-only conditions are common causes. I transfer deterministic data and postpone browser effects until after hydrating.

Captures interactions that occur on HTML SSR before Angular connects listeners and plays them upon completion of the corresponding hydration. Prevents an early click from appearing lost.

Full hydration activates the full application. Incremental hydration preserves dehydrated @defer limits and activates them by triggers such as viewport or interaction, reducing initial JavaScript in exchange for more states and loading decisions.

The condition may cause server and client to create different nodes during hydration. I keep the same structure and run only the browser integration after the render, or exclude an isolated case from hydration as a last resort.

The most expensive risk: domain rule, permission, payment, migration or interaction that has already failed. Percentage coverage does not replace that prioritization.

I replace the service border, execute the interaction with the DOM and check the visible result and the relevant call. I don't test Angular.

One unit covers pure rules and states with few borders. An integration test checks template, DI, router or HTTP when their composition is part of the behavior. I choose the lowest level that can still detect the actual fault.

I control clock, scheduler and external responses. I wait for a observable condition instead of using arbitrary delays, close pending requests, and remove shared state between cases.

Vitest runs suites, assertions, spies and timers. TestBed creates the Angular environment of providers, components and change detection. A pure service may not need TestBed; a component with DI and template usually benefits.

When multiple tests or consumers need to operate a complex component without relying on its internal DOM. The harness offers stable actions and queries and reduces breakages due to markup changes.

I use fake timers or the virtual scheduler, I advance the clock explicitly and check broadcasts, cancellations and number of attempts. The test does not wait real time nor does it depend on the speed of the machine.

Method, URL, params, headers and body that are part of the contract; then respond with success or error and check the visible result. verify() ensures that there were no unresolved requests left.

Reduces XSS by escaping and sanitizing known contexts. DOM Direct APIs, bypasses, libraries and external HTML reopen the risk.

It depends on the threat model. HttpOnly cookies reduce reading by XSS and require CSRF controls. LocalStorage simplifies headers but exposes the token to compromised JavaScript.

The call does not sanitize the content. Declares that the application trusts that source and bypasses Angular protection for that sink. I restrict it to a revised boundary and prefer to transform data before producing HTML.

The user controls the client and can skip navigation or call the API directly. The guard improves the experience. The server verifies identity, permissions and ownership in each operation.

I sanitize it with an appropriate policy and library on the server or an audited border, keep CSP and avoid bypassSecurityTrustHtml. If the product supports a subset, I allow only explicit tags and attributes.

It depends on the threat model. An HttpOnly cookie reduces direct theft by XSS and requires CSRF protection; Memory prevents persistence but is lost on reload. I do not introduce localStorage as the default secure option for long-lived credentials.

Button provides keyboard, focus, role and activation without recreating behavior. A div requires implementing and maintaining all of that.

I combine lint and ax with real keyboard, screen reader in critical flows and review of focus, contrast and accessible names.

ARIA may contradict native semantics or announce a state that the behavior does not implement. I start with the correct HTML element and add name, status, or relationships only when information is missing.

I move focus to a useful point within the dialog, keep the navigation on its content, close with Escape when appropriate, and return focus to the trigger. The dialogue also needs a name and an inert background.

I open it only with the keyboard, I check accessible name, initial focus, Tab cycle, Escape and return of focus. Then I validate the inert background and listen to the flow with VoiceOver or NVDA.

To announce a relevant asynchronous change that does not receive focus, such as a saved result or a remote error. I avoid announcing every press or visual change because it interrupts and overwhelms the screen reader.

I maintain temporary API compatibility, handle chunk-load errors, use versioned assets, and avoid deleting previous files before their cache expires.

Errors, tests, bundles, Web Vitals, warnings, browser support changes and even dependencies. Later I removed obsolete compatibility.

I define owner, audience, fallback, metrics and retirement date. The backend maintains the authorization rules. Both paths remain tested as long as the flag exists and I remove the code when the rollout ends.

I generate them to relate minified errors to the TypeScript, but I restrict their access to the observability system. I associate each map with release and commit to symbolize the correct stack.

I keep artifacts immutable per release, maintain temporary API compatibility, and can point hosting back to the previous build. New databases and contracts need a forward-compatible strategy for the old bundle to continue working.

Initial bundle limits and critical chunks, typecheck, tests and main path metrics. A budget must fail close to the cause and have owner; an ignored figure in each pipeline does not protect performance.

I increase observable context, compare version, browser and data path, and create a testable hypothesis. I avoid speculative changes without a signal.

Normalized endpoint, status, duration, correlation ID and operation. I redact or delete body, tokens and personal data.

I propagate an allowed identifier in requests and register it along with route, release and action. Backend and gateway keep the same value to link the visible fault with logs and traces without saving personal data.

I repeat the traversal, force garbage collection in a diagnostic environment and compare heap snapshots. I look for retained components, detached DOM nodes, listeners, timers and caches that preserve references.

I relate the browser event to the backend's request, status, correlation ID and trace. If the API responded well, I check parsing and rendering; If it failed, the same identifier allows the operation to be followed by gateway and service.

Tokens, passwords, sensitive bodies, unnecessary personal data and complete HTML. I define an allowlist, anonymize identifiers, and apply sampling and retention based on the operational purpose.

I group widgets by frequency and ownership, use a connection service with multiplexing, normalize events, apply backpressure and render with signals. I pause invisible streams and measure INP.

I define design tokens, accessibility and small APIs; I publish harnesses, documentation and semver. I try keyboard, themes, SSR and breaking changes.

WebSocket is for bidirectional communication, SSE for a server-to-client stream over HTTP and polling for infrequent changes or simple infrastructure. I compare reconnection, proxies, order, volume and backend support.

Defines key, TTL, invalidation, deduplication and stale behavior. It also explains how to reconcile optimistic updates, conflicts, and pagination changes without mixing different user data or filters.

I define useful frequency per widget, group events, deduplicate by version and apply backpressure. I pause consumers out of the viewport and separate the receive rate from the render rate.

Data contracts, ownership, cache strategy, errors, security, accessibility, metrics and rollout. I also leave thresholds that indicate when the first solution needs another architecture.

I align constraints, compare options with criteria, spike if evidence is missing, and document the decision. Then I support the agreed option.

I described the form modularization case: you listened, reviewed standards, refactored for responsibility, asked for another review, and applied the learning.

Blocking due to correction, security, data loss, broken contract or a debt that prevents the change from operating. I mark preferences as suggestions and explain the risk so the author can apply the criteria.

Record context, restrictions, options considered, decision and consequences. I add owner and review date when conditions may change. The document allows the election to be discussed without depending on oral memory.

We agree on the objective and restrictions, we write alternatives with the same criteria and we execute a spike if the uncertainty requires it. The decision is recorded with consequences and review date.

I automate repeatable rules, document examples and distribute ownership. In reviews I explain the criteria and allow other people to make decisions with clear limits.

It is not the number of named APIs. It is being able to explain the mechanism, choose according to restrictions, compare alternatives and propose a way to validate the result. For example, it is not enough to say "I use switchMap": you must explain that it keeps only the most recent internal operation and why that policy matches the problem.

Say which part you know, reason from the Angular model and explain how you would verify the detail. Inventing a signature is more damaging than recognizing an edge.

Name two or three decisive conditions, set a reasonable scenario and choose. For example: “If the page needs SEO and quick initial content, I would choose SSR; “If it is an authenticated internal tool, I would start with CSR.” Then explain what information would change the decision.

Define the objective, compare alternatives with the same criteria and agree on a sign of success. "I prefer Signals" is an opinion; "I use Signals for synchronous local state because it simplifies derivations and I verify the impact with readability, tests and profiling" is a debatable and measurable decision.

I start with a one-sentence definition, explain the mechanism, and make a decision for a specific scenario. I close with the cost, the alternative and how I would check the result. If the question is broad, I point out that structure so that the interviewer can go deeper where they are interested.

I ask for the constraints that really change the answer: volume, change frequency, SEO, latency, consistency, security, and team capacity. If they are not available, I declare an assumption, choose under that scenario and say what information would make me change my option.

I am a Frontend Developer specialized in Angular, with experience since Angular 2 and distributed teams. I have designed dynamic scale forms and data products. I am looking for a role where I can combine architecture, delivery and mentoring.

Focus on growth, technical scope and type of product. Avoid badmouthing the current team or using a generic response.

I summarize the situation and task in a few sentences. I dedicate most of it to my decisions, alternatives and coordination. I close with a measurable result and the learning that changed my subsequent work.

I choose a real mistake, explain the decision that produced it, and take responsibility for my part. I describe how I limited the impact, what signal I added, and what code or process change prevented it from happening again.

I describe the restriction, each party's position, and how I brought the discussion into evidence. I explain the final decision, my contribution and what changed in the product or the way of working.

I use verifiable signals such as incidents, delivery time, defects or feedback, and clarify what was not measured. I close with the metric I would implement today instead of making up a number.