Last week there was an interesting discussion about coding samples on /.  As if technical phone interviews weren't enough, some companies would like or even require you to submit a coding sample for their review.  These come in various flavors, but I've encountered 3 variations of this:

1. Random code sample of your choosing.
2. Code you write on site while interviewing, usually on a whiteboard.
3. Take home test where you complete a specific assignment.

Of the 3, the first one is pretty liberal and for the most part I would expect any decent programmer to be able to come up with some pithy example.  Sure, not all of us spend a significant part of our time writing code outside of work, but you should have something. 

I think OSS contributions are the best way to answer this type of request - even if you're the only one who uses it.  Its a very simple matter to setup a public OSS Google code playground.  Better yet, submit a patch for your favorite OSS project.  This shows not only you know how to code, but that you can work with existing code on a large project with other people - something you will not likely learn in college classes.

To me, these type of requests are nothing more than a starting point of a discussion between you and a prospective employer.  Which also means, any code you find that is public domain could be turned in.  Is this valid in this context?  I think so, because the code should be a discussion topic and not a test.  You should be able to talk about patterns used, coding standards, and most importantly... what would you do to improve this piece of code.  Clearly you must understand the code to be able to do this.

Writing code on a whiteboard (#2) is a bit different than one or three.  Its real time coding.  Coding under pressure without the aid of intellisense, IDE, or other technical reference.  Everything is based on your recall which only happens through experience, or at least good memorization.  More on this topic later...

Number three is interesting.  Often time the assignment is very particular and requires your to solve a particular problem, often times academic in nature.  This basically means homework; something you won't do in real life, nor something you have laying around already coded.

I think these type of coding samples are particularly useless for several reasons.

1. Good coders often won't waste their time tackling these problems unless they are really interested in the position.
2. They aren't real world and won't likely come up in real life.
3. These type of tests take time.  Why would a highly sought after engineer waste several hours with a home work assignment?

There are probably more reason than the three I stated, but that's more than enough reason for most good candidates to forgo application.

My question is why do companies do this?  Last I checked neither Microsoft or even Google do anything like this.  Perhaps to filter out the truly dedicated?  Maybe...  but perhaps its because someone non-technical is reviewing these tests?

Companies that do have a programming test of sorts like this are just lazy.  They are unwilling to take the burden of weeding out the good from the chaff, so they put the burden on the candidate with these tests, I mean hoops.  To me, these type of tests are a red flag. Perhaps this works for a small minority, but I surely wouldn't want to work somewhere like this.

A good software company should use code as a starting point for a discussion about software and systems.  Particular design decisions made in a complete vacuum are irrelevant without context.  Its all about the context, and that should just be the starting point of a bidirectional discussion, because that's where the real discovery comes from.

Looking for a new job can be an intimidating proposition, especially for developers who haven't changed jobs in a few years.  Are my skills current?  What kind of horrible interview trivia questions are popular these days?  Luckily the initial phone screen is the easiest part of the interview process, especially if you do your homework. 

Despite this, it amazes me how many candidates completely flounder the phone screen regardless of how senior their resume says they are.  I've found that a large majority of candidates don't pass the phone screen.  Yet, its doesn't have to be this way.  Don't rest on your laurels, do your homework!

Most phone screen questions are very superficial and don't go into any depth, you either know the answer or you don't.  If you've been coding every day for the majority of your time then you will generally find the questions very easy.  If you're fumbling for an answer, then that's definitely a bad sign to the interviewer because most of these questions they expect you to just know the answer as if it were reflex.  Its usually better to give answers promptly that are shallow than in depth answers that take a while to get out. 

And if you don't know an answer, just say so - don't try and BS your way through it.  Its disrespectful and you will get negative points, but having said that you should also follow up with a guess if you have one.  Here's an example. 

Interviewer: Is XML case sensitive? 

You: I don't know, but I always pretend it is when I write out my tags.

Beyond that, what kind of stuff should I do to prepare?  I'm glad you asked.  Find interview questions online and spend some time brushing up your skills.  Maybe even take a BrainBench test to help solidify your knowledge, the C# one used to be free.  Eventually you will notice a pattern to the interview questions.  Some of the most common that I've asked and/or answered are below.

General C#

• Brush up on the basics: and, or, xor, bits, bytes, hexadecimal, max size of data types, etc. etc.
• Learn the collection types. How does a stack differ from a queue?  What's a linked list?  What collection types are available in .NET 2.0?  How do you find something (quickly) in a given collection?
• What is the heap?  What is the stack?  You should know how .NET manages memory.  What is System.GC.Collect()?
• IDisposable.  Why does IDisposable exist?  What does using have to do with IDisposable in C#?  What's a Finalizer? How is a Finalizer different from a C++ destructor?
• What is the GAC?  What problem does it solve?  What is sn.exe?
• In .NET is a string a stack or reference type?  Is the .NET string class immutable?  Why does StringBuilder exist?
• What is an interface?  Abstract class?  Virtual method?  Does C# allow multiple inheritance?
• What is recursion?  Why would you use/not use recursion?
• Exception handling. How many catch blocks can a try block have? When does the finally block run? How do you rethrow an exception without killing the stack trace?
• What's a thread?  What's a process?  Compare contrast a thread and a process.  What's the lock keyword in C# do?  What's a deadlock?
• What does Debug.Assert, Debug.Trace, Debug.Write do?  Why would you use these?
• What an event?  What's a delegate?  When/why would you use them?

ASP.NET

• ASP.NET page lifecycle.  I know, I know... but learn it!  You will be asked this question!
• What's a postback?  What is Page.IsPostback? 
• What kind of controls exist in ASP.NET?  What's a user control?  What's a master page?
• What are several ways to maintain state in ASP.NET?  Where is session stored?  How does having a web farm affect this?
• How can we secure an ASP.NET application?  Your answer should cover coding as well as infrastructure.
• How can you debug an ASP.NET app?  How about with IIS?  How about with a remote IIS server?
• Does POST or GET mean anything to you?  How do they differ?  What is Fiddler?  What's a cookie?
• What's an http module?  What is an ASHX file?

SQL Server

• What types of joins exist in SQL Server?  Compare contrast the different types.
• Learn your indexes and how they differ. How does SQL Server store data?
• What's a primary key?  What's a foreign key?  What's a candidate key?  How would you model a many to many relation?
• When would you use GROUP BY and HAVING clauses?  How would you write a query that finds all the duplicate rows in a table?
• Sprocs and functions, how to they differ?  What advantages/disadvantages do they have?  What are the different ways of returning data from a sproc?
• What's a transaction?  How do they work?  When would you use one?  What's optimistic concurrency?
• What's a SqlConnection?  What's a connection pool and why are they useful?  What's a trusted connection?

I'm not sure this is true, but it seems to me that the better employers will ask a few basic comp sci questions (like 1 & 2 above), while the crappier ones skip this area and focus more on ASP.NET or SQL.

Sometimes you'll actually have a class that needs to read and parse files on disk.  This is pretty easy to do with the FCL StreamReader, but the problem is how do we test a class that is accessing resources on disk like text files?

Most devs first reaction is to create a file on disk in the test project and read that in.  This is often better than nothing, but has some problems associated with it.  Your test assembly now requires physical files on disk which are probably not in the current running test directory, or maybe you've moved the entire assembly to a different location then the test expected.  The real issue is that the class under test controls where the data is read from, not the test.

In short, these external files make your tests brittle, slower, and less intention revealing.  Not only that, but the external dependency really makes the test an integration test and less of a unit test.

The normal solution is to hide the external dependency behind a facade or interface that is mockable.  Unfortunately this is difficult because access to files on disk normally is very short lived.  A StreamReader instance often only lives for the duration of a method call, if even that.  The typical usage pattern  is: construct/open, read, close.

   1: using (var reader = new StreamReader(@"c:\file.txt"))

   2: {

   3:     fileType = reader.ReadLine();

   4: }

We really can't just inject a StreamReader instance into our class under test because the StreamReader opens the file via its constructor.  The problem is that the class under test is responsible for the entire StreamReader life cycle.

The simplest way around this is to use a factory class to create StreamReader instances which allows us to control the instantiation of the StreamReader, which is important when we go to unit test.

   1: public class StreamReaderFactory : IStreamReaderFactory

   2: {

   3:     public StreamReader CreateReader(string path)

   4:     {

   5:         return new StreamReader(path);

   6:     }

   7: }

   8:  

   9: public interface IStreamReaderFactory

  10: {

  11:     StreamReader CreateReader(string path);

  12: }

With that interface in place we can then inject a StreamReaderFactory implementation into our class when running in production. The factory couldn't be any simpler, its just a simple wrapper around the new statement. 

Now when we unit test we'll swap out the very simple factory implementation with a mocked one using RhinoMocks.  This mocked factory will return a predefined result which is located at the beginning of the test, keeping everything located in the test.

   1: [Test]

   2: public void Should_parse_resource_type_from_first_line()

   3: {

   4:     using (var content = CreateStream("F4", "some text resource"))

   5:     {

   6:         var streamReaderFactory = MockRepository.GenerateStub<IStreamReaderFactory>();

   7:         streamReaderFactory.Stub(x => x.CreateReader(@"resource.dat"))

   8:             .Return(new StreamReader(content));

   9:  

  10:         var classUnderTest = new ResourceParser(streamReaderFactory);

  11:         classUnderTest.ParseResources();

  12:  

  13:         Assert.AreEqual("F4", classUnderTest.ResourceType);

  14:     }         

  15: }

  16:  

  17: private static Stream CreateStream(params string[] lines)

  18: {

  19:     string rawContent = string.Join(Environment.NewLine, lines);

  20:     return new MemoryStream(Encoding.UTF8.GetBytes(rawContent));

  21: }

If we had a really complicated external file I would more than likely stick it into an embedded resource text file, but that's only if the file was complicated or a pain to create in code as a string.  The point is with the factory in place the test controls where the data comes from, not the class under test.

It always amazes me when I find some little gem of functionality in a code library that I've used for some time.  Today I was amazed to find out that RhinoMocks has a logging facility built into it, and I'm willing to bet this feature has been there for a long time and I just never noticed it.

Turning on RhinoMocks logging in your test fixture setup (or test) outputs all kinds of nifty informational messages about what RhinoMocks is doing.  There appears to be 3 built in loggers in RhinoMocks:

• TraceWriterExpectationLogger
• TraceWriterWithStackTraceExpectationWriter
• TextWriterExpectationLogger

Here's a simple test case using TraceWriterExpectationLogger (line 4):

   1: [Test]

   2: public void Should_login_user_with_valid_user_name_and_password()

   3: {

   4:     RhinoMocks.Logger = new TraceWriterExpectationLogger();

   5:  

   6:     var userRepository = MockRepository.GenerateStub<IUserRepository>();

   7:     userRepository.Stub(x => x.GetUserByUserName("sneal")).Return(new User

   8:     {

   9:         UserName = "sneal",

  10:         Password = "password"

  11:     });

  12:  

  13:     var controller = new LoginController(userRepository);

  14:     controller.Login("sneal", "password");

  15:     

  16:     Assert.AreEqual("sneal", controller.UserContext.UserName);

  17: }

You might have noticed I'm using the new AAA syntax in RhinoMocks 3.5.  Very elegant.  No setup method, no explicit replay or verify calls.  I really like it.

Using the TraceWriterExpectationLogger looks like this from the ReSharper test runner, notice the trace messages from my mock:

So the next time you get stuck with an over complicated test session, try turning the logger on - I know I will.

Sensitive information on your website should be encrypted between the client and the server, which generally means we need to use SSL (https).  How do we require SSL on specific MonoRail controllers or URLs?

With ASP.NET you could go into IIS and just check the "Require SSL" checkbox for a particular ASPX page.  With MonoRail, or even ASP.NET MVC, there's no corresponding resource on disk for IIS.  So how do we enable SSL at the controller level?

First off you need to add a certificate to your site in IIS, make sure you don't check "Require SSL" at the site level otherwise all requests will need to be over https. Remember we want finer grained SSL settings.

The solution I came up with was to create a MonoRail filter that gets runs before every action on a controller.  This declarative solution using attributes is much better than a base class since it can easily be added or removed from a controller.

   1: public class SecureChannelFilter : IFilter

   2: {

   3:     public const string AppKey = "SecureChannelFilterDisabled";

   4:  

   5:     public bool Perform(

   6:         ExecuteWhen exec,

   7:         IEngineContext context,

   8:         IController controller,

   9:         IControllerContext controllerContext)

  10:     {

  11:         if (context.Request.IsLocal)

  12:             return true;

  13:  

  14:         if (context.Request.Uri.Scheme == "https")

  15:             return true;

  16:  

  17:         bool disabled;

  18:         bool.TryParse(ConfigurationManager.AppSettings[AppKey], out disabled);

  19:         if (disabled)

  20:             return true;

  21:  

  22:         context.Response.StatusCode = 403;  // access forbidden

  23:         return false; // don't continue with request

  24:     }

  25: }

As you can see from the code, the filter allows local requests through without SSL but requires SSL for all other requests unless the filter has been configurationally disabled.  This allows us to run without SSL on our local development boxes.

If a request requires SSL and is not coming in over SSL, this filter then returns a 403 (Forbidden) status code which will then end up showing the IIS 403 error page.  If you wanted to get real fancy you could change your 403 error page to just redirect you back to the requested page, but using https instead of http.

To require SSL for a particular controller, like lets say a credit card controller, we would add the Filter attribute specifying the SecureChannelFilter:

   1: [Filter(ExecuteWhen.BeforeAction, typeof(SecureChannelFilter))]

   2: public class AccountDetailController

   3: {

With that in place we can feel confident that our controller will not be viewable without SSL.

My combination of a Microsoft USB Natural Ergonomic Keyboard 4000 and a Microsoft USB Dual Receiver Wireless Mouse was causing my PC to immediately wake after hibernating.  This was also causing S4 sleep mode in Vista to fail to wake up.

Normally the wireless mouse has a wireless keyboard as part of the package, but I'm only using the mouse so I think this was causing problems - my device manager showed two keyboards even though I only have one wired keyboard.

To fix this I ended up disabling both the keyboard and mouse (receiver) from being able to resume the PC.  You can do this using the command line tool powercfg.  Here's what I did:

powercfg -devicedisablewake "Microsoft USB Natural Ergonomic Keyboard 4000 (IntelliType Pro) (001)"

powercfg -devicedisablewake "Microsoft USB Dual Receiver Wireless Keyboard (IntelliType Pro) (001)"

You can verify the device are disabled using: powercfg -devicequery wake_armed

After disabling both of those, S4 and hibernation started working again.

Over the years I've struggled with naming conventions for unit test methods, picking up various habits from different projects and people.  Roy Osherove (who reminds me of Adam Sandler) at one point recommended the following format for your unit test names:

[MethodName_StateUnderTest_ExpectedBehavior]

Although workable, and certainly an improvement over chaos, I don't find it all that appealing.  Non-programmers probably won't get it, and even programmers might have to read it a couple of times - at least that's what I ran into.  It does organize a group of tests in a fixture nicely, but beyond that...  its just not for me.

I've tried varying other methods, but I've generally always started my test names with some sort of assertion like "Should" or "Can".  This makes the test at least state what the expected behavior that is supported in a semi-fluid way.

Beyond that I like my unit test method names to convey exactly what is being tested, not just the class or method name being tested along with a state - I want a full sentence describing the expected behavior.

Up until recently I've been following the .NET naming conventions for my unit tests, but the simple fact is my method names are too long to be readable sentences.  You see, my test method names tend to be sentences which may or may not come from the user story or task itself. 

Here's an example method name from my current project using the .NET naming conventions: ShouldRedirectToShippingPageWhenShippingIsRequiredAndShippingAddressIsMissing.  Not only is this long, but its also unreadable except to programmers.  Even to programmers this isn't pretty, its just too long.

Now here's how I've been formatting my test names as of recent:

Obviously I'm breaking .NET naming conventions left and right here, but I don't care who you are, that's waaaaay more readable. Even more importantly I can discern what the test does just by reading the method name.  I find this handier than reading comments since it also shows up in your test runner. 

There's little need to go back through and re-read the test itself to figure out what the test does, its clearly stated in the method name. With this style anyone can go back and read the unit test method name and figure out the expected behavior.

I've never been too happy with the .NET naming standards especially in regards to unit tests.  The world is bigger than .NET, so take that convention!