5 ms·

When looking for a software developer you're not just looking for someone who can implement a solution to a problem. Daily duties involve discussing issues and

When looking for a software developer you're not just looking for someone who can implement a solution to a problem. Daily duties involve discussing issues and impediments, navigating organizational bureaucracy, managing code bases via source control repositories, troubleshooting environment issues, playing nice with other developer's code, updating ticketing systems, providing systems documentation, and writing maintainable code. A coding challenge addresses none of that, it just asks the candidate to solve a problem. Often coding challenges are sent to candidates and there's no verification that they're even the one completing the work. I've spoken with many candidates who submitted coding samples or code challenges and were completely unable to discuss the code. Often times I wondered if their recruiter supplied the code and not the candidate because of their confusion surrounding the code. I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit.

Clubber 9y ago
>I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit. This is what I do. If an interviewer can be bullshitted doing it this way, they don't need to be interviewing. Non-technical managers really need to defer this sort of thing to technical people.
- saas_co_de 9y ago
  > If an interviewer can be bullshitted doing it this way, they don't need to be interviewing There is no magical BS detector. You can't judge a person's skill without seeing them work. Everyone I have met who thinks they are smart enough to not get duped by smooth talkers gets duped all the time.
  - Clubber 9y ago
    >There is no magical BS detector. You can't judge a person's skill without seeing them work. You are conflating the issues. A tech top can detect BS, but no one can judge a person's skill without seeing them work for several months. Think of it this way. How long do you think it would take an MD to detect a fraud MD talking shop? Not long. How long does it take a military veteran to spot a fraud? Seconds. You have to be technical to spot the issues though. If something pops up that makes you think they are bullshitting, you have to drill in on it.
    - saas_co_de 9y ago
      Those examples are not the same though. You can have someone who has an extensive education in Computer Science and can talk about it all day long very articulately but has no implementation skills. You might be able to catch someone with no comp-sci background by talking to them but not someone who has an advanced comp sci education. The doctor example is relevant though. Doctors don't get hired based on talking. They have to do residencies, get certified, and demonstrate ability before even applying for a job. Same reason. Someone could learn how to repeat everything in the text books without being able to do the procedures, which require practice to master.
      - Clubber 9y ago
        To use our Doctor simile, you wouldn't ask about anatomy (or only briefly), you ask about diagnosing and treating ailments; that's what you are paying the person to do. For technical interviews, you don't ask them about Computer Science things (or only briefly), you ask them about real-world software development; that's what you are paying them to do. The stuff they really don't go over in CompSci classes. What was the project you were most proud of and why? What was the hardest project for you and why? What are some of the ways you've connected to a database / datastore (if applicable)? What were some database design decisions you've grappled over? What designs were you considering? What's the most impressive code you've seen written by someone else and why? Tell me about how you organized classes in a particular project and why you did it that way. Describe a way you've organized your classes and wish you had done it another way, and why. How do you make sure if your software has a problem, you know about it and can figure it out quickly? What's the hardest software you've written and why? How do you handle disagreements with a colleague? Can you site an example of a disagreement and each person's reasoning? Notice almost all of those examples asked "why." That's the most important part. If someone isn't up to par, they will do one of two things: 1. Answer Briefly. 2. Babble on to the point it's obvious they don't know what they are talking about. #1 of course can be because the person is shy or intimidated or an extreme introvert, but not likely. Because you're talking about a subject they should feel extremely comfortable about, even introverts will come out of their shell.
tytytytytytytyt 9y ago
> I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit. Being able to answer those still doesn't mean they can actually code proficiently, which would also make them not a good fit. You seem to be swinging the other way too much. Not testing their programming ability just because other things are important doesn't sound like a great way to interview people, either.
- cptskippy 9y ago
  Perhaps but we're not hiring for our autonomous car division, we're hiring people to write and maintain line-of-business applications based on half-baked requirements from non-technical business owners. The problems aren't terribly complicated and the code is relatively simple.

Clubber 9y ago

>I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit. This is what I do. If an interviewer can be bullshitted doing it this way, they don't need to be interviewing. Non-technical managers really need to defer this sort of thing to technical people.

saas_co_de 9y ago
> If an interviewer can be bullshitted doing it this way, they don't need to be interviewing There is no magical BS detector. You can't judge a person's skill without seeing them work. Everyone I have met who thinks they are smart enough to not get duped by smooth talkers gets duped all the time.
- Clubber 9y ago
  >There is no magical BS detector. You can't judge a person's skill without seeing them work. You are conflating the issues. A tech top can detect BS, but no one can judge a person's skill without seeing them work for several months. Think of it this way. How long do you think it would take an MD to detect a fraud MD talking shop? Not long. How long does it take a military veteran to spot a fraud? Seconds. You have to be technical to spot the issues though. If something pops up that makes you think they are bullshitting, you have to drill in on it.
  - saas_co_de 9y ago
    Those examples are not the same though. You can have someone who has an extensive education in Computer Science and can talk about it all day long very articulately but has no implementation skills. You might be able to catch someone with no comp-sci background by talking to them but not someone who has an advanced comp sci education. The doctor example is relevant though. Doctors don't get hired based on talking. They have to do residencies, get certified, and demonstrate ability before even applying for a job. Same reason. Someone could learn how to repeat everything in the text books without being able to do the procedures, which require practice to master.
    - Clubber 9y ago
      To use our Doctor simile, you wouldn't ask about anatomy (or only briefly), you ask about diagnosing and treating ailments; that's what you are paying the person to do. For technical interviews, you don't ask them about Computer Science things (or only briefly), you ask them about real-world software development; that's what you are paying them to do. The stuff they really don't go over in CompSci classes. What was the project you were most proud of and why? What was the hardest project for you and why? What are some of the ways you've connected to a database / datastore (if applicable)? What were some database design decisions you've grappled over? What designs were you considering? What's the most impressive code you've seen written by someone else and why? Tell me about how you organized classes in a particular project and why you did it that way. Describe a way you've organized your classes and wish you had done it another way, and why. How do you make sure if your software has a problem, you know about it and can figure it out quickly? What's the hardest software you've written and why? How do you handle disagreements with a colleague? Can you site an example of a disagreement and each person's reasoning? Notice almost all of those examples asked "why." That's the most important part. If someone isn't up to par, they will do one of two things: 1. Answer Briefly. 2. Babble on to the point it's obvious they don't know what they are talking about. #1 of course can be because the person is shy or intimidated or an extreme introvert, but not likely. Because you're talking about a subject they should feel extremely comfortable about, even introverts will come out of their shell.

tytytytytytytyt 9y ago

> I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit. Being able to answer those still doesn't mean they can actually code proficiently, which would also make them not a good fit. You seem to be swinging the other way too much. Not testing their programming ability just because other things are important doesn't sound like a great way to interview people, either.

cptskippy 9y ago
Perhaps but we're not hiring for our autonomous car division, we're hiring people to write and maintain line-of-business applications based on half-baked requirements from non-technical business owners. The problems aren't terribly complicated and the code is relatively simple.