Today is Monday, 4th July 2022

Archive for July, 2010

The Only Question You Need To Ask: FizzBuzz

When you are interviewing job candidates, how do you know if they can really write good code? Do they simply copy/paste previous code from other projects? Or do they lead the development with new and creative code? In an interview, you need to ask only one question:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.  Link to original question

Sounds pretty trivial right? You would be surprised at how many developers can not complete this simple exercise. Here are some comments from hiring managers who asked this question:

Want to know something scary ? – the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

I’ve personally interviewed graduates who can’t answer “Write a loop that counts from 1 to 10” or “What’s the number after F in hexadecimal?” Less trivially, I’ve interviewed many candidates who can’t use recursion to solve a real problem.

Pretty alarming huh? So in your next interview, you can skip past the normal questions “Tell me about your previous project.  Have you used Hibernate/JSF/Framework X”?  Instead, just cut to the chase and ask the FizzBuzz question.

The Joel Test: How does your software team stack up?

The Joel Test determines the quality/maturity of your software development process. You can think of it as the poor man’s CMMI.  Answer the following questions. Give yourself 1 point for each correct answer. In general, you should strive for 10-12 points.

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

This all sounds good. We’re all doing this … right???? 🙂

Other Applications

How else can you apply this test? You can ask these same questions when interviewing for a new assignment / job. This will give you a good feel for what you are walking into (ie is this a hornet’s nest?). From there, you can decide if you want to be the hero and save the day. Or turn and run as fast as you can 🙂

Agile, Scrum, XP …. I’m All In!

In the past couple of months, I’ve developed an interest in the Agile software development process. The funny thing is that I’ve worked on “Agile” projects in the past, however we only used bits and pieces of Agile. In fact, we only picked the areas of Agile that we liked such as unit testing, frequent releases and continuous integration. The areas that we didn’t like were daily scrums and pair programming. I would say it was more of our corporate culture on why didn’t adopt daily scrums and pair programming. At the time, we felt daily scrums were a waste of time (why not just send an email w/ status updates). Also, the pair programming intruded on our personal space and private time for listening to music on our ipods. I know, very silly in hindsight but I’m sure you understand where I’m coming from.

And if that wasn’t enough, the developers on my team started conjuring up conspiracy theories about Agile development. In the hallways we would grumble that “code sprints are a euphenism for mini death march”. We thought the daily scrums was a diversionary tactic to micromanage the developers.  Oh boy, as adults we do not like change….

Lately, I’m starting to come around. After doing a good deal of reading on Agile, I finally understand the benefits of daily scrums and pair programming. I wasn’t aware that the scrum meetings where time-boxed to 15 minutes. I can do that on a daily basis 🙂 Also, the pair programming can work out fine if we have a well-defined task. For a given task, we can set up a pair programming session for 2-3 hours. That is doable and we’ll probably be more productive than one developer in an 8 hour day. Previously, I dreaded pair programming because I thought I would have to code for 8 hours a day with another developer sitting on my shoulder. But, 2-3 hours per day is okay.

Anyways, I’m Johnny-Come-Lately to the Agile party. But now I’m all in! Here’s a list of books that I just purchased. My plan is to get through them in the next month.  Wait, should I define that as a “sprint” ??? 🙂