Hacker News Reader

Comment by Retric | Hacker News Reader

It really is about interviewing skills. I noticed a strong trend over time that the people I interviewed kept doing better. You need to engage with people without letting things get confrontational.

The best advice I can give is look at how entertainers get random audience members to relax and engage in front of huge audiences. Many people lock up in such situations and can barely say their own name, yet with the right approach it’s a non issue.

Compare that to the rapid fire technical questions I have watched people get into and it’s obvious what’s going on. Someone fumbles something and then gets flustered and shuts down. But, pepper the exact same questions into a larger conversation, perhaps going so far as to occasionally complement them, and shockingly they do better on the exact same problems.

View on HN

You're just making assumptions again.

I have witnessed a huge range of anxiety levels from candidates and when you get used to interviewing it is pretty clear what comes down to anxiety and what comes down to simply not being able to program.

When a candidate struggles, I gently lead them and help move things along in a very collaborative way - I am also very tolerant of mistakes or poor starts and proactively give every opportunity for those to be discounted.

If somebody, after 10 hints as to the ordering of the if/else if/else of fizzbuzz, still cannot figure it out when you have held their hand for 30 minutes that's not because you lack interview skill.

Interviewing is inevitably vastly imperfect and many aspects that are not relevant to the job will play a role (for example - time constraints dictate that you must ask small questions that are sufficiently challenging that might not always be entirely representative of the job) - nobody who is honest could claim otherwise, but that is the nature of the task - it has to be an approximation - and you have to asssess actual ability to code and do the job.

Handholding doesn’t solve the problem of someone second guessing themselves, and can make this much much worse. Outside of pair programming it’s normally a solitary activity where people get plenty of time to reflect. Interjecting in the middle of this is again very different from a work environment.

> and have been repeatedly complimented on my ability to put people at ease

You calling them a liar eh?

No, I am saying putting someone at ease is only half of it you need to keep them at ease. The standard script I see people use is basically some warmup conversation where everything seems fine, followed by a grilling.

Conducting a full interview “without letting things get confrontational” is difficult. However, unless the job actually requires intense face to face confrontation you want to know how well they can do the job, not how well they can interview for it.

No you're assuming that this is what happened because it contradicts your assertion. Your opinion flies in the face of my extensive experience and that of the majority of people, you may want to start considering whether it is you who is mistaken.

I don't think a candidate who I put at ease then absolutely hammered would compliment me on putting them at ease would they? Or does your theory stretch to them somehow having short-term memory loss?

When in the face of empirical evidence I adjusted my world view from close to yours to where I am now. Based on your other comment you’ve having people do fuzzbizz, simply split things into two samples and see which they do better with. Interactive face to face help, or an open IDE they can run code on uninterrupted.

If the second group preformed better then presumably the testing methodology played a role with a higher percentage of people being able to actually program than your suggesting.

Granted it takes a lot of interviews to build a reasonable sample, but we aren’t talking about 1% better performance here.

>Interactive face to face help, or an open IDE they can run code on uninterrupted.

I've tried both. I've tried leaving them to it entirely, I've tried leaving them to it then if they get stuck helping both from a lesser to a greater degree.

It really makes no difference - the bad coders struggle on that and other problems, they just lack the ability to think through the problem.

And again I've seen enough anxious candidates to see the difference. I'm pretty good at gauging things well as to how and when to help.

Overall I'm not hearing many specifics more 'I am great at interviewing'.

The empirical evidence is overwhelmingly that there are many bad programmers out there with long CVs. That's also my experience WITHIN companies, though a lesser proportion.

Fair enough, I can accept it could be a difference in candidate pools or something. That said, I personally saw a bump from about 40% to 90% using different methods for what it’s worth.

In terms of a test I use mean, median, mode, and range for an array. Then go into basic performance trade offs.

Reply on news.ycombinator.com