How will you know if you don't ask them a question that asks them to solve a small-scale problem that can be solved via a for loop? In our process it takes like 10 minutes. Granted we don't ask fizz buzz, but also we don't ask for implementations of textbook algorithm. Just a simple programming problem or two.
The way I see it is, the most condescending interview for a programmer is the one that contains no coding at all. And if you refuse to implement FizzBuzz, well, that is okay, but I will not recommend you for being hired.
Why is that?
The last two interviews I had involved no coding. Both led to an offer.
In one of them, I demoed a personal project and showed bits of its code. I think it would've been quite condescending of them to have me do a fizzbuzz after I've shown them 10k lines of working code.
The other company didn't even care to see my code even though I brought my laptop.. they just took it for granted that I can code.
I guess its a reasonable substitute, IFF the candidate has such a project to show.
> The other company didn't even care to see my code even though I brought my laptop.. they just took it for granted that I can code.
With such a company I would have doubts that I might start in a team with people who cannot code or code fairly badly. I expect, in an interview as an applicant, to see that the position that I start in has a certain appreciation of engineering work. If the prospective employer can convince me that they are caring about their staff's skill levels and code quality, etc without a code-interview, I guess its ok. But most companies that have no coding part in their interview process just don't assess the skill-level.
> With such a company I would have doubts that I might start in a team with people who cannot code or code fairly badly.
FWIW that was a military contractor hiring for a fighter jet project. Expensive machinery and lives at stake. They must have a bar for quality, and they can't leave it to the skill of an individual contributor.
Why do you need to ask them specifically to code fizzbuzz? There's nothing magical about it and it's a condescending coding exercise.
Ask stuff about their everyday coding and their favourite language. What's the difference between an Array and a Set (in your language of choice). How do you add an element to those? (if it's your day to day language you should remember, right?)
Tell me about an issue you had to debug. Tell me how (something) works in general. Something basic, no need to go into much detail, but just to see if they get the basic idea and have used it.
Again, who cares about fizzbuzz when you can ask them about http headers, network delays, etc (it will be more job relevant as well). People who can't code fizzbuzz will usually fall flat on those questions as well.
I'd consider it to be a "handshake". If the basics don't work you don't need to waste both sides time.
> People who can't code fizzbuzz will usually fall flat on those questions as well
yes, but it is harder to tell whether they were completely incapable (what FizzBuzz will tell you) or whether they just didn't touch certain topics in their career. I'll gladly hire a capable engineer who was active in a different domain who I am certain will be able to grasp the necessary knowledge quickly.
Someone who wants to know if you can code at all, or if you’ve just learned to talk the talk. Those people exist.
So you are correct in your pedantry, I did indeed mean high-pass :) Good job I'm not a signal-processing engineer! Or pretending to be...
> Yes, you don't. But you don't need to ask them that directly, or have them code live.
I am not being flippant, but why not? Asking seems to be the simplest way to know.
Also, you're making a strong assumption regarding the type of tech questions that OP is asking. You go from fizzbuzz (probably described by the interviewer, not just "do a fizzbuzz") to a sorting algorithm from memory. That's clearly not the same.
My personal experience interviewing candidates is:
At the end of our first interview (discussing their work, projects, experience, what they are looking for in the next 1-2-3 years etc.) I ask a very simple coding question that should take 1 min to solve if they were by themselves, with no complex algorithm and requiring no prior knowledge beside the language they are using. Typically, a fizzbuzz.
To solve that 1 min question, they have 10-15min where they can ask for guidance, help, etc. The goal is just to exclude people who just can't code. And surprisingly at least half of the candidates fail this.
Now maybe this is because our recruiters are not good enough, but this 10 min coding is super useful to prevent wasting more time on a candidate that is not a fit for us.
Why? Some people are very good at talking the talk and yet cannot write basic code. Fizzbuzz is a 2 minute exercise for most engineers I've interviewed (except those who fail it, which does happen) and is generally low stress for the candidate. It's not a trick question or require any mental acrobatics. Do you think you're above it somehow? Why?
In the same way I'd refuse if they'd begin asking me "how much is 10 divided by 2" or something.
"Oh but you can answer it in 2 min". Don't devalue your time. I bet they can ask something more relevant. I'm happy to solve a different coding exercise or test.
Experienced developers know this is a serious problem.
By the way feel free to try to write a sorting algo (preferably not bubblesort) by memory in your favourite language. It will be a good reality check.
> My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team
Yes, you don't. But you don't need to ask them that directly, or have them code live.