.NET Backend Developer Interview — Reviewed Study Guide

Big-O describes how the number of operations (time) or amount of memory (space) grows as the input size n grows toward infinity. It ignores constants and hardware — it's about the shape of growth, not the exact count.

How to derive it in 4 steps:

1. 9/10Count the loops. One loop over n = O(n). A loop inside a loop, both over n = O(n²).
2. 9/10Halving the input each step = O(log n) (that's binary search, balanced trees).
3. 9/10Drop constants and lower-order terms: O(2n + 100) becomes O(n); O(n² + n) becomes O(n²) because n² dominates as n grows.
4. 9/10Recursion: multiply the number of calls by the work per call. Naive Fibonacci makes 2 calls per level for n levels = O(2ⁿ).

Space complexity counts extra memory you allocate: a second array = O(n); recursion uses the call stack, so depth-d recursion = O(d) space even with no explicit arrays.

When you read a problem, try to map it to one of these. The trigger phrases in italics tell you which to reach for.

Two Pointers sorted array, pair, palindrome 8/10

Two indices move toward each other (or one chases the other). Trigger: "sorted array", "pair that sums to target", "is it a palindrome", "remove duplicates in place".

// Pair that sums to target in a SORTED array — O(n), O(1) space
int lo = 0, hi = arr.Length - 1;
while (lo < hi) {
    int sum = arr[lo] + arr[hi];
    if (sum == target) return new[]{ lo, hi };
    if (sum < target) lo++;   // need bigger → move left pointer up
    else hi--;                // need smaller → move right pointer down
}

Sliding Window longest/shortest subarray or substring 8/10

Grow a window from the right, shrink from the left when a condition breaks. Turns many O(n²) substring problems into O(n). Trigger: "longest/shortest contiguous …", "substring without repeats", "max sum of k elements".

// Longest substring with no repeating characters — O(n)
var last = new Dictionary<char,int>();
int start = 0, best = 0;
for (int end = 0; end < s.Length; end++) {
    if (last.TryGetValue(s[end], out int idx) && idx >= start)
        start = idx + 1;              // jump past the previous duplicate
    last[s[end]] = end;
    best = Math.Max(best, end - start + 1);
}
return best;

Fast & Slow Pointers cycle detection 6/10

A slow pointer moves 1 step, a fast pointer 2 steps. If there's a cycle they meet. Trigger: "does the linked list have a cycle", "find the middle".

Binary Search sorted, or 'search the answer' 9/10

Repeatedly halve the search space — O(log n). Also works on an abstract "answer space" (e.g. minimum capacity that satisfies a condition). Trigger: "sorted", "minimum/maximum value that works".

int lo = 0, hi = arr.Length - 1;
while (lo <= hi) {
    int mid = lo + (hi - lo) / 2;      // avoids integer overflow
    if (arr[mid] == target) return mid;
    if (arr[mid] < target) lo = mid + 1;
    else hi = mid - 1;
}
return -1;

BFS & DFS trees & graphs 8/10

BFS uses a queue and visits level by level → shortest path in unweighted graphs. DFS uses recursion/stack and goes deep → good for exploring all paths, detecting cycles, topological sort.

// BFS shortest path (unweighted) — O(V + E)
var q = new Queue<int>(); var dist = new Dictionary<int,int>{ [start]=0 };
q.Enqueue(start);
while (q.Count > 0) {
    int node = q.Dequeue();
    foreach (int next in graph[node])
        if (!dist.ContainsKey(next)) {
            dist[next] = dist[node] + 1;
            q.Enqueue(next);
        }
}

Backtracking permutations, combinations, subsets 5/10

Try a choice, recurse, then undo it and try the next. Explores a decision tree. Trigger: "all combinations/permutations/subsets", "sudoku", "generate all valid …".

void Backtrack(List<int> path, bool[] used) {
    if (path.Count == nums.Length) { results.Add(new(path)); return; }
    for (int i = 0; i < nums.Length; i++) {
        if (used[i]) continue;
        used[i] = true;  path.Add(nums[i]);      // choose
        Backtrack(path, used);                    // explore
        used[i] = false; path.RemoveAt(path.Count-1); // un-choose
    }
}

Other must-know patterns 6/10

• 6/10Hash Map counting — frequencies, anagrams, "first unique". O(n).
• 6/10Prefix Sum — precompute cumulative sums so any range sum is O(1).
• 6/10Top-K / Heap — keep a heap of size K → O(n log k).
• 6/10Merge Intervals — sort by start, then merge overlaps.
• 6/10Topological Sort — order tasks with dependencies (build order, course schedule); DFS or Kahn's algorithm.
• 6/10Union-Find — group connected items, detect graph cycles, near-O(1) per op.
• 6/10Greedy — take the locally best choice; works when local optima lead to a global optimum (interval scheduling, Huffman).

In real code you just call list.Sort() (introsort — a quicksort/heapsort hybrid) or OrderBy (stable). But interviewers ask you to explain why merge sort is O(n log n): it splits the array in half (log n levels) and does O(n) work merging at each level.

Recursion = a function calling itself on a smaller input until a base case stops it. Every recursion needs (1) a base case and (2) progress toward it.

Dynamic Programming = recursion where subproblems repeat, so you cache results to avoid recomputing. Two flavors:

• 6/10Memoization (top-down): normal recursion + a cache (Dictionary/array).
• 6/10Tabulation (bottom-up): fill a table from the smallest subproblem upward.

Classic example — Fibonacci goes from O(2ⁿ) to O(n):

// Naive: O(2^n) — recomputes the same values exponentially
int Fib(int n) => n < 2 ? n : Fib(n-1) + Fib(n-2);

// Memoized: O(n) — each value computed once
var memo = new Dictionary<int,long>();
long Fib(int n) {
    if (n < 2) return n;
    if (memo.TryGetValue(n, out var v)) return v;
    return memo[n] = Fib(n-1) + Fib(n-2);
}

How to spot a DP problem: you're asked for a count, a min/max, or "is it possible", AND the answer for n depends on answers for smaller inputs, AND those overlap. Classics: coin change, longest common subsequence, edit distance, knapsack, climbing stairs, house robber.

Bits are occasionally tested, especially at bigger companies. The essentials:

// "Single number": every value appears twice except one — XOR cancels the pairs
int Single(int[] nums) { int r = 0; foreach (int n in nums) r ^= n; return r; }

// Is x a power of two? Exactly one bit set.
bool IsPowerOfTwo(int x) => x > 0 && (x & (x - 1)) == 0;

↑ back to top

• 9/10S — Single Responsibility. One class, one reason to change. A class that parses a file and emails results and writes to the DB should be three classes.
• 9/10O — Open/Closed. Open to extension, closed to modification. Instead of a growing switch on payment type, add a new IPaymentMethod implementation — existing code doesn't change.
• 9/10L — Liskov Substitution. A subtype must work anywhere its base type is expected. The classic violation: a Square subclassing Rectangle breaks code that sets width and height independently.
• 9/10I — Interface Segregation. Prefer several small interfaces over one fat one, so implementers aren't forced to stub methods they don't use.
• 9/10D — Dependency Inversion. High-level policy should not depend directly on low-level implementation details; both should depend on a useful abstraction, for example IEmailSender rather than an SMTP SDK. A DI container helps compose dependencies, but using a container alone does not guarantee good abstractions.

A web server has a limited ThreadPool. When a genuinely asynchronous I/O operation is incomplete, await records the continuation and returns control without blocking a request thread. When the I/O completes, execution resumes later, possibly on a different ThreadPool thread. This improves throughput; it does not make CPU-heavy work faster.

public async Task<User?> GetUserAsync(int id, CancellationToken cancellationToken) {
    // The request thread is not blocked while asynchronous database I/O is pending.
    var user = await _db.Users.FindAsync(new object[] { id }, cancellationToken);
    return user;
}

• 10/10Task vs Thread: a Task represents an asynchronous operation and its eventual result; it does not necessarily own or run on a thread. A Thread is an OS execution resource. I/O tasks can be pending with no thread blocked.
• 10/10I/O-bound vs CPU-bound: await asynchronous APIs for database, file, and network I/O. Use Task.Run only when you intentionally move CPU-bound work to the ThreadPool; in a web server, sustained CPU work is usually better moved to a worker service.
• 9/10Composition: use Task.WhenAll for independent operations, but do not create unbounded parallelism. Limit fan-out with SemaphoreSlim, a channel, or a bounded worker queue.
• 10/10Cancellation: pass CancellationToken through every cancellable call, including EF Core and HttpClient. In APIs, propagate HttpContext.RequestAborted. Cancellation is cooperative and often throws OperationCanceledException.
• 9/10Avoid async void: except for event handlers, return Task so callers can await failures. Consider ValueTask only for measured hot paths where operations frequently complete synchronously.
• 6/10ConfigureAwait: ASP.NET Core has no request SynchronizationContext, so ConfigureAwait(false) is usually unnecessary in application code. It can still be appropriate in reusable libraries that should not depend on a caller's context.
• 9/10Thread safety: shared mutable state may require lock, Interlocked, concurrent collections, or immutability. You cannot await inside a C# lock; use SemaphoreSlim.WaitAsync for asynchronous coordination.

Kestrel accepts HTTP requests, commonly behind a reverse proxy or cloud load balancer. A request then flows through the ordered middleware pipeline. Middleware can inspect or short-circuit the request, call the next component, and inspect the response on the way back. Typical ordering puts exception handling early, then forwarded headers/HTTPS/static files as needed, routing, authentication, authorization, and endpoints. Exact ordering depends on the application.

// Interviewers often ask you to sketch a custom middleware:
app.Use(async (context, next) => {
    var sw = Stopwatch.StartNew();
    await next(context);                        // run the rest of the pipeline
    app.Logger.LogInformation("{Method} {Path} => {Status} in {Ms} ms",
        context.Request.Method, context.Request.Path,
        context.Response.StatusCode, sw.ElapsedMilliseconds);
});

• 8/10Controllers vs Minimal APIs: both are first-class. Minimal APIs are concise and fit small focused services; controllers provide conventions, filters, and organization for larger APIs. Choose by complexity and team conventions—not by a blanket performance rule.
• 5/10Keyed DI services: when several implementations share one interface, register and resolve keyed services with AddKeyedScoped/AddKeyedSingleton and [FromKeyedServices]. Prefer ordinary constructor injection when one implementation is enough; excessive runtime key selection can hide dependencies.
• 8/10Middleware vs filters: middleware is framework-wide and runs before MVC/endpoint-specific behavior. MVC filters have action/controller context. Endpoint filters provide similar interception for Minimal APIs.
• 9/10Binding, validation and errors: map route/query/header/body data to request models, validate at the boundary, and return standardized RFC 7807/9457-style ProblemDetails. Use global exception handling such as IExceptionHandler; do not leak stack traces.
• 8/10Serialization: ASP.NET Core commonly uses System.Text.Json. Return DTOs rather than EF entities, define naming/null/enum behavior intentionally, prevent reference cycles, and use streaming/source generation only when profiling justifies it.
• 10/10Authentication and authorization: authentication builds a ClaimsPrincipal; authorization evaluates roles, claims, policies, or resource-based handlers. UseAuthentication() must run before UseAuthorization().
• 8/10OpenAPI: expose an OpenAPI document for API discovery, generated clients, and testing. Know request/response contracts, content negotiation, versioning strategy, and backward compatibility.
• 9/10IHttpClientFactory: do not create and dispose an HttpClient per request. Use factory-created named/typed clients, or a long-lived client configured with SocketsHttpHandler.PooledConnectionLifetime, so connections are reused without pinning DNS indefinitely. Add explicit timeouts and resilience policies.
• 8/10Background work: never fire-and-forget request-scoped work with unobserved Task.Run. Use a bounded queue plus BackgroundService, or an external broker/worker. Create a DI scope inside the worker when scoped services are needed.
• 9/10Configuration and options: configuration is layered from files, environment variables, secret stores, and command-line values. Bind to IOptions<T>, validate options at startup, and use IOptionsSnapshot/IOptionsMonitor only when reload semantics are needed.
• 9/10Operations: use structured ILogger logs, OpenTelemetry traces/metrics, correlation or trace IDs, and separate liveness/readiness health checks. Never log passwords, tokens, or sensitive personal data.

• 8/10Unit tests: test behavior of a small unit quickly. Use fakes/mocks at real external boundaries; do not mock every internal class or assert implementation details.
• 9/10Integration tests: use WebApplicationFactory<Program> to run the real ASP.NET Core pipeline. EF Core's InMemory provider is not relational and can hide constraint, transaction, translation, and SQL differences. Use SQLite for lightweight relational tests or a disposable instance of the production engine when fidelity matters. Testcontainers is valuable when Docker is available; it is an option, not a universal requirement.
• 6/10Contract and end-to-end tests: contract tests protect service/API compatibility; end-to-end tests cover a few critical user journeys. Keep the suite deterministic and isolate test data.
• 8/10Structure: Arrange, Act, Assert. Name tests by observable behavior, for example Withdraw_WhenBalanceTooLow_Throws. Include happy paths, boundaries, failures, authorization, cancellation, and concurrency where relevant.
• 6/10Tools: xUnit, NUnit, or MSTest; a mocking library when useful; and built-in or third-party assertion helpers. The tool matters less than readable, stable tests.

.NET manages memory automatically with a generational, tracing garbage collector:

• 8/10Gen 0 — new, short-lived objects; collected frequently and cheaply.
• 8/10Gen 1 — survivors of a Gen 0 collection; a buffer between short- and long-lived.
• 8/10Gen 2 — long-lived objects (caches, singletons); collected rarely.
• 8/10Large Object Heap (LOH) — large allocations (commonly ≥85 KB) are collected with Gen 2 and are compacted less routinely, so repeated large allocations can cause fragmentation and long pauses.
• 7/10Workstation vs Server GC — Server GC (the ASP.NET Core default) uses per-core heaps and parallel collection for throughput at the cost of memory; Workstation GC favors a smaller footprint. Gen 0/1 collections are frequent and cheap; blocking full Gen 2 collections are what cause noticeable pauses.

The idea (the "generational hypothesis"): most objects die young, so collecting Gen 0 often and Gen 2 rarely is efficient. You rarely call GC.Collect() manually — instead you avoid leaks: unsubscribe from events, dispose IDisposable, and don't hold references longer than needed. A memory leak in .NET is usually an object still referenced somewhere (e.g. a static list or an event handler) so the GC can't reclaim it.

↑ back to top

• 8/10Primary key (PK) — uniquely identifies a row (often an auto-increment id or a GUID).
• 8/10Foreign key (FK) — a column pointing at another table's PK; the database enforces that the referenced row exists (referential integrity).
• 8/10Relationships: one-to-one, one-to-many (a user has many orders → the FK lives on orders), many-to-many (students ↔ courses → needs a junction table enrollments).

Normalization removes redundancy so data can't contradict itself:

• 8/101NF — every column holds one atomic value (no comma-separated lists in a cell).
• 8/102NF — no column depends on only part of a composite key.
• 8/103NF — no non-key column depends on another non-key column (store city once in an addresses table, don't repeat it per order).
• 8/10Denormalization — deliberately duplicating data to avoid expensive joins on read-heavy paths. It's a performance trade-off you now maintain by hand.

The examples are mostly portable SQL. Dialects differ: SQL Server commonly uses TOP or OFFSET … FETCH, while PostgreSQL/MySQL use LIMIT. State which dialect you are using in an interview.

-- Filtering, sorting, limiting
SELECT TOP (10) name, email FROM users
WHERE country = 'NO' AND is_active = 1
ORDER BY created_at DESC;

-- Aggregation: WHERE filters ROWS, HAVING filters GROUPS
SELECT country, COUNT(*) AS user_count, AVG(age) AS avg_age
FROM users
WHERE is_active = 1
GROUP BY country
HAVING COUNT(*) > 100;

Join types (know exactly what each returns) 10/10

-- Simple, portable
SELECT MAX(salary) FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

-- General "Nth highest" via a window function
SELECT DISTINCT salary FROM (
    SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
    FROM employees
) t
WHERE rnk = 2;

SELECT u.id, u.name
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.id IS NULL;

SELECT department_id, name, salary FROM (
    SELECT department_id, name, salary,
           DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS salary_rank
    FROM employees
) t
WHERE salary_rank = 1;

SELECT email, COUNT(*) AS n
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

An index is an auxiliary access structure—commonly a B-tree—that can let the optimizer seek to matching rows instead of scanning every row. Complexity is often described as roughly O(log n), but real performance also depends on selectivity, pages read, key lookups, caching, and how many rows are returned.

• 10/10Trade-off: reads get faster, but every INSERT/UPDATE/DELETE must also update the index, and indexes use storage. Don't index everything.
• 8/10Clustered vs non-clustered: in SQL Server, the clustered index organizes table rows by its key and there can be only one; non-clustered indexes are separate structures. Other engines use different storage models, so do not present this as universal SQL behavior.
• 10/10Composite index — spans multiple columns; the order matters (leftmost-prefix rule): an index on (country, city) helps queries filtering by country or country + city, but not by city alone.
• 10/10Covering and filtered indexes: included columns can let SQL Server satisfy a query from the index alone; filtered indexes target a selective subset such as active rows.
• 10/10SARGability: write predicates the engine can seek on. For example, WHERE CreatedAt >= @start is usually better than wrapping CreatedAt in a function. Use the actual execution plan and measured reads—not guesses—to verify improvement.

A transaction groups statements so they all commit or all roll back — critical for things like transferring money (debit one account, credit another; you can't do just half).

• 9/10A — Atomicity: all steps succeed or none do.
• 9/10C — Consistency: a committed transaction preserves declared constraints and application invariants when the transaction logic is correct.
• 9/10I — Isolation: controls how concurrent transactions observe and interfere with one another.
• 9/10D — Durability: once committed, data survives a crash (written to disk/log).

Isolation levels trade correctness against concurrency, from weakest to strongest:

Exact behavior is database-specific. SQL Server also offers snapshot-based isolation; PostgreSQL implements some named levels using multiversion concurrency control. In an interview, explain the anomaly you need to prevent rather than assuming every engine behaves identically.

The most-asked ORM question. With lazy-loading proxies enabled, you fetch a list (1 query), then access a related entity per item (N more queries) → 1 + N round-trips that can crush performance. EF Core does not enable lazy loading automatically.

// BAD — N+1: one extra query per order to load its user
var orders = db.Orders.ToList();
foreach (var o in orders)
    Console.WriteLine(o.User.Name);      // lazy loads each time

// GOOD — project only the columns the endpoint needs.
var orders = await db.Orders
    .Select(o => new { o.Id, UserName = o.User.Name })
    .ToListAsync(cancellationToken);

Many real systems use both (polyglot persistence): PostgreSQL for core data, Redis for caching/sessions, a search engine for full-text.

CTEs (Common Table Expressions) & recursion 7/10

A CTE is a named query expression scoped to one statement that can improve readability. It is not necessarily materialized; the optimizer may inline or otherwise transform it. Recursive CTEs can walk hierarchies such as org charts and category trees.

-- Readable multi-step query
WITH active_users AS (
    SELECT id, name FROM users WHERE is_active = 1
),
big_spenders AS (
    SELECT user_id, SUM(total) AS spent FROM orders GROUP BY user_id HAVING SUM(total) > 1000
)
SELECT a.name, b.spent
FROM active_users a JOIN big_spenders b ON b.user_id = a.id;

Window functions (very common in senior interviews) 8/10

They compute across a set of rows related to the current row without collapsing them (unlike GROUP BY):

• 8/10ROW_NUMBER() — unique sequential number per partition.
• 8/10RANK() / DENSE_RANK() — ranking with/without gaps on ties.
• 8/10LAG() / LEAD() — previous/next row's value (great for month-over-month deltas).
• 8/10SUM() OVER (...) — running totals.

-- Running total of order amounts per user, in date order
SELECT user_id, created_at, total,
       SUM(total) OVER (PARTITION BY user_id ORDER BY created_at) AS running_total
FROM orders;

Subqueries vs JOINs 7/10

Many equivalent queries are transformed into similar plans by modern optimizers; neither syntax is inherently faster. Correlated subqueries can become expensive if repeatedly evaluated. EXISTS clearly expresses an existence check and avoids some NULL surprises, while IN may be equally efficient. Compare actual plans and measured reads.

Views & stored procedures 6/10

A view is a stored query definition selected from like a table; it can simplify access and restrict exposed columns. A stored procedure is server-side SQL code with parameters and permissions. Both ad-hoc parameterized SQL and procedures can use cached execution plans, so “stored procedures are precompiled and therefore always faster” is not a reliable rule.

NULLs, constraints and set operations 7/10

• 7/10NULL means unknown/missing, so use IS NULL, not = NULL. SQL uses three-valued logic; predicates involving NULL may evaluate to unknown.
• 7/10Use NOT NULL, UNIQUE, CHECK, foreign keys, and appropriate defaults to protect invariants close to the data.
• 7/10UNION removes duplicates; UNION ALL keeps them and is usually cheaper.
• 7/10For large ordered result sets, keyset pagination is usually more stable and efficient than deep OFFSET paging.

• 8/10Pessimistic locking — acquire locks so conflicting work waits. Syntax is engine-specific: PostgreSQL/MySQL support forms of SELECT ... FOR UPDATE; SQL Server uses transaction isolation and locking behavior/hints. Safe for some workflows but reduces concurrency.
• 8/10Optimistic concurrency — don't hold a lock while the user works; include a version/timestamp predicate in the update. If no row is updated, resolve or retry the conflict. EF Core supports this when you configure a concurrency token.
• 8/10Deadlock — transaction A locks row 1 then wants row 2; transaction B locks row 2 then wants row 1. Neither proceeds. The DB detects it and kills one ("deadlock victim"). Avoid by always acquiring locks in a consistent order and keeping transactions short.

• 7/10Replication — primary handles writes, read replicas serve reads (eventual consistency lag to watch for).
• 7/10Partitioning/sharding — split a huge table by a key (range, hash, or geography). Trade-off: cross-shard queries and joins get hard.
• 7/10Query tuning — inspect the actual execution plan and logical reads, select only needed columns, use selective/SARGable predicates, avoid accidental cartesian products, and use keyset pagination for deep pages.
• 7/10Connection pooling — ADO.NET providers normally pool physical connections. Open late, dispose promptly, and let pooling reuse them; a short-lived DbContext does not imply a new physical connection every time.

↑ back to top

• 9/10Resources are nouns; HTTP methods express semantics:
  GET /users (list) · GET /users/42 (one) · POST /users (create/process) · PUT /users/42 (create or replace at a known URI) · PATCH /users/42 (partial change) · DELETE /users/42.
• 9/10Status codes: 200 OK · 201 Created · 204 No Content · 400 Bad Request · 401 Unauthorized (not logged in) · 403 Forbidden (logged in, not allowed) · 404 Not Found · 409 Conflict (e.g. duplicate) · 422 Unprocessable · 429 Too Many Requests · 500 Server Error · 503 Unavailable.
• 9/10Statelessness: each request carries everything needed (e.g. an auth token); the server keeps no per-client session in memory, so any server can handle any request — that's what makes horizontal scaling possible.
• 9/10Idempotency: PUT and DELETE are idempotent by HTTP semantics; GET and HEAD are also safe. POST is usually not idempotent, and PATCH depends on the patch operation. Use an idempotency key for retried commands such as payments.
• 9/10Contracts: validate at the boundary, return ProblemDetails, publish OpenAPI, and preserve backward compatibility. Use ETags/If-Match for conditional updates where lost updates matter.
• 9/10Collections: filter and sort explicitly, cap page size, and prefer cursor/keyset pagination for large changing datasets. Version only when a breaking contract change cannot be evolved compatibly.

AuthN = "who are you?" · AuthZ = "what are you allowed to do?"

JWT (JSON Web Token) is one access-token format, not an authentication protocol by itself. A common flow is:

1. 9/10User logs in with credentials; server verifies them.
2. 9/10An authorization server issues a signed access token containing limited claims and an expiry.
3. 9/10The client sends it to the resource API, commonly in the HTTP Authorization header using the Bearer scheme (Authorization: Bearer <token>).
4. 9/10The API validates the allowed signing algorithm, signature, issuer, audience, lifetime, and required claims before authorizing the request.
5. 9/10Short-lived access tokens limit exposure. Refresh tokens require secure storage, rotation, reuse detection, revocation, and server-side records.

• 9/10OAuth 2.0 is an authorization framework for obtaining delegated access tokens; OpenID Connect (OIDC) adds authentication and identity claims. For browser/mobile public clients, know Authorization Code + PKCE.
• 9/10JWT trade-off: local validation can avoid a database lookup, but immediate revocation is harder. Sensitive systems may use reference tokens/introspection or a revocation strategy.
• 8/10Storage: do not automatically recommend localStorage. Browser apps often use secure HttpOnly, Secure, appropriate SameSite cookies or a backend-for-frontend; the right choice depends on XSS, CSRF, and architecture.
• 9/10Passwords: prefer ASP.NET Core Identity or an external identity provider. Use adaptive salted password hashing; never design a custom password scheme.

Store expensive results somewhere faster so you do not repeatedly compute or fetch them. Layers include HTTP/browser and CDN caches, per-instance IMemoryCache, and shared IDistributedCache/Redis. In-memory cache is fastest but not shared across replicas; distributed cache adds network and operational cost.

Cache-aside is the common pattern:

value = cache.Get(key);
if (value == null) {              // cache miss
    value = db.Load(key);         // go to the source
    cache.Set(key, value, ttl);   // populate for next time
}
return value;

• 7/10ASP.NET Core output caching: AddOutputCache/UseOutputCache can cache complete endpoint responses with policies for expiry, vary-by values, tags, and invalidation. Cache only responses that are safe to reuse; authenticated or user-specific output needs explicit partitioning or should not be cached.

• 7/10Vertical scaling — a bigger machine (more CPU/RAM). Simple, but has a ceiling and a single point of failure.
• 7/10Horizontal scaling — more machines behind a load balancer that spreads requests. Needs stateless servers (or a shared session/cache store) so any server can serve any request.
• 7/10Database scaling:
  • 7/10Read replicas — copies that serve read traffic; writes go to the primary and replicate out (eventual consistency).
  • 7/10Sharding/partitioning — split data across DBs by a key (e.g. user id range) when one DB can't hold it all.
  • 7/10Connection pooling — reuse a pool of DB connections instead of opening one per request.
• 7/10CDN — caches static content at edge locations near users to cut latency.

Slow or unreliable work (sending email, processing images, generating reports, calling a flaky third party) shouldn't block the user's request. Put a message on a queue and let background workers process it.

• 8/10Producer → queue → consumer. The API returns immediately; workers handle the job. This decouples services and smooths traffic spikes (the queue absorbs bursts).
• 8/10Delivery guarantees: most queues are at-least-once, so a message can be delivered twice — make consumers idempotent (processing the same message twice has no extra effect).
• 8/10Dead-letter queue — messages that keep failing get moved aside for inspection instead of blocking the queue.
• 8/10Backpressure and ordering: bound queues and consumer concurrency so producers cannot exhaust memory. Ordering is usually guaranteed only within a partition/session, not globally.
• 5/10In-process producer/consumer: System.Threading.Channels provides asynchronous bounded queues for work inside one process. A bounded channel gives backpressure and fits a BackgroundService; use a durable external broker when work must survive process failure or cross service boundaries.
• 8/10Failure handling: use bounded retries with backoff, detect poison messages, include correlation and message IDs, and monitor queue age—not just queue length. “Exactly once” normally requires application-level idempotency and transactional design.
• 6/10Tools: RabbitMQ, Azure Service Bus, AWS SQS, Kafka (Kafka is really a distributed log, great for event streaming).

• 8/10Monolith — one deployable app. Simple to build, test, and deploy; great to start with. Downsides: one small change redeploys everything, and you can't scale parts independently.
• 8/10Modular monolith — one deployment with explicit module boundaries and controlled dependencies. It preserves simple operations while making later extraction possible; this is often a better default than immediate microservices.
• 8/10Microservices Role-dependent — independently deployable services can support team autonomy and targeted scaling, but introduce network failure, data ownership, versioning, observability, and operational complexity. Start with clear boundaries and a concrete reason.
• 8/10Layered (n-tier): Controller/API → Application/Service → Domain → Data-access. Each layer only talks to the one below.
• 8/10Clean / Hexagonal: the domain sits at the center with no dependencies; infrastructure (DB, HTTP, queues) plugs in at the edges and dependencies point inward. Very common in modern .NET.
• 8/10SignalR: .NET's library for real-time web functionality. Uses WebSockets under the hood with fallbacks. Great for chat apps, live dashboards, or progress notifications.
• 8/10YARP Optional — a customizable .NET reverse-proxy toolkit. Know it only if the role or existing architecture uses it; reverse-proxy and gateway concepts matter more than the product name.

• 8/10Observability: logs explain events, metrics expose trends and saturation, and traces follow work across dependencies. Use OpenTelemetry and propagate trace context rather than inventing isolated correlation IDs.
• 8/10SLI/SLO/SLA: an SLI is a measured indicator such as latency or error rate; an SLO is the target; an SLA is an external commitment. Error budgets guide how much unreliability is acceptable.
• 8/10Recovery: RTO is the target time to restore service; RPO is the maximum acceptable data-loss window. Backups are not enough—restore them in tests.
• 8/10Resilience: start with deadlines/timeouts. Retry only transient, safe/idempotent operations, with exponential backoff and jitter. Add circuit breakers, concurrency limits, rate limiting, and graceful degradation. Modern .NET can use resilience handlers built on Polly.

This is the most common junior/mid system-design prompt. Here's how to talk through it using the 7-step method.

Other prompts to rehearse the same way: pastebin, rate limiter, news feed, chat app, a "like" service, a file storage service.

Over-fetching means an endpoint returns more than needed; under-fetching means several calls are needed. GraphQL can reduce both, but resolvers can create N+1 queries, authorization and cost controls are harder, and one client query may still trigger many backend calls.

• 5/10Load-balancing algorithms: round-robin (rotate), least-connections (send to the least busy), IP-hash / sticky sessions (same client → same server), weighted (bigger servers get more).
• 5/10L4 vs L7: Layer-4 balances on TCP/IP (fast, dumb); Layer-7 understands HTTP so it can route by path/host/header.
• 5/10Consistent hashing — when nodes change, naive hash(key) % N remaps most keys. Ring- or rendezvous-based hashing reduces movement and is associated with Dynamo-style systems and Cassandra. Redis Cluster instead maps keys to a fixed set of hash slots; understand the goal rather than claiming every product uses the same algorithm.

• 6/10Fixed window — N requests per clock minute. Simple but allows bursts at boundaries.
• 6/10Sliding window — smooths the boundary problem.
• 6/10Token bucket — tokens refill at a steady rate; each request spends one; allows short bursts up to the bucket size. Most common in practice.
• 6/10Leaky bucket — processes at a constant rate, queueing/dropping overflow.
• 7/10ASP.NET Core implementation: register policies with AddRateLimiter and add UseRateLimiter in the pipeline. Built-in policies support fixed/sliding windows, token buckets, and concurrency limits; partition by a trustworthy user, tenant, API key, or address and return 429 with useful retry metadata.

Many .NET roles use Azure, but cloud-product trivia is less important than understanding the underlying compute, storage, messaging, identity, networking, and observability concepts:

• 7/10Compute: App Service (PaaS for web apps), Azure Functions (serverless/event-driven), AKS (Kubernetes).
• 7/10Data: Azure SQL Database (managed relational), Cosmos DB (global NoSQL), Blob Storage (files/assets).
• 7/10Messaging: Service Bus (enterprise queues/topics), Event Grid (pub/sub), Event Hubs.
• 7/10Security: Key Vault (store secrets, connection strings without keeping them in code), Managed Identities (resources authenticate to each other without passwords).

↑ back to top

• 10/10Request/response model — client sends a method + path + headers + optional body; server replies with a status code + headers + body.
• 10/10Methods: GET/HEAD are safe and idempotent; POST processes or creates and is not inherently idempotent; PUT creates/replaces a resource at a known URI and is idempotent; PATCH applies a partial change whose idempotency depends on the patch; DELETE is idempotent by intended effect.
• 10/10Status families: 1xx info, 2xx success, 3xx redirect, 4xx client error, 5xx server error.
• 10/10Headers you should know: Content-Type, Accept, Authorization, Cache-Control, ETag/If-None-Match/If-Match, Location, Retry-After, Set-Cookie, and tracing headers.
• 10/10Idempotency & safety — "safe" = no side effects (GET); "idempotent" = same effect if repeated (GET/PUT/DELETE).

• 6/10HTTP/1.1 — persistent connections are reusable, but there is no practical multiplexing; clients often use several connections and requests can block behind earlier work.
• 6/10HTTP/2 — multiplexes many requests over one connection, header compression, binary framing.
• 6/10HTTP/3 — runs over QUIC (UDP), removes TCP head-of-line blocking, faster connection setup.

A favorite "does he understand the stack" question:

1. 8/10DNS lookup — resolve the domain to an IP (cache → resolver → root → TLD → authoritative).
2. 8/10TCP handshake — SYN, SYN-ACK, ACK establishes a connection (3-way handshake).
3. 8/10TLS handshake — for HTTPS, verify the certificate and establish shared session keys; asymmetric cryptography authenticates/key-agrees, then efficient symmetric encryption protects application traffic.
4. 8/10HTTP request sent; load balancer routes it to an app server.
5. 8/10Server processes (auth, DB, cache) and returns HTML/JSON.
6. 8/10Browser renders; fetches more assets (often via CDN).

• 8/10TCP — reliable, ordered, connection-based (web, DB). UDP — fast, connectionless, may drop packets (video, gaming, DNS).
• 8/10HTTPS/TLS — provides confidentiality, integrity, and server authentication. Certificates bind a public key to a host identity; clients must validate the chain and hostname.
• 8/10Cookies vs tokens: these are not opposites. A cookie is a browser transport/storage mechanism and can contain an opaque session ID or token. A bearer token is an authorization credential and can be sent in a header or cookie. Automatic cookie sending creates CSRF considerations; script-readable token storage creates XSS-exfiltration risk.
• 8/10CORS — a browser-enforced policy controlling which origins may read cross-origin responses. It is not authentication, does not protect server-to-server endpoints, and must not replace authorization.
• 8/10Real-time choices: WebSockets provide full-duplex communication, Server-Sent Events stream server-to-client updates over HTTP, and long polling is the fallback. SignalR abstracts transport selection and connection management.
• 8/10Reverse proxies: TLS termination, compression, request-size limits, forwarded headers, timeouts, and client IP handling often happen before Kestrel. Trust forwarded headers only from known proxies.

↑ back to top

• 7/10Singleton — one shared instance (a cache, config). In .NET, prefer registering it as a DI singleton over a static class.
• 7/10Factory / Factory Method — a method decides which concrete type to create, hiding construction from callers.
• 7/10Builder — construct a complex object step by step (fluent APIs like StringBuilder, query builders).

• 6/10Adapter — wrap an incompatible interface to make it fit (e.g. wrap a third-party SDK behind your own interface).
• 6/10Decorator — add behavior by wrapping (logging/caching layer around a repository). ASP.NET middleware is decorator-like.
• 6/10Facade — a simple front over a complex subsystem.
• 6/10Proxy — stand-in that controls access (lazy loading, caching, access control).

• 7/10Strategy — swap an algorithm at runtime via an interface (different payment/shipping calculators). The Open/Closed principle in action.
• 7/10Observer — publish/subscribe; subscribers react to events (C# events).
• 7/10Template Method — a base class defines the skeleton, subclasses fill in steps.
• 6/10Mediator — objects communicate through a coordinating abstraction. Libraries such as MediatR can implement request/handler dispatch, but using a mediator does not automatically mean the architecture is CQRS.

• 8/10Repository — can provide a domain-focused persistence boundary when it expresses meaningful aggregate operations. EF Core's DbSet and DbContext already provide repository/unit-of-work-like behavior, so a generic CRUD repository often adds indirection and blocks useful query composition.
• 8/10Unit of Work — tracks a set of changes and commits them together; EF Core's DbContext already serves this role.
• 8/10Dependency Injection — supply dependencies from outside (the whole basis of ASP.NET Core).
• 8/10DTO — plain data objects to shape API input/output, decoupled from domain entities.

↑ back to top

• 8/10Validate input at every trust boundary with allow-lists, length/range limits, and request-size limits. Encode output for its destination context; “sanitize everything” is not a substitute for parameterization and output encoding.
• 8/10Principle of least privilege for DB users, services, and tokens.
• 8/10Keep dependencies patched (supply-chain / known-CVE risks).
• 8/10Rate limit and add lockouts to resist brute force.
• 8/10Don't leak stack traces or internal details in error responses.
• 8/10For cookies use HttpOnly, Secure, and an intentional SameSite value; rotate session identifiers after privilege changes and logout.
• 8/10Use ASP.NET Core Data Protection for protected application data and a managed secret store/managed identity for service credentials. Plan key rotation and multi-instance key sharing.
• 8/10Log security-relevant events without logging credentials, access tokens, reset links, or sensitive personal data.
• 8/10Hashing vs encryption: hashing is one-way (passwords); encryption is reversible with a key (data in transit/at rest). Never "encrypt" passwords — hash them.

↑ back to top

• 8/10merge vs rebase: merge preserves history with a merge commit; rebase rewrites your commits on top of the target for a linear history. Don't rebase shared/public branches.
• 8/10Common flow: branch → commit → push → pull request → review → merge. Keep commits small and messages meaningful.
• 8/10Useful commands: git stash (shelve changes), git cherry-pick (grab one commit), git revert (undo a commit safely), git reset (move the branch pointer — careful).
• 8/10Resolving conflicts — Git marks both versions; you pick/merge the correct result and commit.

• 7/10CI (Continuous Integration) — every push builds and runs tests automatically, catching breakage early.
• 7/10CD (Continuous Delivery/Deployment) — automatically ship passing builds to staging/production.
• 7/10Deployment strategies: blue-green (two environments, switch traffic), canary (roll out to a small % first), rolling (replace instances gradually). All aim for zero-downtime and easy rollback.
• 7/10A useful pipeline: restore with a locked dependency graph → compile with warnings treated intentionally → unit/integration tests → security/license scans → build an immutable artifact/image → deploy progressively → smoke/health checks → observe → roll back if needed.
• 7/10Database changes: use backward-compatible expand/migrate/contract steps so old and new app versions can overlap during a rolling deployment.

• 7/10Container — packages the app and runtime dependencies into an isolated process image. It improves repeatability but does not by itself solve configuration, state, networking, or observability.
• 7/10Image vs container — an image is the immutable template; a container is a running instance of it.
• 7/10Docker practices: use multi-stage builds, small supported runtime images, a non-root user, immutable tags/digests, environment/secret injection, and a correct ENTRYPOINT. Write logs to stdout/stderr and handle SIGTERM for graceful shutdown.
• 4/10Kubernetes Role-dependent — orchestrates containers: scheduling, scaling, replacement, service discovery, and rolling updates. Know Pod, Deployment, Service, Ingress/Gateway, ConfigMap/Secret, resource requests/limits, and liveness/readiness/startup probes if the job uses it.
• 7/1012-Factor App — config in the environment, stateless processes, logs as streams, dev/prod parity — principles for cloud-native services.
• 7/10Infrastructure as Code: tools such as Bicep, Terraform, or Pulumi make environments reviewable and repeatable. Keep application configuration separate from secrets.

↑ back to top

Choose one project you know well and prepare a 5–10 minute explanation:

1. 10/10The user/business problem and your exact responsibility.
2. 10/10The request flow: client → API → domain/service → database/external dependency.
3. 10/10Why you chose the architecture and data model; what alternatives you rejected.
4. 10/10Authentication, authorization, validation, error handling, logging, and tests.
5. 10/10One production bug or performance issue, how you diagnosed it, and the measured result.
6. 10/10What you would change with more time. Honest trade-offs are stronger than claiming perfection.

Review in this order: correctness and edge cases → security/authorization → data consistency and transactions → async/cancellation → SQL/EF query shape → error handling/observability → tests → readability. Comment on high-impact issues, explain the consequence, and propose a concrete fix; do not drown the author in style preferences.

• 9/10Clarify requirements and make the smallest complete design; avoid unnecessary microservices, generic repositories, or patterns.
• 9/10Use request/response DTOs, validation, correct status codes, ProblemDetails, cancellation tokens, and async I/O.
• 9/10Use migrations, constraints, deliberate EF queries, and tests that cover behavior and one realistic integration path.
• 9/10Add a short README explaining how to run it, assumptions, trade-offs, and what you would improve—not a novel.
• 9/10Before finishing, run tests, inspect generated SQL/logs, try invalid/unauthorized/concurrent requests, and remove secrets and debug artifacts.

• 8/10What would success look like in the first 90 days?
• 8/10How are architecture decisions made and reviewed?
• 8/10What are the largest reliability or delivery challenges today?
• 8/10How do you test, deploy, observe, and handle on-call incidents?
• 8/10Which .NET versions and cloud/data technologies are actually used?

1. 9/10Big-O of hash lookup? O(1) average, O(n) worst.

   ☆✓ Read
2. 9/10Big-O of binary search? O(log n).

   ☆✓ Read
3. 6/10When is quicksort O(n²)? When pivot choices are consistently poor—for example, always choosing the first item on already sorted input. Randomized/introspective implementations avoid this simple case.

   ☆✓ Read
4. 5/10Which sorts are stable? Merge sort, insertion sort.

   ☆✓ Read
5. 8/10Array vs linked list trade-off? Array: O(1) index; list: O(1) insert at node.

   ☆✓ Read
6. 8/10Stack vs queue? LIFO vs FIFO.

   ☆✓ Read
7. 7/10BFS data structure? Queue. DFS? Stack/recursion.

   ☆✓ Read
8. 5/10Shortest path unweighted? BFS. Weighted? Dijkstra.

   ☆✓ Read
9. 6/10Detect a cycle in a list? Fast/slow pointers.

   ☆✓ Read
10. 6/10What is memoization? Caching subproblem results in recursion.

    ☆✓ Read
11. 5/10DP vs greedy? DP explores optimal substructure; greedy takes local best.

    ☆✓ Read
12. 6/10In-order traversal of a BST yields? Sorted order.

    ☆✓ Read
13. 6/10Heap gives you? Min/max in O(1), insert/remove O(log n).

    ☆✓ Read
14. 7/10Two-pointer use case? Sorted-array pair sums, palindromes.

    ☆✓ Read
15. 7/10Sliding window use case? Longest/shortest contiguous subarray.

    ☆✓ Read
16. 9/10Hash set solves? Dedup / "seen before" in O(1).

    ☆✓ Read
17. 5/10Topological sort needs? A DAG (no cycles).

    ☆✓ Read
18. 7/10Space complexity of recursion depth d? O(d) stack.

    ☆✓ Read

1. 10/10Value vs reference type? Assignment copies the value data vs copies a reference to the same object; storage location is not the definition.

   ☆✓ Read
2. 8/10Why is string immutable? Its value cannot change after creation, enabling safe sharing, stable hashing, and interning of eligible strings such as literals.

   ☆✓ Read
3. 7/10StringBuilder when? Many concatenations in a loop.

   ☆✓ Read
4. 9/10IEnumerable vs IQueryable? IEnumerable<T> enumerates values using .NET operators; IQueryable<T> builds expression trees a provider may translate, commonly to SQL.

   ☆✓ Read
5. 9/10Deferred execution? LINQ runs when enumerated.

   ☆✓ Read
6. 10/10Task vs Thread? A Task represents an operation/result; it may have no dedicated thread. A Thread is an OS execution resource.

   ☆✓ Read
7. 10/10Why not block on async? It wastes ThreadPool threads and can cause starvation; classic context deadlocks are not the default ASP.NET Core explanation.

   ☆✓ Read
8. 10/10DI lifetimes? Transient, scoped, singleton.

   ☆✓ Read
9. 9/10DbContext lifetime? Scoped; not thread-safe.

   ☆✓ Read
10. 9/10abstract class vs interface? Shared base identity/state vs a multi-implementable contract; modern interfaces may include default members.

    ☆✓ Read
11. 8/10override vs new? Override = runtime polymorphic dispatch; new = hides the base method, chosen by the reference's compile-time type.

    ☆✓ Read
12. 8/10protected internal vs private protected? Subclasses OR same assembly vs subclasses AND same assembly.

    ☆✓ Read
13. 6/10What does sealed do? Blocks inheritance (class) or further overriding (member).

    ☆✓ Read
14. 8/10What is boxing? Copying a value type into an object or interface representation, normally allocating a boxed object.

    ☆✓ Read
15. 7/10const vs readonly? Compile-time vs runtime.

    ☆✓ Read
16. 9/10record vs class? Records provide value-based equality by default; they are not automatically immutable.

    ☆✓ Read
17. 7/10yield return? Lazy iterator.

    ☆✓ Read
18. 8/10What is a closure? Lambda capturing outer variables.

    ☆✓ Read
19. 8/10GC generations? 0 (young), 1, 2 (old), LOH.

    ☆✓ Read
20. 7/10Workstation vs Server GC? Server GC (ASP.NET Core default) trades memory for throughput with per-core heaps; Workstation favors footprint.

    ☆✓ Read
21. 9/10GC vs Dispose? GC reclaims managed memory; Dispose releases scarce resources deterministically.

    ☆✓ Read
22. 9/10What does using guarantee? Dispose runs even on exception.

    ☆✓ Read
23. 10/10Middleware order matters? Yes—exception handling early; routing before conventional authentication/authorization; authentication before authorization.

    ☆✓ Read
24. 8/10Func vs Action? Returns a value vs void.

    ☆✓ Read
25. 8/10What do CLR, IL, and JIT do? C# compiles to IL/metadata; CLR loads/manages it; JIT compiles executed methods to native code.

    ☆✓ Read
26. 9/10throw; vs throw ex;? throw; preserves the original stack trace.

    ☆✓ Read
27. 9/10Why avoid async void? Callers cannot await completion or observe exceptions; reserve it for event handlers.

    ☆✓ Read
28. 9/10When use Task.WhenAll? For independent async work, with bounded fan-out.

    ☆✓ Read
29. 10/10What is cancellation? Cooperative signaling through CancellationToken; propagate it to I/O.

    ☆✓ Read
30. 9/10Why IHttpClientFactory? Handler/connection reuse, DNS refresh, typed configuration, and resilience.

    ☆✓ Read
31. 8/10What is ProblemDetails? A standardized machine-readable API error shape.

    ☆✓ Read
32. 10/10Authentication vs authorization? Establish identity vs decide permission.

    ☆✓ Read
33. 8/10Controllers vs Minimal APIs? Both are valid; choose based on conventions and complexity.

    ☆✓ Read
34. 8/10How test the real ASP.NET Core pipeline? WebApplicationFactory<Program> integration tests.

    ☆✓ Read
35. 5/10What are keyed DI services? Named/keyed registrations for choosing among multiple implementations of one service contract.

    ☆✓ Read
36. 7/10How do you enable built-in rate limiting? Register policies with AddRateLimiter, call UseRateLimiter, and partition by a trustworthy client identity.

    ☆✓ Read
37. 7/10Output caching vs data caching? Output caching reuses a complete HTTP response; data caching reuses an internal value used to build a response.

    ☆✓ Read
38. 5/10What is System.Threading.Channels for? Bounded asynchronous producer/consumer queues inside one process, including backpressure.

    ☆✓ Read

1. 9/10WHERE vs HAVING? Rows before grouping vs groups after.

   ☆✓ Read
2. 10/10INNER vs LEFT JOIN? Matches only vs all-left + NULLs.

   ☆✓ Read
3. 10/10What is an index? An access structure, often a B-tree, that can reduce pages scanned; benefit depends on selectivity and query shape.

   ☆✓ Read
4. 9/10Index downside? Slower writes, storage.

   ☆✓ Read
5. 8/10Clustered vs non-clustered in SQL Server? Rows are organized by one clustered key vs separate index structures that locate rows.

   ☆✓ Read
6. 10/10ACID? Atomicity, Consistency, Isolation, Durability.

   ☆✓ Read
7. 10/10N+1 problem & fix? One parent query plus per-row queries; prefer projection or deliberate eager/split loading.

   ☆✓ Read
8. 8/10Normalization goal? Remove redundancy.

   ☆✓ Read
9. 7/10When denormalize? Read-heavy performance.

   ☆✓ Read
10. 7/10SQL vs NoSQL? Choose by data relationships, invariants, query/access patterns, consistency, and operations—not a slogan about scale.

    ☆✓ Read
11. 8/10Window function vs GROUP BY? Keeps rows vs collapses them.

    ☆✓ Read
12. 8/10Optimistic vs pessimistic locking? Version-check vs lock upfront.

    ☆✓ Read
13. 8/10What causes a deadlock? Opposite lock ordering.

    ☆✓ Read
14. 9/10Transaction isolation levels? Read Uncommitted → Serializable.

    ☆✓ Read
15. 6/10EXISTS vs IN? Choose semantics first; modern optimizers may produce the same plan, while NULL behavior can differ.

    ☆✓ Read
16. 7/10Read replica purpose? Scale reads; eventual consistency.

    ☆✓ Read
17. 6/10Sharding? Split data across DBs by key.

    ☆✓ Read
18. 10/10Fix a slow query? Index, plan, select fewer cols, avoid N+1.

    ☆✓ Read
19. 9/10When use AsNoTracking? Read-only entity queries that do not need change tracking; projection may be better.

    ☆✓ Read
20. 6/10When consider DbContext pooling? After measuring context setup overhead in a high-throughput service; pooled contexts must not retain request-specific mutable state.

    ☆✓ Read
21. 10/10When does an EF query execute? On enumeration or terminal operations such as ToListAsync/FirstAsync.

    ☆✓ Read
22. 7/10Bulk update without loading entities? ExecuteUpdateAsync/ExecuteDeleteAsync (EF Core 7+); they bypass change tracking and run immediately.

    ☆✓ Read
23. 9/10Why use projection? Fetch only required columns and avoid unnecessary entities/tracking.

    ☆✓ Read
24. 8/10What is cartesian explosion? Large duplicated result sets caused by joining multiple collection navigations.

    ☆✓ Read
25. 8/10What is SARGability? Writing predicates an index can seek on.

    ☆✓ Read
26. 8/10NULL = NULL? Unknown, not true; use IS NULL.

    ☆✓ Read
27. 7/10UNION vs UNION ALL? Deduplicates vs keeps all rows and is usually cheaper.

    ☆✓ Read

1. 8/10Stateless server benefit? Any server handles any request → scale.

   ☆✓ Read
2. 7/10Vertical vs horizontal scaling? Bigger box vs more boxes.

   ☆✓ Read
3. 8/10Cache-aside pattern? Check cache → miss → DB → populate.

   ☆✓ Read
4. 8/10Hard part of caching? Invalidation / staleness.

   ☆✓ Read
5. 8/10Why a message queue? Async work, decoupling, spike absorption.

   ☆✓ Read
6. 8/10At-least-once delivery needs? Idempotent consumers.

   ☆✓ Read
7. 9/10What must an API validate in a JWT? Allowed algorithm, signature, issuer, audience, lifetime, and required claims.

   ☆✓ Read
8. 10/10401 vs 403? Not authenticated vs not allowed.

   ☆✓ Read
9. 10/10200 vs 201 vs 204? OK vs Created vs No Content.

   ☆✓ Read
10. 9/10Which HTTP methods are idempotent by specification? GET, HEAD, PUT, DELETE, OPTIONS, and TRACE; POST and PATCH are not guaranteed to be idempotent.

    ☆✓ Read
11. 7/10CAP theorem? During a network partition, an operation cannot guarantee both linearizable consistency and a non-error response from every node.

    ☆✓ Read
12. 7/10Strong vs eventual consistency? Latest read vs converges over time.

    ☆✓ Read
13. 8/10TCP vs UDP? Reliable/ordered vs fast/lossy.

    ☆✓ Read
14. 8/10What is CORS? Browser cross-origin permission via headers.

    ☆✓ Read
15. 5/10Consistent hashing solves? Minimal remap when nodes change.

    ☆✓ Read
16. 7/10Circuit breaker does? Stops calling a failing dependency.

    ☆✓ Read
17. 5/10Load balancer algorithms? Round-robin, least-conn, IP-hash.

    ☆✓ Read
18. 8/10Monolith vs microservices? Simple vs independently scalable+complex.

    ☆✓ Read
19. 10/10Prevent SQL injection? Parameterized queries.

    ☆✓ Read
20. 8/10Prevent XSS? Encode output, CSP.

    ☆✓ Read
21. 10/10Store passwords how? Use a maintained adaptive salted password hasher such as ASP.NET Core Identity—not custom crypto.

    ☆✓ Read
22. 8/10Hashing vs encryption? One-way vs reversible with key.

    ☆✓ Read
23. 6/10Blue-green deployment? Two envs, switch traffic, easy rollback.

    ☆✓ Read
24. 7/10Container vs VM? Shares kernel (light) vs full OS (heavy).

    ☆✓ Read
25. 6/10Rate limiter algorithm? Token bucket (allows bursts).

    ☆✓ Read
26. 9/10OAuth 2.0 vs OIDC? Delegated authorization vs authentication/identity on top of OAuth.

    ☆✓ Read
27. 7/10Why PKCE? Protect authorization-code flow for public clients from intercepted codes.

    ☆✓ Read
28. 8/10Cookie security flags? HttpOnly, Secure, and intentional SameSite.

    ☆✓ Read
29. 8/10When is CSRF relevant? When credentials such as cookies are attached automatically to cross-site requests.

    ☆✓ Read
30. 6/10What is SSRF? Attacker causes the server to request restricted/internal destinations.

    ☆✓ Read
31. 7/10What is a cache stampede? Many misses rebuild the same value simultaneously.

    ☆✓ Read
32. 7/10SLI vs SLO vs SLA? Measurement vs target vs external commitment.

    ☆✓ Read
33. 6/10RTO vs RPO? Recovery-time target vs acceptable data-loss window.

    ☆✓ Read
34. 7/10Why the outbox pattern? Atomically save business data and a message-to-publish in one database transaction.

    ☆✓ Read
35. 8/10What is backpressure? Limiting producers/concurrency so slow consumers do not exhaust resources.

    ☆✓ Read

1. 9/10First step in an incident? Define impact and stabilize the system before deep diagnosis.

   ☆✓ Read
2. 9/10How investigate latency? Start with p95/p99 and traces, then check ThreadPool/CPU, SQL, pools, dependencies, payloads, and GC.

   ☆✓ Read
3. 8/10How investigate memory growth? Measure managed/native memory and compare heap snapshots for retained roots and unbounded structures.

   ☆✓ Read
4. 8/10Code-review priority? Correctness/security/data consistency before style.

   ☆✓ Read
5. 9/10What makes a strong take-home? Small complete design, correct contracts, tests, migrations, errors, security, and documented trade-offs.

   ☆✓ Read
6. 10/10What should a project story contain? Problem, your role, architecture, trade-offs, failure/debugging story, result, and improvements.

   ☆✓ Read