I have been reading a quora answer about why most of the developers fail FizzBuzz test and the author differentiates between Programming and Engineering and he says that programming is aimed at making the machine work, where as engineering is more about the artistic aspect of building software (which is highly dependent upon experience and tenacity to get the job done). That people wanna hire Engineers, but they test for Programmers.
This got me thinking about a common pattern I have been observing. Most of the algorithms I implement in a real world code are very basic. Most of the work I do, revolves around the fact that my code should be easily understandable to other people (and sophisticated algorithms prevent that), that people should be easily be able to modify it, repurpose it or expand it
In real world, if I ever was asked to implement FizzBuzz, I wouldn't even open my editor until I understood what is it going to be used for, what future features it will have, and what existing code will it work with. Once I understand it all, I might never write the code which most people write (or I myself write) during a fizzbuzz interview.
Maybe it's time to create a Software engineering fizz buzz rather than programming fizzbuzz.
I like the "Software engineering fizz buzz" idea. For backend engineers, I usually ask the candidate to implement a commonly used API in a language she/he is most proficient at.
The interviewer will give a simple user story to the user. "As a user I want to be able to add two numbers".
After the candidate implements that, "As a user I want to be able to subtract two numbers". At this point look how the candidate continues. If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if he just writes another method then zero points.
Then ask him to add multiplication functionality. If at this point he encapsulates the code as a class, good, if not then make him do that and let him choose the encapsulation(with no bonus points).
Now the point of this exercise is how good of a job does a developer do of figuring out what does the client want especially when client himself doesn't know what he wants.
Somehow once the Calculator class is implemented, the next user story is to "create an interest rate calculation method which offers different interest rate based on credit rating", the idea is the new user requirement is a client asking for to do something quite weird. You can't JUST add this method to the Calculator class. This is the point where the candidate shows how good he is in being an artist with the code.
Sorry I typed it all on mobile, so laziness got to me. But it seems like that you missed the point of the test by a fair margin. The test allows you to judge overengineering too. The whole idea is, give them scenarios like this, suitable to your values and business needs. Every language has abstractions, and it is the decision to figure out good abstraction vs bad abstraction vs no abstraction.
Making a calculator class is an overkill IMHO, and this is precisely why the next task is to "create an interest rate calculation method which offers different interest rate based on credit rating", the whole idea is, that here any developer worth their salt, will be separated from the chafe. Of course, you will need to help them a bit to steer in the right direction, but the test isn't about knowledge, but of their perspective.
> If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if he just writes another method then zero points.
Sorry for misunderstanding your whole point (no sarcasm, my english is not ideal)
The fundamental point is, who can best figure out the requirements of the customer, and write code which makes most sense with least amount of 'future problems'.
Do you do that on the spot or is it a "take home" assignment? I've known many solid programmers (myself included) that could code anything you want, but if you put them in a room, sit there and watch them do it, they'd freeze up. On the other hand, if you give them a project, give them a timeframe to develop it, then have them walk you through what/why they did, they would absolutely excel. It's sitting there in front of someone(s) and the expectation, that would just cause them to freeze up.
As long as the candidates get the logic flow on the solution, can write code down in well-formatted manner, pay attention to corner cases, it doesn't matter if the candidates actually complete the coding, if I think given enough time in a real work environment that the candidate has no problem in doing it.
There are some red flags I pay attention to. For example, readable code is very important to me since we work in a team and we spend more time reading code than actually writing it. Once we had a candidate. he got the coding right, but his code was very hard to read. It reminded me of some obscure C code in the past that one statement was trying to do many things so that it became very convoluted. For me, it is not "smart". It is bad engineering.
I just ask them to bring code, and tell them we're going to talk about it.
It doesn't have to be their own (it normally is though). It doesn't have to be good code (nobody has yet brought bad code, but I wouldn't really care).
I would rather talk to somebody in their own code and language. If they can't explain it to me, then that's a data point, too.
I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding.
This approach has been working well for senior candidates. It is much harder to interview new graduates.