> Very few people are going to pass that test.

Agree that this isn't a reasonable "normal" programming mistake to run into, but I think the question may be used for seeing how candidates approach a problem that they don't know how to solve.

I doubt the interviewers are looking for someone to get this question 100%, and more likely looking for how candidates would deal with a problem they haven't been confronted with before that seems unsolvable. Does the candidate just say it's impossible or a trick? Or do they double down and try to think of what could possibly cause this and offer up some possibilities?

That’s the ideal, but they are typically thrown out when you have ten candidates to interview and so becomes one more binary filter.

It doesn't have to even be "underhanded". Libraries like SQLAlchemy overload `==` to return a piece of a query predicate (e.g., `foo == 0` => `WHERE foo = 0`), similarly, if I recall correctly, there's an overloaded `and` operator, which performs a similar function. Because Python is truthy and these operators return objects, I think this may evaluate to `True` without being deliberately underhanded. Granted, building a query predicate `WHERE a = 1 AND a = 2 AND a = 3` isn't a useful thing to do in the first place, but still not underhanded.

Nitpick, SQLAlchemy overrides the binary operators (~, &, |) for query construction, not the logical operators (and, or, not). It also has its own operators you can import (and_, or_, etc.)

And you are right, it can easily lead to mistakes; if you use logical operators by mistake when building a query, you will probably get 'True' instead of a query object.

I appreciate your nitpick! It's been a little while since I used SQLAlchemy, and I did run into surprises with these overloaded operators.

Python supports operator overloading, js doesn't. Expectations are different.

I'm not familiar with threads in javascript, but the expression could be true (though mighty hard to bring it about) in many multi-threaded languages.

JavaScript is a single-threaded execution environment with an event pump. When people talk about asynchronous actions like in Node.JS, they really mean doing non-JavaScript things in another thread and waiting for an event to arrive back. For example, load this file, and put an event on the queue when it's completed loading so that I can process it. In this way, you can queue multiple files to be loaded at once, even though only one can be processed by the JavaScript code at one time. This generally works out OK, because many systems are effectively IO bound and not processing bound.

Sure, that exact code is unlikely to be an honest mistake, but couldn't it be a distilled example of much more complicated code where that mistake -- unexpected or undocumented sideeffectiness -- was made honestly?