7 ms·
I've interviewed loads of people over the years in different ways. I'd say the real dud hires were not that different from other hires. The duds were people who
by lordnacho 6y ago
I've interviewed loads of people over the years in different ways. I'd say the real dud hires were not that different from other hires. The duds were people who for one reason or other did not want to do what was assigned, yet took some time to say so. Personal issues for sure.
When hiring what works for me is looking at past experience. If someone says they are a cpp performance guy, that creates an expectation of what they should be able to chat about. If you're making it up, you will run out of stuff to say, and I'm patient enough to let people keep talking. Hopefully I'll learn something too, it happens often with top pros. But basically if you're experienced in a field it should be hard to come up with anything where you draw a total blank. If that's the case you're pretty good in my book, the main differentiator after that is whether you've done exactly what the firm needs or just something similar.
With entry level people it's hard. That's why they typically make less money, it's an Akerlof lemon cut due to the being a lot of people who just aren't going to be good at it. This isn't even necessarily a coding thing, but general life maturity. We had a guy who couldn't wake up on time to get to work, and he couldn't phone in when he was late either. I reckon there's no way to know about this kind of attitude problem until you hire them. This is also why you can expect a relatively high jump in pay after your first few years, it's proven that you aren't one of the lemons. The distribution is a large mass of hard to differentiate professionals, plus some duds of near zero value.
So for entry level, your best bet is simply finding someone you think is smart. You'll end up falling back to the same thing as everyone else who is hiring: the prestige of the uni they went to, and some pot luck questions to make sure they picked up something. However that's really not enough to know what you want to know, which is whether they are able and willing to learn what you need.
- 6keZbCECT2uB 6y agoI like this idea of focusing on listening quietly. One hour suddenly seems so short.
- RandoHolmes 6y ago> The duds were people who for one reason or other did not want to do what was assigned, yet took some time to say so. Personal issues for sure. If there's one thing I don't want to do, it's work by assignment. I'm not a school kid, I'm a professional software developer. I'll tell you what needs to be done. You can inform me of the goals you have for the company, and I'll make sure that happens. What I'm saying is that despite all my successes, you would consider me a 'dud'.
- lordnacho 6y agoI'm perfectly happy to let people explore, that's why it takes a bit of time to determine that someone isn't going to work out. These guys I'm thinking of basically didn't want to do the job they were described. At least one of them changed careers, preferring something more to do with people than code. Fair enough, but for the hiring manager there's not that much warning. They still have the skills so they'll pass the interview, and the money on offer is enough to temporarily summon up some motivation.
- mattm 6y agoI think for entry level people you might be able to replace the chat with something they're interested in even if it's not related to the job. I've gone by the philosophy that if the person doesn't have anything they're interested in their life, are they really going to be interested in the job? It's possible but highly unlikely. Of course, it doesn't mean the opposite holds. They could be interested in something but not end up being interested in the job.