We analyzed thousands of interviews on everything from language to code style

Post by [deleted] » Wed, Jun 14, 2017, 10:03 PM UTC

Fishkins wrote: post #44

elgenie wrote: post #27

Earlier quoted context omitted.

Not being able to successfully and clearly communicate their thought process about a simple problem one-on-one is a bad signal for being able to communicate clearly about a difficult problem in a group setting or being a useful sounding board for technical ideas.

It's clearly important to be able to communicate about technical problems, but is it really necessary to be able to narrate your thoughts about a technical problem in real time as you're first having them? In my work experience I don't remember ever having to do that. I'd look at code & investigate a problem independently, then talk to someone about it afterward. I think that should be considered at valid approach to…

Post by paganel » Wed, Jun 14, 2017, 10:05 PM UTC

lettergram wrote: post #14

Jemaclus wrote: post #5

> Furthermore, no matter what, poor technical ability seems highly correlated with poor communication ability – regardless of language, it’s relatively rare for candidates to perform well technically but not effectively communicate what they’re doing (or vice versa), largely (and fortunately) debunking the myth of the incoherent, fast-talking, awkward engineer. My interpretation of this is that interviewees who can c…

That's actually how I conduct interviews. It's been immensely successful at weeding out candidates within 5 minutes; although most interviews are 45 - 60 minutes. Basically, give them less than ten lines of code, ask them what it does, where are a couple bugs, ask what would you name the function, etc. Then we talk about how to improve it. I'd say, less than 20% of people I interview pass. It's actually amazingly low…

Post by BurningFrog » Wed, Jun 14, 2017, 10:13 PM UTC

irrational wrote: post #56

BeetleB wrote: post #37

Earlier quoted context omitted.

I don't know if the following is what the GP meant, but: I've often had the pain of dealing with people who try to do it all in their head. Sure, one or two are good enough where it's not a problem. The rest of them? They keep getting confused and making mistakes. For things that are not very complex. If they had only written it out or drawn on paper/board, they would not get confused. It's most obvious when I try ex…

I have sort of the opposite problem with a coworker. This coworker only wants to talk through things and doesn't want to work them out on paper or a white board. The problem is that I can understand/remember almost everything I read, but have almost no ability to comprehend things that are being spoken (I suspect people are talking faster than my ability to think and parse what they are saying). I've talked to him ab…

Post by Jemmeh » Wed, Jun 14, 2017, 10:19 PM UTC

fwefwwfe wrote: post #72

irrational wrote: post #59

Earlier quoted context omitted.

I've been in this situation. Often we know within a few minutes whether the candidate is a good fit for our team, but for legal reasons we have to stretch out the interview so that the candidate can't make a claim against us. It would be better for both of us if we could cut them loose quickly, but we have to cover our butts because that's the kind of litigious society we live in. And their is an initial phone interv…

Isn't that why a lot of companies do tech phone screens?

Post by surement » Wed, Jun 14, 2017, 10:25 PM UTC

paganel wrote: post #73

lettergram wrote: post #14

Earlier quoted context omitted.

That's actually how I conduct interviews. It's been immensely successful at weeding out candidates within 5 minutes; although most interviews are 45 - 60 minutes. Basically, give them less than ten lines of code, ask them what it does, where are a couple bugs, ask what would you name the function, etc. Then we talk about how to improve it. I'd say, less than 20% of people I interview pass. It's actually amazingly low…

> Half the people don't even tell me what they are thinking. And no matter how many times I try to work with them, act like their buddy, or w.e. they just kind of shut down. They think in their head, don't work through the problem at all. As it happens most of my "aha!" code-related moments come when I'm either under the shower or when I'm washing the dishes. Very rarely did it happen for me to look at a piece code w…