3 ms·

> 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

> 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.
solarkraft 9y ago
Talking to someone is not a magical, but highly effective bullshit detector.

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.

solarkraft 9y ago

Talking to someone is not a magical, but highly effective bullshit detector.