For developer roles these days I tend to ask candidates what are the main differences between Lists and Sets.
It’s an quick question to weed out most weaker candidates, and is more relevant to the nature of our development: using data structures rather than reinventing them.
These type of broad questions are a good conversation starter.
How the person goes about leveling their answer is very telling. Is it collaborative with the interviewer to figure out what level of detail is appropriate? Do they immediately interpret the question one of several ways and shoot off an answer? When asked to go into more detail, are they annoyed, happy go give in depth technical explanations, talk about where they would go for answers?
> a lot of people think Python list is a linked list
Well, the Python list is designed to present the operational complexity and API of a linked list in worst case, as that makes it easiest to reason with without knowing/leaking the internal structure details. (This is something of a very classic Lisp tradeoff where "everything is a linked list", but sometimes things are optimized as best as possible as an implementation detail.) The fact that the internal implementation is closer to an array in best case and is in the general case sometimes more like a linked list of array buckets (whether by CDR coding [0] or Unrolled link lists [1], maybe something as recent as Skip List [2] in some implementation cases, or other Linked List variations) is an implementation detail that Python says in its API design shouldn't be important to the consumer.
Skimming through Python's own documentation as a refresher for this discussion, the first obvious signal that I can find that Python's lists might not be implemented as basic Linked Lists is all the way down in 5.1.2 (Using Lists as Queues):
> It is also possible to use a list as a queue, where the first element added is the first element retrieved (“first-in, first-out”); however, lists are not efficient for this purpose.
It still doesn't state what the lists actually are, though, because again Python wants the consumer to treat it as a black box and to know only the risks of the worst case performance.
So it is entirely correct from the perspective of a consumer of Python lists to treat them as Linked Lists, because that's what Python presents them as an API (for good black box reasons, including that the implementation could change) and what Python tells you is the absolute worst case for working with them. (Just an unlikely worst case, because Python works hard to optimize away from it.)
From the perspective of a Python implementer, yes, it is a huge mistake to build Python lists out of strict, basic introductory textbook Linked Lists without flipping a few more pages to more optimized data structures.
All of the above discussion of which would be nearly impossible, especially citing even the relatively few sources as I have, in the context of an interview. It doesn't take into account people that take Python's black boxing of its implementation details at its word. It doesn't take into account the decades old functional programming philosophy (that Python essentially inherits here) that "everything is a linked list until proven otherwise" as a part of the Zen of Lisp. It does seem to point back to the C/C++ centricity of asking Linked List questions the Twitter thread alludes to, because in assuming "Python list is a linked list" is a wrong answer probably does show more of a bias to C/C++-style data structure design and low level concerns than Lisp data structure design and low level concerns.
(All of which is fascinating at a meta level, but terrifying to me in the context of actual interviews. There's an increasing feeling that more I know about the field the worse I do on interview "basic" questions because interviewers don't even know which assumptions to check at the door.)
Interview enough people and you'll get people with Masters or PhDs in computer science failing what seem to be trivial problems. Like FizzBuzz trivial. You can find anecdotes on HN and other places...
My own personal worst experience is limited to a Masters in Physics who couldn't code at all, code-like experience was limited to some sort of software tool that some PMs might use to create acceptance tests. Though I think a lot of these cases are just indications of a bigger problem higher up, like HR or the hiring manager not adequately setting expectations of the job role, or just not doing basic screening.
I once asked a person with an MSCS what a string was and they didn’t know. I think it might be a language barrier thing so I asked the difference between an array of characters and a string and again, no answer.
Yes, I'd believe it. At a previous employer, our phone screen was "implement min()" for a long time, and it weeded out way too many candidates.
(My questions have often been tailored around "get the candidate to implement something that would require a for loop" and that is typically enough to start weeding people out, particularly at the phone screen.)
I usually start with, "In JavaScript what 6 values evaluate to false?" ... almost nobody gets it, but it's usually an excellent barometer for how well they know JS as a language and guides the rest of the questions.
Aside: I tend to prefer people who have worked with multiple languages that are different from each other, regardless of language. Also, way too many people look down on JS without actually knowing JS.
It’s an quick question to weed out most weaker candidates, and is more relevant to the nature of our development: using data structures rather than reinventing them.