3 ms·

”Why are "juniors" interviewing candidates?” I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right o

by irq11 8y ago

”Why are "juniors" interviewing candidates?” I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right out of undergrad”. If you wait for the senior people to interview everyone, you’re going to be waiting a while. ”Coding questions are among the most quantifiable and objective questions there are.” Bullshit. Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.

dunpeal 8y ago
OK, I suppose lack of seniors is a legitimate constraint. Still, interviewing is so important, that I typically give it a high priority. Even when I had only one other senior engineer, I made sure each candidate spent a long time with each of us. Typically, I'd go in with a junior developer, and he'd go in with some other junior developer. I'd even see the same candidate twice rather than have two juniors interview him. I've been on the other side of that kind of interview and I know how badly it can get messed up. > Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. I don't see a reason to swear, as this is a friendly discussion. Either way, we'll have to agree to disagree. Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets.
- shady-lady 8y ago
  > Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets. Except for coding style (incl. naming convention), code organisation, test coverage, arch style, level of abstraction..plus a myriad of other things. I don't know anybody who treat the code in a coding question as a black box. It gets about as subjective as you can get when reviewing, with the (objectively) correct answer weighted the least. Shit code that gets the right answer rates worse than code which ticks all the above subjective boxes but gets the answer wrong.
bradleyjg 8y ago
> Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. > Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not. It seems as though there are a fair number of things like this, where people sort-of play act science but don’t bother with the rigor. I guess it’s a type of cargo culting.
0xfeba 8y ago
This topic was pretty lively last time I commented about my interviewing practices. Coding is a creative effort -- yes. It's not objective. But I see no other way to test if the person is competent than sitting them down with a problem to solve -- if only to have them explain what they do and don't understand, and what their process is.
- dunpeal 8y ago
  This is a key point. I see a lot of criticism of the coding interview. But what's the viable alternative? My goal is to figure out the candidate can do their job - write software - and that myself and the rest of my team would enjoy working closely with them on their daily tasks. How else do I figure that out, if not by a coding exercise?
  - irq11 8y ago
    I’m not saying that you shouldn’t do a coding exercise. I’m saying that coding exercises are overrated and far too difficult. Programmers today think that TopCoder questions are “FizzBuzz” tests. That’s idiotic. Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. It’s just bizarre how people have twisted that over the years. But to answer your question: focus on what matters. Communication, writing skill, the ability to read code (this is easily 10x more important than algorithmic wizardry IRL), good habits (e.g. “does this person insist on putting all of their code in a single file?” - an actual thing I have seen!!), opinions that match your team, etc. All of these things can be answered in interviews, but nobody cares to try.
    - dunpeal 8y ago
      Communication is obviously being tested in both phone screens and onsites. It's not like a candidate in a coding interview can simply start coding silently, finish, and then pass to the next stage because their code works. A big part of a coding interview is working with the candidate. > the ability to read code How do you test for that in isolation? There are exercises that do that: you show the candidate a piece of code, and ask them to find the bug. They have all the worst issues that folks here are complaining about, amplified: stressful, awkward, etc. In my experience these types of exercises are also more random: i.e. depend more on luck. Sometimes great candidates fail them, and poor candidates get them right on a fluke. So they are overall less indicative. Ultimately, though, it's back to the first point: how do I test if the candidate can do their job, i.e. code? A candidate may communicate really well, say all the right things in best-practice questions like the one you mentioned, write well in English, but still unable to code their way out of a matchbox.

by irq11 8y ago

dunpeal 8y ago

OK, I suppose lack of seniors is a legitimate constraint. Still, interviewing is so important, that I typically give it a high priority. Even when I had only one other senior engineer, I made sure each candidate spent a long time with each of us. Typically, I'd go in with a junior developer, and he'd go in with some other junior developer. I'd even see the same candidate twice rather than have two juniors interview him. I've been on the other side of that kind of interview and I know how badly it can get messed up. > Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. I don't see a reason to swear, as this is a friendly discussion. Either way, we'll have to agree to disagree. Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets.

shady-lady 8y ago
> Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets. Except for coding style (incl. naming convention), code organisation, test coverage, arch style, level of abstraction..plus a myriad of other things. I don't know anybody who treat the code in a coding question as a black box. It gets about as subjective as you can get when reviewing, with the (objectively) correct answer weighted the least. Shit code that gets the right answer rates worse than code which ticks all the above subjective boxes but gets the answer wrong.

bradleyjg 8y ago

> Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. > Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not. It seems as though there are a fair number of things like this, where people sort-of play act science but don’t bother with the rigor. I guess it’s a type of cargo culting.

0xfeba 8y ago

This topic was pretty lively last time I commented about my interviewing practices. Coding is a creative effort -- yes. It's not objective. But I see no other way to test if the person is competent than sitting them down with a problem to solve -- if only to have them explain what they do and don't understand, and what their process is.

dunpeal 8y ago
This is a key point. I see a lot of criticism of the coding interview. But what's the viable alternative? My goal is to figure out the candidate can do their job - write software - and that myself and the rest of my team would enjoy working closely with them on their daily tasks. How else do I figure that out, if not by a coding exercise?
- irq11 8y ago
  I’m not saying that you shouldn’t do a coding exercise. I’m saying that coding exercises are overrated and far too difficult. Programmers today think that TopCoder questions are “FizzBuzz” tests. That’s idiotic. Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. It’s just bizarre how people have twisted that over the years. But to answer your question: focus on what matters. Communication, writing skill, the ability to read code (this is easily 10x more important than algorithmic wizardry IRL), good habits (e.g. “does this person insist on putting all of their code in a single file?” - an actual thing I have seen!!), opinions that match your team, etc. All of these things can be answered in interviews, but nobody cares to try.
  - dunpeal 8y ago
    Communication is obviously being tested in both phone screens and onsites. It's not like a candidate in a coding interview can simply start coding silently, finish, and then pass to the next stage because their code works. A big part of a coding interview is working with the candidate. > the ability to read code How do you test for that in isolation? There are exercises that do that: you show the candidate a piece of code, and ask them to find the bug. They have all the worst issues that folks here are complaining about, amplified: stressful, awkward, etc. In my experience these types of exercises are also more random: i.e. depend more on luck. Sometimes great candidates fail them, and poor candidates get them right on a fluke. So they are overall less indicative. Ultimately, though, it's back to the first point: how do I test if the candidate can do their job, i.e. code? A candidate may communicate really well, say all the right things in best-practice questions like the one you mentioned, write well in English, but still unable to code their way out of a matchbox.