The World’s Leading Microsoft .NET Magazine
Sign-In | Register
   
 
timstall

Donate Today!

Search Box

 

Calendar

««Jul 2009»»
SMTWTFS
    12
3
4
567891011
12131415161718
19202122232425
262728293031

My RSS Feeds








Mailing List

Most Popular Tags

                                                           

Why you need to be able to write code on a whiteboard

« H E email
posted Thursday, 3 July 2008
During a software engineering interview, you need to be able to write code on a whiteboard. During too many interviews, at multiple companies, I've seen candidate after candidate struggle to write simple code on the whiteboard. Many of these candidates are decent people, with CS degrees, Master degrees , "years or experience", "senior developer" titles, etc... Yet they cannot write 10 lines of correct code on a whiteboard.

 

For example, such candidates will struggle to answer "given a array of integers, write a method that returns the sum of all the positive numbers." Seriously. This is just a few lines of trivial code - no advanced API, no design patterns, no trivia, no tricks. It's what you'd see in a college CS101, first semester exam:

public static int GetPositiveSum(int[] aInt)
{
  if (aInt == null)
    return 0;

  int intSum = 0;
  foreach (int i in aInt)
  {
    if (i > 0)
      intSum += i;
  }

  return intSum;
}

I've seen experienced, honest, candidates continually miss code of this simplicity.  They'll have logic, syntax, or style problems:

  • Logic - They'll add the numbers wrong, such as overwriting sum (intSum = i), or adding it exponentially (i += i), or completely ignore any validation (what if an input parameter of a public method is null?) It's one thing not to get bogged down in tedious plumbing, but a candidate should be prepared to call out if something could crash their code.

  • Syntax - A significant chunk of developers just dismiss syntax, emphasizing that they know the concepts instead. Good recruiters don't care about trivia, like if you miss a semi-colon at the end. But I've seen people have the wrong method signature, declare a variable wrong, have the wrong for-loop syntax, or reference an array wrong. A mistype is okay, but when you try to drill down on concepts ("Does the variable intSum need to first be assigned before being used?", "Will your loop execute the correct number of times?"), and they shrug it off, that's not good.

  • Style - Style is subjective, but important none-the-less. A good recruiter doesn't care if you indent with two spaces or four spaces. But there are other "style choices" that really do matter. I've seen developers declare their variable out of scope, such as using an extra static member instead of keeping it encapsulated as an instance field. I've also seen many devs just dismiss validation by wrapping the method in a try-catch. Or they'll make a method instance when it could be static instead. It's okay to have personal coding preferences, but these kind of "style" things actually affect the functionality of the code. A candidate should be prepared to explain why these made certain "style" choices.

Obviously, recruiters know that the candidate can write code, and could stumble through 10 lines of C#. But the idea is that if a candidate struggles to write trivial code, without the aid of Visual Studio's intellisense, compiler, and debugger, then they don't really get it. In other words, if a candidate uses VS as a crutch for simple code, then they're probably just "coding by coincidence" as opposed to proactively thinking through the code. And while you can "code by coincidence" for easy problems, on small, standard, applications, it will result in endless bugs on larger, complex apps. For example, if a candidate doesn't realize that they need to check for a null input parameter on simple code (even when prompted), how can they be expected to validate complex and critical code?

 

Some interviewees seem to dismiss these coding questions as "beneath them". The problem is that you must judge the unknown by the known. If a recruiter observes the candidate mess up simple code (that the recruiter can see), they'll be less likely impressed by fancy-sounding projects that they [the recruiter] cannot see. In other words, if for whatever reason the candidate cannot conceptually work through simple code, most recruiters won't even pay attention to all that allegedly complex code that the developer wrote elsewhere.

 

As a candidate, this coding on the whiteboard is the chance to shine. This is not the time to say things like "I guess this is how you do it", or "I'm trying to remember back in my college days". Rather, this is where the candidate can show that they know C# so well such that they can write it straight - without any crutch - and then explain it, and then adapt it on the fly. Now that's a great way to get off to a good start in an interview.

 

 

FYI, here are some of the unit tests that I'd run the above code through:

Assert.AreEqual(0, GetPositiveSum(null));

Assert.AreEqual(0, GetPositiveSum(new int[] { 0 }));
Assert.AreEqual(0, GetPositiveSum(new int[] { -1, -4, -4 }));
Assert.AreEqual(0, GetPositiveSum(new int[] { 0, -4 }));
Assert.AreEqual(0, GetPositiveSum(new int[] { Int32.MinValue }));

Assert.AreEqual(4, GetPositiveSum(new int[] { 4 }));
Assert.AreEqual(10, GetPositiveSum(new int[] { 1,2,3,4 }));
Assert.AreEqual(4, GetPositiveSum(new int[] { -4, 4 }));
Assert.AreEqual(Int32.MaxValue, GetPositiveSum(new int[] { Int32.MaxValue }));
Assert.AreEqual(3, GetPositiveSum(new int[] { 0, 1, 2, -3 }));

.

 

tags:  

links: digg this    technorati    


comments (3)


1. Derik Whittaker left...
Thursday, 3 July 2008 10:45 am :: http://www.devlicio.us

Tim,

I agree with your intent of this post. However, I would not hold syntax errors against someone. I am more looking for their thinking and approach then the 100% right syntax.

Also, Could reduce the code to this and make life a little better

return aInt.Where( x => x. > 0 ) .Sum();


2. Dave Schinkel left...
Thursday, 3 July 2008 11:02 am

Ok, I do have to reply to this, cannot refrain. This is not meant to sound irritated but it's meant to debate your points.

I disagree with 50% of what is stated here. Most developers do not remember 100% syntax even if they lets say use a for loop every day. Lets say they had for(i=0, myArray.Length, i++). Ok fine, missed the i < myArray.Length

Developers take advantage of snippets often. Do they make it a point to remember syntax of all things, simple or complex. I can tell you that even architects don't remember all this. They certainly try, and some they just remember because they use it a lot or even if they do use things a lot, our brain tends to pick and choose what to remember in a sea of syntax typically. If all developers had the memory to do so, would that not be a great thing..no need for snippets or MSDN. That is not to say hey, the developer should at least know how to construct the syntax for the most part but being 100% on...that's unrealistic.

If a developer has the general loop and method hashed out...and it's 90% close in an interview, remember that this developer may be a bit nervous. One could also say "hey, then how would he hack pressure in a work situation". That would not be a fair assessment either as that's a different kind of stress alltogether.

With that said, being too picky on syntax and not listening to what the developer is saying and missing a simple null check...well, sure but in reality it's an interview. If they have the logic mostly right I am pretty positive when they are coding at their desk, they're going to be much more focused on those little null checks when they are actually head down in code.

If a developer can tell you and explain design patterns he or she has actually used, or for example how to bubble up items efficiently from a DL to BL or PL... doesn't that tell you a little about their "intelligence" and "capability"? A whiteboard is not the end all and does not gauge as the primary filter to get a "good" candidate. I can tell you probably 50% of the coders out there can't even hash out that simple question. But if they come close, hey, again, this is an interview. Maybe the candidate is nervous...or tired? Again, interview vs. really sitting in your cube vs. having to remember syntax 100% is way off base.

So with all this said; If the guy is a decent guy, and he can hack out the logic on a board and it makes pretty good sense (he used a for loop, he was able to check return an integer value, whatever) then I would say he's a pretty good coder and there are other things such as potential there especially if he's already been using Generics, Anonymous methods, Extension methods, and other more advanced "stuff" out there already. Does the candidate remember the exact syntax of everything even the small stuff....no. If you do, give me your memory cause mine is not that perfect. Maybe he did not check it in a perfect way due to just being nervous? When you have an interview when someone is being that picky it’s sort of difficult to be perfect when they are looking at SYNTAX with a 1000x micron microscope.

Half the battle is getting a guy who CAN contribute (by talking to him you can figure this out without even a whiteboard) and wants to grow and is a team player and works well with others is very important. I thing those are much more important than perfect SYNTAX in the end.

Other than that, your blog rocks! Continue with the good work, especially the “team” attitude!


3. Tim Stall left...
Thursday, 3 July 2008 2:42 pm

Thanks for the replies.

Derik - I completely agree with your comment: "I am more looking for their thinking and approach then the 100% right syntax." A syntax error or two is absolutely no problem. My point is that syntax errors on every line, which directly border on conceptual errors, which a candidate doesn't see after several promptings and direct hints - that is a problem.

Dave - I agree with several of your points. I am also eager for a candidate who discusses higher-level concepts (design patterns, codeGen, automation, Generics, Anonymous methods, Extension methods) - of course that's more valuable then a trivial syntax thing. I agree that people can be nervous and tired, which is why I personally always try to build people up by playing to their strengths and giving them the benefit of the doubt. I agree that people shouldn't need to have perfect memories (I sure don't). I completely agree with your comment "and wants to grow and is a team player and works well with others is very important. I thing those are much more important than perfect SYNTAX in the end."