I like the idea, but my first reaction was that this is a test of how well you know Python's quirks (like the problems with not deep-copying things).
But then I realised that that's not true. For example, call-by-value and call-by-reference are pretty pervasive across languages: many of those examples would've worked the same in Java, say. It's not familiarity with Python, but rather familiarity with a certain kind of language (which admittedly constitutes the majority of those used in industry ATM) that the test demands, at a time when even Java is getting nice FP-like abstractions and the JavaScript community is cooking up all sorts of ways to bring the benefits of that kind of thinking to their own work (from React/Redux all the way to Ramda and the like).
If you're more used to languages that "get out of the way" by eliding what could very well be termed "implementation details" (e.g. is there any reason[0] to use call-by-reference in the absence of global mutable state given a "sufficiently smart optimizing compiler"?), I'd predict (n = 1) that you'll be more likely to make mistakes.
I would've done far better on this quiz back when I was playing with matplotlib as an eighth- or ninth-grader: apart from the token map implementation, the quiz really favors knowledge of counterintuitive behavior common in "mainstream" imperative languages over an understanding of "composability" that users of modern functional languages are used to. (And no, that doesn't only mean Haskell or "ultra-Haskells" like Idris, but also languages like OCaml, F#, and so on.)
It would be much nicer if the quiz could be less about the candidate coaxing her preferred meaning out of a language implementation and more about testing the meanings a candidate knows how to implement with the help of the language.
[0]: For instance, the standard reaction to things like
sum (map (\x -> x ** 2) (map (\y -> sin (y * pi / 10)) [0..9]))
is that a single for-loop is better than this for "real-world purposes". That is very false: the Haskell vector package is usually capable of efficiently fusing the code above into exactly what one would've written by hand.
At the risk of going all peak-HN, these things are more a problem with implicit, nonuniform behavior which well-designed languages solve with abstractions like the Copy trait in Rust or even C++ move semantics.
But then I realised that that's not true. For example, call-by-value and call-by-reference are pretty pervasive across languages: many of those examples would've worked the same in Java, say. It's not familiarity with Python, but rather familiarity with a certain kind of language (which admittedly constitutes the majority of those used in industry ATM) that the test demands, at a time when even Java is getting nice FP-like abstractions and the JavaScript community is cooking up all sorts of ways to bring the benefits of that kind of thinking to their own work (from React/Redux all the way to Ramda and the like).
If you're more used to languages that "get out of the way" by eliding what could very well be termed "implementation details" (e.g. is there any reason[0] to use call-by-reference in the absence of global mutable state given a "sufficiently smart optimizing compiler"?), I'd predict (n = 1) that you'll be more likely to make mistakes.
I would've done far better on this quiz back when I was playing with matplotlib as an eighth- or ninth-grader: apart from the token map implementation, the quiz really favors knowledge of counterintuitive behavior common in "mainstream" imperative languages over an understanding of "composability" that users of modern functional languages are used to. (And no, that doesn't only mean Haskell or "ultra-Haskells" like Idris, but also languages like OCaml, F#, and so on.)
It would be much nicer if the quiz could be less about the candidate coaxing her preferred meaning out of a language implementation and more about testing the meanings a candidate knows how to implement with the help of the language.
[0]: For instance, the standard reaction to things like
is that a single for-loop is better than this for "real-world purposes". That is very false: the Haskell vector package is usually capable of efficiently fusing the code above into exactly what one would've written by hand.https://www.schoolofhaskell.com/user/commercial/content/vect...
At the risk of going all peak-HN, these things are more a problem with implicit, nonuniform behavior which well-designed languages solve with abstractions like the Copy trait in Rust or even C++ move semantics.