The range/xrange question was likely to check if you were a fraud.

Having interviewed close to a hundred people in a year for a senior C dev position I can assure you that people lie like you wouldn't believe. They cheat with take-home tasks, they show others' code as their own. And that's in the system programming circles, where the level of professionalism is typically much higher than in app/web development areas. We got burnt really bad when a brilliant dude whom we relocated across the country turned out to be the laziest moron I've ever had a misfortune to work with. So you bet we started most of the interviews with fuzz-buzz kind of questions.

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...

Knowledge of the deepest arcana of the Python language is less valuable than the humility and self-awareness that keeps one from forming fast conclusions based on little data.

Oh how I wish I had that skill! And the complementary skill of knowing when what little data you have is totally enough and you should trust your gut instinct. I've waited far too long to make a decision when the answer should have been clear a long time ago.

That's a pretty elaborate story to rationalize the fact you didn't know the difference between range and xrange....

Unless you've written a lot of Python 2, or ported a lot of it in my case, then you wouldn't know. It's a stupid question with little basis in actually seeing if someone know's what they are talking about.

Really? I used python for a few years a long while back and I thought that this was common knowledge. Perhaps it was the timing of it all as I now that I google around a bit most of the SO posts and such are from when I was writing Python.

It doesn't need to be rationalized. I don't know it without googling it, but I can still get by writing some useful automation for Ops work. Granted, I haven't interviewed for a full-time Python gig, but even the one or two REALLY sharp programmers I know need to reference the web for a lot of stdlib stuff they don't use often.

xrange vs range is basic competence for any Python 2 programmer. They are two of the most commonly used functions and have very distinct uses. I think that was the point of the original post, however, that the question is so basic it is actually insulting - like interviewing a doctor and asking the difference between red and white blood cells.

I don't know this. And I don't care. I don't self-identify as anything near a "Python programmer" and yet I've written, modified, read, and debugged (and put into production at times), let's say 100's of thousands of lines of Python since the late 90s. Not a ton, perhaps, but I certainly feel qualified to write it.

I'm forced to maintain (or deploy) other people's Python code all the time. Personally, I would rarely choose it for a team project I have to maintain (if the choice is mine) because I've seen most teams commit the same annoying type errors over and over in every dynamic language I've ever used, including epecially Python. I've worked with much more competent Python programmers than myself who still do this.

But if I was on your team, I wouldn't complain and my code would be somewhere between pretty good to great. I would help the team ship that Python and ship it well.

I'm not sure what this rant says more about: me or this 'range vs xrange' question?

The problem is that it's bad style to write (in Python 2.x):

    for i in range(n):
        # your code here

because it potentially allocates a lot of memory for no reason whatsoever. It's the equivalent of this C code:

    int* r = calloc(sizeof(int), n);
    for (int j = 0; j < n; j++) r[j] = j;
    for (int j = 0; j < n; j++) {
        int i = r[j];
        // your code here
    }
    free(r);

If you don't want to deal with the distinction then what you can do is just treat range() as deprecated and always use either xrange() or list(xrange()) depending on the situation. But you had probably ought to know about the issue.

Ok, I would certainly agree then that I ought to know about that (for Python 2.x).

And here's the thing: despite my rant, given that explanation, I'm going to have to say I respect that as a Python (2.x) interview question.

But that's because I care about performance optimization and good style in every language I use. I'm not sure that everyone else always should or that this should be a deal breaker for a python dev gig.

The correct answer is of course, is that xrange doesn't exist.

I'd say that the correct answer would be "Which version of Python are you using?" but I actually kind of like the question - it's an important enough function that most people doing more than toy projects would have needed to use it at some point or at least would have considered it, but it's also something that has changed recently enough that people who are claiming long-term experience will have dealt with both versions.

My Python is rusty, but I actually had to go look up the differences - my initial thought was "I'm pretty sure it used to be that range() generated a list and xrange() basically just iterated a value, but at some point range() was changed to use the xrange() behavior - I'd have to look it up to give you more detail than that." I didn't realize that xrange() had been completely removed from 3.x, for example. For that matter, I was thinking that both of them might have existed in 1.x, though it looks like they were added in 2.0.

In short, it's the default behavior in Python 3; it doesn't exist anymore:

http://pythoncentral.io/how-to-use-pythons-xrange-and-range/

From that article (buried near the end for some reason):

>One more thing to add. In Python 3.x, the xrange function does not exist anymore. The range function now does what xrange does in Python 2.x, so to keep your code portable, you might want to stick to using range instead.

so they removed it from python 3?

`range` took the behaviour of `xrange`; the latter name was removed.

https://docs.python.org/3/whatsnew/3.0.html#views-and-iterat...

And if they don't agree or laugh, time for a table flip.

He didn't say he didn't.

Probably should of put /s at the end of my comment.... :)

Oh, oops, sorry!

Some people aren't born to code...

On the other hand, I think it's a good idea to sanity test your candidates, especially when it feels like everyone is trying to pass themselves off as a developer nowadays.