Programmers who can't program

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/programmers_who_cant_program.htm]

I've lost track of how many "senior developers" I've interviewed who fundamentally can not program. Their resume makes them sound like the next Bill Gates, but they can't write 5 lines of code on a white board. (Jeff Atwood discusses this on his blog). I'm not talking about knowing useless trivia like the 19 overload signatures for StringBuilder, but rather core programming concepts like writing a for-loop or if-then structure.

Many devs are great at telling their credentials ("Yes, I have experience in C#") or simple fact regurgitation ("A DataReader is faster than a DateSet"), but they don't want to actually think. I expect this relates to Bloom's Taxonomy, namely that there are several tiers of thinking: mere knowledge (i.e recalling facsts) is easy, analysis and synthesis (what writing code requires) is hard. Someone one joked "Thinking is hard, which is why so few people do it." A related trend is that many people think that "coding" means "copying the right snippet from a Google search."

At Paylocity, every developer writes code each day, so any interview candidate is also required to write at least a trivial code sample.

What sorts of mistakes do interview candidates make:

• Compile errors
• Bad logic
• Ignored important boundary cases. -
• Code works, but it awful performance or hard to maintain

Why may this be?

• Some developers never really write code from scratch to begin with, they just tweak existing code or copy Google snippets.
• Some developers can't write code on the whiteboard because they're completely reliant on the IDE, intellisense, reference guides, and compiler to hold their hand for each line. They can't write code on paper because they never have before.
• Some devs only program by coincidence (constant trial and error until "that result looks right, so my code must work"). Writing code from scratch on the whiteboard is pro-active and deliverate, not just a coincidence.
• Extensive use of wizards, drag & drop, out-of-the-box functionality.

What can a candidate due to practice?

• Actually write code snippets on a whiteboard or paper - away from the comfort of a IDE.
• Write small code snippets from scratch in your IDE to solve a specific problem.
• Check out some of these samples: http://www.spoj.pl/problems/classical/
• Check out the "exercises" section at the end of your local C# book.
• Make sure that you can at least do the basics like:
  • public static bool IsEven(int i)
  • public static int Factorial(int i)
  • public static bool DoesArrayContainValue(string[] astrList, string[] strValue)
• When you're actually giving your answer in an interview, step through your thinking process, as this is what the interviewer is really after. It will also make them much more lenient on a trivial error if they know that you have the important concepts down.

What are the interviewers really looking for? Obviously the real code you write for a job is much harder than the above trivia. Interviewers want to see your thinking process and style. Do you think first or just whip off an answer? Can you communicate why you wrote what you wrote? How did you determine your algorithm?

This is what software engineering cares about, not if you've memorized soon-to-be obsolete trivia. I'm glad to work for a company that gets this.