Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.interviewing.io

Post reply on HN
Print view View original

41–50 of 181 posts

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

#41

Post by woodandsteel »

krzyk wrote: post #31
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.

Yeah, but if you shoot for elaborate ones you will get politicians/lawyers not coders. I don't have any source but from my experience mathematical/computer minded people are more likely to be introverted/talk less then arts people.

>I don't have any source but from my experience mathematical/computer minded people are more likely to be introverted/talk less then arts people.

I think you are right about that, but that just means that if they want to be effective members of a team in an organization, they need to work on their communication skills. Ability to communicate is something you can learn to do better.

I know this for a fact. I used to teach public speaking, and students came out far better at it than they came in. The same is true for many other communication skills. See for instance Marshall Rosenberg's book Nonviolent Communication, which is great for interpersonal conflict situations.

In fact, I think a lot of introversion is at least in part due to poor communication skills that could be improved with training and practice.

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

#42

Post by hexane360 »

NumberCruncher wrote: post #15

>> An average, successful candidates interviewing in Python define 3.29 functions, whereas unsuccessful candidates define 2.71 functions. This finding is statistically significant. The "average" is too sensitive to outliers and should not be used for such a comparison... [Edit] Being bored I calculated the Kolmogorov-Smirnov statistic based on the chart. It is between 10%-10.5%. The number of defined funtions seems t…

Soon to be a clickbait article: "7 simple ways to hack your interviews. #1: Define 10,000 functions. That makes you a good programmer"

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

#43

Post by rnprince »

watwut wrote: post #24
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." Maybe they are introverted or simply need to think before they talk. Around 50% of people are introverted (less in usa). Many people are like that and simultaneously quite skilled. Moreover, some environments punish errors, so people who worked/studied there tend to be conditioned to think before talking. "And no matter how many times I try to work with the…

"You are not buddies, you are interviewer about to decide whether they get hired. Many people shutting down might mean that they are not comfortable juggling "buddy" social role and expectations and "serious job interview" social expectations simultaneously."

Very good point.

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

#44

Post by Fishkins »

elgenie wrote: post #27
marcosdumay wrote: post #18

Earlier quoted context omitted.

> They think in their head I'm left wondering why this would be a problem.

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 the interview.

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

#45

Post by default-kramer »

leeny wrote: post #9

Graphs have been fixed! Sorry about that, HNers.

You might want to think about upping the contrast and/or font weight too. It's nearly unreadable for me and I have pretty good vision.

Edit - it looks way better if I disable Open Sans. It might just be a font issue with Chrome or Windows.

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

#46

Post by DoofusOfDeath »

Jemmeh wrote: post #34
marcosdumay wrote: post #18

Earlier quoted context omitted.

> They think in their head I'm left wondering why this would be a problem.

Because you might need to work with the team at some point to help each other solve a problem.

At least in my case, there's a big difference between

(a) discussing an open problem with a colleague, and

(b) explaining what's going on in my mind as I'm attempting to solve the problem single-handed.

I'm very effective at (a), and it's a skill that I've used many times as a software developer and/or grad student.

But (b) is more typical in psychoanalysis sessions.

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

#47

Post by DoofusOfDeath »

jghn wrote: post #22
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…

I used to take "relatively rare" a step further and viewed it as a myth. I'd get into debates with coworkers that all one needs to do is have a conversation with a candidate to fully judge their abilities. No need for coding tests or the typical questions. Unfortunately after we brought in a ton of candidates there were a few people who fell into this bucket. I have no idea how it happened but they couldn't code them…

That happened to me once, during a phone interview with Google.

My brain simply froze during the live coding test. I looked like an idiot, even though the coding challenge was one I could have normally handled in my sleep.

My guess is that it was due to anxiety about doing well on the interview. But to this day I'm gun-shy regarding live coding tests.

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

#48

Post by UK-AL »

skylark wrote: post #13

Overall, the data lines up with my own intuition, but I thought I might throw my own interpretation into the ring. One of the biggest keys to doing well on technical interviews is to completely separate the problem solving from the coding. The strongest interviewers will discuss the problem and solve it at an abstract level using diagrams. Once satisfied with the solution, they'll code the entire thing making few mis…

Completely devalues working with prototyping though.

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

#49

Post by DoofusOfDeath »

vonmoltke wrote: post #11
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…

My previous company did this. I have seen three variants over my time: explain what this code does; explain why this code is wrong and how to fix it; explain why this code is inefficient and how to optimize it.

> explain why this code is inefficient and how to optimize it.

That sounds like a trick question. I've done a lot of code optimization. Here are a few generalizations I've drawn:

(a) You rarely know what part of a program is the bottleneck until you profile it on an appropriate workload.

(b) You often don't know why it's slow until you dig into performance metrics like cache-miss ratios, branch-mispredicts, etc. Often at the disassembly level.

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

#50

Post by igorbark »

DoofusOfDeath wrote: post #49
vonmoltke wrote: post #11

Earlier quoted context omitted.

My previous company did this. I have seen three variants over my time: explain what this code does; explain why this code is wrong and how to fix it; explain why this code is inefficient and how to optimize it.

> explain why this code is inefficient and how to optimize it. That sounds like a trick question. I've done a lot of code optimization. Here are a few generalizations I've drawn: (a) You rarely know what part of a program is the bottleneck until you profile it on an appropriate workload. (b) You often don't know why it's slow until you dig into performance metrics like cache-miss ratios, branch-mispredicts, etc. Ofte…

But for a short, isolated piece of code I assume you would be able to suggest a handful of plausible inefficiencies and explain how they could be tested for and optimized for.
Post reply on HN