There was a good thread in Chris Sells' OT list this morning.

Began as a list of questions that might be asked during an interview (.NET job). People were chiming in with their opinions, and someone eventually mentioned asking an interviewee to flesh out a string reversal function.

Stuart was quick off the block with a VB.NET answer:

Private Function Reverse(ByVal str As String) As String
    Dim rev As New StringBuilder(str.Length)
    For x As Integer = str.Length - 1 To 0 Step -1
        rev.Append(str.Substring(x, 1))
    Next
    Return rev.ToString
End Function

Starting with Stuart's version, the conversation quickly turned to providing potential implementations, most of which (if not all) were in C#.

It began with a couple improvements to Stuart's function, but spiraled into this obscure academic exercise chock full of unsafe blocks and pointer mumbo-jumbo.

Arguments ensued as disagreements arose over the finer points of unsafe coding. Stuart's example was discarded, and the resulting code snippets started looking more and more as though they had been run through obfuscators.

Now, I don't know about you, but if I were interviewing someone for a .NET position, and if I asked that person to implement a string reversal function, I'd want something more like Stuart's answer.

Was Stuart's the best? The fastest? The most compact?

No, no, and no.

But it probably took him about 12 seconds. The arguments over the unsafe pointer-based methods, though, continued. Some of the versions offered wouldn't even compile, while others totally ignored some important feature, and so on.

All the while, Stuart's could have been chunking away on some giant string. By the time the dust settled, Stuart's code could have reversed The Brothers Karamazov and restored it to its original orientation.

Before knowing what the string reversal function was going to be used for, and before knowing how often it was going to be used, these guys were pumping out more and more complex (and fragile in some cases) versions of the function.

As someone interviewing for the position, this would worry me to no end.

Take my day for example. I wrote a log parsing app a while back that took a while to do its thing. It was processing about 30 1 gig files, and sometimes took as much as an hour to complete. This involved file IO as well as some database mucky-muck.

If you can believe it, I wrote the app with no other intention than getting it to work. Goal #1 was for the thing to function. It wasn't until after I had finished that I decided to optimize.

Running a few tests, I found one block of code that was taking much longer than the others. An hour later, I had fixed the trouble spot, and the parser was down to about fifteen minutes to do the same job.

Now, what if I had approached the app with the intention of squeezing every last bit of performance out of it from the get go? Without being able to test the app, and without any profiling, I'd be coding blind - maybe spending hours to save milliseconds, and ignoring the real bottleneck which could very well be elsewhere.

That would suck.

If the app needed a string reversal function, and if I had to write it, then I would have cranked out something like Stuart's version. If it turned out that it was the source of some major performance issue, then I would have gone back and tweaked it.

I would have hired Stuart because I would have seen that Stuart wasn't going to waste my money by optimizing code that might have been just fine.

It seems to me that people expend a lot of effort on a regular basis for little reward. It's like these people who will circle a building for 20 minutes, waiting for a parking spot to open up. Instead of parking three blocks away and getting inside 15 minutes sooner, they just circle, and circle, and circle, and circle...