Ten years ago, a friend of mine called Imran wrote about hiring programmers.
He said that he was seeing people being interviewed
with good computer science degrees
who, while they knew all the theory,
had no idea about how to actually code in the real world.
And he proposed a simple test.
Now, hiring programmers is a tricky job.
I don't think that asking complicated lateral thinking questions
is a good way to hire people,
and neither is picking folks who you think will "just fit in".
But a simple test to make sure that someone can actually code:
yeah, that makes sense.
So here is the test that Imran proposed:
code something that'll play the children's game of FizzBuzz.
FizzBuzz is really simple.
Traditionally, it is played between two people,
and you count up in turn, 1, 2, 3, 4,
except every time there's a multiple of 3,
you say "Fizz" instead of the number.
And every time there's a multiple of 5, you say "Buzz".
So: 1, 2, fizz, 4, buzz, fizz,
7, 8, fizz, buzz, and so on and so on!
And when it's a multiple of both, at 15, you say "FizzBuzz".
Right, so anyone who's going in for a job in computer programming
should be able to pass this test:
write a program that outputs FizzBuzz for the numbers 1 to 100.
And it's a clever test for a number of reasons.
First, there are many possible approaches.
I'll run through a couple of them here,
but you folks will be able to come up with loads more.
If you want, pause the video now and have a go at it.
The approach that people choose,
and how they work through the problems,
will also give you a good insight into the style of programmer they are.
Do they quickly just bodge things together
to make it work and fix immediate problems,
like I do,
or do they start out planning for the future and try to figure out what might change later?
As well as that, FizzBuzz includes something that's a little tricky
to express well while programming:
If it's a multiple of 3, you do something.
If it's a multiple of 5, you do something else.
If it's a multiple of both,
you do a third thing.
And if it's neither, you do a fourth thing.
That’s not instantly translatable into code.
So I'm going to show you how I would do it,
the quick bodge-it-together approach,
and then we'll see how we can start to push it a little bit further.
I'm writing in JavaScript: it's not the best language in the world,
but it is one of the easiest to get started with.
First and most obvious step: create a loop.
We're going to want to run through the numbers 1 to 100,
so we create a for loop.
A for loop works like this: first, run that bit of code.
It creates a variable, i,
and it starts it out with the number 1.
Then every time it reaches the bottom of the loop, where the bracket is,
it goes back to the top and runs that bit of code,
increasing i by 1,
and then checks it against that bit of code.
If i is less than or equal to 100, it runs this code again.
If not, it exits the loop.
So whatever's inside here?
We are doing it 100 times,
and in each loop i is going to be increased by 1.
Programmers use the letter i for variables like this because...
er, actually, I have no idea, it's just tradition.
Okay.
Next up.
We need something to output the results.
In JavaScript, the sort that's in a plain text window,
you use console.log() for this.
If you were putting it in a web page you'd use something else.
So: console.log(i);
Output whatever is in the i variable.
Test it, and sure enough, you get 1 through 100.
Sometimes, though, we want it to output 'Fizz' or 'Buzz' instead.
So let's put that in an if statement.
If…
If what?
If i is a multiple of 3, we need to write 'Fizz'.
So: code.
That % sign is the modulo operator.
It returns the remainder after you divide something.
So here, it's saying, divide i by 3 and return the remainder.
If the remainder is zero, then we know i is a multiple of 3,
and we run that code.
And if the remainder's anything else,
then i is not a multiple of 3, and we skip it.
So now again for 5.
Now what about FizzBuzz, if it's a multiple of both 3 and 5?
Well, that's already been done for us, right?
then both these tests are going to return true,
and we get 'Fizz' and 'Buzz'.
So the last bit: if neither of thode are true,
just output the number.
In this case, we want that:
Okay, it doesn't look simple, but I promise it is.
That means "not equal to".
And that means "and".
So this whole section will only return true
if both the bits in brackets are true.
Cool.
Let's run it.
And that's... well, it's OK, I guess.
It does the job.
Except... what's going on at 15?
That doesn't say FizzBuzz.
That says "Fizz" and then "Buzz".
Two separate lines.
Two separate answers.
That is not technically correct,
'cos it needs to say 'FizzBuzz' there.
One line.
So we can add a few more tests.
Let's add a separate one for FizzBuzz there,
using what we've learned already.
If both of those tests return true, print "FizzBuzz".
And then let's add some more tests in there, so they don't fire twice.
This is getting quite ugly.
Repeating yourself like this is a sign of dodgy code.
It's clumsy, it's difficult to read and difficult to maintain.
So let’s change it around a bit.
Let’s test for both being true first.
Now we can use an ‘else’ statement:
if it’s not a multiple of both,
is it just a multiple of 3?
And if it’s not, if is just a multiple of 5?
And if it’s still not,
then we know to just output the number.
But to me, this is still dodgy.
Because if someone says,
'okay, now we want it to work on multiples of 7, not 5',
and that's a common sort of follow-up question for something like this,
you have to remember to change all the 5s.
Not a big problem in a section of code this small,
but once you start working on something big,
this is really bad practice.
Ideally, you shouldn't run the same test twice.
But how else can it be done?
Well, here's how I wrote this the first time I tried it.
Create a variable called "output" that's just an empty string.
A blank bit of text, nothing in it.
If i is a multiple of 3, you add "Fizz" to that line of text.
You don't output anything yet, you just store that for the future.
If i is a multiple of 5, you add "Buzz" to that line of text.
Don't replace it: just add it.
And then, don't test the number again -- test that string of text.
If it's empty,
we know none of these tests were true,
so you just make the text the value of i.
Now at the end of the loop, you output… well, the output.
So now, if whoever's running the interview says
'make it work on 7s, not 5s',
you only have to change one thing in an obvious place.
If they say 'make it work on 3s, 5s, 7s, 11s and 13s',
you just copy and paste that line and it just does.
Programming that with else statements would be a nightmare.
Now I think there are still better ways to code this,
particularly if you wanted to plan long into the future.
After all, those lines there...
I'm technically repeating myself.
But I'll leave fixing that as a problem for someone else.
This is good enough for me.
Now there are still some companies who use this particular test for hiring,
particularly because, y'know, some interviewers can’t think of anything better.
But there are also many problems like it:
things that a lot of computer science degrees don't teach
because they're all about the theory.
Me?
I'm more in favour of bodging things together and making them work well enough.
Just don't leave too much of a mess
for whoever comes along to maintain your code once you're done with it.
Thank you to everyone here at the Centre for Computing History in Cambridge
for letting me film
and thank you to all the proofreading team who helped make sure I got my script right.