DEV Community: kirandeepjassal-crypto

JavaScript Interview Questions for Senior Developers in 2026 — Closures, the Event Loop, Prototypes & Async

kirandeepjassal-crypto — Fri, 23 Oct 2026 09:17:36 +0000

Junior JavaScript interviews ask "what does var do." Senior interviews ask why all your click handlers log the same number, why a Promise.then runs before a setTimeout(0), and why your single-page app's memory climbs until the tab crashes after an hour.

JavaScript looks forgiving and turns out to be full of sharp edges — closures, this, the event loop, and the ways a long-lived SPA leaks memory — exactly where senior work lives. Seniority is knowing what the engine actually does, not just what the syntax says.

This is 30 questions across scope & closures, this & prototypes, async & the event loop, and functional patterns, memory & modern JS. Each has a short answer, a deep dive with code, and the senior signal the interviewer is listening for. Examples are grounded in Mattrx — a real long-lived React SPA where memory, the event loop, and bundle size are daily concerns.

Block A — scope, closures & types

1. var vs let vs const — what's actually different?
var is function-scoped and hoisted (initialized undefined); let/const are block-scoped and live in the temporal dead zone until their declaration (accessing early throws). const binding can't be reassigned (the value can still mutate). Default to const, use let when you must reassign, never var.

2. What is a closure, and why is it useful?
A function that remembers the variables of the scope it was created in, even after that scope returned — a live reference, not a copy. It's how JS does private state, factories, memoization, and every hook/callback that captures a value.

function makeCounter() {
  let count = 0;                       // captured, kept alive by the closures below
  return { inc: () => ++count, get: () => count };
}
const c = makeCounter();
c.inc(); c.inc(); c.get(); // 2  — count survives after makeCounter() returned

3. Why do all my loop handlers log the same number?
With var, the loop variable is one function-scoped binding shared by every closure — by the time the handlers run, the loop has finished and they all read the final value. let creates a fresh binding per iteration.

// BUG: var is function-scoped -> every handler closes over the SAME i.
for (var i = 0; i < buttons.length; i++)
  buttons[i].onclick = () => console.log(i);   // always logs buttons.length

// FIX: let is block-scoped -> a new binding each iteration.
for (let i = 0; i < buttons.length; i++)
  buttons[i].onclick = () => console.log(i);   // logs 0, 1, 2, ...

4. How does hoisting work?
Declarations are processed before code runs. function declarations hoist fully (callable before their line). var hoists the binding but not the value (reads undefined early). let/const hoist into the TDZ. It's scope setup, not "code moves up."

5. == vs === — and when is == ever okay?
=== compares value and type, no coercion. == coerces first, with surprising rules. Default to ===. The one common == idiom: x == null to catch both null and undefined.

6. Primitives vs reference types — how are they passed?
Primitives are copied by value. Objects/arrays/functions are held by reference — passing one copies the reference, so mutations inside are visible outside. JS is always pass-by-value; the value of an object is its reference.

7. null vs undefined vs NaN?
undefined = exists but no value (uninitialized, missing arg). null = an intentional "no value" you assigned. NaN = result of an invalid numeric op, and NaN !== NaN (use Number.isNaN).

8. How do you reliably check a value's type?
typeof for primitives (but typeof null === 'object' is a historical bug), Array.isArray() for arrays, instanceof for class instances (fails across realms), and Object.prototype.toString.call(x) as the catch-all.

Block B — this, prototypes & objects

9. How is this determined?
By the call site, not where the function is defined. Four rules by priority: new, explicit call/apply/bind, implicit (obj.method()), and default (undefined in strict mode). Arrow functions ignore all of this and inherit this lexically.

const dashboard = { tenant: 'acme', load() { return this.tenant; } };
dashboard.load();          // 'acme'  (implicit: this = dashboard)
const fn = dashboard.load;
fn();                      // undefined — this lost (bare call = default binding)

10. Arrow functions vs regular functions?
Arrows have no own this (lexical), no arguments, can't be newed, no prototype. Use arrows for callbacks where you want the surrounding this; regular functions for methods and constructors.

11. What do call, apply, and bind do?
All set this explicitly. call(thisArg, a, b) invokes now with args listed; apply(thisArg, [a, b]) invokes now with args as an array; bind returns a new function with this (and leading args) permanently fixed — it doesn't call.

12. Explain prototypal inheritance and the prototype chain.
Every object has a hidden link ([[Prototype]]) to another object. Property lookup walks this chain until found or it hits null. Methods live on the prototype, shared across instances.

instance --[[Prototype]]--> Campaign.prototype --> Object.prototype --> null

13. Is class real inheritance or just sugar?
Syntactic sugar over prototypes. class gives cleaner syntax for constructors, methods (on the prototype), extends, and super — but it's still prototype links underneath. It adds a few real things: methods are non-enumerable, and the body runs in strict mode.

14. Shallow vs deep copy — how do you copy an object?
Spread ({...obj}) and Object.assign are shallow — nested objects are still shared. For a deep copy use structuredClone(obj) (handles cycles, Dates, Maps) — not JSON.parse(JSON.stringify(...)), which drops functions, undefined, and Dates.

15. What does Object.freeze do (and its limits)?
Object.freeze(obj) makes own top-level properties non-writable/non-configurable — shallow immutability. Nested objects stay mutable (deep-freeze recursively). It's runtime enforcement; TS readonly is compile-time only.

16. What are getters/setters and property descriptors?
get/set let a property run a function on read/write while looking like a field. Object.defineProperty controls a property's descriptor — writable, enumerable, configurable, or accessor functions.

Block C — async & the event loop

17. Explain the event loop.
JS runs on one thread. Sync code runs on the call stack. When the stack empties, the event loop drains the entire microtask queue (Promises), then runs one macrotask (setTimeout/I/O/UI), then drains microtasks again, and repeats.

run sync (call stack) -> drain ALL microtasks -> run ONE macrotask -> drain ALL microtasks -> ...

18. What prints first: setTimeout(0) or Promise.then?
Promise.then. A resolved promise's callback is a microtask; setTimeout(0) is a macrotask. All microtasks run before the next macrotask.

console.log('A');
setTimeout(() => console.log('B'), 0);            // macrotask
Promise.resolve().then(() => console.log('C'));   // microtask
console.log('D');
// Output: A  D  C  B

19. Promises — states and error propagation?
A promise is pending, then settles once to fulfilled or rejected (immutable after). A rejection skips .then handlers and jumps to the next .catch. Returning a promise from .then flattens. .finally runs either way.

20. What does async/await desugar to, and how do you handle errors?
async functions return a promise; await pauses until a promise settles, then resumes. Errors are handled with try/catch (a rejected awaited promise throws). An unawaited async call is a floating promise.

async function loadKpis(tenantId) {
  try {
    const res = await fetch('/api/kpis?t=' + tenantId);
    if (!res.ok) throw new Error(res.status);
    return await res.json();
  } catch (e) {
    logger.error('kpi load failed', e);
    return null;                                     // graceful fallback
  }
}

21. Promise.all vs allSettled vs race vs any?
all — resolves when all succeed, rejects on first failure (fail-fast). allSettled — waits for all, never rejects, returns each status. race — settles as the first settles (success or failure). any — resolves on first success, rejects only if all fail.

22. What are the most common async mistakes?
await in a loop when calls are independent (serial instead of parallel), forgetting to await/return (floating), unhandled rejections, mixing callbacks with promises.

// SLOW: N serial round trips.
for (const id of campaignIds) results.push(await fetchStats(id));
// FAST: fire all, await together.
const results = await Promise.all(campaignIds.map(id => fetchStats(id)));

23. How do you convert a callback API to a promise?
Wrap it in new Promise, calling resolve/reject inside the callback (or util.promisify in Node).

const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
await wait(300);

24. Implement debounce vs throttle — and when do you use each?
Debounce delays running until activity stops for N ms (search box). Throttle runs at most once per N ms during continuous activity (scroll/resize).

function debounce(fn, wait) {
  let t;
  return (...args) => { clearTimeout(t); t = setTimeout(() => fn(...args), wait); };
}
const onSearch = debounce(q => fetchResults(q), 300);

Block D — functional patterns, memory & modern JS

25. map / filter / reduce — and immutability in practice?
map transforms each element, filter selects a subset, reduce folds a list into a single value. They return new arrays (immutable-friendly) — exactly what React state needs.

const byCampaign = events.reduce((acc, e) => {
  (acc[e.campaignId] ??= []).push(e);
  return acc;
}, {});

26. What are currying and function composition?
Currying turns f(a, b, c) into f(a)(b)(c) — fixing args one at a time. Composition chains small functions so one's output feeds the next (compose(f, g)(x) = f(g(x))).

27. What causes memory leaks in a browser SPA, and how do you prevent them?
Four causes: event listeners never removed, timers/intervals never cleared, closures that pin large objects, and detached DOM nodes still referenced. Clean up in your component's unmount/effect teardown.

useEffect(() => {
  const onResize = () => layout(data);
  window.addEventListener('resize', onResize);
  const timer = setInterval(poll, 5000);
  return () => {                          // WITHOUT this cleanup, every mount leaks
    window.removeEventListener('resize', onResize);
    clearInterval(timer);
  };
}, [data]);

28. ESM vs CommonJS, and why does it matter for bundle size?
ESM (import/export) is static — the bundler can tree-shake unused code. CommonJS (require) is dynamic and resists tree-shaking. ESM also enables dynamic import() for code-splitting.

const Chart = React.lazy(() => import('./HeavyChart'));

29. What are generators and iterators?
An iterator is any object with a next() returning {value, done}; the iterable protocol (Symbol.iterator) is what for...of and spread consume. A generator (function* + yield) pauses and resumes, producing values lazily. async function* + for await...of streams async data.

30. What is event delegation and why use it?
Attach one listener to a common ancestor and use event.target to find which child fired — leveraging bubbling. Fewer listeners (less memory), and it handles elements added later automatically.

The through-line: JavaScript's ergonomics hide real machinery. Predict output from the event loop, reason about this from the call site, prevent leaks by cleaning up listeners/timers/references, and keep bundles lean with ESM + dynamic import. Answer each question with the engine behavior and the failure it prevents.

This post was originally published on PrepStack. The full original has all the code and senior-signal notes.

EF Core Interview Questions for Senior Developers in 2026 — Change Tracking, Performance, Concurrency & Migrations

kirandeepjassal-crypto — Wed, 21 Oct 2026 18:38:04 +0000

Junior EF Core interviews ask "what is a DbContext." Senior interviews ask why your dashboard fires 200 queries to render one page, what happens when two users save the same row at once, and why calling Migrate() on startup took production down during a rolling deploy.

EF Core makes the easy 80% trivial and hides the hard 20% — change tracking, query translation, concurrency, and schema evolution — right where production breaks. Seniority is knowing what SQL your LINQ actually becomes and what EF is doing on your behalf.

This is 30 questions across change tracking & the DbContext, querying & performance, concurrency & transactions, and migrations & production. Each has a short answer, a deep dive into the mechanism with code, and the senior signal the interviewer is listening for. Every example is from Mattrx — a real multi-tenant marketing-analytics platform on .NET 9 / EF Core 9 over Azure SQL, with Campaigns (~4M rows) and CampaignEvents (~1.2B rows), every query scoped by TenantId.

Block A — change tracking & the DbContext

1. What is change tracking, and how does SaveChanges know what to do?
The DbContext keeps a snapshot of every entity it loaded. On SaveChanges, it diffs current values against that snapshot, computes each entity's state (Added / Modified / Deleted / Unchanged), and emits the minimal INSERT/UPDATE/DELETE batch. Only changed columns go into the UPDATE.

2. What lifetime should DbContext have, and why not a singleton?
Scoped — one per request/unit of work. DbContext is not thread-safe and accumulates tracked entities, so a singleton corrupts state across concurrent requests and leaks memory as the tracker grows unbounded.

3. What does AsNoTracking do, and when do you use it?
It tells EF not to snapshot or track the results — no change-tracking overhead, less memory. Default for read-only queries.

var rows = await _db.Campaigns
    .AsNoTracking()
    .Where(c => c.TenantId == tenantId && c.Status == CampaignStatus.Active)
    .Select(c => new CampaignListItem(c.Id, c.Name, c.UpdatedAt))
    .ToListAsync(ct);

4. How does EF decide INSERT vs UPDATE?
By tracked state, not by whether the entity "looks new." A detached entity (deserialized from an API) has no state until you attach it — then EF guesses from the key, which is the source of countless bugs.

5. What is the identity map (first-level cache)?
Within one DbContext, EF returns the same instance for the same key. Per-context consistency, not a cross-request cache — and why long-lived contexts drift from the DB.

6. Tracking query returns stale data — why?
The identity map won't overwrite an already-tracked entity's values with fresh DB values by default. Use AsNoTracking, a new context, or Reload() for freshness.

7. What's the danger of Update() on a whole entity?
It marks every property Modified, so EF writes all columns — overwriting fields you didn't intend to change and defeating concurrency. Prefer loading + mutating specific properties, or ExecuteUpdate.

8. What is DbContext pooling and when does it help?
AddDbContextPool reuses context instances (resetting state) to cut allocation/GC overhead at high throughput. Catch: you can't inject per-request state into the constructor.

Block B — querying & performance

9. IQueryable vs IEnumerable — where does the query run?
IQueryable builds an expression tree EF translates to SQL and runs on the database. The moment you drop to IEnumerable, the rest executes in memory on the app server. Where on 1.2B rows in SQL vs in C# is the difference between 40ms and an outage.

10. What is the N+1 problem and how do you fix it?

// N+1: one query for campaigns, then one MORE per campaign for its count.
var campaigns = await _db.Campaigns.Where(c => c.TenantId == tenantId).ToListAsync(ct);
foreach (var c in campaigns)
    c.EventCount = await _db.Events.CountAsync(e => e.CampaignId == c.Id, ct);

// Fix: one server-side query that projects the aggregate.
var list = await _db.Campaigns
    .Where(c => c.TenantId == tenantId)
    .Select(c => new CampaignSummary(c.Id, c.Name, c.Events.Count()))
    .ToListAsync(ct);

11. Eager vs lazy vs explicit loading?
Eager (Include) up front when you know you need it. Explicit (.Entry(e).Collection(...).LoadAsync()) on demand, deliberately. Lazy (proxies) transparently on access — the #1 cause of accidental N+1; most teams disable it.

12. Two Includes made the query huge — why?
Cartesian explosion. Multiple collection navigations produce a JOIN whose row count is the product of the collections. Fix with AsSplitQuery().

var campaign = await _db.Campaigns
    .Include(c => c.Events)
    .Include(c => c.Segments)
    .AsSplitQuery()
    .FirstOrDefaultAsync(c => c.Id == id, ct);

13. Projection vs loading full entities?
Select into a DTO fetches only those columns and skips tracking. Loading full entities pulls every column (including blobs) whether you use them or not. For reads, project.

14. What are compiled queries?
EF.CompileAsyncQuery caches the LINQ→SQL translation so a hot query skips expression-tree compilation per call. EF already caches plans; reserve explicit compiled queries for genuinely hot paths you've measured.

15. What is client-side evaluation and why is it dangerous?
When part of your LINQ can't translate to SQL, older EF silently ran it in memory after fetching all rows. EF Core 3.0+ throws instead (except the final projection) — treat that exception as the framework protecting you.

16. When do you drop to raw SQL, and how safely?
FromSql/ExecuteSql when LINQ can't express it. Use parameterized interpolation so EF parameterizes it — never string-concatenate user input (SQL injection).

var rows = await _db.Database
    .SqlQuery<DailyKpi>($@"SELECT ... FROM CampaignEvents
                           WHERE TenantId = {tenantId} AND EventDate >= {from}")
    .ToListAsync(ct);

17. Streaming vs buffering results?
ToListAsync buffers the whole set into memory. AsAsyncEnumerable streams row by row — constant memory for large exports. Buffer small results; stream large ones.

Block C — concurrency & transactions

18. How does optimistic concurrency work in EF Core?
Add a concurrency token (a SQL rowversion). EF appends it to the UPDATE's WHERE; if someone changed the row since you read it, 0 rows match and EF throws DbUpdateConcurrencyException — a lost update becomes a detectable conflict.

public class Campaign
{
    public Guid Id { get; set; }
    public string Name { get; set; } = "";
    [Timestamp] public byte[] RowVersion { get; set; } = default!;
}
// UPDATE Campaigns SET Name=@n WHERE Id=@id AND RowVersion=@original

19. How do you handle DbUpdateConcurrencyException?

try { await _db.SaveChangesAsync(ct); }
catch (DbUpdateConcurrencyException ex)
{
    var entry = ex.Entries.Single();
    var dbValues = await entry.GetDatabaseValuesAsync(ct);
    if (dbValues is null) { /* row was deleted -> handle */ }
    else
    {
        entry.OriginalValues.SetValues(dbValues);   // rebase, then retry
        await _db.SaveChangesAsync(ct);
    }
}

Pick a policy per entity: client wins, store wins, or merge.

20. How do transactions work in EF Core?
A single SaveChanges is already atomic. For multiple saves or mixing EF with raw SQL as one unit, open an explicit BeginTransactionAsync.

await using var tx = await _db.Database.BeginTransactionAsync(ct);
_db.Orders.Add(order);
await _db.SaveChangesAsync(ct);
_db.Outbox.Add(evt);
await _db.SaveChangesAsync(ct);
await tx.CommitAsync(ct);   // both, or neither

21. Does EF Core support pessimistic locking?
Not natively — the model is optimistic. For SELECT ... WITH (UPDLOCK, ROWLOCK) you drop to raw SQL inside a transaction. Default to optimistic unless contention is high.

22. What is an execution strategy, and what's the transaction gotcha?
EnableRetryOnFailure wraps operations in a retrying strategy for transient faults. A retrying strategy can't implicitly retry a user-initiated transaction — wrap that block in strategy.ExecuteAsync(...).

var strategy = _db.Database.CreateExecutionStrategy();
await strategy.ExecuteAsync(async () =>
{
    await using var tx = await _db.Database.BeginTransactionAsync(ct);
    // ... multiple SaveChanges ...
    await tx.CommitAsync(ct);
});

23. How do you do a bulk update without loading every row?
EF7+ ExecuteUpdate/ExecuteDelete run a set-based UPDATE/DELETE in SQL — no loading, no tracking, one round trip. They bypass the change tracker and don't run SaveChanges interceptors.

await _db.Campaigns
    .Where(c => c.TenantId == tenantId && c.Status == CampaignStatus.Draft)
    .ExecuteUpdateAsync(s => s.SetProperty(c => c.Status, CampaignStatus.Archived), ct);

24. How do you handle transient failures against Azure SQL?
Enable EnableRetryOnFailure so EF retries transient errors with backoff. Pair with idempotent writes/optimistic concurrency so a retry after an ambiguous failure doesn't double-apply.

Block D — migrations, modeling & production

25. How do EF Core migrations work?
dotnet ef migrations add diffs your model against the committed model snapshot (a C# file) and generates an Up/Down migration. database update applies pending ones, recording each in __EFMigrationsHistory.

26. How should you apply migrations in production?
Not with db.Database.Migrate() on startup — multiple instances race, it needs schema-owner permissions at runtime, and nothing is reviewed. Generate an idempotent SQL script in CI and apply it as a gated deploy step.

dotnet ef migrations script --idempotent -o migrate.sql
-> review in PR -> apply as an explicit, gated deploy step

27. Fluent API vs data annotations?
Annotations ([Required], [MaxLength]) are simple and co-located. Fluent API (OnModelCreating) is more powerful (composite keys, relationships, filters, converters) and keeps mapping out of domain classes. Fluent wins where they conflict.

28. What are owned types and value converters?
Owned types map a value object (Money, Address) into the owner's table without its own identity. Value converters translate a property between CLR and DB types (enum as string, encrypted column).

29. What are global query filters and their pitfalls?
HasQueryFilter applies a predicate to every query for an entity — perfect for multi-tenancy and soft-delete. Pitfalls: the context must be scoped, it doesn't apply to raw SQL, and you need IgnoreQueryFilters() for admin/cross-tenant jobs.

modelBuilder.Entity<Campaign>().HasQueryFilter(c => c.TenantId == _tenant.Id);
var all = await _db.Campaigns.IgnoreQueryFilters().Where(...).ToListAsync(ct);

30. What EF Core performance mistakes do you check for in production?
Missing AsNoTracking on reads, N+1 from lazy loading, loading full entities instead of projecting, cartesian explosion from multiple Includes, no pagination, client-side evaluation, Update() writing all columns, and auto-migrate on startup. Verify with the generated SQL (ToQueryString() / logging), not by trusting that it compiled.

The through-line: EF Core is a leaky abstraction on purpose. Project reads into DTOs with AsNoTracking, kill N+1 with one query, split multi-collection includes, make concurrency a rowversion plus a resolution policy, wrap real units of work in explicit transactions with retries, and ship migrations as idempotent reviewed scripts. Answer each question with the generated SQL and the failure it prevents.

This post was originally published on PrepStack. The full original has all the code and senior-signal notes.

Microservices Interview Questions for Senior Developers in 2026 — Boundaries, Saga & Consistency, Resilience & Observability (Deep Answers)

kirandeepjassal-crypto — Mon, 19 Oct 2026 16:31:27 +0000

Junior microservices interviews ask "what is a microservice." Senior interviews ask why your services share a database (so they're really one service that can't deploy independently), what happens when the payment call times out halfway through an order, and how you debug a request that touched six services at 3am. Microservices trade in-process simplicity for distributed-systems hard problems — and seniority is knowing which problems you just bought and how to pay for them.

This is 30 questions across four blocks: boundaries & decomposition, data & consistency, resilience & communication, and observability & production. Every answer is a short answer you could say in one breath, a deep dive into the mechanism with code, and the senior signal the interviewer is listening for. Every example is from Mattrx — a multi-tenant marketing-analytics platform on .NET 9 whose services talk over Kafka, Azure Service Bus, and Event Grid.

The lens for all 30

A junior lists patterns; a senior reasons about what you traded for them. "Should we use microservices?" gets "yes, they scale!" from a junior and "only when a module needs independent scaling/deploy/ownership — otherwise a modular monolith, because you're buying network failure, eventual consistency, and distributed debugging" from a senior.

Block A highlight — the distributed monolith

The biggest failure mode is going distributed too early: services that must deploy together, call each other in long synchronous chains, and share a DB — all the ops pain of microservices with none of the independence. The litmus test is one question: "can I deploy this service alone?" If releasing these three services needs a specific order, they're one service wearing three uniforms. Draw boundaries by business capability / DDD bounded context, not by technical layer (a layer split makes every feature cross every service).

Block B highlight — the outbox pattern

The dual-write problem: you update your DB and publish an event as two operations — a crash in between loses one. The outbox writes the event into an outbox table in the same transaction as the state change; a relay publishes it afterward.

// BUG (dual write): a crash between these two loses the event.
await _db.SaveChangesAsync(ct);
await _bus.PublishAsync(new CampaignPublished(id), ct);   // if this fails, event is lost forever

// FIX (outbox): event + state commit atomically; a relay publishes from the outbox later.
using var tx = await _db.BeginTransactionAsync(ct);
_db.Campaigns.Update(campaign);
_db.Outbox.Add(new OutboxMessage(Guid.NewGuid(), "campaign.published", Serialize(evt)));
await _db.SaveChangesAsync(ct);
await tx.CommitAsync(ct);   // atomic: state change AND event persist together

And because delivery is at-least-once, every consumer must be idempotent — dedup by a stable event id:

public async Task Consume(ConsumeContext<ConversionTracked> ctx)
{
    if (!await _dedup.TryMarkProcessedAsync(ctx.Message.EventId, ctx.CancellationToken))
        return;                                    // already applied -> no-op
    await _kpis.ApplyAsync(ctx.Message, ctx.CancellationToken);
}

Exactly-once delivery is a myth; you get exactly-once effect = at-least-once delivery + idempotent consumers.

Block C highlight — resilience (breaker + retry + timeout)

One slow dependency makes its callers block, exhaust their pools, and fail — which fails their callers: a cascade. Each resilience pattern caps one link.

services.AddHttpClient<PaymentClient>()
    .AddResilienceHandler("payment", b => b
        .AddRetry(new() { MaxRetryAttempts = 3, BackoffType = DelayBackoffType.Exponential, UseJitter = true })
        .AddCircuitBreaker(new() { FailureRatio = 0.5, MinimumThroughput = 20, BreakDuration = TimeSpan.FromSeconds(30) })
        .AddTimeout(TimeSpan.FromSeconds(3)));

Retry only transient/idempotent calls, with jitter + a budget (fixed-interval retries synchronize into a retry storm that DDoSes the recovering service). Every call needs a timeout (a hung dependency ties up threads forever) and bulkheads isolate pools so one slow dependency can't sink the whole service. A dead-letter queue parks poison messages instead of blocking the queue.

Block D highlight — distributed tracing

A single request fans out across many services; without a trace id propagated through every hop, a failure is un-debuggable — six services' logs and no way to connect them.

// One trace spans every hop; OTel propagates it via the W3C traceparent header.
using var activity = ActivitySource.StartActivity("GenerateReport");
activity?.SetTag("tenant.id", tenantId);
// downstream HTTP + Service Bus calls carry traceparent -> one correlated trace across services.

Pair it with structured + centralized + trace-correlated logs and per-service RED metrics (Rate, Errors, Duration). And deploy schema changes with expand/contract: add the new field (old + new both work) → migrate/backfill → drop the old once nothing uses it — so producers and consumers deploy in any order.

The through-line

Microservices aren't "small services" — they're a bet that independent deployability is worth distributed-systems pain. Everything follows: own your data (database-per-service), talk async where you can, accept eventual consistency and reconcile with sagas + the outbox, make every consumer idempotent, wrap every call in timeouts/breakers/retries-with-jitter, and make the whole thing observable with distributed tracing.

The full guide has all 30 — each with the short answer, the deep dive with code, and the exact senior signal:

https://prepstack.co.in/blog/microservices-senior-interview-questions-boundaries-saga-resilience-deep-answers

Originally published on PrepStack.

SQL Server Interview Questions for Senior Developers in 2026 — Execution Plans, Indexing, Locking & Parameter Sniffing (Deep Answers)

kirandeepjassal-crypto — Sat, 17 Oct 2026 20:16:54 +0000

Junior SQL interviews ask "what is an index." Senior interviews ask why the index you added is being ignored, why a query that's fast for one tenant times out for another, and why the deadlock only happens in production at 9am. SQL Server rewards people who can read a plan, reason about statistics and locks, and know when the database — not the C# — is the bottleneck.

This is 30 questions across the four areas seniors actually get grilled on: indexing & tuning, execution plans & the optimizer, concurrency & locking, and performance & T-SQL. Every answer is a short answer you could say in one breath, a deep dive into the mechanism with T-SQL, and the senior signal the interviewer is listening for. Every example is from Mattrx — a multi-tenant marketing-analytics SaaS on Azure SQL with CampaignEvents at 1.2 billion rows, serving dashboards at ~3,200 req/sec.

The lens for all 30

A junior recites feature definitions; a senior reasons from the plan, the statistics, and the locks. "Why is it slow?" gets "it does a scan" from a junior and "the predicate isn't SARGable so it scans, and the estimate-vs-actual skew says the stats are stale — here's the covering index and the RCSI change" from a senior.

Block A highlight — why your index isn't used (SARGability)

Almost always because the predicate isn't SARGable — a function/calculation on the indexed column, an implicit type conversion, or a leading wildcard — so SQL Server can't seek and falls back to a scan.

-- NOT SARGable: function on the column -> scan.
WHERE CAST(OccurredAt AS date) = @day;
WHERE YEAR(OccurredAt) = 2026;
-- SARGable: range on the bare column -> seek.
WHERE OccurredAt >= @day AND OccurredAt < DATEADD(day, 1, @day);

And the companion fix — a covering index that kills the key lookup:

CREATE NONCLUSTERED INDEX IX_Kpis_Cover
  ON dbo.CampaignDailyKpis (TenantId, CampaignId, Day)   -- seek/range (equality before range, leftmost prefix)
  INCLUDE (Impressions, Clicks, Conversions);            -- covered -> no key lookup

Block B highlight — parameter sniffing

On first execution SQL Server "sniffs" the parameter values and compiles a plan for them, then reuses it. If tenants have wildly different data distributions, the cached plan can be terrible for the next caller — a plan compiled for a tiny tenant (nested loops) reused for the biggest tanks p99.

-- 1) OPTIMIZE FOR UNKNOWN: a stable, distribution-agnostic plan.
... WHERE TenantId = @t OPTION (OPTIMIZE FOR UNKNOWN);
-- 2) RECOMPILE: fresh plan every run for volatile ranges.
... OPTION (RECOMPILE);
-- 3) Query Store: force a known-good plan.
-- 4) Azure SQL compat 160: Parameter Sensitive Plan optimization (automatic).

Diagnose it by the estimate-vs-actual row skew in the actual plan — not the pretty picture. A big gap usually means stale statistics or a sniffing/SARGability problem.

Block C highlight — RCSI vs NOLOCK

With Read Committed Snapshot Isolation on, readers get a consistent row-version snapshot instead of taking shared locks — so readers don't block writers and writers don't block readers. The cost is extra tempdb for the version store.

ALTER DATABASE CURRENT SET READ_COMMITTED_SNAPSHOT ON;  -- readers use the version store, no S-locks

WITH (NOLOCK) is not a "make it faster" button — it's Read Uncommitted, reading dirty data and able to miss or double-count rows during page splits. Seniors reach for RCSI to get non-blocking reads without the dirty-read hazards.

And the lock-free queue pattern (SKIP LOCKED):

-- UPDLOCK reserves, READPAST skips rows other workers locked -> no double-dispatch, no blocking.
UPDATE TOP (100) dbo.OutboxMessages WITH (UPDLOCK, READPAST, ROWLOCK)
SET Status = 'Processing'
OUTPUT inserted.Id, inserted.Payload
WHERE Status = 'Pending';

Block D highlight — keyset pagination and safe big writes

OFFSET n still reads and discards the first n rows, so page 10,000 gets linearly slower. Keyset pagination seeks straight past the last row seen in constant time:

-- OFFSET: reads + throws away 200,000 rows. KEYSET: seeks directly.
SELECT TOP (20) ... WHERE EventId > @lastEventId ORDER BY EventId;

And a large DELETE/UPDATE is batched so it never escalates to a table lock or bloats the log:

WHILE 1 = 1
BEGIN
  DELETE TOP (5000) FROM dbo.CampaignEvents WHERE OccurredAt < @cutoff;
  IF @@ROWCOUNT < 5000 BREAK;
END

The through-line

Senior SQL Server is three instincts: make the query SARGable so the optimizer can seek; keep statistics fresh so it estimates right; and manage locks/isolation so reads and writes don't fight. Nearly every "slow query" and "random deadlock" traces back to one of those. Read the plan, compare estimated to actual, change one thing at a time.

The full guide has all 30 — covering indexes, key lookups, filtered indexes, cardinality estimation, Query Store, isolation levels, lock escalation, deadlock prevention, optimistic concurrency, columnstore, tempdb, and more — each with the short answer, the deep dive with T-SQL, and the exact senior signal:

https://prepstack.co.in/blog/sql-server-senior-interview-questions-execution-plans-indexing-locking-deep-answers

Originally published on PrepStack.

ASP.NET Core Interview Questions for Senior Developers in 2026 — Middleware Pipeline, DI Lifetimes, Kestrel & Auth (Deep Answers)

kirandeepjassal-crypto — Tue, 13 Oct 2026 05:48:51 +0000

Junior ASP.NET Core interviews ask "what is middleware." Senior interviews ask why your UseAuthorization ran before routing and silently allowed an anonymous request through, or why a singleton that took a DbContext corrupted data across tenants. The framework is easy to use and easy to misuse in ways that only show up in production — under load, across tenants, at 3am.

This is 30 questions across the four parts that actually separate seniors: the request pipeline, DI & lifetimes, hosting & performance, and auth & APIs. Every answer is a short answer you could say in one breath, a deep dive into the mechanism with code, and the senior signal the interviewer is listening for. Every sample is from Mattrx — a multi-tenant marketing-analytics SaaS on .NET 9 / ASP.NET Core, ~3,200 req/sec peak, Azure SQL + Redis, OAuth via Entra ID.

The lens for all 30

A junior describes a feature; a senior explains the ordering, lifetime, and failure mode. "What is middleware?" gets "a request delegate chain" from a junior and "an ordered, unwinding pipeline where auth must sit between routing and endpoints, and a mis-order silently lets requests through" from a senior.

Block A highlight — the pipeline, and the #1 ordering bug

Middleware is a chain of components, each of which can act on the request, call next(), and act on the response as the chain unwinds. Order is everything: a component only sees what the components before it let through.

Request
  → [ ExceptionHandler ] → [ HTTPS ] → [ Routing ] → [ AuthN ] → [ AuthZ ] → [ Endpoint ]
  ← ───────────────────── response unwinds back up ───────────────────────── ┘

The single most common pipeline bug: UseAuthentication/UseAuthorization must sit between UseRouting and the endpoints. Authorization needs to know which endpoint matched to read its [Authorize] metadata — which only exists after routing — and it must run before the endpoint executes.

app.UseRouting();          // endpoint selected + its [Authorize] metadata attached
app.UseAuthentication();   // populate ctx.User
app.UseAuthorization();    // enforce the selected endpoint's policy
app.MapControllers();      // BUG if this ran before UseAuthorization

Block B highlight — the captive dependency bug

A longer-lived service capturing a shorter-lived one — classically a singleton holding a scoped service. The scoped service now lives forever, leaking state across requests/tenants and breaking thread-safety.

// BUG: singleton CacheWarmer captures a scoped DbContext -> lives for the whole app.
builder.Services.AddSingleton<CacheWarmer>(); // ctor takes MattrxDbContext (scoped)

// FIX: create a scope per unit of work.
public sealed class CacheWarmer(IServiceScopeFactory scopes)
{
    public async Task WarmAsync(CancellationToken ct)
    {
        using var scope = scopes.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<MattrxDbContext>();
        // ...use db within this scope...
    }
}

And why DbContext is scoped: it's not thread-safe and tracks entity state per unit of work. A singleton DbContext across concurrent requests corrupts its change tracker ("A second operation was started on this context") and leaks data across tenants. The same scope-per-unit-of-work rule is how you use a DbContext inside a BackgroundService (which is itself a singleton).

Block C highlight — sync-over-async and thread-pool starvation

Blocking a thread-pool thread (.Result/.Wait()) on async I/O ties up threads that can't serve other requests; under load the pool can't grow fast enough and latency explodes.

// STARVATION: blocks a pool thread on I/O.
var kpis = _service.GetKpisAsync(t, c, r, ct).Result;
// CORRECT: keep the thread free.
var kpis = await _service.GetKpisAsync(t, c, r, ct);

Plus: Kestrel behind a reverse proxy + UseForwardedHeaders, config precedence with secrets in Key Vault, graceful BackgroundService shutdown honoring the stopping token, caching tiers (in-process vs distributed Redis vs output caching), liveness vs readiness health checks, and the built-in rate limiter partitioned per tenant.

Block D highlight — multi-tenant isolation and JWT validation

Derive the tenant from the authenticated token, never from a query string, route, or header the client controls — then scope every query by it (with row-level security as a backstop).

// SAFE: tenant from the verified token, not from input.
var tenantId = User.FindFirstValue("tenant_id")!;      // trusted
var data = await _db.Campaigns.Where(c => c.TenantId == tenantId).ToListAsync(ct);
// NEVER: var tenantId = Request.Query["tenantId"];    // client-controlled -> cross-tenant read

A JWT bearer token is validated every request, statelessly: signature (against the issuer's JWKS), issuer, audience, expiry. The audience check is what stops a token minted for another API being replayed against yours (the confused-deputy guard). Also covered: roles vs claims vs policies vs resource-based auth, the CORS AllowAnyOrigin+credentials mistake, when CSRF actually matters (cookie auth vs bearer tokens), and middleware vs MediatR pipeline behaviors for cross-cutting concerns.

The through-line

Senior ASP.NET Core is four instincts: the pipeline is ordered and it unwinds; lifetimes are about shared state and thread-safety; the tenant and the user come from the token, never the request; and cross-cutting concerns live at the right layer. Answer every question with the mechanism, the real failure it prevents, and the trade-off.

The full guide has all 30 — each with the short answer, the deep dive with code, and the exact senior signal:

https://prepstack.co.in/blog/aspnet-core-senior-interview-questions-middleware-di-kestrel-auth-deep-answers

Originally published on PrepStack.

C# Interview Questions for Senior Developers in 2026 — async/await, GC & Memory, the Type System, and LINQ (Deep Answers)

kirandeepjassal-crypto — Wed, 07 Oct 2026 09:16:11 +0000

Junior C# interviews test definitions — "what is a delegate," "value vs reference type." Senior interviews test judgment: not what async is, but why your .Result deadlocked in production; not what a struct is, but when copying one silently doubled your allocations.

This is 30 questions across the four areas seniors actually get grilled on — async & concurrency, memory & GC, the type system, and LINQ & production patterns. Every answer follows the same shape: a short answer you could give in one breath, a deep dive into the mechanism (with code), and the senior signal the interviewer is listening for. Every snippet is from Mattrx — a multi-tenant marketing-analytics SaaS on .NET 9 / ASP.NET Core / Azure SQL / Redis, with a 1.2B-row events table and a CQRS core.

The lens for all 30

A junior answers what; a senior answers why, when-not-to, and what it costs. "How does async work?" gets "it waits for the task" from a junior and "it suspends, frees the thread, and the continuation is scheduled — and here's how blocking on it deadlocks" from a senior.

Block A highlight — what actually happens when you `await`

await is not "wait here." It's "suspend here, free the thread, and schedule the rest as a continuation." That's why an ASP.NET Core server handles thousands of concurrent requests on a small thread pool — threads aren't parked waiting on I/O.

await _repository.AggregateAsync(...)
      │  suspend — thread returned to the pool (NOT blocked)
      ▼
   ...Azure SQL runs the aggregate...
      │  completes
      ▼
continuation resumes on a pooled thread

And the classic deadlock: in a context-capturing host (classic ASP.NET, WPF), blocking the one context thread with .Result while the continuation needs that same thread to resume is a self-deadlock. The fix is "async all the way," never block.

// DEADLOCK RISK: blocks the context thread
public CampaignKpis GetKpis(...) => _service.GetKpisAsync(...).Result;
// CORRECT — async all the way:
public Task<CampaignKpis> GetKpisAsync(..., CancellationToken ct) => _service.GetKpisAsync(..., ct);

Bounded concurrency is the other outage-preventer — never unbounded Task.WhenAll over 10,000 tasks:

await Parallel.ForEachAsync(tenants,
    new ParallelOptions { MaxDegreeOfParallelism = 8, CancellationToken = ct },
    async (tenant, token) => await GenerateNightlyReportAsync(tenant, token));

Block B highlight — GC, allocations, and the HttpClient trap

.NET's GC is generational: most objects die young and are collected cheaply in gen 0; survivors get promoted to gen 1, then gen 2 (whole-heap, expensive); objects >85KB go on the LOH. The win on Mattrx — 2.1GB → 380MB working set — was mostly about not promoting short-lived allocations to gen 2.

And the senior HttpClient gotcha — know both failure modes:

// BUG: socket exhaustion under load (TIME_WAIT)
using var http = new HttpClient();
// A single static HttpClient fixes that but never picks up DNS changes.
// CORRECT: IHttpClientFactory — pooled, DNS-aware handlers.
factory.CreateClient("stripe").PostAsync(...);

Boxing is the silent allocator — an enum boxed to object per event is millions of gen-0 objects/sec at ingestion rate. Span<T>/Memory<T> give zero-allocation slicing (but Span<T> can't cross an await — it's a ref struct).

Block C highlight — deferred execution

A LINQ query over IEnumerable<T> doesn't run until you enumerate it; enumerating it twice runs it twice:

// BUG: query executed TWICE — Count() enumerates, then the foreach enumerates again.
IEnumerable<CampaignEvent> q = repo.Query(tenant);
if (q.Count() > 0) foreach (var e in q) Handle(e);   // two DB round-trips
// FIX: materialize once.
var events = repo.Query(tenant).ToList();

Block D highlight — the EF Core IQueryable trap

IQueryable<T> builds an expression tree EF translates to SQL (filtering runs in the database); IEnumerable<T> runs LINQ in memory. Accidentally crossing the boundary is the difference between a WHERE clause and loading 1.2B rows:

// GOOD: filter runs in Azure SQL
var q = _db.CampaignEvents.Where(e => e.TenantId == tenant && e.OccurredAt >= from);
// TRAP: ToList() first => the Where now runs in memory over the ENTIRE table.
var bad = _db.CampaignEvents.ToList().Where(e => e.TenantId == tenant);

Plus the captive-dependency bug (a singleton capturing a scoped DbContext), ConcurrentDictionary.GetOrAdd running its factory twice under load (fix: Lazy<T>), and why returning IEnumerable<T> from a repository hands the caller control of when and how many times your query executes — after the DbContext is disposed, or twice.

The through-line

Senior C# is a handful of production truths: async suspends, it doesn't block; allocations become GC pressure; the type system is a compile-time aid, not a runtime guarantee; and the boundary between in-memory and in-database (or one thread and many) is where systems break. Answer every question by naming the mechanism, the real failure it prevents, and the trade-off.

The full guide has all 30 — each with the short answer, the deep dive with code, and the exact senior signal:

https://prepstack.co.in/blog/csharp-senior-interview-questions-async-memory-linq-concurrency-deep-answers

Originally published on PrepStack.

Angular Interview Questions for Senior Developers in 2026 — Change Detection, RxJS, Signals & Performance (Deep Answers)

kirandeepjassal-crypto — Mon, 05 Oct 2026 11:31:25 +0000

Junior Angular interviews ask "what is a component." Senior interviews ask why your dashboard re-runs change detection thousands of times a second, why a typeahead fires a request per keystroke and shows stale results, and why that subscription leaks memory until the tab crawls. Angular is a big, opinionated framework, and seniority is knowing the machinery underneath — change detection, RxJS, the new signals model, and where performance goes to die.

This is 30 questions across four blocks. Each answer is a short answer you could say in one breath, a deep dive into the mechanism (with code), and the senior signal the interviewer is listening for. Examples use modern Angular (v17+: standalone, signals, the new control flow) and are grounded in Mattrx — a real multi-tenant marketing-analytics platform whose internal admin console is built in Angular.

The lens for all 30

A junior uses the APIs; a senior understands change detection, the reactivity model, and RxJS semantics — and designs to work with them. "Why is the app janky?" gets a shrug from a junior and "default CD is re-checking a 2,000-node tree on every mousemove — OnPush + signals cut it to the subtree that changed" from a senior.

Block B highlight — how change detection actually works

Angular runs CD to sync model → DOM. Zone.js monkey-patches async APIs (events, timers, XHR) so after any async task, Angular walks the component tree top-down and dirty-checks each binding.

async event (click / http / timer)
  -> zone.js notifies Angular
  -> CD walks the component tree top-down, checks each binding
  -> updates the DOM where a bound value changed

Default vs OnPush: Default checks every component every run. OnPush skips a component unless an @Input reference changed, an event fired inside it, or an async-bound observable emitted. On big trees OnPush is the single biggest perf lever.

@Component({
  selector: 'campaign-list',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: \`@for (c of campaigns(); track c.id) { <campaign-row [campaign]="c" /> }\`,
})
export class CampaignListComponent {
  campaigns = input.required<Campaign[]>();   // new reference -> this subtree is checked
}

Senior signal: you default to OnPush, know it relies on immutable inputs, and can name the three triggers that still run it.

Block C highlight — the RxJS flattening operators

The high-stakes RxJS question. They all map to an inner observable and flatten, differing in how they handle overlap:

switchMap:  new value -> CANCEL previous, start new     (search/typeahead)
concatMap:  queue -> run one after another, in order    (ordered writes)
mergeMap:   run all concurrently                        (independent parallel)
exhaustMap: ignore new while one runs                   (dedupe rapid submits)

// Typeahead: switchMap cancels the in-flight request when a new term arrives -> no stale results.
this.search.valueChanges.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap(term => this.api.search(term)),
).subscribe(r => this.results.set(r));

Pick switchMap for search, exhaustMap for submit, concatMap for ordered writes, mergeMap for independent parallel work. Most "senior" candidates get tripped here.

Block C highlight — signals vs RxJS

Signals are Angular's synchronous reactive primitive — a value you read as a function, with computed() for derived values and effect() for side effects. They power fine-grained, zoneless CD. RxJS stays for async streams/events; signals are for synchronous state. Bridge with toSignal / toObservable.

count = signal(0);
double = computed(() => this.count() * 2);          // recomputes only when count changes
constructor() { effect(() => console.log(this.count())); }
this.count.update(n => n + 1);                       // triggers dependents precisely

And preventing leaks — prefer the async pipe or takeUntilDestroyed() over manual ngOnDestroy bookkeeping:

this.api.pollKpis().pipe(takeUntilDestroyed()).subscribe(k => this.kpis.set(k));

The through-line

Angular is fast and maintainable when you cooperate with change detection (OnPush, immutability, signals), pick the right RxJS operator by its overlap semantics, and tear down subscriptions (async pipe / takeUntilDestroyed). Fight it and you get jank and leaks. Answer each question with the mechanism and the failure it prevents, and you sound like someone who has shipped and profiled a real Angular app.

The full guide has all 30 — components & DI, change detection & performance, RxJS & state, and routing/forms/testing/production — each with the short answer, the deep dive with code, and the exact senior signal:

https://prepstack.co.in/blog/angular-senior-interview-questions-change-detection-rxjs-signals-performance-deep-answers

Originally published on PrepStack.

Angular Performance Optimization in 2026 — OnPush, trackBy, Lazy Loading, Signals, Standalone (Real Code, Production Metrics)

kirandeepjassal-crypto — Wed, 30 Sep 2026 17:34:20 +0000

Angular apps don't go slow because Angular is slow. They go slow because the defaults — Default change detection, NgModules with eager imports, no trackBy, BehaviorSubject everywhere, no lazy loading — were designed for a world where bundle size and per-keystroke render cost weren't the user-facing scoreboard. In 2026 they are: Core Web Vitals (LCP, INP) are part of the Google ranking signal and the conversion funnel.

This is the production playbook for Angular 19+. Five techniques compose into the biggest wins, each with before/after code and real metrics from Mattrx — a multi-tenant marketing-analytics SaaS (Angular 16 → 19, 540+ components, 22k LOC, 110k MAU).

TL;DR — the five, ranked by impact

#	Technique	Before	After	Win
1	Lazy loading (routes + `@defer`)	Initial JS 1.2 MB	290 KB	LCP −67%
2	OnPush change detection	60 CD cycles/sec	3/sec on dashboard	INP −78%
3	Signals (replace BehaviorSubject)	manual `markForCheck`	auto-react on read	fewer bugs
4	Standalone components	NgModule barrels	direct imports, tree-shake	bundle −18%
5	`trackBy` / `track`	4,000 nodes recreated	only changed rows	filter 280ms → 35ms

Aggregate (Angular 16 → 19 + the 5 techniques, 4 weeks, no new features): LCP 4.6s → 1.5s, INP 420ms → 80ms, initial JS 1.2 MB → 290 KB, CrUX "Good" CWV 38% → 91%, trial signup conversion +12%.

The model you need: change detection

Every time Zone.js patches an async API (click, XHR, setTimeout), Angular schedules a CD pass and walks the tree top-down. Default CD re-checks every binding on every component on every pass — even if nothing changed. A setInterval(fn, 100) triggers a full-app CD pass every 100ms. OnPush prunes the tree: a component is checked only when an @Input reference changes, an event fires in it, an async pipe emits, a signal it reads changes, or markForCheck() is called.

1. Lazy loading — the biggest LCP win

export const routes: Routes = [
  { path: '', loadComponent: () => import('./pages/login.component').then(m => m.LoginComponent) },
  { path: 'dashboard', loadComponent: () => import('./pages/dashboard.component').then(m => m.DashboardComponent), canMatch: [authGuard] },
  { path: 'reports', loadChildren: () => import('./pages/reports/reports.routes').then(m => m.REPORTS_ROUTES), canMatch: [authGuard] },
];

Add background prefetch so subsequent navigation is instant too:

provideRouter(routes, withPreloading(PreloadAllModules))

Then @defer for anything heavy that isn't above-the-fold:

@defer (on viewport) {
  <mx-revenue-chart [data]="revenue()" />
} @placeholder {
  <div class="chart-skeleton h-64"></div>
} @loading (minimum 200ms) {
  <mx-spinner />
} @error {
  <mx-chart-load-error />
}

@defer downloads the component and its transitive imports as a separate chunk automatically — no webpack config. Triggers: on idle, on viewport, on interaction, on hover, on timer(2s), when condition. Result: initial bundle 1.2 MB → 290 KB, LCP 4.6s → 1.5s.

2. OnPush — the biggest CPU win

@Component({
  selector: 'mx-kpi-card',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: \`...\`,
})
export class KpiCardComponent {
  @Input() label!: string;
  @Input() value!: number;
}

The Mattrx dashboard did ~13,000 binding evaluations/sec at idle. Blanket OnPush on leaf components: 540/sec. The contract: never mutate input objects in place — create new references (this.user = {...this.user, name}), or use Signals to enforce it structurally. Convert leaf components first (cards, rows, badges) — highest fan-out.

3. Signals — replace BehaviorSubject for state

@Injectable({ providedIn: 'root' })
export class KpiService {
  readonly kpis = signal<Kpis | null>(null);
  readonly revenuePerCampaign = computed(() => {
    const k = this.kpis();
    return k && k.campaigns > 0 ? k.revenue / k.campaigns : 0;
  });
  load(id: string) { this.http.get<Kpis>(\`/api/kpis?u=\${id}\`).subscribe(v => this.kpis.set(v)); }
}

Reading kpis() in a template auto-subscribes the component; kpis.set(...) marks only readers for check. No async pipe, no markForCheck, no takeUntilDestroyed. Use Signals for component/service state; keep RxJS for genuine async pipelines (HTTP, WebSocket, debounced search) and bridge with toSignal / toObservable. /inbox: re-renders per WebSocket message 23 → 2, 62 takeUntilDestroyed removed. Once everything reads signals, you're on the path to zoneless (−28 KB bundle).

4. Standalone components — tree-shaking + lazy loading

Standalone (default in Angular 19) drops the NgModule ceremony and lets the bundler see the exact import graph — no barrel of unrelated junk. Run the schematic in chunks:

ng generate @angular/core:standalone

For Mattrx: 540 components in ~3 days, ~8% needed manual tweaks (mostly forwardRef cycles). Bundle −18% on top of lazy; compile time 42s → 28s.

5. trackBy / @for track — the afternoon fix

@for (campaign of filteredCampaigns(); track campaign.id) {
  <tr><td>{{ campaign.name }}</td><td>{{ campaign.spend | currency }}</td></tr>
} @empty {
  <tr><td colspan="2">No campaigns match.</td></tr>
}

Without a stable track, filtering a 4,000-row table (new array of references) destroys and recreates all 4,000 DOM nodes — and silently unchecks checkboxes. With track campaign.id: only changed rows. Use a stable id, never $index for dynamic lists. Filter latency 280ms → 35ms.

Bonus: block control flow

@if / @for / @switch (Angular 17+) compile smaller and faster than *ngIf / *ngFor, support @else if and @empty. Use for all new code.

The right mental model

Do less work, and do it later. Lazy loading = do it later. OnPush = do less. track = don't recreate what didn't change. Signals = do less, more precisely. Standalone = ship only what you use.

Three habits: OnPush + standalone on every new component by default; lazy-load before you optimize; profile before you tune (Chrome Performance, ng build --stats-json, Lighthouse).

The full guide has every before/after, the Default-vs-OnPush tree-walk diagrams, the bundle-split diagram, the full @defer trigger list, the Signals interop table, and the step-by-step diagnostic checklist for inheriting a slow app:

https://prepstack.co.in/blog/angular-performance-optimization-guide-onpush-trackby-lazy-loading-signals-standalone-components

Originally published on PrepStack.

Angular Micro Frontends in 2026 — Webpack Module Federation vs Native Federation, Independent Deployments (Real Project, Production Metrics)

kirandeepjassal-crypto — Mon, 28 Sep 2026 18:06:26 +0000

Micro frontends sound like an architecture pattern. They're actually a deployment pattern that happens to have UI consequences. The question they answer isn't "how do we structure code?" — it's "can team A ship without waiting for team B, even though both teams' code runs in the same browser tab?"

The wrong reason to adopt them: "our app is big." (Big apps want an Nx monorepo with feature libraries.) The right reason: independent deployments, different release cadences, separate teams that don't want to coordinate every push to production.

This is the production playbook, built on the same real app throughout: Mattrx, a multi-tenant marketing-analytics SaaS on Angular 19, where the partner-widgets team carved out into a separate remote in early 2026. Real numbers from that split are throughout.

The one idea

Independent deployment is the whole point. The shell's HTML never re-bundles the remote — it fetches it fresh at runtime (or from cache), evaluates it in place, and reuses the singleton shared deps. Update the remote on its CDN → the next navigation picks it up. The shell does not redeploy when the remote ships.

Three concepts:

Host (shell) — loads first. Owns routing, auth, layout, in-host features. Knows the URLs of its remotes, not their code.
Remote — a separately-built, separately-deployed Angular sub-app that exposes lazy-loadable components/routes via a manifest.
Contract — the named exports each remote exposes. The host imports them by name; the remote promises to keep them stable.

Two paths: Webpack MF vs Native Federation

	Webpack MF	Native Federation
Basis	Webpack 5 ModuleFederationPlugin	Import Maps + ESM
Build	webpack (slower)	esbuild (faster)
Config	custom webpack	default Angular builder
New Angular 19 project	only with webpack expertise	Recommended
Already on webpack	stay	migrate later if convenient

For Mattrx we chose Native Federation for the two new remotes. Honest reason: it didn't require swapping our build system back to webpack.

Native Federation — the modern setup

npm i -D @angular-architects/native-federation
ng add @angular-architects/native-federation --project shell --type host --port 4200
ng add @angular-architects/native-federation --project partner-widgets --type remote --port 4201

The shell points at remotes via a small JSON manifest (.json, not .js):

// apps/shell/src/assets/manifest.json
{
  "partner-widgets": "https://partners.mattrx.io/remoteEntry.json",
  "labs":            "https://labs.mattrx.io/remoteEntry.json"
}

A lazy route pulls the remote:

import { loadRemoteModule } from '@angular-architects/native-federation';

export const APP_ROUTES: Routes = [
  { path: 'dashboard', loadChildren: () => import('@mattrx/features/dashboard').then(m => m.DASHBOARD_ROUTES) },
  { path: 'partners',  loadChildren: () => loadRemoteModule('partner-widgets', './Module').then(m => m.PARTNER_ROUTES) },
];

The remote declares what it exposes:

// apps/partner-widgets/federation.config.js
module.exports = withNativeFederation({
  name: 'partner-widgets',
  exposes: {
    './Module':                 './apps/partner-widgets/src/app/partner.routes.ts',
    './PartnerCampaignsWidget': './apps/partner-widgets/src/app/widgets/partner-campaigns.component.ts',
  },
  shared: { ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }) },
});

The day-2 reality (where the real engineering lives)

Immutable chunks, mutable manifest. remoteEntry.json changes every deploy → Cache-Control: no-cache. The content-hashed chunks it references → cache forever. Get this wrong and a user loads yesterday's manifest pointing at today's missing chunks.

Atomic deploys. Upload chunks first, verify they return 200 from the CDN, then flip the manifest pointer. If the manifest goes live before the chunks exist, anyone loading in that window crashes. We learned this the hard way — two broken minutes in production.

Shared dependency version drift — the #1 source of pain. If the shell is on @angular/core@19.1.3 and the remote was built against 19.0.7:

singleton: true, strictVersion: true — boot-time error. Loud, deterministic, right. Use this for Angular packages.
strictVersion: false — uses whichever loaded first. Silent breakage if APIs drift. OK only for a backwards-compatible design system.
singleton: false — two Angulars. Don't.

When the shell bumps an Angular minor, every remote bumps the same week — a "version-bump-only" PR per remote.

The exposes contract is a SemVer surface. The host imports './PartnerCampaignsWidget' by name — that string is a public contract. Add freely, coordinate on signature changes, deprecate-for-one-release before removing. Keep a literal EXPOSES.md per remote. Contract-test it in CI against the remote's staging URL, on every shell PR and every remote PR.

Rollback is flipping the manifest back:

aws s3 cp s3://mattrx-partners/remoteEntry.PREVIOUS.json s3://mattrx-partners/remoteEntry.json
aws cloudfront create-invalidation --distribution-id ABC --paths "/remoteEntry.json"
# Live within ~30s. No build, no redeploy.

The production numbers (after carving out 2 remotes)

Metric	Before	After
Partner team deploys/week	1	15–40 (3–8/day)
Time to ship a partner hotfix	25 min	4 min
Cross-team coordination tickets/sprint	9	1
Prod incidents from cross-team merges/mo	12	3
Shell bundle (gzipped)	290 KB	290 KB (unchanged)
Cold-start LCP (first remote hit)	1.5s	1.7s (+200ms — honest cost)
Warm-start LCP (cached remote)	1.5s	1.4s
Rollback on a remote regression	25 min	45 seconds

The LCP cost is real and we own it. Idle-prefetch the manifest after the shell loads and cold-start drops back to ~+40ms:

provideAppInitializer(async () => {
  await new Promise<void>(r => requestIdleCallback(() => r()));
  await prefetchRemote('partner-widgets');
}),

When NOT to use micro frontends

The most-skipped section of every MFE article. Most teams shouldn't. Don't reach for MFEs if you're under ~25 frontend engineers in 1–2 teams, if you want smaller bundles (that's lazy loading), if you want faster CI (nx affected is cheaper), or if your teams ship together anyway.

Do consider them if a team ships to a different surface (partner CDN, extension), needs a conflicting deploy cadence, embeds the same code in third-party hosts, or is an acquired team merging in without a rewrite. For Mattrx, exactly one of those was true — so we carved out one remote, not ten.

The right mental model

Micro frontends are an operational tool dressed in architecture clothes. The architecture exists so that the deployment property (independent ship) becomes possible. Without the deployment property, the architecture is overhead with no upside.

Three habits: adopt one remote at a time for one reason at a time; treat the exposes contract as a SemVer surface (document + test in CI); coordinate the boring stuff (Angular minor bumps, design-system versions, CDN caching).

The full guide has the complete Webpack MF setup too, the request-flow and deploy-flow diagrams, the embeddable-widget use case, the 8-week adoption path, and the honest "what we'd do again / what we'd skip":

https://prepstack.co.in/blog/angular-micro-frontends-module-federation-webpack-native-federation-independent-deployments-guide

Originally published on PrepStack.

Angular Signals vs RxJS in 2026 — When to Use Each, Performance Benchmarks, and the Interop Pattern (Real Code)

kirandeepjassal-crypto — Sat, 26 Sep 2026 17:51:32 +0000

"Should I use Signals or RxJS for this?" is the most-asked question in modern Angular code review. The bad answer — "use Signals everywhere, RxJS is legacy" — produces fragile WebSocket handling and re-invented switchMap. The other bad answer — "stick with RxJS, Signals are toys" — produces 30 lines of BehaviorSubject + takeUntilDestroyed to track which tab is active.

The right answer is mechanical, not philosophical: Signals are pull-based, synchronous, fine-grained reactive values; RxJS is push-based, asynchronous, time-aware event composition. Each is excellent at exactly one half of the problem. Real code, benchmarks, and production numbers from migrating Mattrx — a multi-tenant marketing-analytics SaaS (540 components, 22k LOC, 110k MAU).

The mental model (the one chart you need)

                        SIGNALS                  RxJS
Direction              PULL (read latest)       PUSH (subscribe, get next)
Time                   SYNCHRONOUS              ASYNCHRONOUS
Granularity            Per-value, fine-grained  Per-stream, coarse-grained
Cancellation           N/A (no async)           takeUntil / abort
Memoization            Built-in (computed)      Manual (shareReplay)
OnPush integration     Auto-marks for check     Needs async pipe / markForCheck
Conceptual fit         "the current value of X" "the stream of X events over time"

Ask one question:

"I need to know the latest X" -> Signal
"I need to react to every event of X over time" -> RxJS

That resolves 90% of the real ambiguity.

When Signals win (state)

Local UI state, derived values, service-level shared state, side effects — all Signal territory. The service-level case is where the code shrinks most:

// BEFORE - BehaviorSubject ceremony (29 lines)
private dateRange$ = new BehaviorSubject<DateRange>(...);
private status$    = new BehaviorSubject<Status[]>(['active']);
// ...asObservable(), setters, combineLatest, shareReplay...

// AFTER - Signals (9 lines)
readonly dateRange = signal<DateRange>({ from: lastWeek(), to: today() });
readonly status    = signal<Status[]>(['active']);
readonly filters   = computed(() => ({ dateRange: this.dateRange(), status: this.status() }));

computed() is the multicast — lazy, memoized, O(1) cached reads. No shareReplay, no combineLatest, no next(). Mattrx had 240 BehaviorSubjects; the cleanup deleted ~1,400 lines of state code.

When RxJS wins (events over time) — and Signals genuinely can't

Debounced search with race cancellation is the canonical example:

results$ = this.query.valueChanges.pipe(
  debounceTime(250),
  distinctUntilChanged(),
  switchMap(q => this.http.get(`/api/search?q=${q}`).pipe(catchError(() => of([])))),
  shareReplay(1),
  takeUntilDestroyed(),
);

To replicate this in pure Signals you'd hand-roll a setTimeout debounce, an AbortController you abort per keystroke, try/catch, and a loading flag — ~40 lines re-inventing switchMap. Same story for WebSocket streams (webSocket() + retry({delay}) + share()), drag-to-resize (mousedown -> switchMap(mousemove) -> takeUntil(mouseup)), and multi-source merge (combineLatest + throttleTime). Anything with debounce / throttle / retry / timeout / switchMap / scan in its description belongs in RxJS. Signals do not model time.

Performance (numbers, not vibes)

Operation	Time
`signal()` read	~12 ns
`signal.set(v)` write (no listeners)	~50 ns
`BehaviorSubject.next(v)` (one sync sub)	~700 ns
`computed()` read (warm cache)	~15 ns
Observable `pipe(map).subscribe()`	~3.4 us

Signals are ~14x faster than BehaviorSubject for "publish a value, one sync reader." But the real win is structural, not micro: on Mattrx's /inbox, re-renders per WebSocket message went 23 -> 2 — because fine-grained dependency tracking re-renders only the specific slice that changed, not 23 components subscribed via | async. And with zoneless + Signals, idle change-detection passes on /dashboard dropped to 0 (only run when a signal changes).

The honest caveat: Signals don't make a slow app fast on their own — they make change-detection precise. The big wins come combined with OnPush + standalone + @for track.

Interop — you don't have to pick

Bridge at the boundary and keep each half native:

// stream -> state (HTTP as an OnPush-aware Signal)
campaigns = toSignal(this.http.get<Campaign[]>('/api/campaigns'), { initialValue: [] });

// state -> stream (debounce a Signal-driven input through RxJS, back to a Signal)
results = toSignal(
  toObservable(this.query).pipe(debounceTime(250), distinctUntilChanged(),
    switchMap(q => this.http.get(`/api/search?q=${q}`))),
  { initialValue: [] },
);

toSignal() and toObservable() aren't workarounds — they're the design. (One gotcha: toSignal without initialValue returns Signal<T | undefined> — always supply initialValue for HTTP.)

The decision tree

Is this "the current value of X" (state)? -> SIGNAL
  ├── Local to a component -> signal()
  ├── Shared across the app -> signal() in a service
  └── Derived from other signals -> computed()
Otherwise it's an event stream / time-based / async:
  ├── HTTP -> HttpClient Observable; toSignal() if read as state
  ├── debounce/throttle/switchMap input -> RxJS
  ├── WebSocket / SSE -> RxJS (webSocket + retry + share)
  └── composing DOM events (drag, gesture) -> RxJS (fromEvent + operators)

The right mental model

In one line: Signals are nouns. RxJS is verbs. "What is the current set of selected campaigns?" -> Signal. "What's happening when the user types?" -> RxJS. Three habits: default to Signals for state, default to RxJS for streams, bridge with interop instead of fighting it.

The full guide has all 10 code examples each way, the full benchmark tables, the end-to-end /campaigns component using both, and the 4-week Mattrx migration path (including the bugs that bit us):

https://prepstack.co.in/blog/angular-signals-vs-rxjs-when-to-use-which-performance-comparison-guide

Originally published on PrepStack.

Enterprise Angular Architecture in 2026 — Core, Shared, Feature + Nx Monorepo (Real Project Layout, Production Metrics)

kirandeepjassal-crypto — Wed, 23 Sep 2026 18:44:42 +0000

Most Angular apps don't fail because the framework runs out of steam. They fail around the 18-month mark, when the directory tree turns into a swamp: shared/utils/helpers/index.ts re-exports everything, three teams import each other's internals through it, CI takes 14 minutes because one test change rebuilds the world, and nobody can ship a feature without breaking two others.

The four patterns here — Feature, Core, Shared, and an Nx monorepo with enforced library boundaries — are what stops that. Not 2017 NgModule dogma; the directory-and-dependency-graph discipline underneath, which works just as cleanly with Angular 19 standalone components.

Every section uses the same real app: Mattrx, a multi-tenant marketing-analytics SaaS — Angular 19 standalone, 4 apps in one repo, 540+ components, 22k LOC, 5 product teams sharing a design system and data-access layer.

The mental model: the dependency graph IS the architecture

The single biggest decision in a large Angular app is what's allowed to import what. The arrows go ONE way:

Apps (shells) -> Features (lazy) -> Shared (ui, util)
                     |
                     v
                   Core (imported only by the app shell)

Never:
  Shared -> Features    (shared can't know about features)
  Features -> Features  (features can't reach across each other)
  Anything -> Core, except the app shell

Layer	Owns	Imported by
Core	auth, interceptors, error handler, config, logger	only main.ts, once
Shared	buttons, tables, pipes, DTOs - no business logic	any feature
Feature	routes, components, services, state for one capability	the app router (lazy)
Nx libs	tagged boundaries, ESLint enforcement, nx affected	the whole repo

Core — the app-singleton layer (modern, no NgModule)

export function provideCore(): EnvironmentProviders {
  return makeEnvironmentProviders([
    AuthService, ConfigService, LoggerService,
    { provide: ErrorHandler, useClass: GlobalErrorHandler },
    provideHttpClient(withInterceptors([authInterceptor, errorInterceptor])),
    provideAppInitializer(() => inject(ConfigService).load()),
  ]);
}

// apps/customer/src/main.ts — called exactly once
bootstrapApplication(AppComponent, {
  providers: [provideCore(), provideRouter(routes), provideAnimationsAsync()],
});

makeEnvironmentProviders is the modern equivalent of the "Core module can only be imported once" guard.

Shared — the cardinal rule

Shared cannot import from Features. Ever. If a "shared" component needs to know about campaigns, it isn't shared — it's a campaigns component.

Each Shared component is its own Nx library, imported at the leaf — no barrel @mattrx/shared/ui that re-exports everything (so the bundler tree-shakes per-library, not per-monolith):

import { MxButton } from '@mattrx/shared/ui/button';import { MxTable } from '@mattrx/shared/ui/table';```

Don't ship a `SharedModule` in 2026 — importing it to use `<mx-button>` drags in `<mx-modal>`, `<mx-toast>`, `<mx-table>`, and everything else. Use standalone leaves.

## Feature — one bounded business capability, lazy-loaded



```ts
// app.routes.ts — the app router doesn't know the feature's internal structure
{ path: 'campaigns', canMatch: [authGuard],
  loadChildren: () => import('@mattrx/features/campaigns').then(m => m.CAMPAIGNS_ROUTES) },

The bundler emits one chunk per feature. Landing on /dashboard downloads main.js (~280 KB) + dashboard.chunk.js (~140 KB) — not campaigns, inbox, reports. Feature state is Signals-first (toSignal at the HTTP boundary, computed for derived).

Nx — the structural firewall

Tags declare what each library is and belongs to, and ESLint enforces the arrows:

"@nx/enforce-module-boundaries": ["error", { "depConstraints": [
  { "sourceTag": "type:feature",     "onlyDependOnLibsWithTags": ["type:ui","type:data-access","type:util"] },
  { "sourceTag": "type:ui",          "onlyDependOnLibsWithTags": ["type:ui","type:util"] },
  { "sourceTag": "type:util",        "onlyDependOnLibsWithTags": ["type:util"] },
  { "sourceTag": "scope:customer",   "onlyDependOnLibsWithTags": ["scope:customer","scope:shared"] }
]}]

A type:ui library that imports a type:feature library is an ESLint error in CI. That's the difference between "we have a convention" and "the codebase enforces the convention."

And nx affected runs CI only for what the PR touched:

- run: npx nx affected --target=build --base=origin/main   # 2.5 min, not 12

The before/after (after the structure landed, 4 weeks)

Metric	Before	After
CI on a typical PR	22 min	6 min
affected:build	12 min	2.5 min
affected:test	8 min	90 s
Initial JS (gzipped)	1.2 MB	290 KB
Cross-team merge conflicts/wk	~6	~1
Scaffold a new feature	~3 days	~4 hours
"Where does this go?" PR comments/wk	~12	~1
Velocity (features/sprint)	9	14

The migration path (4 weeks, not one big PR)

Week 1 — tease apart Core (move Auth, interceptors, error handler, logger, config; replace CoreModule with provideCore()). Week 2 — tease apart Shared (one lib per component, tag everything, turn on @nx/enforce-module-boundaries, fix violations). Week 3 — extract Features one at a time, most isolated first, ~1-2/day. Week 4 — enable nx affected in CI + add any second frontend as a new app that reuses your shared libs.

The right mental model

Enterprise Angular at scale isn't NgModules vs standalone — it's the dependency graph being a layered DAG, and the codebase enforcing that picture so humans don't have to. Core = app-singletons imported once. Shared = presentation + utilities that know no business concepts. Features = lazy-loaded leaves that can't reach each other. Nx = makes the graph visible, enforces it, makes CI fast.

Three habits: generate every library (nx g) with tags from day one; treat boundary violations as test failures; keep apps as thin shells.

The full guide has the real Mattrx layout with file counts, the classic-vs-standalone code for every layer, the nx graph, the full ESLint config, the decision tree for "where does this go?", and the week-by-week migration path:

https://prepstack.co.in/blog/enterprise-angular-architecture-feature-core-shared-modules-nx-monorepo-guide

Originally published on PrepStack.

LLMs & Transformers from First Principles (2026) — Tokenization, Attention, LoRA, and a Tiny GPT You Can Train (with PyTorch Code)

kirandeepjassal-crypto — Mon, 21 Sep 2026 18:18:08 +0000

Everyone uses LLMs in 2026. Far fewer can explain what happens between text in and text out. The gap matters because every LLM problem — bad outputs, high latency, wrong answers, costly fine-tunes — is solved by knowing which mechanism inside the model is responsible.

This rebuilds the LLM stack piece by piece with real PyTorch and Hugging Face code: tokenization, embeddings, self-attention, the transformer block, a tiny GPT you can train on your laptop, pretraining vs fine-tuning vs LoRA vs DPO, and decoding.

The one idea

An LLM is a function from token sequences to a next-token probability distribution. That's it.

sequence = [<bos>, "The", " sky", " is"]
while not done:
    probs = LLM(sequence)
    next_token = sample(probs)
    sequence.append(next_token)

Every chat API, code assistant, agent, and RAG system is a sampling loop around "predict the next token."

Tokenization — text becomes integers first

A model can't read characters. Modern LLMs use subword tokenization (BPE for GPT/Llama/Mistral, WordPiece for BERT, SentencePiece for T5).

from transformers import AutoTokenizer
tok = AutoTokenizer.from_pretrained("gpt2")
tok.convert_ids_to_tokens(tok.encode("Mumbai and Indore are cities in India."))
# ['Mumbai', 'and', 'Ind', 'ore', 'are', 'cities', 'in', 'India', '.']

"Mumbai" is 1 token; "Indore" is 2. Token counts drive API cost, context window, and latency — French text costs 2-3x more tokens than English. Tokenization is the source of most "why does the model do X?" bugs. And always use apply_chat_template — hand-concatenating "user: ... assistant: ..." is a classic bug.

Self-attention — the one idea that changed everything

For each token, compute a weighted sum of every other token's value, where the weights depend on relevance. Every token gets three roles: Query ("what am I looking for?"), Key ("what do I represent?"), Value ("what do I contribute?").

Attention(Q, K, V) = softmax(Q @ K.T / sqrt(d)) @ V

The whole revolution is one matrix multiply + a softmax:

scores = Q @ K.transpose(-2, -1) / math.sqrt(self.d_k)
if mask is not None:
    scores = scores.masked_fill(mask == 0, float("-inf"))
weights = F.softmax(scores, dim=-1)
return weights @ V

The causal mask (lower-triangular) is why GPT can't see the future. Multi-head attention runs several of these in parallel. In production, use Flash Attention via F.scaled_dot_product_attention.

The transformer block

x -> LayerNorm -> MultiHeadAttention -> +residual ->
  -> LayerNorm -> FeedForward -> +residual -> output

Residuals are the gradient highway — without them, deep transformers don't train.
LayerNorm (Pre-LN) stabilizes training.
Feed-forward is a 2-layer MLP per token, usually d_ff = 4 x d_model.

Stack 6-96 of these and you have a model. Llama-3-8B is 32 blocks; GPT-3 is 96. The guide has a full runnable ~200-line GPT you can train on Shakespeare on a laptop — that's the entire architecture of GPT-3, just bigger and on more data.

Training, decoded

Pretraining = predict the next token on 5-15 trillion tokens. The intelligence emerges from that one boring objective at scale ($10M-$100M for a frontier model).
Fine-tuning — start with prompting/few-shot; if that's not enough, LoRA trains ~0.1% of params at ~1000x less memory:

lora_config = LoraConfig(r=16, lora_alpha=32,
    target_modules=["q_proj","k_proj","v_proj","o_proj"],
    lora_dropout=0.05, task_type="CAUSAL_LM")
model = get_peft_model(model, lora_config)
# trainable%: 0.4%, adapter ~130 MB

QLoRA (LoRA on a 4-bit base) fine-tunes a 70B model on a single 24 GB GPU — the standard recipe for small teams in 2026.
SFT trains on (instruction, response); DPO on (prompt, chosen, rejected) — much simpler than classic RLHF.

Decoding

Greedy is deterministic but repetitive. The production default is temperature + top-p:

out = model.generate(inputs, do_sample=True, temperature=0.7, top_p=0.9,
                     repetition_penalty=1.05, max_new_tokens=128)

Chat: 0.7. Code: 0.0-0.3. For production, swap model.generate for vLLM — paged attention + continuous batching, often 5-20x faster.

The honest stuff

Context length costs scale quadratically — 32k isn't 4x 8k, it's ~16x.
Most prod LLM systems are 90% retrieval + 10% LLM.
Fine-tuning is rarely the answer — try prompting, RAG, and a bigger model first.
Evals beat vibes — build a golden set of 50-200 queries before you fine-tune.
Inference cost dominates training cost. Optimize for serving.

The right mental model

An LLM is not magic. It's: a tokenizer, an embedding table, a stack of transformer blocks, and a head that projects back to vocabulary. Pretraining gives general competence; fine-tuning teaches your task; decoding turns probabilities into text.

Three habits: always inspect the tokens first; build the eval set before the model; reach for the smallest model that works.

The full guide has the complete PyTorch — scaled dot-product + multi-head attention, the transformer block, the runnable tiny GPT + training loop, full/LoRA/QLoRA fine-tuning, DPO, the decoding recipes, RAG, tool-use, and the 2026 model menu:

https://prepstack.co.in/blog/llms-transformers-tokenization-attention-embeddings-pretraining-finetuning-pytorch-guide

Originally published on PrepStack.

DEV Community: kirandeepjassal-crypto

JavaScript Interview Questions for Senior Developers in 2026 — Closures, the Event Loop, Prototypes & Async

Block A — scope, closures & types

Block B — this, prototypes & objects

Block C — async & the event loop

Block D — functional patterns, memory & modern JS

EF Core Interview Questions for Senior Developers in 2026 — Change Tracking, Performance, Concurrency & Migrations

Block A — change tracking & the DbContext

Block B — querying & performance

Block C — concurrency & transactions

Block D — migrations, modeling & production

Microservices Interview Questions for Senior Developers in 2026 — Boundaries, Saga & Consistency, Resilience & Observability (Deep Answers)

The lens for all 30

Block A highlight — the distributed monolith

Block B highlight — the outbox pattern

Block C highlight — resilience (breaker + retry + timeout)

Block D highlight — distributed tracing

The through-line

SQL Server Interview Questions for Senior Developers in 2026 — Execution Plans, Indexing, Locking & Parameter Sniffing (Deep Answers)

The lens for all 30

Block A highlight — why your index isn't used (SARGability)

Block B highlight — parameter sniffing

Block C highlight — RCSI vs NOLOCK

Block D highlight — keyset pagination and safe big writes

The through-line

ASP.NET Core Interview Questions for Senior Developers in 2026 — Middleware Pipeline, DI Lifetimes, Kestrel & Auth (Deep Answers)

The lens for all 30

Block A highlight — the pipeline, and the #1 ordering bug

Block B highlight — the captive dependency bug

Block C highlight — sync-over-async and thread-pool starvation

Block D highlight — multi-tenant isolation and JWT validation

The through-line

C# Interview Questions for Senior Developers in 2026 — async/await, GC & Memory, the Type System, and LINQ (Deep Answers)

The lens for all 30

Block A highlight — what actually happens when you await

Block B highlight — GC, allocations, and the HttpClient trap

Block C highlight — deferred execution

Block D highlight — the EF Core IQueryable trap

The through-line

Angular Interview Questions for Senior Developers in 2026 — Change Detection, RxJS, Signals & Performance (Deep Answers)

The lens for all 30

Block B highlight — how change detection actually works

Block C highlight — the RxJS flattening operators

Block C highlight — signals vs RxJS

The through-line

Angular Performance Optimization in 2026 — OnPush, trackBy, Lazy Loading, Signals, Standalone (Real Code, Production Metrics)

TL;DR — the five, ranked by impact

The model you need: change detection

1. Lazy loading — the biggest LCP win

2. OnPush — the biggest CPU win

3. Signals — replace BehaviorSubject for state

4. Standalone components — tree-shaking + lazy loading

5. trackBy / @for track — the afternoon fix

Bonus: block control flow

The right mental model

Angular Micro Frontends in 2026 — Webpack Module Federation vs Native Federation, Independent Deployments (Real Project, Production Metrics)

The one idea

Two paths: Webpack MF vs Native Federation

Native Federation — the modern setup

The day-2 reality (where the real engineering lives)

The production numbers (after carving out 2 remotes)

When NOT to use micro frontends

The right mental model

Angular Signals vs RxJS in 2026 — When to Use Each, Performance Benchmarks, and the Interop Pattern (Real Code)

The mental model (the one chart you need)

When Signals win (state)

When RxJS wins (events over time) — and Signals genuinely can't

Performance (numbers, not vibes)

Interop — you don't have to pick

The decision tree

The right mental model

Enterprise Angular Architecture in 2026 — Core, Shared, Feature + Nx Monorepo (Real Project Layout, Production Metrics)

The mental model: the dependency graph IS the architecture

Core — the app-singleton layer (modern, no NgModule)

Shared — the cardinal rule

Nx — the structural firewall

The before/after (after the structure landed, 4 weeks)

The migration path (4 weeks, not one big PR)

The right mental model

LLMs & Transformers from First Principles (2026) — Tokenization, Attention, LoRA, and a Tiny GPT You Can Train (with PyTorch Code)

Block A highlight — what actually happens when you `await`