Glen Thomas

Software / Platform Engineer

12 minute read Software Engineering

Coding interviews can feel like a mix between a logic puzzle and a high-speed performance test.
The interviewer is watching how you think, how you communicate, and whether you can collaborate under pressure.

In this post, I’ll walk you through:

  • What to expect in a typical coding interview
  • How to approach problems in a way that stands out
  • Several realistic practice tasks (with full C# solutions)
  • Commentary on the thought process and trade-offs

Whether you’re aiming for a Senior Engineer role or your first dev job, these strategies will help you shine.

What Happens in a Coding Interview

Most coding interviews follow a familiar pattern:

  1. Problem introduction The interviewer explains a challenge — often intentionally vague.
    Your job is to clarify, rephrase, and set scope.

  2. Collaborative problem solving You think out loud, explore options, and design a solution before coding.

  3. Implementation You write working code that meets the requirements and handles edge cases.

  4. Testing and debugging You verify your solution with examples, spot issues, and fix them in real time.

  5. Optimisation & discussion You discuss complexity, trade-offs, and possible improvements.

Remember:
They’re not just grading the final code — they’re evaluating how you get there.

How to Approach the Interview

Here’s my formula for tackling any problem under interview pressure:

  1. Restate the Problem

    “So if I understand correctly, we need to…”

    • Shows active listening
    • Confirms you’re on the same page
  2. Ask Clarifying Questions
    • Input size limits?
    • Can inputs be null or empty?
    • Is order important?
    • Are there performance constraints?
  3. Choose the Right Data Structure
    • Dictionary for fast lookups
    • Stack for LIFO problems
    • Queue for BFS/level-order traversal
    • LinkedList for quick insert/remove in the middle
    • HashSet for fast membership checks and eliminating duplicates
  4. Solve in Steps
    • Start with a brute force version
    • Then refine to a more efficient approach
  5. Test as You Go
    • Use small, easy test cases
    • Print intermediate steps to debug
  6. Communicate Trade-offs
    • Performance vs. memory
    • Readability vs. complexity

Example 1: Stack-Based Undo Feature

We’ll start with an easy example that uses basic data structures and no complex algorithms.

Scenario:

CodeX is building a rich text editor for its document editing tool, and they want to support undo/redo functionality for user input. You’re asked to prototype the core logic.

Implement a TextEditor class with basic editing and undo/redo support.

public class TextEditor
{
    public void Type(string text);  // Appends text
    public void Delete(int count);  // Deletes last N characters
    public void Undo();             // Reverts the last action
    public void Redo();             // Re-applies an undone action
    public string GetContent();     // Returns current editor content
}
  • Only two operations can be undone/redone: Type and Delete
  • Undo reverses the last operation (whether it was typing or deleting)
  • Redo re-applies the last undone operation
  • Typing or deleting after an undo clears the redo history (just like most editors)

Approach:

Take your time to read through the scenario and then restate the problem. Ask questions if anything is not clear.

💡 Tip: Explain what you are doing and what you are thinking at all times. Good communication throughout is essential.

Begin the code by writing a simple test case for the smallest piece of deliverable functionality.

public class TextEditorTests
{
    [Fact]
    public void TypeShouldAppendTextToContent()
    {
        TextEditor textEditor = new();
        textEditor.Type("Hello");
        textEditor.Type(" ");
        textEditor.Type("world");

        var result = textEditor.GetContent();

        Assert.Equal("Hello world", result);
    }
}

Add the TextEditor class with required methods, but throw NotImplementedException.

public class TextEditor
{
    public void Type(string text)
    {
        throw new NotImplementedException();
    }

    public string GetContent()
    {
        throw new NotImplementedException();
    }
}

Run the test to demonstrate that it fails. This is of course expected, but a good engineer wants to ensure that the test does not pass before the feature has been implemented, otherwise we may have an invalid test.

Now implement the functionality to make the test past in the simplest way possible. Don’t try to over-engineer at this stage.

public class TextEditor
{
    private readonly StringBuilder content = new();

    public void Type(string text)
    {
        content.Append(text);
    }

    public string GetContent()
    {
        return content.ToString();
    }
}

Now run the test again and see the result has changed to a pass!

Next it’s time to deliver another slice of functionality - Delete. But first we should create a new test.

[Fact]
public void DeleteShouldRemoveTextFromContent()
{
    TextEditor textEditor = new();
    textEditor.Type("Hello");
    textEditor.Type(" ");
    textEditor.Type("world");
    textEditor.Delete(6);

    var result = textEditor.GetContent();

    Assert.Equal("Hello", result);
}

Add the Deleted method, throwing NotImplementedException.

public void Delete(int count)
{
    throw new NotImplementedException();
}

Run the tests again and the previous test should pass while the new one fails.

Then implement the minimum functionality to make the new test pass.

public void Delete(int count)
{
    content.Remove(content.Length - count, count);
}

And then run the test again to see that both tests are now passing.

At this stage you could earn some bonus points by pointing out some possible edge cases that are not covered, like an invalid character count argument for the Delete method. Add a new test to validate the expected failure.

[Fact]
public void DeleteShouldThrowArgumentExceptionForNegativeCount()
{
    TextEditor textEditor = new();
    textEditor.Type("Hello");
    
    Assert.Throws<ArgumentException>(() => textEditor.Delete(-6), "count");
}

Add a guard clause to the Delete method to handle the invalid argument.

public void Delete(int count)
{
    if (count < 0)
    {
        throw new ArgumentException("Cannot delete negative character count", "count");
    }

    content.Remove(content.Length - count, count);
}

Run the test and see that is passes.

Now it’s time to implement the Undo functionality. We will start with undo support for Type. Create a new unit test for the Undo method.

[Fact]
public void UndoTypeShouldRemoveTextFromContent()
{
    TextEditor textEditor = new();
    textEditor.Type("Hello");
    textEditor.Type(" ");
    textEditor.Type("world");
    textEditor.Undo();
    textEditor.Undo();
    
    var result = textEditor.GetContent();

    Assert.Equal("Hello", result);
}

Add the Undo method.

public void Undo()
{
    throw new NotImplementedException();
}

Don’t forget to run all of the tests to ensure that the current implementation results in the expected failure.

Then implement the undo functionality. A TypeAction class is used to store the required data for the action to be undone. To manage the action history we use a Stack<TypeAction> data structure to store the actions that have occurred. Stacks are perfect for Last-In, First-Out (LIFO) history. The Type method pushes the TypeAction onto the stack, and the Undo method pops the TypeAction from the stack and uses it to undo the last change.

public class TextEditor
{
    private readonly StringBuilder content = new();
    private readonly Stack<TypeAction> undoStack = new();

    public void Type(string text)
    {
        content.Append(text);
        undoStack.push(new TypeAction(text));
    }

    public void Delete(int count)
    {
        if (count < 0)
        {
            throw new ArgumentException("Cannot delete negative character count", "count");
        }

        content.Remove(content.Length - count, count);
    }

    public void Undo()
    {
        if (undoStack.Count == 0) return;

        var lastAction = undoStack.pop();
        lastAction.Undo(content);
    }

    public string GetContent()
    {
        return content.ToString();
    }
}

public class TypeAction
{
    public TypeAction(string text)
    {
        this.text = text;
    }

    public void Undo(StringBuilder content)
    {
        content.Remove(content.Length - text.Length, text.Length);
    }
}

Now when we run the tests again, UndoTypeShouldRemoveTextFromContent should result in success.

Next we can implement the Redo functionality for the Type action. First, add a unit test.

[Fact]
public void RedoTypeShouldAddRemovedTextToContent()
{
    TextEditor textEditor = new();
    textEditor.Type("Hello");
    textEditor.Type(" ");
    textEditor.Type("world");
    textEditor.Undo();
    textEditor.Redo();
    
    var result = textEditor.GetContent();

    Assert.Equal("Hello world", result);
}

Add the Redo method to TextEditor.

public void Redo()
{
    throw new NotImplementedException();
}

Run the test to observe the fail status.

Then update the TextEditor. Add a new Stack<TypeAction> for redo actions. Update the Undo method to push the undone action onto the redoStack. Update the Redo method to pop the last action from the redoStack and use it to redo the last action. Update the Type method to clear the redoStack, because the scenario specified that “Typing or deleting after an undo clears the redo history”.

public class TextEditor
{
    private readonly StringBuilder content = new();
    private readonly Stack<TypeAction> undoStack = new();
    private readonly Stack<TypeAction> redoStack = new();

    public void Type(string text)
    {
        content.Append(text);
        undoStack.push(new TypeAction(text));
        redoStack.clear();
    }

    public void Delete(int count)
    {
        if (count < 0)
        {
            throw new ArgumentException("Cannot delete negative character count", "count");
        }

        content.Remove(content.Length - count, count);
    }

    public void Undo()
    {
        if (undoStack.Count == 0) return;

        var lastAction = undoStack.pop();
        lastAction.Undo(content);
        redoStack.push();
    }

    public void Redo()
    {
        if (redoStack.Count == 0) return;

        var lastAction = redoStack.pop();
        lastAction.Redo(content);
    }

    public string GetContent()
    {
        return content.ToString();
    }
}

public class TypeAction
{
    public TypeAction(string text)
    {
        this.text = text;
    }

    public void Undo(StringBuilder content)
    {
        content.Remove(content.Length - text.Length, text.Length);
    }

    public void Redo(StringBuilder content)
    {
        content.Append(text);
    }
}

We’re almost there. We just need to add Undo/Redo support for the Delete action. Add tests to cover this.

[Fact]
public void UndoDeleteShouldAddTextToContent()
{
    TextEditor textEditor = new();
    textEditor.Type("Hello");
    textEditor.Type(" ");
    textEditor.Type("world");
    textEditor.Delete(5);
    textEditor.Undo();
    
    var result = textEditor.GetContent();

    Assert.Equal("Hello world", result);
}

[Fact]
public void RedoDeleteShouldRemoveAddedTextFromContent()
{
    TextEditor textEditor = new();
    textEditor.Type("Hello");
    textEditor.Delete(1);
    textEditor.Undo();
    textEditor.Redo();
    
    var result = textEditor.GetContent();

    Assert.Equal("Hello", result);
}

Ensure the tests fail.

We can create a new DeleteAction class to go on the stack, but will need to use an interface for the generic type so that both classes can be used. Create an IAction interface with Undo and Redo methods. Update the TypeAction class to use the interface too.

public interface IAction
{
    void Undo(StringBuilder content);
    void Redo(StringBuilder content);
}

public class TypeAction : IAction
{
    public TypeAction(string text)
    {
        this.text = text;
    }

    public void Undo(StringBuilder content)
    {
        content.Remove(content.Length - text.Length, text.Length);
    }

    public void Redo(StringBuilder content)
    {
        content.Append(text);
    }
}

public class DeleteAction : IAction
{
    public DeleteAction(string text)
    {
        this.text = text;
    }

    public void Undo(StringBuilder content)
    {
        content.Append(text);
    }

    public void Redo(StringBuilder content)
    {
        content.Remove(content.Length - text.Length, text.Length);
    }
}

Then update the undoStack and redoStack to be of type <IAction>.

private readonly Stack<IAction> undoStack = new();
private readonly Stack<IAction> redoStack = new();

Update the Delete method of TextEditor to push DeleteAction onto the undoStack and clear the redoStack.

public void Delete(int count)
{
    if (count < 0)
    {
        throw new ArgumentException("Cannot delete negative character count", "count");
    }

    content.Remove(content.Length - count, count);
    undoStack.push(new DeleteAction(text));
    redoStack.clear();
}

Now for the best part — run all your unit tests and watch them light up green! There’s nothing quite like that satisfying moment when every test passes and you know your code is solid.

At this stage you have completed the scenario. Ask the interviewers if they have any questions about your implementation and there may be discussion around further improvements you could make.

Example 2: Job Scheduler

As we have already gone through an example step-by-step, demonstrating the iterative TDD approach, The following examples will be just the approach and final implementation.

Scenario:

CodeX processes jobs for different customer tiers:

  • Enterprise → highest priority
  • Pro → medium priority
  • Free → lowest priority

You need to design a scheduler that:

  • Accepts incoming jobs with a jobId and a priority
  • Always processes the highest priority job first
  • Within the same priority, jobs are processed in the order they arrived (FIFO)
  • Supports checking the next job without removing it

Implement:

public class JobScheduler
{
    public void AddJob(string jobId, int priority);
    public string GetNextJob(); // Removes and returns next jobId
    public string PeekNextJob(); // Returns next jobId without removing it
}

Requirements:

  1. Multiple jobs may have the same priority → must preserve order of arrival within that priority.
  2. Must run in O(log n) or better for job insertion/removal.
  3. Priority can be assumed to be 1 (low) to 3 (high), but should be easy to extend.

Full Implementation:

Warning: Spoilers below!

using System;
using System.Collections.Generic;
using System.Linq;

public class JobScheduler
{
    private readonly SortedDictionary<int, Queue<string>> jobQueues = new();

    public void AddJob(string jobId, int priority)
    {
        if (!jobQueues.ContainsKey(priority))
        {
            jobQueues[priority] = new Queue<string>();
        }
        jobQueues[priority].Enqueue(jobId);
    }

    public string GetNextJob()
    {
        if (!jobQueues.Any()) return null;

        int highestPriority = jobQueues.Keys.Max();
        var queue = jobQueues[highestPriority];
        string job = queue.Dequeue();

        if (queue.Count == 0)
        {
            jobQueues.Remove(highestPriority);
        }

        return job;
    }

    public string PeekNextJob()
    {
        if (!jobQueues.Any()) return null;
        int highestPriority = jobQueues.Keys.Max();
        return jobQueues[highestPriority].Peek();
    }
}

Data Structures Used:

  • Dictionary<int, Queue> → One queue per priority.
  • A SortedSet or simple max-priority tracking for quick priority selection.
  • This gives O(1) enqueue and dequeue for each priority bucket.

How to Discuss in Interview

Why Dictionary<int, Queue> instead of PriorityQueue<string,int>?

  • Built-in PriorityQueue in C# 10 doesn’t preserve FIFO order for equal priorities; combining a dictionary of queues explicitly guarantees it.

Scaling Considerations

  • In a distributed system, this could be backed by a message broker (RabbitMQ, Kafka) and use a consumer group per priority level.

Example 3: Language Translation Router

This scenario is a little more complex, involving more data structures and algorithms.

Scenario:
A language translation system can’t translate directly between all language pairs. Sometimes it needs to chain translations through intermediate languages.

For example:

  • English → Japanese might require going through German (EN → DE → JA).
  • We want to find the shortest path (fewest hops) from a source to a target language.

You need to:

  • Accept a list of supported direct translations.
  • Given a source and target language, find the shortest route (if any).
  • Return the path as a list of language codes.

Implement:

public class TranslationRouter
{
    public TranslationRouter(List<(string from, string to)> supportedPairs);
    public List<string> FindShortestPath(string from, string to);
}

Requirements:

  1. Treat translation links as bidirectional (if EN → DE is supported, DE → EN is also supported).
  2. If no path exists, return an empty list.
  3. Use an efficient algorithm for shortest path.

Warning: Spoilers below!

Approach:
This is a classic unweighted shortest path problem — perfect for Breadth-First Search (BFS).

Full Implementation:

using System;
using System.Collections.Generic;
using System.Linq;

public class TranslationRouter
{
    private readonly Dictionary<string, List<string>> graph = new();

    public TranslationRouter(List<(string from, string to)> supportedPairs)
    {
        foreach (var (from, to) in supportedPairs)
        {
            if (!graph.ContainsKey(from)) graph[from] = new List<string>();
            if (!graph.ContainsKey(to)) graph[to] = new List<string>();
            graph[from].Add(to);
            graph[to].Add(from); // Bidirectional
        }
    }

    public List<string> FindShortestPath(string from, string to)
    {
        if (!graph.ContainsKey(from) || !graph.ContainsKey(to))
            return new List<string>();

        var queue = new Queue<string>();
        var visited = new HashSet<string>();
        var parent = new Dictionary<string, string>();

        queue.Enqueue(from);
        visited.Add(from);

        while (queue.Count > 0)
        {
            var current = queue.Dequeue();

            if (current == to)
                return ReconstructPath(parent, from, to);

            foreach (var neighbor in graph[current])
            {
                if (!visited.Contains(neighbor))
                {
                    visited.Add(neighbor);
                    parent[neighbor] = current;
                    queue.Enqueue(neighbor);
                }
            }
        }

        return new List<string>(); // No path found
    }

    private List<string> ReconstructPath(Dictionary<string, string> parent, string start, string end)
    {
        var path = new List<string>();
        string current = end;

        while (current != start)
        {
            path.Add(current);
            current = parent[current];
        }
        path.Add(start);
        path.Reverse();
        return path;
    }
}

Data Structures Used:

  • Dictionary<string, List<string>> → adjacency list
  • Queue<string> → BFS queue
  • Dictionary<string, string> → to store the path

How to Discuss in Interview

Why BFS?

  • Graph is unweighted, so BFS guarantees shortest path in terms of edges.

Why the adjacency list?

  • Space-efficient for sparse graphs, O(V+E) traversal time.

Scaling considerations

  • In a large-scale system, language mapping could be dynamic, fetched from a service registry, and cached in memory with updates pushed in real time.

Wrapping Up

Key Takeaways for Acing the Interview:

  1. Think out loud.
  2. Choose the right data structure for the job.
  3. Start simple, then optimise.
  4. Test with examples early.
  5. Be ready to discuss trade-offs.

If you prepare with real-world style problems like these, and focus as much on how you solve as what you solve, you’ll be well ahead of the pack.

Leave a comment

You may also enjoy