5 Alternatives to the Fizzbuzz Test for Hiring Programmers | Hacker News Reader

5 Alternatives to the Fizzbuzz Test for Hiring Programmers

david.elbe.me

47 pointsstandout83 comments

I like questions that bootstrap productive discussions. Showing code might work, but asking to write code is a bad idea. Even simple code can become a nightmare to write if the person is uncomfortable due to the natural pressure that arises in a technical interview. The best programmers transform themselves while alone, in front of their computers, and there is no way to induce this kind of behavior in an interview. There is no way to get completely "in the zone" there. The best you can do is to read code previously written and talk - a lot. Talk about algorithms and data structures if that's the case, but don't ask the subject to write it down. He is not prepared to.

To filter out extremely unskilled candidates, simple questions might suffice: "how many bits does a byte have?", "what's the difference between an array and a linked list?", "what is the difference between GET and POST?", "what is the difference between a function and a macro?", and also more informal questions: "what technologies are you watching lately?", " what fields of computer science you would like to dive more?". These make it very easy to spot people who have no idea of what they are doing.

One thing that I have never seen but I suspect it should work is to ask the candidate to write the code days before the interview, and then bring it to discussion in the moment of the interview. In this method, you eliminate the uncomfortable process of writing code in an unusual circumstance but keeps the feature of discussion.

Agreed that coding is not a very good idea on an interview, especially during a phone-screen. But it's good to pose a problem and make the candidate roughly describe the approach he would take. Combined with a small homework task that sounds good enough.

It's important to remember the purpose of questions such as these. The purpose is to short-circuit the interview process when you're presented with someone so hopelessly unqualified that they're wasting your time and everybody else's. That's why they tend to be laughably simple.

More detailed questions -- how they react in real-world situations, how they manage under pressure, and so on -- can come later, once they've cleared that first hurdle.

An article well worth reading here is "The Five Essential Phone Screen Questions" by Steve Yegge.[1] He gives some good advice on what to look for in the candidate's answer as well as how to construct FizzBuzz-style questions of your own.

[1] https://sites.google.com/site/steveyegge2/five-essential-pho...

I understand the reasoning.

You want to test my programming ability that's fine. Just don't make me be present on site (if this involves more than going somewhere in the same city or in the vicinity)

Or do a phone screen. You can filter people that can't code FizzBuzz with that, with a high confidence level. Just ask the right questions.

Because you can believe that to get called for a senior job interview and being asked to do FizzBuzz P! me off! It's extremely disrespectful.

Still better than an hour and a half timed hacker rank challenge. Who the hell even needs to implement an algorithm in an hour and a half?

I don't see the issue in being asked to write FizzBuzz. If you're remotely qualified, this is a 3-5 minute task before I can see, "OK, you pass the 'can fog a mirror' level of test; sorry about that, but you wouldn't believe the trainwrecks we get sometimes..."

I had a senior level candidate on-site about 15 years ago who seemed ready to physically fight me when I asked him to write some (approximately) FizzBuzz level code on the whiteboard. I'd gotten a whiff of, "Johnny can't code" from some of his answers and figured I needed to see how deep the rot went.

Come to find out, he couldn't do it and had snowed the phone screen and first two interviewers and was angry that the jig was up. Interviewing for a senior-level position is, sadly, no guard against hopelessly unqualified applicants. With the advent of glassdoor and pre-briefed interview candidates, phone screen questions are fairly game-able as well.

I find it funny that I never needed to do such test to gauge people's ability. Also, when I saw people using, I never saw it fail.

Example questions:

(Python) When should you use a list instead of a tuple? What's the difference between range and xrange? What does ' %s' in a string means? Then elaborate from there.

I don't think that anyone who can't pass FizzBuzz knows the answers to those questions.

We had an IT candidate with the same problem. Extremely strong interpersonal skills allowed him to skim past the first three interviews, but couldn't get past "how do you view the IP of your computer" in the technical interview.

And he also got really mad at the interviewer for daring to ask the question. Amazing what you can get away with if you have strong interpersonal skills and no sense of morals to hold you back.

"Write a function that takes three measurements in centimeters as input and returns a the volume over a litre"

I have a hard time understanding what this us supposed to mean. Is there a typo somewhere? "returns a the volume over a litre" sounds like gibberish, but then I am not a native speaker.

Yeah, it's gibberish. I'm not sure what was intended either. Something like "return how much the volume goes over a litre".

Not gibberish per se. 1000 centimeters cubed = 1 L So if you have 3 measurements in cm, you would multiply them all together and divide by 1,000 to get an answer in Liters.

[Edit for typo]

Not sure if you were being facetious, but you actually misunderstood the question (I think).

Oh sorry. Not saying the question is gibberish or anything. It's just missing a couple words so it's hard to parse.

The question is probably more aptly written as "Take the width, height and depth of a cuboid in centimetres, and return its volume in litres".

Non native speaker here. Does this above question mean, calculate volume with the three measurements and convert that from centimeter to litre? (thousand cubic centimeters make a litre)

Native British English speaker here. The question is not at all clear. It might be a test to see if the candidate says "can you rephrase the question?".

It means the volume in excess of 1 litre, since it talks about returning a negative number if it is less than that.

This. But as for non-native English speaker, that "over a litre" part is easy to miss. Special care should be taken when interviewing candidates not in their mother tongue and such single word catch should be emphasized more.

I am a native English speaker, and I've never seen that. I was very confused, and I would have had to ask many questions to figure out what "the volume over a litre" meant.

The "a" is superfluous.

>> and returns the volume over a litre

From the description of the problem immediately afterwards, they're looking for you to return "a" (a variable name) which is the magnitude of the volume given less the volume of 1 litre (i.e "a" cm^3 - 1000 cm^3)

The questioner really meant to say "Return as the volume exceeding a litre." Even saying "over a litre" will probably make anybody familiar with physics wonder just exactly what they are asking. "Volume over litres" is what it made me think initially which is very confusing as I don't know what that would actually be in the physical world (other than a nonsensical scalar).

It's a common idiom to use "over" as an equivalent for "divided by". I'm not certain that's what's meant here, now that you question it, but I assume it means "give the volume in fractional liters".

EDIT: Actually, looking at the context again, I'm quite certain that's not what is meant at all. They must want the part of the volume exceeding a liter, as mentioned in other comments. But that was definitely not my first interpretation, due to the idiom I just described.

It sounds gibberish to a native speaker too, but from context what he meant was, 'take three measurements in centimetres, calculate the volume and return the amount in excess of one litre.'

#5 (write a bad version of fizz buzz) is a great question. Just asking such a unique question in an interview would raise my estimation of the company.

I think that generally "how to write bad code" is a great interview topic as you probably get a positive fun response from those are know and get a nice insight what things they might be caring about.

Just how useful is it as a test? Suppose the "good" code is:

  for (1..100) {
    my $fizz = ($_ % 3 == 0) ? "Fizz" : "";
    my $buzz = ($_ % 5 == 0) ? "Buzz" : "";
    ($fizz ne "" || $buzz ne "") ? print "$fizz$buzz\n"
            : print   "$_\n";
  }

and the "bad" code is the one-liner:

  print ( ((($_ % 3) ? "" : "Fizz") . (($_ % 5) ? "" : "Buzz"))
     || $_, "\n") for (1..100);

or is the following:

  #!/usr/bin/perl
  @v=(0, "Fizz", "Buzz", "FizzBuzz");
  for($v[0]=1;$v[0]<=100;$v[0]++){
	$k = ($v[0]%3)?0:1;
	$k += ($v[0]%5)?0:2;
	print($v[$k]."\n");
  }

(All three from http://c2.com/cgi/wiki?FizzBuzzTest .)

What does that reveal about the interviewee that makes this a great interview topic? To my eye, I prefer #1, #3, and #2, but it starts to get into personal preference rather than anything seriously indicative.

Do you want to dock someone for not being able to give a seriously bad implementation?

The worse the code is, the greater the understanding of the language in these cases.

So how would you answer my question? Would you really dock someone who could give all three of those implementations, but struggled to give a truly horrible implementation? How bad does it need to be truly horrible?

I ask because I struggled coming up with a horrible implementation of FizzBuzz. My best attempt was to have Python create a sqlite table then use SQL to do the test. Such implementations occur all too frequently at http://thedailywtf.com/ .

But surely this would not be an example of great understanding of either Python or SQL. Therefore, I don't see how you can draw your conclusion.

Could you explain more fully?

I got the impression the idea wasn't about writing the poorest code, but getting a chance to discuss what would make something better worse. I personally put readability and maintainability close to the top of my list.

The question was "Write the worst – but working – implementation of Fizz Buzz that you can think of." It is designed to 'bring up some good laughs, and takes some of the pressure off of the applicant' with the assumption that the candidate will respond "Write bad code? I can do that!".

My question is, what if the interviewee is unable to produce bad code? Or even better, if the interviewee's worst code is better than the interviewer's best code. Does that inability to produce bad code on demand count as a negative?

Well that's up to the interviewer. I would say it doesn't count as negative, but that's me. I am assuming the conversation around it is what is important.

I recently got asked to do fizzbuzz in an interview. Then "fizzbuzz without the modulo operator". It's such an obvious way to approach the problem, that coming up with an alternative was surprisingly tricky. Caused a bit of a mental block for me.

If it's up to the interviewer then it isn't really a test of one's skills, is it? ("The worse the code is, the greater the understanding of the language in these cases") Instead, the interviewee needs to intuit what it is that the interviewer is looking for.

Doesn't that restriction reduce to "how do you implement modulo?"

  def modulo(a, b):
    return a - a // b * b

  def modulo(a, b):
    while a > b:
      a -= b
    return a

or pulling a hack from http://graphics.stanford.edu/~seander/bithacks.html#ModulusD... , which is equivalent to casting-out-9s but in base 16:

  def mod15(a, b):
    while a > 15:
      b = 0
      while a:
        b += a & 15
        a >>= 4
      a = b
    if a == 15:
      return 0
    return a

If it doesn't reduce to that, then it's another example of trying to guess what the interviewer is really asking, rather than trying to demonstrate one's expertise.

As I pointed out, I don't think the objective of the question is to test skills, but to start a discussion about what one values in "good code". It's an area that is partially subjective.

Yes, I understand your explanation. But you also said "The worse the code is, the greater the understanding of the language in these cases."

My question is, what if the interviewee is unable to give an example of bad code? I don't see how failure to come up with bad code implies a worse understanding of the language. I can also easily see how people with poor understanding of the language can still produce horrible code.

For example, at the end of this comment I write a simple assembly language interpreter in Python. That's a horrible solution to the problem. Explain to me how that shows I understand Python. Or for that matter, how it's a useful segue into a discussion of the factors that go into good code.

If the point is to discuss what "good code" means, then why not a question which is better targeted towards that specific goal? For example, give four examples of FizzBuzz, ask the interviewee to discuss the pros and cons of each one, and ask for a preferred ranking.

That's surely more like what happens in real life, doesn't have a failure mode where someone can't come up with really bad code, and actually leads to the discussion you want.

    import sys

    def execute(memory, code):
        lineno = 0
        while 1:
            try:
                line = code[lineno]
            except IndexError:
                break
            if line[0] == "jeq":
                if memory[line[1]] == memory[line[2]]:
                    lineno = line[3]
                    continue
            elif line[0] == "inc":
                memory[line[1]] += 1
            elif line[0] == "mod":
                memory[line[3]] = memory[line[1]] % line[2]
            elif line[0] == "print":
                sys.stdout.write(str(memory[line[1]]))
            elif line[0] == "load":
                memory[line[1]] = line[2]
            elif line[0] == "jmp":
                lineno = line[1]
                continue
            elif line[0] == "jz":
                if memory[line[1]] == 0:
                    lineno = line[2]
                    continue
            else:
                raise AssertionError(line[0])
            lineno += 1


    def fizzbuzz(n):
        memory = {"a": n+1, "b": 0, "c": 0, "d": "\n", "e": " "}
        code = (
            ("inc", "b"),
            ("jeq", "a", "b", 1000),
            ("print", "b"),
            ("mod", "b", 15, "c"),
            ("jz", "c", 14),
            ("mod", "b", 5, "c"),
            ("jz", "c", 12),        
            ("mod", "b", 3, "c"),
            ("jz", "c", 10),
            ("jmp", 17),

            ("load", "c", "Fizz"),
            ("jmp", 15),
            ("load", "c", "Buzz"),
            ("jmp", 15),
            ("load", "c", "FizzBuzz"),
            ("print", "e"),
            ("print", "c"),
            ("print", "d"),
            ("jmp", 0),
            )
        execute(memory, code)

    fizzbuzz(100)

There are much simpler ways without using modulo than defining your own modulo and using it. For example (in Java)

   class FizzBuzz {
      public static void main(String[] argc) {
        int next5 = 5;
        int next3 = 3;

        for (int i=1; i<=100 ; i++ ) {
            String output = "";
            if (i == next3) {
                output = "Fizz";
                next3 += 3;
            }
            if (i == next5) {
                output += "Buzz";
                next5 += 5;
            }
            if (output.isEmpty()) {
                output = Integer.toString(i);
            }
            System.out.println(output);
        }
        return;
      }
   }

Yes, that works. But I don't understand the goal of these variant question.

The original goal was to weed out obviously incompetent programmers. I accept that for some positions that's reasonable. But if I were given that question, and end up implementing my own modulo function to replace the missing operator, is that a mark against the interviewee, compared to someone with otherwise identical qualifications who implements your solution? Or someone who does this sieve solution:

  def fizzbuzz(n):
    n += 1
    values = ["%d"]*(n+1)
    for i in range(0, n, 3): values[i] = "%d Fizz"
    for i in range(0, n, 5): values[i] = "%d Buzz"
    for i in range(0, n, 15): values[i] = "%d FizzBuzz"
    for i in range(1, n): print values[i]%i

All of these have different performance/memory/maintenance characteristics, but the full constraints are unspecified. At some point it feels like the interviewer just wants to see the monkey dance, by throwing in non-realistic constraints.

I meant talking critically about code during the interview, discussing things that can make code bad or good.

One time I got a nice task to do as part of recruitment process. Given very, very badly written module with no tests and so on, my task was to implement new feature of this module and apply "the boy scout rule" with constraint that I could not change any main interface, "because it would broke a project".

I wish I could do more tasks like this which really tests real-world problems in jobs rather than valueless Fibbonacci's sequence.

The company was Krakow Office of Base CRM. Unfortunately, I do not work there. https://getbase.com/

Like this? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Question for the HN community: I've been learning Python on and off for about 6 months and I can answer all of these questions with ease. I'm subscribed to Interview Cake's emails and generally figure out their programming tasks. Question is, am I good enough to make the leap to doing 'proper' programming? The gulf between hobbyist and professional coded seems huge. How did you all cross it?

The only way to cross something is by going forward.

Agreed. And willingness to learn is more important than any current skill you have. Bet on your future skills, not your current shortcomings. Don't think "can I do this?" but "can I learn this?".

May be a mild case of https://en.wikipedia.org/wiki/Dunning_kruger_effect -- you think you know the correct solutions, whereas actually there are no single, unique correct solutions for at least some of the questions.

Don't be discouraged, though -- to gather certain kinds of experience you have to go into 'proper' programming. As long as you're open to questioning your assumptions and current state of knowledge, you stand to improve :)

Consider question #4 - there's no single correct way to indicate `underflow' condition. You could raise an exception, return zero, return negative value... it's all about considering and picking trade-offs, knowing convetions and matching client (caller) code.

Consider question #5 - while certainly you can provide your worst FizzBuzz, a programmer with different experience would probably provide a much different, perhaps even worse example [1]. As author notes, the 5th question is about experience with ineffective, brain-damaged, ugly, unmaintainable etc. code.

[1] speaking of some really insidious code: http://underhanded.xcott.com/

Thing is though, these questions / exercises are just that - exercises. If you can write real code / real applications (could you build a contact form, forum, shopping cart, order form etc in Python?), then you're ready.

I have been using Python for 4 years, and honestly I don't think I know the language so well (not compared to the knowledge I had of Perl before I started using Python).

I use Django, and I have an in depth knowledge of the framework. It has done pretty much all the hard work, so its a case of understanding its high level concepts and plugging them, together, rather than being able to implement every one of its features myself.

Whats going to be more use in the real world? Knowing how to use Django's reverse function, or being able to write my own in less than an hour?

This is an excellent question. Here is a blog post from a colleague of mine about how he got into professional programming without having an academic background in it: http://sharktank.co.uk/articles/how-i-got-into-programming/

Now, I should say in advance that my colleague is very talented and not everybody can do what he did. You will notice, though, that he spent several years before he was able to make the jump. He's now a full stack developer and a good one at that.

It is hard to give good advice because there are probably people who will hire you (at very low pay) even with as little experience as you have. You can then spend time working to improve on somebody else's dime. On the other hand, it will be very stressful because you will have a literal mountain to climb and you may even cause the failure of projects without realizing it.

I think ideally, I would spend a considerable amount of time working on real projects on your own, spending 3-4 hours a day average. After a few years you will probably be more accomplished than many new grads out of university.

The other approach is to go to school and get a degree. It is expensive (in time as well as money), but that piece of paper is worth its weight in gold at the beginning of your career.

Whatever you do, good luck! Try to understand that it will be 10-20 years before you even realize how much you suck, so never give up trying to improve yourself :-) The only people who I've met who were not embarrassed about how bad they were at the beginning of their career are people who are still bad at their job.

Thanks to everyone for the advice. I'm very aware that all I'm doing now is building very basic toy programs without any knowledge of how, say, a function that finds anagrams in an array of strings is 'useful' in the scope of a project a professional coder would work on. I've been dancing around Django and maybe it's time to dive in properly.

I find great joy in programming but I'm also grappling with the fact that I work in a well paid tech field (online marketing) and that the market for coders in the UK isn't great, especially for a (maybe) entry level Python coder. Could I conscience taking a £25,000 pay cut to code? Unfortunately I'm not sure I could.

I would encourage you to keep at it. If my colleague is anything to go by marketing people have an interesting skill set which can complement programming skills very nicely. Having experience with the business requirements is very useful and marketing requires a lot of people/presentation skills that many programmers don't develop.

It will take a long time (years as I said), but you can get there eventually if you want. The best way is to just build personal projects that you actually want. I would stay away from the toy problems after you have a basic grasp of the concepts and just learn along the way. You will need to go back to the toy problems to polish certain skills, but you should finding out what you need to work on from your every day coding.

Good luck!

I'd add to this list some simple binary logic questions. I've noticed that some programmers struggle with De Morgan's laws. Also many prefer to write hardcore one-line boolean expressions, often with multiple negations, instead of splitting it into smaller subexpressions assigned to properly named variables.

An interesting question would be hence to show a candidate some complex, buggy logical one-liner, with the comment above the code stating something different than the code actually does, and ask him to fix it.

A good candidate should extract booleans out of it and then see the flaw in reasoning, fix a bug, and perhaps write code so self-explanatory, so that the comments can be removed.

Do they do that when hiring mechanical engineers? Make them fix a Rube Goldberg design?

IMO fixing bugs and refactoring complex code is a part of daily job in any long-lasting project (especially when there's big rotation), hence it makes sense to check for that in an interview - contrary to asking some stuff that a developer won't ever likely do in a project.

I froze up a bit in an interview over a DeMorgan's law equivalency question. All I could think of were Karnough maps. On the way home I palm slapped myself when I remember DeMorgan's...

"not (A or B)" is the same as "(not A) and (not B)".

What you should be looking for in a candidate is the ability to do what a good developer would do in a real world situation. In your test a good candidate would just bin the opaque, broken code and write it from scratch in a better, more readable way. If something is quicker to rewrite something than it is to work out what the previous developer did wrong the right answer is always going to be a rewrite, and that's always going to be the case for a one-liner.

If you want to test someone's ability to fix broken code then you need to give them a test that reflects that, not a test where you tell them not to work properly.

Also, in the real world a candidate would probably google De Morgans laws.

Coding is not bomb disposal, if anything it's bomb construction. I would argue it's desirable for a developer to look these complex-and-not-frequently-used concepts up when they need them, to ensure they are not misremembering. It would be better to test a candidates ability go search for good reference material than whether they can remember your specific question off the top of their head. Wouldn't you want your nitration chemist to be regularly looking at his textbook?

De Morgan's laws are complex-and-not-frequently-used? What are you even programming?

I don't want to hire programmers who have to constantly be looking up how to program--that's an enormous waste of time. It makes sense to be looking up APIs, because interfaces change and have caveats. But DeMorgan's laws, divide and conquer algorithms, basic data structures, should all be in your brain. These are the building blocks of software and if you don't have them you can't build software.

> Also, in the real world a candidate would probably google De Morgans laws.

So I hand you a function to optimize:

    def is_taxed(transaction):
        return (not transaction.buyer.is_nonprofit()) and (not transaction.location.is_duty_free())

What about this problem would indicate to the candidate that they should Google "De Morgan's Laws" if they didn't already know it?

Most developers would be able to work out that the answer to the test is "return not (X or Y)" (unless Python has a nor operator.. I don't know because I rarely use it) without even realising they're using De Morgan's laws, but...

1. If the app is anything bigger than a trivial case there will be bigger things to optimize. Individual code optimizations give you so little in return they're rarely worthwhile.

2. Unless you're doing it millions of times a second you won't actually see the time saving. If you are then you're probably better off generating is_taxed when the transaction object is generated (eg generating and caching the result).

3. If you're still at the point where this change will actually make a difference you probably should be using something that isn't Python.

I wonder if something like Nuitka would be able to optimize it automagically.

> Most developers would be able to work out that the answer to the test is "return not (X or Y)" (unless Python has a nor operator.. I don't know because I rarely use it) without even realising they're using De Morgan's laws, but...

> 1. If the app is anything bigger than a trivial case there will be bigger things to optimize. Individual code optimizations give you so little in return they're rarely worthwhile.

> 2. Unless you're doing it millions of times a second you won't actually see the time saving. If you are then you're probably better off generating is_taxed when the transaction object is generated (eg generating and caching the result).

> 3. If you're still at the point where this change will actually make a difference you probably should be using something that isn't Python.

Yes, and that would be a great answer to my question.

Ok, maybe de morgans laws are a bad example for a complex idea, but I'll tell you this: I'd have to look them up to know they are called de morgans laws, as the name is not relevant to their use.

Right, I don't care if people know that they are called DeMorgan's laws, I only care that they understand them.

For the tax one, what rounding rules apply? How many significant digits are in the dollar amount and tax rate? Do I have access to IEEE 854 decimal or should I used scaled integers? And to how many digits?

This is important! Consider the following Python code, which shows how the order of operations can change the result by a penny:

  >>> d = 6405  # amount in dollars
  >>> r = 0.018   # tax rate of 1.8%
  >>> int(d * r * 100)
  11529
  >>> int(r * 100 * d)
  11528

This occurs because:

  >>> d * r * 100
  11529.0
  >>> r * 100 * d
  11528.999999999998

whereas if I use 854 math:

  >>> from decimal import Decimal as D
  >>> d = D("6405")
  >>> r = D("0.018")
  >>> int(d * r * 100)
  11529
  >>> int(r * 100 * d)
  11529

The person who proposed the question believed that the key point was for the interviewee to ask why the result was to be returned in an array. As an inverted fizz-buzz test, this question really reveals that the questioner has little experience with the details of doing accurate math on a computer.

You're absolutely right in your worries, but I think they usually don't consider those factors in the interview (bonus points if you mention it usually)

I usually prefer to work using integer cents, Decimal has some quirks in Python (like a unique precision for all numbers)

Well, that is why I called it an 'inverted fizz-buzz test'. The test itself reveals limitations in the organization doing the interviewing.

While you may be able to work in integer cents, there is still the question of how you handle rounding. Does Richard Pryor get your fractional cent, a la the salami slicing in Superman 3?

Banks typically work in five or six decimal places, and not the 2 decimals you can use. As a specific example, the final conversion rates from the national currencies to the Euro are given to 6 significant digits, eg, 1.95583 Deutsch marks to the Euro. Zimbabwe had problems when their hyperinflation caused overflows in systems that assumed 64 bit integers was enough for any currency.

I don't understand what you mean by "quirks in Python". Your concern seems to be with the General Decimal Arithmetic Specification, and not its implementation in Python.

Sure, rounding is important as well.

> I don't understand what you mean by "quirks in Python"

Setting a precision for decimal numbers "globally" in the module. https://docs.python.org/2/library/decimal.html

But of course, working with cents might get complicated if you're doing a lot of calculations, people should use Decimal

Then there was Django's Decimal field which wouldn't even do comparisons correctly and was filled with bugs (in 1.2 at least)

Minor correction; the decimal context is thread-local, and not set '"globally" in the module'.

It's similar in philosophy to C99's support for IEEE 754's rounding modes and exception modes. Compare to http://en.cppreference.com/w/c/numeric/fenv :

> The floating-point environment is the set of floating-point status flags and control modes supported by the implementation. It is thread-local, each thread inherits the initial state of its floating-point environment from the parent thread.

Since standard floats in C have similar behavior, it's hard for me to agree that it's really a "quirk".

I don't think these type of silly questions tell you anything meaningful as this is not how you code in the real world. Most people get nervous during interviews or don't perform well under timed tests. These type of interview questions really only test if you've heard these questions before. You're basically testing their interview skills.

There's no substitute for reading code they've written in production.

The majority of candidates I've interviewed do not have code they can show me. Usually because they don't have permission to share code from their previous job.

The idea of these questions is to filter out those that cannot program at all; any competent programmer should be able to solve these; or at least talk about them for a while.

The point is to avoid making a bad hire; not to find an excellent person.

Sure, any competent programmer could solve these under normal circumstances, but I've had a few interviews where I was kicking myself right afterwords for giving such stupid answers under pressure.

While I still believe that a short (paid, ideally) project is a more meaningful test of a developer's skills than whiteboard coding or the like, I thought this made a reasonable case for a quick set of heuristics to filter out non-starters.

I especially like the "bug fix" item (#3), as it contains a variety of different possible issues and seems like it would expose how the candidate thinks and approaches reading code (which they will be doing a lot of, if it's like every programming job I've ever had...), in a meaningful way. Combined with a nice but simple problem like the anagram (#1) question it seems like you could filter the wheat from the chaff rather quickly.

Semi-off-topic:

Unless I'm mistaken there's a typo in the little "about this author" blurb at the bottom: "David Elbe is web entreprenur..."

It also seems like the problem statement for #4 is not quite correct, I'm having trouble parsing it (as some others in this thread also seem to be):

"Write a function that takes three measurements in centimeters as input and returns a the volume over a litre"

Everything past "and returns..." needs some editing, methinks.

"the remaining volume past 1 liter" would sound more accurate maybe?

I still find it surprising people with no programming knowledge actually apply to these kinds of jobs.

This is like a construction worker applying for a doctors position.

Do they really think programming is just that easy that you can pick everything up at work.

We don't spend years learning this just for fun.

There's two questions here - anagram and something with centimeters and liters those with the imperial system may not be familiar with. I wouldn't actually bother explaining those - if the applicant can't figure out what an anagram is or how to calculate volume in liters from centimeters (which is simpler in the metric system), they're inept and completely unsuitable for software development.

I'd rather hire someone that can't write a word of code - yet - but can figure it out on his own using some googling than someone that passes fizzbuzz but gives me a blank stare when I mention the word "anagram". "I don't know what an anagram is /yet/" would be the correct answer.

A good set of questions - they don't rely on too much esoteric knowledge, and look to see how the programmer would apply any experience gained to date in solving them.

One question we often use early in interviews is "could you show me something neat you have learnt whilst programming?" - we want to see if they have actually programmed before, if they took the time to dig in a bit more than hello world or the fabulous Paula bean (dailywtf classic) and importantly, why they thought it was neat.

I enjoyed this and felt it was a more reasonable set of tests than what fizzbuzz usually equates to.

I do not test well. ever. Especially if there is a timer going. Thankfully, I've been able to get work from just taking about the stack or problems, and that's worked so far.

That anagram question...I would have never figured out to use sorting. I would have done a simple loop that checks to see if the letter exists in the other word. Loop until false is returned...The length check seems 100% necessary to solve this problem.

Solution they've described doesn't account for duplicate letters in a word. The right solution would be to build frequency maps of letters in each word and compare the maps.

(defn anagram? [a b] (= (frequencies a) (frequencies b)))

No, it does. Once both strings are sorted alphabetically, you just compare them.

"tallaf" -> sort -> "aafllt"

"laftal" -> sort -> "aafllt"

Does "aafllt" == "aafllt" ? yes? Then we're good!

What you're saying:

"tallaffffff" -> sort -> "aaffffffllt"

"latfal" -> sort -> "aafllt"

Does "aaffffffllt" == "aafllt" ? Of course not.

The length check is just early exit. Actually for my solution the length is necessary.

Your solution is good too - I actually googled after to see other possible solutions and counting characters was the "second" solution.

Your method doesn't account for the following case:

are_anagrams("moo", "mom")

Each letter in "moo" appears in "mom", and the length is the same, but the words are not anagrams of each other.

Haha, nice catch.

So there appears to be really only two solutions to the problem.

These are great kinds of questions because they can spark discussion, which is the point. Whether someone can solve the problem or not doesn't teach you much; what they say while solving it is illuminating.

These little questions are only going to weed out people who have never programmed.

I suppose some such people will try their luck from time to time, but how different is this to picking soccer players based on whether they can juggle the ball? Any pro soccer player can juggle the ball, but that's not what they do at work at all. And not everyone over the threshold is equally good at the actual job.

You can try to gather data to figure out a smart way to hire programmers, but then you have the problem that you aren't going to hire the ones you think are bad. So how do you know how they would have done?

It's a tough nut to crack.

FizzBuzz and the like isn't "juggling the ball"; it's "identifying shoes as suitable for soccer and putting them on the correct foot" level of qualification.

Let me emphase that; 75 out of 100 applicants to a programming job can not program. At all.

...

Remember, the goal is not to make people fail on tests - only to quickly discard the people who can not write software at an early stage to save time and effort for both of us.

...

I again want to emphasize that this is only to sort out the real developers from the crowd. I really don't want to waste anyone's time and energy on doing multiple interviews when we both can find out with a simple test that they're not going to make it. No pointing fingers, no harsh comments - just a simple test to find who we are looking for.

I was surprised at the need for all those disclaimers, but I guess it was necessary, after all.

If you want to hire a professional soccer player, and a candidate can't juggle a ball. Would you hire him?

Who cares if he does it at work? If he fails a test that, supposedly, "any pro soccer player" should pass, then he's not suited, is he?

And the other commenter is right---fizzbuzz isn't juggling a ball, it's knowing how to walk upright.

I am surprised, actually. And yet not.

I've interviewed hundreds of people in the past who all on paper had a degree in something numerical. And somehow they can't answer the question "what's the expectation of a dice roll?". That's supposed to be a warmup question.

It simply stretches credulity that someone, anyone, doesn't know this. Same with FizzBuzz. Just about any kid in a high school math class should be able to do either? The fact that people can't do it suggests a number of hypotheses.

- They think it's a harder question than it really is. One highly qualified lady made a "WTF" face when it dawned on her I was asking a grade 10 question. She didn't want the job later on.

- They think they've missed something, and are scouring their minds against hope that they'll figure out the missing piece.

- I've intimidated them like a bully. People aren't used to interviews where they might fail. Perhaps there's some psychological trigger I've inadvertently hit, and they've turned into rabbits in the headlights.

- They've lied on their CV but have shown up to the interview anyway. Maybe. How long can you blag this kind of thing though?

Maybe my priors (or evidence credulity) are just different from yours.

Reply on news.ycombinator.com