On a team I worked on, our technical screening question was, essentially, to implement Python's `dict.get()` function. A surprising number of applicants who passed HR's screen failed at this stage.

asking candidates to reimplement stdlib methods is asinine. (unless of course your company is working on python core)

The exercise wasn't a literal reimplementation, there were some additional constraints rather than a generalized problem, but it was literally 3 or 4 lines of simple if-then statements.

And not that it mattered to the purpose of this question, but this team did frequently work with kernel, language runtime and container runtime source code.

> A surprising number of applicants who passed HR's screen failed at this stage.

Perhaps you didn't notice this part of the parent comment.

"surprising" indicates that the expectation was the candidates were supposed to be able to perform the task. Perhaps you read some sarcasm into the comment that wasn't explicit?

It wasn't a trick question or complicated in any way. It was something a first semester CS student could have done without hesitation.

I like this question! Let's assume a<b, x<y, and intervals are open.

Okay: max(a,x)<min(b,y), using three comparisons.

Better: (a<x)?(b>x):(a<y), using two.

Best: (a<y)&&(b>x), using either one or two.

Those are all fine to me, and I'll follow up with a "how do you know that's right?" if needed. Looping over all valid values in one interval, testing for membership in the other, is kind of a red flag. A predicate that is incorrect and not caught by testing might be a very bad sign.

I would decline to move forward in your process. I'm not here for banal, performative nonsense. Unless you're hiring entry level, an interview isn't a CS201 exam. I'm here for you to sell me on your team, culture, and technology choices. That question shows me that your company culture values performative pageantry versus discussing what I can add as a member of the team. Hard pass.

I like to work with engineers who don't write buggy code. Do you? How do you avoid hiring them?

Experienced engineers know that this is a hard problem and don't mind demonstrating basic competence. If you don't ask me to code, it's a hard pass from me -- your team has no filter.

> I like to work with engineers who don't write buggy code.

I'm not sure if this is one of the most arrogant statements about engineering I've seen, or if you've found a treasure trove of demigods who never write code with bugs. If the latter, please have them fix the world posthaste.