Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How about neither. Should be: talk to the guy, talk about prior work. If you think they fit, hire them. If they end up being bad, fire them.


I've worked with and interviewed enough people who can talk a good talk and can't code their way out of a paper bag. I would rather figure that out before investing in onboarding someone.


This is going to sound worse than I intend it to, but If you can't tell when a programmer is blowing smoke up your ass during an interview, you are either asking the wrong questions or you need to have someone else in there with you.

Interviews, technical or not is a psychological process. Ask them about their previous projects, ask them what their favorite projects were and why. Ask them what their least favorite projects were and why. Ask them what the hardest thing they've worked on to date was and why.


I would have to agree with parent post though. There are always people who can talk they way through well but can't code. Its actually amazing to watch the real pros at this deflect all the tough questions. It is a great talent for something likes PR, sales or marketing but it might not be programming.


I've only hired one person like that and it was my fault. I was bedazzled by his color printouts of his UI. It was probably fine, but he was super lazy.


How many programmers have you hired using this method? How many have you fired?


I worked at a place once where they got so tired of trying to figure out which interview practices were best that they just started telling the recruiting firm to send people in for their first day of work without even bothering to interview them. This was a big local contact, so the recruiting firm wasn't going to send in known duds. The results worked out about the same as when we had actually done our traditional interview process.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: