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

101–110 of 181 posts

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

#101

Post by kccqzy »

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…

I'm an introvert, hates social gatherings, etc. Yet I've found the ability to think aloud extremely helpful. Sometimes just vocalizing my thought makes the thinking clearer, almost as if hearing myself again makes the brain think over every thought once again. In a collaborative situation (such as pairing) this is even more helpful.

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

#102

Post by dpark »

flukus wrote: post #99
graphememes wrote: post #94

Earlier quoted context omitted.

Generally to get candidates who are like this to open up, I simply assert: "Tell me what you are thinking about right now" "What is jumping out at you for you to be stalling?" "Did you see something?" --> "Why?" --> "You seem to be quiet and deep in thought, what are you thinking about?" etc...

That sounds awful, you are actively sabotaging someone by ruining their concentration while they're trying to solve a bug in unfamiliar code under time pressure. This is like having a manager requesting status updates every 10 minutes when you're trying to fix a production failure. Even if I solve the problem I'm walking out of that interview with a very negative opinion of your company.

If you completely shut down during the interview and don't communicate, you're probably getting walked out from the interview. If you cannot or will not communicate, then the interviewer is unable to evaluate you.

I also don't think he was advocating nagging either, simply asking questions to get the candidate talking. If you "go dark" for 10 minutes, you're pretty much definitely stuck. Talking to the interviewer might get you unstuck. Staring at the whiteboard quietly probably will not.

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

#103

Post by amalcon »

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…

The version of this where that code is clearly unsuitable for its stated purpose is my favorite coding interview question.

The unsuitability should be extremely obvious, no "spot the missing semicolon". Maybe it has a severe performance problem, maybe an obvious security flaw, maybe a logic error. The point is to prompt a discussion of better alternative ways to do what the code is trying to do.

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

#104

Post by delazeur »

maxxxxx wrote: post #82
watwut wrote: post #24

Earlier quoted context omitted.

"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…

If someone can't express himself, most likely that person won't work well in the team.

There is an enormous difference between a person taking a minute to collect their thoughts without speaking and a person being unwilling or unable to communicate. I can't be sure, but it sounds like at least some people in this thread are talking about pushing back against the former as well as the latter.

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

#105

Post by lj3 »

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…

I worked with somebody like that once. He would get massively frustrated because he needed that back and forth to think through ideas and I was giving him nothing. I would get frustrated because I had to digest information before I could say anything about it and he wouldn't stop talking long enough for that to happen.

I had a lot of success with asking him if I could think about the problem and we could schedule a meeting in half an hour or so. He was much happier with that result because I had thought through the problem and was now able to give him the back and forth he needed. I was also much happier because I was no longer expected to come up with insight on problems I had no time to chew on.

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

#106

Post by delazeur »

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.

No. Thinking out loud is not the same as communicating a thought process.

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

#107

Post by maxxxxx »

delazeur wrote: post #104
maxxxxx wrote: post #82

Earlier quoted context omitted.

If someone can't express himself, most likely that person won't work well in the team.

There is an enormous difference between a person taking a minute to collect their thoughts without speaking and a person being unwilling or unable to communicate. I can't be sure, but it sounds like at least some people in this thread are talking about pushing back against the former as well as the latter.

I am fine if they think about it for minutes or need a while to sort thoughts out. But at some point I would like to get some response. What else can I go by in the interview? And even if that person can write great code I am not sure things will work in the long run if he can't explain himself.

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

#108

Post by lj3 »

gxs wrote: post #83
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…

That's an interesting approach, but I wonder if you're screening for people who can speak and code vs just people who can code. I'm a product manager and I suspect I would do pretty well in this type of interview unless the snippet is especially complicated and/or esoteric. In that case you might be screening for people who can talk but not actually code or people who can code but might not be the best communicator.…

> In that case you might be screening for people who can talk but not actually code or people who can code but might not be the best communicator.

From TFA and literally the thing that started this whole thread:

> 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).

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

#109

Post by omot »

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…

I think this applies to actual software management too. I don't see people with the most code commits as the ones who gets promoted. The ones promoted are usually the ones who really scope out the problem. Once they're sure of a complete solution they code out their plans on a steady pace.

I think Einstein's the one that said: "If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."

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

#110

Post by lj3 »

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

We do it in reverse. In the first 2 hour interview, candidates learn our tech from 2 or 3 engineers. We then send them home with a set of coding tasks that are all relevant to what we do. As in functions of utilities that we actually would need to write, as opposed to puzzles. They choose one of 6 tasks, write ~100 lines of code, then come back for the next 2 hour interview and lead a code review of the code they wro…

So, based on the new information presented in the article that people who can talk clearly about code can also write code, are you likely to change your interview practices to omit the take home task and ask the candidate to talk about code that somebody else wrote? It would be faster, easier and according to the data in TFA just as accurate, yes?
Post reply on HN