Idiotic Interview Questions

Interviews questions always seem to be a topic that comes up frequently at a developer peer group I attend and while at work.  In a recent .NET Rocks! podcast, they touched on this topic and brought up the Fizz Buzz Test.  We have all been in interviews where we are given some ridiculous programming question, that is “intended” to show the interviewer your problem solving skills.  Or maybe (I think likely) they ask these questions because they are the stock questions, and everyone asks them.  It’s like asking someone for their strengths and weaknesses.  Do you really think people aren’t telling you what you want to hear.  These stock questions have stock answers.

Back to the ridiculous programming questions.   If someone asked me today in an interview some asinine array sorting question, or better yet a problem that you rarely encounter in the real world, I think my answer would be: Google.

Most of the problems that I encounter in the real world have been already dealt with.  I do not need to come up with my own solution.  I’m not arrogant enough to think that my solution is the best.  Using available resources (ie, Google) to to find the best solution to a problem seems like a better answer.  After all, wasn’t the point of the question to see your problem solving skills?  Why not ask questions related to Patterns, Practices, and Principles?  If the interviewee can discuss SOLID principles, doesn’t the Fizz Buzz Test seem idiotic to ask?

Agile and Beyond 2013

Jim Benson (@ourfounder), author of Personal Kanban, was the keynote speaker at this years Agile and Beyond conference.  Overall, I had a great time again this year and found the sessions I attended to be very insightful and reaffirmed some of my opinions.

One little thought I wanted to share was from Jim Benson’s keynote:

Velocity is the single most useless number invented by human beings.

Effort points are estimates.  Guesswork.  The velocity metric is a calculation of that guesswork.

We took something as inherently variable as an estimate and we gave it an integer value.

I thought this was pretty amusing when I really started to think about it.

Crappy Code Judgement

What’s the first thing most developers say after diving into legacy code?

It’s crap.  Giant plate of spaghetti!  What in the world was the person who wrote this thinking?

What’s interesting is we ask this question without really trying to answer it.  What were the objective and/or constraints to the person who wrote it? Without knowing this, you are making your judgement on unknowns.

Example #1: You have 30 days to complete.  This application is only assumed to be a temporary application.

Example #2: You have 30 days to complete, but don’t spend more than 16 hours.  This will be a legacy application.

Time and legacy are important objectives/constraints that were given to example #1.  Why practice programming to interfaces and create abstraction if you are writing throw away code?  If you know you are writing legacy code, maintainability is going to be more important.

We also often fail to acknowledge the technologies and practices that have changed.  Look back at your own code from 6 months to a year ago.  Do you catch yourself thinking:

I could of written this better by applying “X” pattern or following “X” principle?

Don’t be so quick to judge at first glance, unless you know all the objectives.