[RudiVisser]

Hola

So recently we've been looking around for some C# developers and in amongst the usual programming competency and language related stuff I came up with this quick (written) test of understanding of how the language works, you know reference variables, what readonly means, constructor execution order, etc.

You would be surprised how many were unable to answer correctly, whilst taking note that this was for a mid-senior level role:

class TestClass
{
    private readonly StringBuilder _stringBuilder;

    public TestClass()
    {
        _stringBuilder = new StringBuilder();
    }

    void AppendSomething(string apnd)
    {
        _stringBuilder.Append(apnd);
    }
}

Would this code produce a class that 1; Compiles, 2; Allows an instance to be created AND 3; Has a usable AppendSomething method?

class TestClass
{
    private static readonly StringBuilder _stringBuilder;

    public TestClass()
    {
        _stringBuilder = new StringBuilder(50);
    }

    static TestClass()
    {
        _stringBuilder = new StringBuilder(100);
    }

    void AppendSomething(string apnd)
    {
        _stringBuilder.Append(apnd);
    }
}

Would this code compile? If so, what is the default length of the StringBuilder? If not, why would it not compile?

------------------

How many of you in a management-ish development role have come up with questions that can trip up people who are meant to know the language, and what were they?

This post has been edited by RudiVisser: 21 July 2012 - 09:17 AM

[Michael26]

No it won't compile, AppendSomething method can't modify readonly field.
Readonly can change with declaration or in the constructor of he same class

[sepp2k]

Michael26, on 21 July 2012 - 05:41 PM, said:

No it won't compile, AppendSomething method can't modify readonly field.

It won't compile, but that's not the reason why. The AppendSomething method is perfectly fine.

Readonly only prevents you from reassigning variables. It's perfectly possible to call mutating methods on readonly variables.

[RudiVisser]

Michael26, on 21 July 2012 - 04:41 PM, said:

No it won't compile, AppendSomething method can't modify readonly field.
Readonly can change with declaration or in the constructor of he same class

Oops! There were 2 questions, the first is perfectly fine. AppendSomething does work like sepp2k said, because readonly only affects the assignment of a variable when it comes to reference variables, so you can very much change the StringBuilder, just not to a different instance of it.

The second one wouldn't compile, because the field is static and so the static constructor would run upon first access, making it unsettable via the instance constructor.

-------

This is why I'm thinking it's a candidate for a great interview question when you're hiring in a med/senior level for a C# role, it trips up some people who don't understand exactly how the object model works, ie. separates those that know the language wholly and understand the root principles of how it works rather than just using it.

EDIT: Just to clarify btw, this wasn't meant for people to answer it like a test, I'm more interested in questions that other developers have used when hiring somebody to try and gauge the knowledge of the candidate.

This post has been edited by RudiVisser: 21 July 2012 - 09:06 AM

[Michael26]

Thanks for clarification, sepp2k

[sepp2k]

RudiVisser, on 21 July 2012 - 06:02 PM, said:

Oops! There were 2 questions, the first is perfectly fine.

If that was your intention, you must have made a mistake because neither of the code samples in your question compile (both have a non-static constructor that tries to assign to _stringBuilder).

[RudiVisser]

sepp2k, on 21 July 2012 - 05:11 PM, said:

If that was your intention, you must have made a mistake because neither of the code samples in your question compile (both have a non-static constructor that tries to assign to _stringBuilder).

Oops again, I had actually pasted the same snippet (second one) twice by accident, and retrofitted the first snippet to be how it was originally, forgot to remove the static - It's fixed now! Thanks.

[Curtis Rutland]

Ok, I'll just say why I hate questions like these. I'm not a compiler. I'm a programmer. I use compilers, and I expect them to tell me when things go wrong. So, yes, I'm reliant on my tools. But when you put me on the spot, with a printout of some code and expect me to explain what's wrong with it, I'm going to have trouble. Because that's not what I'm experienced with; that's not what I do. I use a compiler and a debugger to figure out what's wrong with code. I have access to documentation and intellisense and compiler errors. Why should you care that I didn't notice one keyword in a printout that made the code fail to compile. I wound't have written it in the first place, and if I had, the IDE would have reminded me that I screwed up.

---

Sorry, I kinda blew up on you there. I just hate interview questions where I'm expected to stand in for a compiler, or god forbid, write code on a whiteboard. Quiz me on the mechanics of the language if you must, but if you really want to know my skills, give me a real world problem, perhaps one your company has already solved, and let's discuss how I would go about solving it. If you want to assess my competence with the language, sit me down in front of Visual Studio and ask me to write a simple exercise program.

[Skydiver]

How about this:

In the code below, predict whether the Hugo or the Ferrari will collect more "wins" or if there will be an even distribution. Explain why you picked a winner, or think it is a draw.

using System;
using System.Diagnostics;

namespace StructClass
{
    struct Hugo
    {
        public Hugo(int value)
        {
            this.value = value;
        }

        public int Next()
        {
            return value + 1;
        }

        int value;
    }

    class Ferrari
    {
        public Ferrari(int value)
        {
            this.value = value;
        }

        public int Next()
        {
            return value + 1;
        }

        int value;
    }

    class Program
    {
        void DriveHugo(int depth, int max)
        {
            Hugo hugo = new Hugo(depth);
            if (hugo.Next() < max)
                DriveHugo(depth + 1, max);
        }

        void DriveFerrari(int depth, int max)
        {
            Ferrari ferrari = new Ferrari(depth);
            if (ferrari.Next() < max)
                DriveFerrari(depth + 1, max);
        }

        long MeasureRunTime(Action<int, int> drive, int max)
        {
            Stopwatch stopwatch = new Stopwatch();
            stopwatch.Start();
            drive(0, max);
            stopwatch.Stop();
            return stopwatch.ElapsedTicks;
        }

        double GetAverageRunTime(int numberOfSamples, Action <int, int> drive, int max)
        {
            if (numberOfSamples <= 0)
                return 0.0;

            long sum = 0;
            for (int i = 0; i < numberOfSamples; ++i)
            {
                long runTime = MeasureRunTime(drive, max);
                sum += runTime;
            }
            return (double)sum / numberOfSamples;
        }

        void WriteWithColor(ConsoleColor color, string format, params object [] args)
        {
            var old = Console.ForegroundColor;
            Console.ForegroundColor = color;
            Console.Write(format, args);
            Console.ForegroundColor = old;
        }

        void Run()
        {
            const int MaxRaces = 20;
            const int MaxSamples = 20;
            const int MaxDepth = 20000;

            Console.WriteLine("{0,20}{1,20}", "Hugo", "Ferrari");
            for (int i = 0; i < MaxRaces; ++i)
            {
                double hugo = GetAverageRunTime(MaxSamples, DriveHugo, MaxDepth);
                double ferrari = GetAverageRunTime(MaxSamples, DriveFerrari, MaxDepth);
                var hugoColor = ConsoleColor.Green;
                var ferrariColor = ConsoleColor.Red;
                if (hugo > ferrari)
                {
                    hugoColor = ConsoleColor.Red;
                    ferrariColor = ConsoleColor.Green;
                }
                WriteWithColor(hugoColor, "{0,20:f2}", hugo);
                WriteWithColor(ferrariColor, "{0,20:f2}", ferrari);
                Console.WriteLine();
            }
        }

        static void Main(string[] args)
        {
            new Program().Run();
        }
    }
}

As an aside, Tailean: Look colors on the console!

A little bit of rambling and wandering off topic:

Or will a candidates' response "I'm not a profiler. Put me in front of VS, and I'll run it for you." be acceptable?

Why the current trend nowadays among interview questions asking about the big O characteristics of algorithms and data structures? It seemed to fall out of fashion during the 90's and early 2000's, but seems to be coming back again.

Shouldn't a candidate be able to reply, "Let's just measure the real world performance. If it's acceptable, who cares if it is O(n^2)? Only if it is a bottleneck should we look at replacing the algorithm." or "In extreme programming and test driven development, we use the simplest possible thing that could work. We only change the code to something more efficient if the current code is a performance hotspot."

If as a potential employer we respond with "we expect a certain base level of understanding of data structures and algorithms, and asking about the big O characteristics lets us gauge the candidates proficiency", then doesn't the same argument apply that "we expect certain base level of understanding the difference between classes and structs in C#..." or "we expect a certain base level of understanding of "static" and "readonly" in C#..."?

This isn't to take away anything from what Curtis wrote above. I completely agree with him. As I said, just rambling.

This post has been edited by Skydiver: 21 July 2012 - 12:04 PM

[RudiVisser]

Curtis Rutland, on 21 July 2012 - 07:01 PM, said:

Ok, I'll just say why I hate questions like these. I'm not a compiler. I'm a programmer. I use compilers, and I expect them to tell me when things go wrong. So, yes, I'm reliant on my tools. But when you put me on the spot, with a printout of some code and expect me to explain what's wrong with it, I'm going to have trouble. Because that's not what I'm experienced with; that's not what I do. I use a compiler and a debugger to figure out what's wrong with code. I have access to documentation and intellisense and compiler errors. Why should you care that I didn't notice one keyword in a printout that made the code fail to compile. I wound't have written it in the first place, and if I had, the IDE would have reminded me that I screwed up.

---

Sorry, I kinda blew up on you there. I just hate interview questions where I'm expected to stand in for a compiler, or god forbid, write code on a whiteboard. Quiz me on the mechanics of the language if you must, but if you really want to know my skills, give me a real world problem, perhaps one your company has already solved, and let's discuss how I would go about solving it. If you want to assess my competence with the language, sit me down in front of Visual Studio and ask me to write a simple exercise program.

Have to say that's a little ridiculous, this is meant to test people'a understanding of basic OOP principles. If they don't understand the basics of how readonly or static constructors work then, as a candidate for a senior developer role, I would not want them on my team at all.

I understand with something more complex, but this is literally a test of basic principles, though it shows that they know enough about the language to be a competent developer.

The reason it's worded as "does it compile" is because the instinct of somebody that doesn't understand readonly or static constructors is that it won't, and that will be their answer. The answer of somebody who has used the language enough or understands these basic principles will be logical and correct.

EDIT: Curtis Rutland I'm genuinely curious how you'd test a senior dev's ability? It's obvious we go for more programming/logic/understanding based questions for the most part, but we should definitely also test some language principles too Ibfact, I think the readonly would be known by most good programmers regardless of language.

This post has been edited by RudiVisser: 21 July 2012 - 01:33 PM

[Curtis Rutland]

I think you missed my point. It's not a matter of knowing about readonly, it's about being handed a printout of code and saying "what's wrong with this?" That's not what my job is going to entail, is it? Of course not.

Go ahead and ask all the questions you want about readonly. Just don't present them to me like I'm a compiler.

And the way I'd test a senior dev's ability would be to focus more on architecture and problem solving. Like I said, present a scenario that perhaps your company has already solved, and discuss how he would go about implementing it. See if he anticipates any issues you already had, etc...That is, unless the job is just re-working old code. Then simple tests are fine. But if the job will involve designing and implementing new projects, it's more important to determine if they can solve problems than if they know the ins and outs of a facet of the language. Languages can be learned; it's much harder to teach architecting.

[RudiVisser]

Ah no it should be said that this would of course come after all of the more generic questions, such as how they handle under pressure and situational (job related) ability.

The point is this isn't a test saying what's wrong with this. It's a simple test of how readonly / static constructors work, like I say I would expect (on certain situations) that they would know what static and readonly does and use them in the appropriate code.

I would fully expect that any developer would be able to do such basic static analysis on code. As a senior you would be expected to help other developers who needed help, and to be fair, being able to spot errors in code immediately (of course you may have aid from Visual Studio). Of course in addition, being able to educate juniors on features they've never used before would also be expected.

Perhaps it's just me that thinks this, but it's certainly what I expect from my team.

[Skydiver]

Curtis Rutland, on 21 July 2012 - 01:59 PM, said:

And the way I'd test a senior dev's ability would be to focus more on architecture and problem solving. Like I said, present a scenario that perhaps your company has already solved, and discuss how he would go about implementing it. See if he anticipates any issues you already had, etc...That is, unless the job is just re-working old code. Then simple tests are fine. But if the job will involve designing and implementing new projects, it's more important to determine if they can solve problems than if they know the ins and outs of a facet of the language. Languages can be learned; it's much harder to teach architecting.

Treat this as anecdotal and maybe a one-off incident:
During the .COM boom, the company I work for hired somebody like that once. When I was doing the interview I was told to skip the programming skills part and just focus on problem solving skills, architecture design, and contingency planning because "he's coming from industry and already has a proven track record of code". Sure, no problem. I gave a hire reco, as did others. A few weeks later, the guy starts up and he's given a nice piece virgin territory of problem space to design a solution for. The design reviews went well, and we felt good that we'd made a good hire. But when it was time to implement things, the guy couldn't write code to even do a simple lookup table that was part of his design. The singly linked list he implemented had a nasty habit of losing nodes. He had no concept of what a memory leak was and that something should be done to prevent them from happening. We were quite sure the job description included words like "design, implement, and maintain" so I don't think we were just hiring somebody to do design work.

[RudiVisser]

Skydiver, on 22 July 2012 - 04:43 AM, said:

Treat this as anecdotal and maybe a one-off incident:
During the .COM boom, the company I work for hired somebody like that once. When I was doing the interview I was told to skip the programming skills part and just focus on problem solving skills, architecture design, and contingency planning because "he's coming from industry and already has a proven track record of code". Sure, no problem. I gave a hire reco, as did others. A few weeks later, the guy starts up and he's given a nice piece virgin territory of problem space to design a solution for. The design reviews went well, and we felt good that we'd made a good hire. But when it was time to implement things, the guy couldn't write code to even do a simple lookup table that was part of his design. The singly linked list he implemented had a nasty habit of losing nodes. He had no concept of what a memory leak was and that something should be done to prevent them from happening. We were quite sure the job description included words like "design, implement, and maintain" so I don't think we were just hiring somebody to do design work.

This is what I was getting at in my previous post, it's imperative that programming skills should be tested, and this is why I feel that the question proposed like mine would be a good candidate, we're not asking somebody to "point out what is wrong with this code and how to fix it", but simply testing their knowledge on a few lesser-known(?!) keywords that any senior developer should have full knowledge of.

When I last applied for a job I was given 4 pages of existing code from their system and told to analyse it for errors. The code was completely out of context, using classes that had no definition and it simply made no sense. Obviously the only real thing that I could do was use language-based fixes to that but it wasn't testing my ability per se it was just extremely confusing, and I'm sure nothing good would have come of it apart from the employer being able to say "Yes he can fix our code!".

With such a small yet intricate (imo) question like the one I had posted above, that would actually test such basic and core knowledge, yet I've asked several people this to date and you would, like I said in the original post, be very surprised at how many don't get understand readonly or static.

[marty617]

Curtis Rutland, on 21 July 2012 - 11:01 AM, said:

Ok, I'll just say why I hate questions like these. I'm not a compiler. I'm a programmer.

I'm with you on this one. I also find that good programmers with more experience tend to block out obscure academic language tricks that confound code to the point that they are not confident to answer such questions because they would just never do it that way in the first place.