Just, wow. I'm sorry you have to deal with that.

For my next job, I've thought about offering to work for free for a week or so as a kind of mutual trial period. I want to know what the entire office is like, what the codebase is like, what the tools are like, and what actually needs to be done. If they want to rip me off and get a week of free work, great! That's exactly the kind of thing I would want to know about a company upfront. And after that week, they should know the degree to which I'm a fraud and be excited to pay me commensurately.

I know this wouldn't work for most potential employees since they don't quit their jobs until they have another one, but I always take a few months between jobs. I wonder how I might actually be able to pull this off..

Legally, you probably will not be able to work for free. That said, you can always propose a 1-week contract-to-hire.

Not for a week and not for free, but we converged to basically saying to every new hire that their 3 month probation period is their hands-on interview. You look at us, we look at you and let's err on the side of caution and assume it won't work. So far it worked well.

Seeing what the codebase is like for just a week may not be something many larger companies would be too happy with (think IP theft).

Instead of offering to work for free, why not propose an at-will contracting arrangement (as opposed to being an employee)?

On the other hand, I'm a skilled dev with only a smattering of python experience, but if you asked me this question I'd have no idea and wouldn't think twice about looking up the python docs for both. What are you actually asking?

P.s. I don't believe anyone actually fails fizz buzz.

I suspect failing fizz buzz typically is caused by nervousness. I've one gotten so nervous in an interview that I'm certain I couldn't have implemented fizz buzz either at that time. I've also seen it on interviewees. As the interviewer it also sucks because you can't be sure it's nervousness.

If someone is the type of person that gets nervous in an interview, these are the people that really need to do good side projects.

Not true. People fail all the time. It's shockingly more common than I imagined possible.

People fail fizz buzz all the time.

I don't believe that. I'd really like a 21st century study showing that devs with > 3 years of experience fail fizz buzz, and that failure is predictive of being a bad developer (and not being a shitty interviewer)

Yes, of course a dev with > 3 years experience should be able to fizz-buzz in their sleep! That's the point!

It's not devs with > 3 years experience or even > 6 months. failing fizzbuzz. It's people _pretending_ to be devs with > 3 years experience. Or folks who started in programming years ago and drifted so far they can't get back to nuts and bolts. Or people who know the principles but can't express them. Or any number of other cases.

Like other folks have posted here in response, I've seen some really sad fizz buzzes in my day, often from people who had no business being near a computer let alone interviewing for a tech job, but somehow landed a phone screen.

And let's never forget the best/worst fizz-buzz ever: http://thedailywtf.com/articles/The-Fizz-Buzz-from-Outer-Spa...

Bear in mind that everyone here on HN is here because they're interested to learn about advancements in technology (and matters of broader interest) - it's too easy to mistake this little echo chamber for the entirety of the talent market.

I often read people say they'd be "insulted" if asked to do fizz-buzz, or would "walk out". I think that's an over-reaction - fair enough they need to make sure you're not useless and lying on your CV. As long as there's a more interesting follow-up question, I don't see the harm.

If you don't believe Jeff Atwood, I'm not sure why you'd believe me based just on my anecdata, but at a previous job I gave a simple filtering programming task to interviewees (not exactly fizz buzz, but very close. Single loop, multiple 10-line solutions possible).

Out of 10, only 1 solved it well, 2-3 solved it acceptably (only edge case bugs), the rest never solved it, or had obvious bugs or code that would never pass peer review.

Of course, I could just be a shitty interviewer, but I always had a (changing) peer present during interviews, and I hope we were an honest enough company that they'd tell me if they thought I was.

Yes, this is typical.

In 2013, I interviewed someone who had allegedly been working for a few years as a support engineer writing Ruby (using the "watir" gem) who could not even write the loop part of Fizzbuzz. They went completely silent on the call when I pasted the Fizzbuzz requirements into a shared code editor we were both viewing. After a few moments and my gentle prodding, they admitted they didn't even know how to begin writing the loop, so I thanked them for their time, wished them luck, and ended the call.

You don't have to believe it - check out the comments in Jeff Atwood's post, where many people assert they can't believe people can't solve FizzBuzz, look they've solved it right here, and post their incorrect solutions.

I've never given a fizzbuzz test, but I can assure you that many people fail to write a simple for... loop to traverse an mxn square. I've seen it so many times that I have absolutely no problem believing that the same people would fail fizzbuzz.

You really don't realize how bad candidates can be until after you've interviewed dozens of them.

One of my teammates had a phone screen with a guy who didn't know what prime numbers were...

You can't blame them for not keeping up with the latest Amazon offerings.

I've also never seen anyone fail FizzBuzz in the wild; I feel like even the barest of 20m phone prescreenings should be able to avoid that...

I was asked for my second job ever - on the phone - for commands that would list files in a directory, change directory, and create a symbolic link. I guess I've started doing that kind of prescreen now too

Once I failed a programming test on factorial. I was younger and less experienced in interviews than I am now, nerves got the better of me.

I implemented the thing, but with plus in place of multiplication. Before that, I realised I was struggling and asked the interviewer whether it was + or *, that was probably the moment he failed me.

I ask similar questions if somebody says he/she is python expert. failing that is not an immediate issue, but i would continue probing by asking other questions on this level. to figure out what the "expert" label means according to my own experience.

I consider myself pretty good at Python, and I would need to look that up. OK yeah whatever, one's a generator. Makes sense. Why would I need to memorize something like this in order to be "legit"? Clearly if I was gonna generate a fairly big range, I'd be like "I wonder what the memory implications for this are".

At the risk of being pedantic, but xrange returns an xrange object which implements things like __len__, __getitem__, etc

Web dev chiming in with a similar experience. Last month I interviewed three people claiming multiple years of PHP/MySQL experience, not one of them could tell me what an SQL transaction is.

I've worked with plenty of developers who knew what they were and massively overused them without any thought as to whether they were appropriate...