Four Free Tools I Built for My Next Senior .NET Interview

I built these four sites for myself so the next time I prepare for a Senior .NET interview, I won't have to start from zero.

That was the original goal: give future me a place to return to. Somewhere to organize my experience, revisit backend fundamentals, work through system design decisions, and go deeper into concurrency.

At some point I realized the same tools might be useful to other developers. So I'm sharing them freely. Everything is free to use, and no account is needed.

The common thread is being able to explain a decision. Which constraint mattered? What alternative did you consider? What happens when the happy path breaks? Those are the questions I want my preparation to help me answer.

CV Creator provides a structured editor for experience, projects, technical skills, and other CV sections, with a live preview, template and style controls, and PDF export. The interface indicates that your CV stays in the browser.

The part I care about most is the thinking that happens while writing. A list of technologies tells someone what you touched. A concrete description helps them understand what you contributed.

For example, here's a hypothetical rewrite of a project bullet:

• Vague: Worked on backend services using C# and SQL.
• Specific: Investigated a slow reporting endpoint, identified repeated database queries, and changed the data-access path to fetch the required data in fewer round trips.

That second version gives an interviewer something useful to explore: how the problem was diagnosed, what changed, and how the result was verified. Add measured impact when you have it, and be precise about your own contribution.

Writing the CV also creates a study plan. Every claim on the page is a topic I should be ready to discuss beyond the first follow-up question.

Senior .NET Interview Prep brings together guided lessons, question libraries, interview drills, coding challenges, and DSA patterns. It also includes a story workshop, home-assignment material, and an interview log.

The learning path covers C# and .NET, data access, system design, and maintainable architecture. That gives me a broad entry point before choosing where to spend more time.

A useful practice question should lead to a chain of reasoning. For a slow endpoint, I would want to discuss what I would measure first, whether the bottleneck is in the application or database, what an execution plan might reveal, and which change I would test.

I can then change the constraints: what if the result set grows significantly, the endpoint needs pagination, or caching introduces an unacceptable freshness delay? The follow-up is where a memorized answer often runs out.

My intended routine is simple: attempt the answer before reading the explanation, say the reasoning aloud, and record the part I couldn't defend. That gives the next study session a specific target.

Distributed Systems and DDIA is a study companion for Designing Data-Intensive Applications. Its curriculum moves through data models, storage, replication, partitioning, transactions, distributed systems, and stream processing, then brings those ideas together in a system design capstone.

The site includes C# and SQL examples, labs, recall questions, and interview practice. Chapter references follow the first edition of Martin Kleppmann's book; the companion is intended to be used alongside your own copy.

For preparation, I want to be able to trace what happens to a piece of data. Where is a write committed? When can a reader see it? Which component owns a retry? What can the caller conclude if the response never arrives?

Consider an order API that times out after sending a request to a downstream service. The timeout alone doesn't tell the caller whether the operation took effect. Retrying an operation with side effects can duplicate the effect unless the design makes repetition safe. Microsoft's retry pattern guidance discusses this idempotency concern.

That's a useful interview exercise: start with a normal request, introduce one failure, and explain what evidence each component actually has. Then choose the guarantee the product needs and account for its cost.

.NET Concurrency focuses on Tasks, Channels, Observables, reliability, and their integration. It includes C# examples and an interactive exercise for exploring what happens when a bounded channel fills up.

The distinctions matter: a task represents an operation's completion; a channel coordinates queued work between producers and consumers; an observable exposes notifications. Understanding each contract makes it easier to reason about a pipeline assembled from them.

Here's a small configuration worth practicing aloud:

using System.Threading.Channels;

var queue = Channel.CreateBounded<string>(
    new BoundedChannelOptions(capacity: 256)
    {
        FullMode = BoundedChannelFullMode.Wait,
        SingleWriter = true,
        SingleReader = false
    });

This configures a buffer for up to 256 items, promises only one concurrent writer, and permits multiple readers. With Wait mode, a producer using WriteAsync waits asynchronously when the buffer is full. The producer must await the write for that wait to pace admission. See the Microsoft Channels documentation for the options and full-mode behavior.

The snippet only configures the queue. An application still needs producers, consumers, cancellation, completion ownership, and failure handling. It also needs a clear durability boundary: an in-memory channel cannot preserve queued work across a process crash.

Those are the follow-ups I want to rehearse. Who observes a failed worker? How are blocked producers released? Does shutdown drain accepted work? When can the caller be told that an operation succeeded?

Imagine preparing to discuss an order-processing service. I would use that one scenario across all four sites.

1. CV Creator: Describe a relevant project from my actual experience, including my contribution and evidence of the result.
2. Interview Prep: Practice explaining the API, data-access choices, and testing approach.
3. DDIA: Introduce duplicate requests, a lost response, or a database-to-broker delivery gap, and work through the consistency and recovery requirements.
4. Concurrency: Examine the worker implementation: queue capacity, processing concurrency, cancellation, and shutdown.

A rough overload calculation helps make the discussion concrete. If arrivals average 1,000 items per second while workers finish 800, unfinished work grows by roughly 200 items per second. A ten-second burst adds about 2,000 items of backlog, assuming those rates hold and admission continues. A larger buffer can absorb a temporary burst; a sustained mismatch requires a decision about capacity, admission, or allowed loss.

Then change one assumption: the process can restart at any moment. Now an in-memory buffer is insufficient for work that must survive restart. The discussion needs to include durable acceptance and safe redelivery.

This is the kind of preparation I want to keep: a scenario, the assumptions behind it, and the questions that expose gaps in my understanding.

These sites give me a reusable base for my next round of preparation. I can return to a weak topic, practice an explanation, or update my CV without rebuilding the whole process.

If you're preparing for a .NET or backend interview, start with whichever part you need most:

• Build your CV
• Practice for a Senior .NET interview
• Study distributed systems and DDIA
• Explore .NET concurrency

All four are free to use. No account needed. I built them for myself, and I hope they help you too.