yoklainterview sim

Backend Csharp Stdlib Http Interview Questions

75 verified Backend Csharp Stdlib Http interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Csharp Stdlib HttpDifficulty 1
var names = new List<string>();
names.Add("ada");
names.Add("grace");
names.Add("ada");

Console.WriteLine(names.Count);

What is printed?
  • a2, because List<T> silently removes duplicate values when Add is called.
  • b3, because List<T> allows duplicate elements and Count simply reflects how many items were added.
  • cIt throws an exception, because Add cannot insert a value that already exists in the list, the same way HashSet<T>.Add enforces uniqueness.
  • d0, because Count is only updated after the list is explicitly sorted.
Explanation:List<T> is an ordered, index-based collection that permits duplicate values — it does not perform any uniqueness check on Add. Each of the three Add calls appends a new element regardless of whether an equal value already exists, so Count reflects the total number of Add calls: 3. Uniqueness enforcement is a HashSet<T> behavior, not a List<T> one.
Csharp Stdlib HttpDifficulty 2
var ages = new Dictionary<string, int>();
ages["ada"] = 30;

Console.WriteLine(ages["grace"]);

What happens when this runs?
  • aIt prints 0, because Dictionary<K,V>'s indexer always returns the default value of V for any key that is not currently present.
  • bIt prints an empty string, because the indexer falls back to a blank result for missing keys.
  • cIt throws a KeyNotFoundException at runtime, because the indexer requires the key to already exist in the dictionary.
  • dIt automatically adds "grace" with value 0 and then prints 0.
Explanation:The Dictionary<K,V> indexer getter (ages["grace"]) throws a KeyNotFoundException when the requested key is not present — it does not return a default value or silently create an entry. To read a possibly-missing key without an exception, use TryGetValue or ContainsKey first; the indexer is only safe to read when the key's presence is already guaranteed. Note that the indexer setter (ages["ada"] = 30) does add-or-update, but the getter has no such fallback.
Csharp Stdlib HttpDifficulty 1
var tags = new HashSet<string>();
bool first = tags.Add("go");
bool second = tags.Add("go");

Console.WriteLine($"{first} {second} {tags.Count}");

What is printed?
  • aTrue False 1, because HashSet<T>.Add returns false and skips insertion when an equal element already exists.
  • bTrue True 2, because HashSet<T> allows the same value to be added twice, just like List<T>.
  • cIt throws an exception on the second Add call, because HashSet<T> forbids re-adding a value that already exists.
  • dFalse False 0, because Add always returns false the first time a set is empty.
Explanation:HashSet<T> enforces uniqueness: Add returns true and inserts the element only if it is not already present, and returns false without modifying the set if an equal element already exists. Here the first Add("go") succeeds (true, count becomes 1), and the second Add("go") finds "go" already in the set, so it returns false without throwing and without increasing Count.
Csharp Stdlib HttpDifficulty 2
var scores = new List<int> { 10, 20, 30 };
Console.WriteLine(scores[3]);

What happens?
  • aIt prints 0, because List<T> silently returns the default value of the element type whenever the given index is out of range.
  • bIt prints 30, because the indexer clamps the requested index to the last valid position.
  • cIt silently extends the list with a new default element and prints that new element's value.
  • dIt throws an ArgumentOutOfRangeException, because index 3 is outside the valid range 0..2 for a 3-element list.
Explanation:scores has three elements at indices 0, 1, and 2. List<T>'s indexer performs bounds checking and throws an ArgumentOutOfRangeException when the requested index is negative or greater than or equal to Count — it never clamps, returns a default value, or auto-grows the list on a read. To grow a list you must call Add/Insert explicitly.
Csharp Stdlib HttpDifficulty 2
You iterate a Dictionary<string, int> with foreach right after inserting several keys in a specific order. Which statement about the iteration order is correct?
  • aDictionary<K,V> always iterates keys in the exact order they were inserted, just like List<T>.
  • bDictionary<K,V> does not guarantee any particular iteration order, and code should not rely on insertion order or any other specific ordering.
  • cDictionary<K,V> always iterates keys sorted alphabetically by their string representation.
  • dDictionary<K,V> iterates keys in a random order that changes on every single enumeration, even within the exact same unmodified instance and process.
Explanation:Dictionary<K,V> is a hash-based collection: its enumeration order depends on internal bucket layout, which is an implementation detail that can change across .NET versions, after resizes, or after removals. In practice it often appears close to insertion order for small dictionaries with no removals, but this is not a documented guarantee, so code must never depend on it — if a specific order is required, use a SortedDictionary<K,V> or explicitly sort with LINQ's OrderBy.
Csharp Stdlib HttpDifficulty 3
var numbers = new List<int> { 1, 2, 3 };
var query = numbers.Where(n => n > 1);

numbers.Add(4);

foreach (var n in query)
    Console.Write(n + " ");

What is printed?
  • a2 3 4 , because Where returns a deferred sequence that re-reads the source list at the moment it is enumerated, after Add(4) already happened.
  • b2 3 , because Where captures a snapshot of the list's contents at the moment it is called, before the Add(4) happens.
  • cIt throws an InvalidOperationException, because the list was modified after Where was called on it.
  • d1 2 3 4 , because Where only filters elements the first time the query is enumerated and ignores the predicate afterward.
Explanation:LINQ's Where does not execute immediately — it returns an IEnumerable<T> that captures the query logic and the source reference, but only walks the source when something actually enumerates it (here, the foreach). Since Add(4) happens before the foreach starts pulling elements, the query sees the list's state at enumeration time, including the newly added 4, and filters it with n > 1: 2, 3, 4. This is the deferred execution trap — modifying the same List<T> the query reads from does not throw here because the modification happens before enumeration begins, not during it.

Test yourself against the 3300-question Backend bank.

Start interview