I respectfully disagree with Peilonrays about one thing: if I got a question like this, I would interpret it to mean that I’m expected to demonstrate some familiarity with both SOLID and Clean Code, as well as how to use them sensibly in moderation.

First, as for the code itself, we can make it a lot nicer by remembering that a number is divisible by both 3 and 5 if and only if it’s divisible by 15. There are a few clever FizzBuzz programs out there, but I generally like to write static single assignments with ternary expressions, so I’ll go with that:

using System;

public class Program
{
    public static void Main()
    {
        for(int i=1; i<= 100; i++) 
        {
            Console.WriteLine(ToFizzBuzz(i));
        }
    }
    
    public static string ToFizzBuzz(int i) {
        return (i%15 == 0) ? "FizzBuzz" :
               (i%3 == 0)  ? "Fizz"     :
               (i%5 == 0)  ? "Buzz"     :
               i.ToString();
    }
}

The helper function is now a single statement. We’ve eliminated all temporary variables and concatenation. This is also pretty efficient. Because of the short-circuiting of the nested ternaries. We only check divisibility by 3 or 5, or convert i to a string, if we need to. And in optimal order: since there are twice as many numbers divisible by 3 but not 15 as by 5 but not 15, it is more efficient to check i%3 before i%5.

That said, no reasonable interviewer is going to expect you to actually come up with all the clever number-theory tricks for these problems on the spot.

One way in which Clean Code is relevant here is that it says to know the coding conventions of the language. For C#, these say, “Use PascalCase for class names and method names.” I therefore renamed your helper method in accordance with Clean Code.

At this point, I’d probably try to tell the interviewer, “The S in SOLID is for Single Responsibility Principle, and everything has a Single Responsibility. The O is for Open for Extension/Closed for Modification, and a maintainer could easily extend it by adding some other transformation or using the string in another way. The problem is too simple for the other three, like substitution, interfaces and dependency inversion, to really apply.” If I’d looked it up recently and had them fresh in my memory, that is. I honestly don’t do a lot of OOP these days.

I respectfully disagree with Peilonrays about one thing: if I got a question like this, I would interpret it to mean that I’m expected to demonstrate some familiarity with both SOLID and Clean Code, as well as how to use them sensibly in moderation.

First, as for the code itself, we can make it a lot nicer by remembering that a number is divisible by both 3 and 5 if and only if it’s divisible by 15. There are a few clever FizzBuzz programs out there, but I generally like to write static single assignments with ternary expressions, so I’ll go with that:

using System;

public class Program
{
    public static void Main()
    {
        for(int i=1; i<= 100; i++) 
        {
            Console.WriteLine(ToFizzBuzz(i));
        }
    }
    
    public static string ToFizzBuzz(int i) {
        return (i%15 == 0) ? "FizzBuzz" :
               (i%3 == 0)  ? "Fizz"     :
               (i%5 == 0)  ? "Buzz"     :
                             i.ToString();
    }
}

The helper function is now a single statement. We’ve eliminated all temporary variables and concatenation. This is also pretty efficient. Because of the short-circuiting of the nested ternaries. We only check divisibility by 3 or 5, or convert i to a string, if we need to. And in optimal order: since there are twice as many numbers divisible by 3 but not 15 as by 5 but not 15, it is more efficient to check i%3 before i%5.

That said, no reasonable interviewer is going to expect you to actually come up with all the clever number-theory tricks for these problems on the spot.

One way in which Clean Code is relevant here is that it says to know the coding conventions of the language. For C#, these say, “Use PascalCase for class names and method names.” I therefore renamed your helper method in accordance with Clean Code.

At this point, I’d probably try to tell the interviewer, “The S in SOLID is for Single Responsibility Principle, and everything has a Single Responsibility. The O is for Open for Extension/Closed for Modification, and a maintainer could easily extend it by adding some other transformation or using the string in another way. But ToFizzBuzz does one thing that doesn’t need to be modified. The problem is too simple for the other three, like substitution, interfaces and dependency inversion, to really apply.” If I’d looked it up recently and had them fresh in my memory, that is. I honestly don’t do a lot of OOP these days.