5 ms·

I find that the best way to expose candidates who can’t actually program is with coding questions that don’t have data structures or even loops in them. Can th

I find that the best way to expose candidates who can’t actually program is with coding questions that don’t have data structures or even loops in them. Can they write a simple Boolean expression to correctly implement a simple predicate? Too often, no, they can’t. (Example: given two intervals [a,b] and [x,y], are they disjoint or do they overlap?)

dharmab 5y ago
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.
- andrew_ 5y ago
  asking candidates to reimplement stdlib methods is asinine. (unless of course your company is working on python core)
  - dharmab 5y ago
    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.
  - pklausler 5y ago
    > 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.
    - andrew_ 5y ago
      "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?
      - dharmab 5y ago
        It wasn't a trick question or complicated in any way. It was something a first semester CS student could have done without hesitation.
deleted 5y ago
[deleted]
andrew_ 5y ago
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.
- pklausler 5y ago
  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.
  - andrew_ 5y ago
    > 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.
cousin_it 5y ago
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.
- pklausler 5y ago
  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.

dharmab 5y ago

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.

andrew_ 5y ago
asking candidates to reimplement stdlib methods is asinine. (unless of course your company is working on python core)
- dharmab 5y ago
  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.
- pklausler 5y ago
  > 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.
  - andrew_ 5y ago
    "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?
    - dharmab 5y ago
      It wasn't a trick question or complicated in any way. It was something a first semester CS student could have done without hesitation.

deleted 5y ago

[deleted]

andrew_ 5y ago

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.

pklausler 5y ago
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.
- andrew_ 5y ago
  > 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.

cousin_it 5y ago

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.

pklausler 5y ago
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.