I love going to interviews. Seriously, I do it for sports.

No matter from what side of the screen you are - most technical interviews are boring. At senior positions, there’s only that much of topics you can cover and only that much of necessary skills you can validate.

Most of the interviews, especially in big corps, are just a question/topic checklist. At one company we had to actually go through centralized topic list and give candidate score on each topic. Some topics didn’t even make sense in the context of our project specifics, and during an interview some topics could be omitted altogether because candidate obviously knows it well, but I still must ask the question. Like a candidate just explained me in details how he goes through query plans to optimize performance, and now I ask they what is an index.

Just recently I was going through a technical interview with a huge, bureaucracy-ridden company. The guy on the other side was definitely reading questions from the list and then comparing my answers to the given correct answers, but then we moved on to practical coding task.

He gave me the code:

class SomeService
{
  public async Task ProcessData()
  {
    try
    {
      await ExecuteOperation();
    }
    catch(Exception e)
    {
      Console.Error.WriteLine("Whoops!");
    }
  }
}

Given the existing ProcessData() function, which calls ExecuteOperation() and in case of exception writes it in the console, how do you make this function to retry ExecuteOperation() three times?

Well, this is a common piece of functionality I implement at my job every other week. This is also a very common question for an interview.

There are different ways of approaching this task. In production code we usually already have some kind of helper, such as DoWithRetry(ExecuteOperation, times: 3) or, realistically, just using Polly to do something like Policy.Retry(3).Execute(ExecuteOperation).

Interviewers usually expect you to quickly come up with such helper, or maybe just implement some readable up-front solution.

The most “normal” solution is probably:

class SomeService
{
  public async Task ProcessData()
  {
    var retries = 3;
    while (retries > 0)
    {
      try
      {
        await ExecuteOperation();
        break;
      }
      catch(Exception e)
      {
        retries--;
        if (retries <= 0) Console.Error.WriteLine("Whoops!");
      }
    }
  }
}

Some will arguably do better with do {...} while() instead. Some will try to come up with overly-specialized recursive solution.

But that’s boring. That was my time to shine. I saw and opportunity to leave the mark on that interview, so I went for it. There’s one unusual solution, which most developers never even think of. Check this out:

class SomeService
{
  public async Task ProcessData()
  {
    var retries = 3;
  retry: // goto label
    try
    {
      await ExecuteOperation();
    }
    catch(Exception e)
    {
      retries--;
      if (retries > 0) goto retry; // bazinga
      Console.Error.WriteLine("Whoops!");
    }
  }
}

That’s an elegant and straight-forward solution. It really conveys the purpose much better than a while loop, and takes less effort to implement than a helper. It does not pollute the code much and is perfectly readable.

No need to say that the interviewer was surprised. You don’t normally see goto in modern days. I was discouraged and taught against using it back in university. There’s a stigma against using goto (rightfully so haha), and it somewhat is a meme. Yet I could proudly use it during technical interview.

I got a “perfect score” for the solution (or more like for going with “tricky” solution and being able to explain it well). But more importantly - that was fun.

I’ve been having intense interview period recently. Like I had 4 interviews just last week, and will probably have the same amount next week. I will probably have more posts on interviews soon.