[Eleopteryx]

>Yes, they're incompetent.

So you feel confident in asserting that, at the time that the person made that tweet, the quality of the Python code that they shipped was poor, or it took an inordinate amount of time to produce? All because they had to look up len()?

[commandlinefan]

Actually, yeah. That one jumped out at me, too: that’s kind of like saying “I know how to drive a car, but I always have to look up which one is the gas pedal and which one is the brake”. If you’ve done _anything_ in Python, the length function is ingrained in your brain, so if you honestly don’t remember it, you just haven’t written any Python (or it’s been more than 10 years).

[jcranmer]

I routinely use several languages, and am constantly forgetting which ones use .size() and which ones .len(). It's not worth committing to memory because, if I get it wrong, the compiler will tell me "what is this function of which you speak?", and I will simply turn around and use the other one, at which point it starts compiling again, wasting me at most a minute of my time.

Furthermore, I should point out that it's not out of the imagination that someone wouldn't use len() all that heavily. Python has functional operators that let you do map/reduce-style operations on lists, strings, dicts, etc. that don't require you to use length all that much. My most recent python script only uses len() in two places for more robust error reporting.

[commandlinefan]

Well... try not to take this personally, but... that means that you're not really an expert in Python, which is what (I assume) the interviewer in the linked post was looking for. You're capable in several languages, and may be an expert in one or more of them, but if they're looking for Python expertise, asking you how to find the length of a string is a good way to get a feel for how much time you're going to need to get to where you can really be trusted to produce mission-critical Python software (which may not be a deal breaker, if you're good at a lot of other things).

[lleolin]

>that’s kind of like saying “I know how to drive a car, but I always have to look up which one is the gas pedal and which one is the brake”

OK, I agree, it's kind of like saying that.

But it's also kind of not like saying that.

Incompetence in driving and incompetence in software development are measured in completely different ways for completely different reasons. In driving, notions of what you definitely should know in order to qualify as "competent" extend from the intrinsic risk to other people's well-being. You can't simply transpose those notions onto the low-stakes sandbox environment that is software development. In software development, process is only important as far as it hinders or helps to deliver good code; competence should be dictated purely by results. All of the actual competence of driving comes during the actual process part; successfully reaching your destination is actually considered to be less important than simply not fucking anything up on the way there.

Sometimes I pick up a video game that I haven't played in weeks, and perform actions incorrectly because the button layout has been overwritten by the button layout of a similar and more recent game. It would foolish to say I'm wholly incompetent at either game; I still have a strong concept of what I should be doing and what I intend to do, it's just that I'm fumbling a bit at the specifics of executing my intent. Am I incompetent for looking up the button layout? Am I incompetent, but only for the 1 hour that it takes me to get back in the groove of things?

Declaring someone is incompetent is a bold assertion to make from such limited information. At the end of the day you either deliver good code in good time or you don't. I would be extremely reluctant to determine this guy can't deliver good code because he had to look something up. Figures no one will hire me.

[commandlinefan]

> I would be extremely reluctant to determine this guy can't deliver good code

See, I’d be extremely reluctant to assume the opposite - that he can, even though he doesn’t remember “len”. Given this one bit of information, all I know is that he has exactly one thing in common with everybody who doesn’t know how to program in Python: he doesn’t know the function for determining the length of a string. Now, he may (somehow?) know everything else about Python except for that one thing: I’m assuming the interviewer was a bit surprised (as I would be) that somebody presenting themselves as a Python programmer didn’t know len, but went ahead and asked him a few more questions which he may well have nailed. If the answer to every question was “I don’t know, I have to look it up”, you’d pass on him, too. I just can’t picture how anybody who didn’t remember that could remember much else, but I guess that’s why job interviews last an hour or so.

[lleolin]

>See, I’d be extremely reluctant to assume >Given this one bit of information, all I know

This seems like a really flawed way of approaching most things. Why assume anything? And if you're going to assume anything, why only factor in that one bit of information, and not any other context. How about the fact that he's been coding for 30 years and works at Google. Is that also relevant?

>I’m assuming the interviewer was a bit surprised

There was no interviewer in this situation. His tweet was not in regards to any interview. Did you read the article?

>If the answer to every question was “I don’t know, I have to look it up”, you’d pass on him, too.

But if I were to do so, at least in such a case I would be basing my suppositions on more than just one thing.