Random thing you loathe right now.

Stele wrote:

Good thing I only have a eufy robot vacuum. If someone can hack in and clean my floor that would be great.

Only if they also come over and help it when it gets stuck on something or when it gets lost and can't find it's way back to it's base station so you have to pick it up and carry it. We had to give ours a name so we can yell at it "DAMMIT WILBUR!!!!!!!"

I had to stop our Eufy from eating it's own damn cord. "I'M JUST TRYING TO SAVE YOU FROM YOURSELF, GOD DAMNIT!"

Chumpy_McChump wrote:

I stand by requiring some amount of coding in a developer interview. I'm not looking for syntax perfection, I don't need something that compiles first time. I do need to know that actually know the basics of how to code. The fact that people apply for dev jobs without being able to write a six line method with a for loop or follow a simple spec is why actual live coding is important.

Just catching up on this thread, but interviewing is already a stressful situation, and there are many competent people who would be great employees that don't code well in that very specific type of environment. You are probably doing yourself a disservice if you are making someone code on the spot while you watch, you could be missing some great candidates.

At our company we do an intro interview, then a more technical interview (usually a couple of them with different developers), and if you pass then we give you a take-home coding challenge that shouldn't take more than 30 minutes to an hour. We don't offer the coding challenge until everyone has said "yes, I would be ready to give this person an offer", just as a final check.

I actually really dig this thread about hiring from someone I follow. I tried these questions (well, something similar since it was for a Java programming job) and they worked remarkably well for getting very interesting and technical answers out of someone that let me evaluate whether they'd be good, without coding challenges that rely on answering something on the fly.

IMAGE(https://pbs.twimg.com/media/E0FqZidVkAEepoh?format=png&name=large)

Those are really good! Although that last one is a trick question. Both of those options are the same thing.

I acknowledge that some people may freeze entirely in an interview. I’m willing to miss out on those potential candidates. I do ask a number of the questions you listed (or similar questions) as well.

To be totally transparent, the coding questions I ask are:
- write a function that, given a byte, will return the number of bits in that byte set to 1. (As follow up,) how would you modify it if speed of execution was the only important thing, assuming no other system constraints?
- given an array of size N containing all but one of the integers from 0 to N, find the missing integer.

I doing think either of those are particularly intense, and they certainly aren’t trick questions. We’re talking maybe 10 minutes of work, hopefully followed by some interesting conversation around possible implementations or improvements.

If you are interviewing for anything but the most junior development position and those questions cause you significant difficulty, I’m happy to shake hands and go our separate ways.

I think you're still off the mark, there. For some people, it's not about the difficulty of the question, or the amount of effort or time it takes. It's simply about the environment. This is something that is well-known and acknowledged in education. Lots of accommodations are made for kids who are completely competent and capable but just absolutely cannot perform under the pressure of a testing environment. Those people need to work, too, and I think they deserve more compassion than that.

Uhh let's slow down a little there. Any kind of interview will inevitably be worse for some people. There are plenty of coders who dread the thought of a free-form "let's have a conversation" interview that tests communication and not programming. Every approach has its drawbacks; let's not suggest someone lacks compassion because they don't use the one you prefer.

(Also, on the subject of things that are well-known and acknowledged, we could talk about how subjective conversational interviews are an excellent tool for filtering out people with diverse backgrounds, non-native speakers, etc.)

Personally I think it's mostly the singer and not the song. Interviewing is hard to do well, and I think the skill and mindset of the interviewer is a much bigger factor than the interview format in whether the whole thing is effective.

Someone keeps letting their dog sh*t in my side yard/the shared side yard where the garbage cans are and stepping in it really throws off my entire day.

I know it's a small thing, but it's really unpleasant, especially if it just rained which makes it even grosser.

If you can't even handle something so simple like picking up your dog's sh*t, at least do the bare minimum and don't let it sh*t somewhere high traffic, like right next to my motorcycle or the garbage cans where someone will inevitably step in it. That's just f*ckery, creating a problem for someone else, and not caring because you personally won't step in it, or being so self-centered that doesn't even occur to you.

I've tried asking around to find out who it is (if it's not just a rando walking by), reminding folks to please make sure they pick it up when they walk their dog, and I'm not trying to be a jerk or get anyone in trouble. I just want to stop starting my morning off with dog sh*t if I don't leave the house with boots and a headlamp so I can inspect every single spot I step.

NSMike wrote:

I think you're still off the mark, there. For some people, it's not about the difficulty of the question, or the amount of effort or time it takes. It's simply about the environment. This is something that is well-known and acknowledged in education. Lots of accommodations are made for kids who are completely competent and capable but just absolutely cannot perform under the pressure of a testing environment. Those people need to work, too, and I think they deserve more compassion than that.

:shrug: Like I said, I know that the format might make me miss otherwise excellent employees, and I’m ok with that. As fenomas suggested, every format has its pros and cons. My job, as I see it, is to find suitable candidates, not to find every suitable candidate.

And if it makes you miss a superior candidate? My whole point is that, if your format automatically filters someone out for something that is not directly their fault, your format is not just flawed, it's discriminatory. Maybe not in a "legal protected class" sense, since I don't think "involuntarily freezes in high-pressure, test-like scenarios" is a legally protected class (unless it's legally identified as some kind of learning disability which can be diagnosed - ADHD is a common underlying cause). It's so simple to remedy - doesn't even have to be take-home. Just let the candidate do those tests under appropriate conditions - you all leave the room or provide a space where they can work without being heavily observed and lift or extend time limits. Sometimes it's that simple.

You certainly won't ever find every suitable candidate, but you can definitely do better by the ones who walk through your doors.

I have ADHD and freeze - my brain verbally locks up and I stop talking and wait for inputs to stop - when someone machineguns questions at me, especially when they are aggressive. I’ve found that people who use this behavior are unpleasant for me to work with and tend to be aggressive and frustrating in their work behaviors, so I consider this an interview breaker. If the job *needs* that kind of ability, I’m mentally unsuited for it, and if it’s just the culture that allows it, I’m not going to be happy there.

NSMike wrote:

..your format is not just flawed, it's discriminatory.

Stuff like this isn't warranted, surely. Just because somebody said they do code questions, that doesn't mean they refuse to leave the room, or refuse to accommodate someone who seems uncomfortable, or whatever else. Good interviewers are flexible and find a way to work with each candidate, and if someone in this thread isn't a good interviewer then accusations aren't going to help.

Let's assume good faith and have a conversation about how to do good interviews, or else leave the topic alone.

ccoates wrote:

I've tried asking around to find out who it is (if it's not just a rando walking by), reminding folks to please make sure they pick it up when they walk their dog, and I'm not trying to be a jerk or get anyone in trouble. I just want to stop starting my morning off with dog sh*t if I don't leave the house with boots and a headlamp so I can inspect every single spot I step.

Seems like a good reason to get a camera.

Chumpy_McChump wrote:
NSMike wrote:

I think you're still off the mark, there. For some people, it's not about the difficulty of the question, or the amount of effort or time it takes. It's simply about the environment. This is something that is well-known and acknowledged in education. Lots of accommodations are made for kids who are completely competent and capable but just absolutely cannot perform under the pressure of a testing environment. Those people need to work, too, and I think they deserve more compassion than that.

:shrug: Like I said, I know that the format might make me miss otherwise excellent employees, and I’m ok with that. As fenomas suggested, every format has its pros and cons. My job, as I see it, is to find suitable candidates, not to find every suitable candidate.

I've looked at thousands of resumes in the past ten years or so for positions in my various groups at biotech companies and interviewed >400 people.

I *will* filter out a resume because of words that are spelled incorrectly. I *will* cut an interview short if an interviewee is clearly not a suitable candidate for technical or cultural fit reasons.

I agree with Chumpy, the goal is to find suitable candidates and given the volume you may well be throwing out wheat with chaff, but the other part of that is that when you're ACTUALLY sorting wheat from chaff, you're enriching for wheat, not getting every grain.

fenomas wrote:
NSMike wrote:

..your format is not just flawed, it's discriminatory.

Stuff like this isn't warranted, surely. Just because somebody said they do code questions, that doesn't mean they refuse to leave the room, or refuse to accommodate someone who seems uncomfortable, or whatever else. Good interviewers are flexible and find a way to work with each candidate, and if someone in this thread isn't a good interviewer then accusations aren't going to help.

Let's assume good faith and have a conversation about how to do good interviews, or else leave the topic alone.

He did say he is happy to dismiss anyone who freezes in an interview or who stumbles when asked to talk out a programming solution. From the outside it looks like that's exactly what he was saying.

fenomas wrote:
NSMike wrote:

..your format is not just flawed, it's discriminatory.

Stuff like this isn't warranted, surely. Just because somebody said they do code questions, that doesn't mean they refuse to leave the room, or refuse to accommodate someone who seems uncomfortable, or whatever else. Good interviewers are flexible and find a way to work with each candidate, and if someone in this thread isn't a good interviewer then accusations aren't going to help.

Let's assume good faith and have a conversation about how to do good interviews, or else leave the topic alone.

I am acting in good faith. I'm not addressing interviews as a whole, either. I'm addressing specific, pressure-cooker situations where the idea is to test someone under scrutiny. Chumpy has left me no reason to think the kind of accommodations I talk about are made in his interviews, and the further comments dismissing my observations lead me to believe he doesn't.

I'm not talking about spelling errors, conversational interview styles, a failure to meet technical expectations, or a cultural incompatibility - indeed, there is no small degree of responsibility on the part of the interviewee to assess these, as well. I'm simply talking about accommodating a specific type of obstacle which doesn't (shouldn't anyway) otherwise disqualify a candidate.

And continued comments about how a particular learning disability makes someone "chaff" or disqualified is actually kinda disturbing.

NSMike wrote:

And continued comments about how a particular learning disability makes someone "chaff" or disqualified is actually kinda disturbing.

right. To someone who is a successful MLS with pretty serious ADHD, that comes off and pretty yikes.

NSMike wrote:
fenomas wrote:
NSMike wrote:

..your format is not just flawed, it's discriminatory.

Stuff like this isn't warranted, surely. Just because somebody said they do code questions, that doesn't mean they refuse to leave the room, or refuse to accommodate someone who seems uncomfortable, or whatever else. Good interviewers are flexible and find a way to work with each candidate, and if someone in this thread isn't a good interviewer then accusations aren't going to help.

Let's assume good faith and have a conversation about how to do good interviews, or else leave the topic alone.

And continued comments about how a particular learning disability makes someone "chaff" or disqualified is actually kinda disturbing.

Okay, just to be clear, I used the wheat/chaff analogy and wasn't in any way discussing someone with a particular learning disability or the like as being "chaff".

I was speaking broadly in the sense of going through a volume of candidates, you might be discarding WHEAT (mostly qualified candidates who don't fit for some reason (technical/cultural fit)) with CHAFF (unqualified candidates) because you're processing through so many mostly qualified candidates.

*quote is not edit* (get it together, Tach!)

Quintin_Stone wrote:
ccoates wrote:

I've tried asking around to find out who it is (if it's not just a rando walking by), reminding folks to please make sure they pick it up when they walk their dog, and I'm not trying to be a jerk or get anyone in trouble. I just want to stop starting my morning off with dog sh*t if I don't leave the house with boots and a headlamp so I can inspect every single spot I step.

Seems like a good reason to get a camera.

I'm thinking about it but it feels so silly. Especially considering the amount of time/effort/energy/costs I'd have to put in compared to whomever it is, who could just, well, just not be base level lazy.

But it does genuinely upset me, so it's frustrating.

Maybe it'd be worth it just to know for sure, and then I could take it from there how to handle it in a way that would hopefully not have weird/awkward repercussions if it is a neighbor after all. As gross as it is, it probably isn't worth starting a grudge match with someone who literally knows where you live.

NSMike wrote:

I am acting in good faith.

I said "assume" good faith; it's a completely different thing.

Also: in Tach's comment if a competent person is rejected then they're the wheat in that analogy, not the chaff. Can we please be less cavalier in throwing accusations around?

Tach wrote:

I was speaking broadly in the sense of going through a volume of candidates, you might be discarding WHEAT (mostly qualified candidates who don't fit for some reason (technical/cultural fit)) with CHAFF (unqualified candidates) because you're processing through so many mostly qualified candidates.

By the time you're to the whiteboard quiz stage, you should already have done a ton of "winnowing" or else something is wrong in the hiring process in general, IMHO. At that point all that should be left is getting into more nuance and exposing them to interview by the folks they'll be working with.

Also as I pay more attention to spaces where marginalized folks or people with ADHD are comfortable, I'm getting more and more wary of the idea of "team fit" -- it's a great way to drop a good candidate just because you're used to working with white dudes. (to be clear, this "you" is people in tech in general, not singling anyone out)

There are obviously going to be certain personality types that should be put on a "work by yourself doing R&D" type thing rather than "working in a small tight team" but I'm trying extremely hard to be more cognizant of my own biases when interviewing because it's easy to just settle into what's comfortable, and if I only let the lizard-brain decide, "comfortable" is "people like me." There's a lot of evidence that team fit interviewing is just another way marginalized folks get kept out of advancement in STEM in general.

fenomas wrote:
NSMike wrote:

I am acting in good faith.

I said "assume" good faith; it's a completely different thing.

Also: in Tach's comment if a competent person is rejected then they're the wheat in that analogy, not the chaff. Can we please be less cavalier in throwing accusations around?

Physician, heal thyself.

Ranger Rick wrote:

By the time you're to the whiteboard quiz stage, you should already have done a ton of "winnowing" or else something is wrong in the hiring process in general, IMHO. At that point all that should be left is getting into more nuance and exposing them to interview by the folks they'll be working with.

Where in the process do you do coding challenges? I was under the impression that for a lot of companies they're basically the first step in the process.

(done remotely, of course, not on a whiteboard. Having somebody code on a whiteboard is pure idiocy and should never be done by any company.)

I have ADHD and freeze - my brain verbally locks up and I stop talking and wait for inputs to stop - when someone machineguns questions at me, especially when they are aggressive.

I think most people do that. I tend to interview really well but I get sort of knocked off my game when someone questions my background or wants a specific yes/no answer when my extensive experience knows every possible exception. At best I waffle when someone asks me yes/no questions on gray area topics. At worst like you I fumble and shut down.

And regarding my experience, I mean you could fake a job or two but not 15 years of experience where I have at least 5-10 stories of accomplishments and insights at each. There is a big difference between wanting to know more about something and questioning something. If you are questioning who I am and what I've done, why am I even being interviewed?

fenomas wrote:

Where in the process do you do coding challenges? I was under the impression that for a lot of companies they're basically the first step in the process.

Our process is:

1. HR or recruiter gives us a pile of resumes
2. Manager reviews them, narrows them down, does initial interview (disclaimer: our managers are reasonably technical, we're not a giant company)
3. 1-2 folks from the team we're hiring for do an interview, digging down into their technical abilities more specifically
4. if everyone likes them, give the coding challenge as a final "make sure you didn't magically bluff your way through 2 hours of technical discussion"

Our coding challenge is a pretty good one, I think. It gives you a list of SNMP OIDs and asks you to create an API to search them. There are many correct ways to implement this, but the decisions you make in how to do it tell a lot about your coding. One of the OIDs in the list is malformed (and we don't tell you that), so you have to catch/handle that as well. It's very small, easily done in 30-60 minutes for anyone other than a beginner, and if you're paying attention (or writing unit tests that match the coding test spec!) you will find the broken entry easily. But it means we learn how they implement a "real" thing -- do they pre-parse the data and create a tree? do they process on the fly and cache as needed? do they brute force with substring matches?

I find there's very little I can learn from an on-the-fly coding exercise that I can't learn from talking through actual projects they worked on, why they think it worked or didn't work, why they made the design decisions they did... and talking about things you did and why you like or hate them is a lot easier for most people than "here's a thing, code for me while I watch."

Do you mean that last part is a take-home thing after interview day? Usually I think of "check they didn't bluff" challenges as being smaller "reverse a linked list" type problems that are meant to be knocked out quickly and without tests. Your challenge sounds like the sort of thing that some companies assign before the interview, and then discussing the person's solution is one of the main topics of the technical interviews. Do you call them back in to discuss it, or is it basically pass/fail?

fenomas wrote:

Do you mean that last part is a take-home thing after interview day? Usually I think of "check they didn't bluff" challenges as being smaller "reverse a linked list" type problems that are meant to be knocked out quickly and without tests. Your challenge sounds like the sort of thing that some companies assign before the interview, and then discussing the person's solution is one of the main topics of the technical interviews. Do you call them back in to discuss it, or is it basically pass/fail?

Ah yes, it's a take-home, after the fact. We don't do it until we've already decided "yes, I would hire this person based on the interviews" -- the coding challenge is a final pass/fail before we make an offer.

I’m sorry that people have had such bad experiences during interviews. (That’s sincere, not snarky. There really needs to be an opposite of ‘/s’.)

Any style has the potential to miss good candidates. Every type of question will hit some people badly. There’s only so much one can reasonably do to try to catch appropriate candidates. Of course, I’ll never know about the ones that “got away”.

That being said, I’ve had interviewees that had an interesting enough resume to make it to an interview and who talked a good game for half an hour and then couldn’t write a for loop properly (and I don’t mean syntactically, I mean that didn’t understand what the construct was for). I’m ok with letting that potential wheat slip away.

If I were at a party and the new person I just met said they were a rocket scientist, I would expect them to be able (and willing and probably eager!) to talk about rocket stuff. If I mentioned the recent Chinese landing on Mars and they sorta mumbled and wandered off, I would be quite comfortable in my assumption that weren’t a particularly good rocket scientist. Same idea (for me).

fenomas wrote:

(done remotely, of course, not on a whiteboard. Having somebody code on a whiteboard is pure idiocy and should never be done by any company.)

(I very much enjoy that fenomas is both defending me and utterly decrying the stuff I’m doing. It’s very “disagree with what you’re saying but will defend your right to say it”. )

You have people use a whiteboard? Duuude you should really consider having them use a machine hooked to a projector, either their own or a loaner with various text editors installed. Having people write code out longhand... it's like making them type it with only one hand. Sure they probably can if they try, but why ask them do something they've probably never done before?

Also, it's an information vector. Ask them which text editor they want to use, and if they say "anything's fine" you can yell "get out thou impostor!!"