Think about a professional athlete before a championship game. They don't just wake up and walk onto the field. They do scrimmages. A scrimmage isn't a real game—there are no fans and no trophies on the line—but it's played at full speed, with a clock running and a coach shouting directions. If they make a mistake during a scrimmage, it's a learning moment; if they make it during the game, it's a disaster.

That's exactly what this mock assessment is. Up until now, you've been learning C# in "practice mode," where you can pause, google a syntax error for twenty minutes, or rewrite a method five times until it works. In a real technical interview or a high-stakes project deadline, you don't have that luxury. We're moving from "knowing the material" to "performing the material."

The Psychology of the Timer

I've interviewed dozens of candidates who knew their way around LINQ and async/await, but they completely froze the moment I started a timer. Why? Because the clock changes how your brain processes problems. You stop thinking about the most elegant architectural pattern and start panic-coding the first thing that comes to mind.

By forcing yourself to complete these tasks under a time limit, you're training your "muscle memory." You want the act of writing a try-catch-finally block or implementing an IEnumerable to be automatic, so your brain can spend its energy on the actual logic of the problem, not the syntax of the language.

What I'm Looking For in Your Code

When you're reviewing your results, don't just check if the code compiles. That's the bare minimum. As someone who has reviewed thousands of pull requests, I'm looking for a few specific "senior" markers in your Core C# implementation:

• Type Safety: Did you use var appropriately, or did you over-use dynamic or object where a generic T would have been safer?
• Resource Management: If you're handling files or database connections, did you use the using statement? If I see a leaked StreamReader, it's a red flag.
• LINQ Efficiency: Are you calling .ToList() too early in your query chain? Remember, we want to keep things deferred as long as possible to avoid unnecessary memory allocations.
• Async Integrity: Did you "async all the way down," or did you commit the cardinal sin of using .Result or .Wait() on a Task?

Dealing with the "Blank Page" Panic

If you hit a wall during this assessment, don't just stare at the screen. That's where the clock eats you alive. I always recommend the "Pseudo-code Pivot." If you can't remember the exact method signature for a ConcurrentDictionary, just write // TODO: Use a thread-safe dictionary here to store user IDs and keep moving. Get the logic down first. You can fix the syntax in the final five minutes if you have time. I'd much rather see a complete logical flow with a few syntax errors than a perfectly written first paragraph and a blank screen for the rest of the problem.

📋 Practical Task

The Core C# Proficiency Gauntlet

Instructions: Set a timer for 90 minutes. Do not use external IDE autocomplete or AI assistants. You may refer to the official Microsoft documentation if absolutely necessary, but try to rely on your memory first. Implement the following three requirements in a single console application.

// Requirement 1: The Generic Data Processor
// Create a generic class 'DataVault<T>' that stores a list of items.
// Implement a method 'FilterData(Func<T, bool> predicate)' that returns 
// only the items matching the condition using a LINQ expression.

// Requirement 2: The Async Resource Fetcher
// Create a service that simulates fetching data from an API.
// It must use 'Task.WhenAll' to fetch three different strings 
// (e.g., "User Profile", "User Settings", "User Posts") concurrently.
// Ensure the entire operation is wrapped in a try-catch block to handle 
// a simulated 'HttpRequestException'.

// Requirement 3: The Custom Exception Pipeline
// Define a custom exception 'InvalidTransactionException'.
// Write a method that processes a decimal amount; if the amount is negative, 
// throw the custom exception. 
// Implement a global handler in Main to catch this specific exception 
// and print a formatted error message to the console.

Success Criteria:

• The code compiles without errors.
• The DataVault is truly generic and not tied to a specific type.
• The API fetcher does not block the main thread (no .Result or .Wait()).
• The custom exception is caught specifically, not via a generic catch(Exception ex).