Nope. At my last company I did all the technical interviews. Now, I have no idea how HR selected them, but I got their CVs on my desk and was asked to schedule a meeting with them.

And so I did. And oh boy, there were a LOT of previous Fortune 500 Senior devs that could not write anything that even resembles a correct fizzbuzz solution in any language they like without time restriction (I had to kick a few people out after I left them alone for 30 minutes and they told me they need more time).

All their CV's looked fine though. If I interview you, I'll ask you to write code, on any level. Usually I asked interviewees for ~3 code samples on paper starting with fizzbuzz moving up in difficulty to still beeing a relatively easy ~5 minute task.

I've had one interviewee that started to laugh when I asked him for a fizzbuzz sample and he said, "well that's like asking a baker to bake a bun". he proceded to write a fizzbuzz solution down and is apparently one of the top developers at that company now.

I don't care how senior you are. If you're offended by quickly writing down a fizzbuzz solution you're not senior enough to realize how much some people suck at programming.

Obviously the actual only interview only started after they wrote fizzbuzz, fizzbuzz helped me stop wasting my time and I convinced HR to stop sending me CVs of people that played bullshit bingo in their CVs.

Sure you could blame HR on this for not filtering good enough but HR aren't developers. Although I'm not saying HR couldn't have given me better CVs...

I've had very similar experience hiring for information security roles.

The volume of "good" CVs that landed on my desk was consistently high, but when we spoke to the candidates on their first telephone interview it became immediately apparent that they were not nearly as skilled at security as they were at writing CVs.

In the end, we inserted a 10 minute quick-fire Q&A at the beginning of the telephone interview which was as basic as "Define: Confidentiality, Integrity, and Availability" and other such trivial security knowledge. It was terrifying the number of people applying for mid/senior level jobs, or contracts with high day-rates who couldn't get past this. What was most galling was when people were obviously googling the anwswers whilst we spoke - we countered this with simple "which is better, and why" type questions so that there was too many variables to google and you also needed to defend your answer.

There were only a very small number of candidates who, when confronted with the Q&A responded in a "are you serious?" kind of way and just rattled off the basic knowledge in a couple of minutes. With these we could get down to the detail of the real interview pretty quickly.

Why would you trust HR to forward you the CVs anyway? I had to beg and plead to get HR to send me the unfiltered resume submissions but finally got them to do so. They're completely unqualified to determine which experience is necessary or relevant (which is fine, since they're not programmers; they just shouldn't be filtering resumes).

To be completely honest, I just really didn't care enough and had other things to do.

I did that when we were ~7 people, then the company grew, we got a HR department and I kinda lost interest in the company and was just doing my job. Efficient shouting-trough-the-room to get shit done was replaced by by slow corporate processes, office politics started to happen, somebody decided that our SMB shared folders must have a number in front so they are shown in the order admin though they needed to be shown... So when they decided to optimize folder structures for mouse-heavy non-technical users, taking my ability to quickly nagivate trough the directory structure, I decided it was time to leave :)

Edit: One funny thing I forgot, they built a file-name generator in excel we had to use :)

Fizzbuzz has not been very useful for me while conducting interviews. Nearly all candidates had no problems solving it fairly quickly. But many of these candidates couldn't solve much simpler problems such as "Initialize a list or array of numbers".

Jeff Atwood has a good post[1] on why something as simple as FizzBuzz is valuable when hiring engineers at any level.

[1] http://blog.codinghorror.com/why-cant-programmers-program/

For anyone above a jr level developer position, I would assume they'd have code or other artifacts you could review. If you weren't satisfied with their approach or style, don't interview further, or ask for clarification.

If you can not find anyone at all with example code/projects, perhaps then start employing fizzbuzz on folks, but... I can't imagine it's too hard to find developers with at least a minimal portfolio that demonstrates something at least as complex, if not moreso, than fizzbuzz.

The problem with sample code is that I have no idea if you actually wrote it. Maybe you copied it from Google, maybe your friend "helped" you. I have no idea. When I'm first interviewing you, I have no idea how honest you are. The only way I know for sure that you wrote the code is if I watch you write it in front of me.

I really like Fizzbuzz because for someone who is a good programmer, whether they've ever seen it or not, they can do it in about two minutes, and then at least I can believe that their code sample is theirs.

I once skipped the "simple programming exercise" part of the interview process for someone who was senior, and severely regretted it when it turned out he struggled with basic programming tasks.

He had a nice code sample (pre-github era).

Yes. I've interviewed "senior software engineers with 10+ years of C++ experience" that could not tell me the difference between a char and a char pointer.

I interviewed a self-declared "biometrics expert" once.

When I see "expert" on a CV I have learned to become cynical.

I asked him about his expertise and he spoke in platitudes about it - at a sort of BBC News kind of level. I'm certainly not an expert but I know sufficient to be able to ask useful questions about it.

He couldn't tell me anything at all about biometrics. I continued to probe.

Turns out that by "biometrics expert" he quite unashamedly meant he had, at the request of a manager, bought a USB fingerprint reader from PC World and installed it so that his manager didn't have to use a password any more.

>When I see "expert" on a CV I have learned to become cynical.

One has to play this game on marketing documents to be considered. For some reason "pretty good, definitely still learning" doesn't click with many HR people. You can't really blame candidates for trying to get hired by presenting themselves in an authoritative context.

I don't consider anyone an actual expert in something unless they have hard, indisputable credentials, like a long history of commits to the core project (for expertise in specific software/languages/frameworks), etc.

I completely agree that it's a sales vs. HR thing, and that the onus is on the candidate to make themselves appear as the best product on the market.

But something about "expert" really grates on me. I think it's that it is a self-anointed title in nearly all cases. There are legitimately experts in lots of different areas - if you happened to invent IDS, for example, you go right ahead and call yourself an expert. If you happen to have run a bunch of Snort rules across a prod environment for a year or two, you might be "experienced", go on, stretch it to "highly experienced" for all I care, but if you stretch it to "expert" then paint me cynical.

How is that even possible? Are you sure they weren't just having (to be crude) a brain fart?

Some of these stories about super experienced ("10+ years") developers not being able to answer the most basic of basic syntax or "algorithm" questions seem far-fetched to me.

Consider that most "valid" implementations of fizzbuzz are wholly dependent on awareness of the target language's modulo operator. Self-taught programmers can easily overlook that, and if a specific language is requested, it's easy to not know the syntax even if the concept is understood.

Really I don't think those sort of on-the-spot tests/trivia questions are representative by themselves. They may be a useful part of a larger investigation.

Two things to stop code sample plagiarism: choose a unique code challenge and, if you're really worried about it, give the client a laptop and tell them to bang something simple out right there and come back in 30-60 minutes to check.

Honestly, though, I've rarely depended on either code samples or code trivia to determine if someone is a good hire. If you sit and talk about dev with a person, you can tell if they're on their game or not 90% of the time. The sample/on-the-spot tests can help weed out that extra 10%.

I've also heard of a story where an "Expert in C" (verbatim from resume) thought that the * in the sample source code was a typo.

I'm not sure how this is possible either, but the world works in mysterious ways.

It's possible if the person lied on their resume about actually having 10+ years of experience.

We're moving towards a code sample as screening method, but then one of the interview sessions is an intensive review of the supplied code including tradeoffs made with other possibilities, etc. If they understand the code well enough to pass that session, personally it doesn't matter to me if they actually wrote it or not - they clearly could have.

In 2002, a company I interviewed with did just that. They tore my code apart, asking me to justify myself, and I felt like I completely bombed it.

In the end they said "Okay, you pass." When I asked why, the answer was "While we don't agree with all the choices, it's basically well-written and does something interesting. We just wanted to know if you were the one who wrote it."

Yeah, we make it clear to reviewers that the point isn't to inject their own opinions as to how it should have been written (and certainly not "your curly brace is in the wrong spot"!) but rather to determine:

- did they likely write the code, for obvious reasons - are they aware of the various tradeoffs and choices they made, i.e. we might not agree but can they make a reasonable argument for them - this demonstrates breadth of knowledge - how are their communication skills?

A lot of developers, myself included, do not perform well under a microscope. They almost can't even type when someone is watching them, making stupid mistakes and blanking on simple concepts. Luckily, the vast majority of programmers don't have to code under this kind of pressure on a daily basis. I find the most effective way to get a good sense of how someone can code is to give them homework to do that they can bring to the interview and discuss. That way they can take their time, put their best foot forward, and it won't weed out introverts or people with test or social anxiety.

I think I usually noticed when someone felt uneasy, so I left the room for a few minutes. Test anxiety might be really bad for some people, I know. But if it's that bad that they can't explain to me how to check if "n mod m == 0" then I think there are usually deeper underlying problems in their programming ability. And if it was really just anxiety, I'm sorry I'd rather have a false negative than hiring them.

I tried homework, it didn't really work that well for me, people would google and copy paste stuff and invest way too much time, in the end they couldn't explain what they did and it was just a waste of time for both parties. The other problem is that I usually let people work with whatever language/frameworks their familiar with. I ended up beeing not familiar with some C# stuff they used and couldn't really judge their code. Fizzbuzz is simple enough that you can see if it looks right in pretty much any language And it's done in 5 minutes even if that means accepting a few false positives.

Oh and, we had I few people where I noticed that they were really nervous and I thought maybe that's why they failed Fizzbuzz, so I invited them in for half a day and gave them a toy project to implement. Usually something really simple like, fetch this RSS Feed, parse it, save it somewhere, make sure that if you fetch it multiple times it doesn't save duplicate entries, and spit out the titles and URL's to stdout or a webpage or anything. A relatively real world exercise I think, nobody was constantly watching them, it was just a "get it done" job, they had internet, their own IDE, their language of choice and everything (a few people complained that they can't implement FizzBuzz without an IDE). And all of them failed. Hard. So I ended up not doing that anymore and treat a failed FizzBuzz as a K.O. criteria.

This is precisely what we do when hiring at our web dev/game/app agency. We have a somewhat casual meeting to first determine if the candidate is the type of person we'd want to work with every day and then we give them a challenge to take home with them. We provide a direct line to one of our developers that fulfills a similar role to what we are hiring for and encourage them to ask questions as they are completing the challenge. It's a very telling process. We are a very collaborative team and expect people to ask questions and grow together. When candidates ask questions that would be really easily answered by a quick Google search, or take far longer to complete the challenge than it should take someone who even sort of knows what they are doing, these are major red flags. At the end we review their code and see if their solutions are well thought out and up to basic standards. I should mention the challenge is typically extremely simple... Some candidates don't make it a priority and make excuses for days or weeks on end why they aren't finished. These don't tend to be the type of people we like to hire.

It's easy to tell if they wrote it. Just start asking them questions about it. How does this work? Why did you make this design decision? What happens in this case?

I would be delighted if an interviewer asked me such questions about my code.

Some interviewees talk up a big game. And some interviewers are too forgiving. "He fudged blah, but he probably meant factory pattern. Hired!"

Fizz buzz you can't skate around. Either you know how to implement something, or you don't.

On the other hand, when I need a new job, I am going to simply spend a week with an interview algorithms book and cram on all the little riddles and exercises that people seem to want.

I'd actually have to think for a minute on how to do fizz buzz right now, simply because it is so far remove from the actual engineering workflow.

> simply because it is so far remove from the actual engineering workflow.

Err, what? Fizzbuzz is NOT a riddle. It's intentionally meant to be a stupid simple test, and everyone has written stupid simple code at some point. Even as a "senior engineer" you'll have to write dumb business logic code, even if it's only occasional.

If you really struggle with fizzbuzz it would almost assuredly be a sign that you would really struggle to write quality software in a timely manner. It's also a sign that you really aren't familiar with even the basic control flow of your chosen language, which is similarly worrying.

The only part of fizzbuzz that's "removed from the actual engineering workflow" is MAYBE the modulus operation, which I'm willing to bet most interviewers probably won't give a shit if you goof on the syntax a little and write "%" when you should've written "%%".

And even then, a perfectly acceptable fizzbuzz can be written without using mod if you're not familiar with that basic arithmetic operation.

> I'd actually have to think for a minute on how to do fizz buzz right now, simply because it is so far remove from the actual engineering workflow.

This type of attitude is highly suspicious.

If you're not the kind of person who thinks fizz buzz is trivial, then there are actual red flags.

You don't have to leave it at just reviewing online code, but it's generally a 1st level filter. If someone has already written moderately advanced stuff online, have them write something at that level. If they can't do that, they wouldn't be able to do fizz buzz either.

> I would assume they'd have code or other artifacts you could review

90% of the code I've written, and all the clever stuff, is copyright of and property of corporations. There's no way I'd jeopardise my current job by showing someone else that code

Sure, but you ask it or something like that very early on, long before the person even walks in the door. If you're wasting valuable interview time with FizzBuzz on anything other than an entry level position, you're doing it wrong.

I've interviewed people who didn't know their way around a loop.

I would love to exist in a world where everyone could fizz buzz flawlessly.

They would be a waste of time, if every job seeker took advantage of such sites / blogs.

That's assuming you respect Jeff Atwood's opinions at all.

I've had senior developers, who came from a large respected companies, bomb fizzbuzz.

I'll stop asking fizzbuzz when people stop failing it.

I really like Fizzbuzz because for someone who is a good programmer, whether they've ever seen it or not, they can do it in about two minutes. I usually use it as my first question on the phone screen.

And you know what? More than 1/2 the people that claim to be doing a job writing code right now can not do it. If you can't write a simple loop in your preferred language, I have to wonder how you are doing coding right now and being successful.

I think part of the key with giving FizzBuzz is telling the candidate that any working solution is AOK and meaning it, in other words the dumbest brute force loop is a successful answer. My suspicion is that more candidates than one would expect get hung up worrying about giving some sort of clever answer to impress the interviewer that they bobble it up a bit.

That said, for FizzBuzz proper, one should have dozens of solutions memorized for these situations, but for similarly easy questions the candidate might not have come across that might end up being a big deal.

> My suspicion is that more candidates than one would expect get hung up worrying about giving some sort of clever answer to impress the interviewer that they bobble it up a bit.

I've definitely felt that pressure as an interviewee. It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.

The most fun technical questions I've had start with making a functional algorithm and then massaging it to meet whatever time/space complexity requirements are asked for. Sometimes it results in a complete rewrite and that's ok, the real world works like that too.

> It's pretty disheartening to write a simple and obviously correct implementation only to have the interviewer express their disappointment that you didn't use a particular optimization.

I almost always preface whiteboard coding sessions with "I'm going to write some dumb, slow code and then we can make it faster if you want. Sound OK?" I've never had anyone disagree with this, but if they tell you they want you to go straight to the clever solution, hey, now you know what they're looking for.

Even still, sometimes it helps just getting a solution down in order to step back and figure out the clever solution.

Plus, you can "scale up" the interview to harder questions so you can test the candidate without making them feel bad by bombing a touch problem at the very start of the interview.

Well, that is just it. Certainly 100% of the people I have ever worked with, even the bad ones, can write a for loop and an if statement. I mistrust the process more than I mistrust the people, though I suppose maybe the same bad people and endlessly interviewing.

50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?

I don't quite buy the whole fizz-buzz story, though I don't have an adequate explanation for what could cause these kinds of failure rates. Something seems very off.

>50% of working programmers can't write a for loop? Does that square with your experience outside of interviewing?

Not 50% of working programmers, but of the programmer applicant pool. The applicants who can find jobs quickly aren't in the pool very long, and so it's dominated by the fakers and those who otherwise shouldn't be there. ... Which should make the reported phenomenon a little more believable.

Fizzbuzz is incredibly useful to quickly smoke out people who have lied or faked or exaggerated their way into the interview.

However, that's all it's good for, which means it should be a single pass/fail question. Asking the candidate increasingly specific iterations of fizzbuzz would be a waste of time.