12 Ways to Add an Array of Integers in C# — Part 1
By: Michael Gant
Tags: Interview, Software Development, Programming

Photo by Roman Mager on Unsplash

At a certain point in my career, I spent a lot of time interviewing candidates for programming jobs ranging from entry-level to senior. As anybody who has ever conducted a technical interview could probably tell you, it’s not an easy thing to get right. You’ve got maybe an hour to try your best to divine whether the person on the other side of the table — who is likely very nervous, maybe thirsty, maybe didn’t sleep well, maybe under a lot of stress from their current job — is going to be able to contribute positively to your team.

One ubiquitous but oft-maligned way to gauge a candidate’s potential is a whiteboard coding exercise. Why is it oft-maligned? Because in real life, uh, you don’t actually, you know, write computer programs on a whiteboard. So then why is it ubiquitous? Because when done right, it can be a very effective way to gauge, not just a person’s knowledge of a particular language, framework, set of requisite buzzwords, etc., but their actual understanding of the complex, highly abstract process of turning a real-world problem into the bits and bytes that comprise a programmatic solution to that problem.

But how to do it right? Much has been written on that. My go-to solution (not my goto solution; more on that later) was to pose a very, very simple problem, tell them to ask me absolutely anything, tell them not to worry about the syntax and to answer the problem in any language, and then see what happens.

My favorite exercise: given an array of integers, write a function that returns the sum. That’s all. Just add up a bunch of numbers. Programming 101 stuff. Simple, right?

Well, whiteboard programming is hard. A good number of candidates struggled with the problem. In many cases it was just nerves, and with a little reassurance, they got their bearings and knocked it out. Thankfully only a few truly had no idea how to do such a thing. Most of them had never written an original line of code in their lives, only googled, copied, pasted, and tinkered.

After we talked about their solution, time permitting (and assuming there was a good reason to continue the interview), I liked to walk them through a few other solutions I had come up with. Some of the solutions were absolutely ridiculous. Others maybe just a little too clever. Some only worked for certain inputs. But all of them highlighted a different way of approaching what seems, on the surface, to be a very basic problem.

As I mentioned in the title, I’ve thought up a total of 12 different ways. They fall into five basic categories. This week, I’ll cover the first three.

The basic

The vast majority of candidates come up with a for loop, like this:

Why is this the most common? A couple of good reasons come to mind. One is that this same basic syntax will work, maybe with a few modifications, in most if not all C-syntax languages. Also it performs well.

Actually, performance is one of the things we would discuss in the interview. Why is one solution likely to perform better than another? How would you know? How might you optimize it?

Another thing we would discuss is readability. To highlight that, here are a couple of variations on that same theme.

goto

Considered harmful? Considered awesome! If you write this code, nobody will dare touch it. You’ll be a legend. Guaranteed job security.

Of course, you would never really do this in real life. But it leads to an interesting discussion. Because, logically speaking, this code is practically identical to the first example. A for loop is just a syntactic way of saying to repeat the same block of code until a condition is satisfied. The goto solution is doing the same thing, just a little more confusingly.

And thinking further about what the condition is that we’re trying to satisfy before exiting the “loop” takes us to an even worse, but still interesting, solution.

Pointers

Honestly, I think if they were inventing C# today, they probably wouldn’t even include unsafe code. Microsoft at the time was trying to lure both VB and C++ developers to use its new platform, so they were trying to thread a pretty tight needle. C++ programmers — and more particularly C programmers — would be unwilling to give up the power of pointers (even though they might be happy to give up the complexity). So Microsoft came up with a way to work pointers into the language spec. At the same time, a big selling point for .NET was that it was memory-safe and garbage-collected. Fixed memory locations don’t fit with that paradigm. Hence the ugliness of this approach. But it does work.

You might think that both of these solutions might offer some performance benefit in exchange for the readability hit. I’ll probably talk more about performance later, but from my testing, that’s not really the case. The for loop and its two ugly cousins were all among the top-performing solutions, but the for loop actually usually beat the goto and pointer solutions. My theory is that the pointer solution loses some time fixing the memory address so that the pointer incrementing will work. I don’t really know why goto is a little slower. Some day I’ll look at the disassembly and try to figure it out.

Next time I’ll talk about the next most obvious solution, the foreach loop. You may be thinking that’s just some kind of syntactic sugar over the for loop. You’d be wrong. Or at least half-wrong.