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

51–60 of 181 posts

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

#51

Post by mmcnl »

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…

Well that would be a perfect answer if you ask me.

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

#52

Post by Jemmeh »

DoofusOfDeath wrote: post #46
Jemmeh wrote: post #34

Earlier quoted context omitted.

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.

May I ask what you feel the difference in the two is?

I often have to explain a problem to my coworker and vice versa. It's also really helpful when pair programming. Just curious about your experience.

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

#53

Post by bluGill »

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…

This is interviewing 101 though: establish a report with the interviewer if at all possible. If the interviewer tries to be a buddy that is in your favor to go along.

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

#54

Post by [deleted] »

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…

[deleted]

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

#55

Post by FLUX-YOU »

If you filter the interviews to only interviewees who:

- liked the person

- rated the questions 3 or 4 stars

- gave the interviewer 3 or 4 stars for being helpful

Do the trends still hold?

How are those trends compared to only looking at interviews with:

- disliked the person

- rated the questions 1 or 2 stars

- gave the interviewer 1 or 2 stars for being helpful

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

#56

Post by irrational »

BeetleB wrote: post #37
marcosdumay wrote: post #18

Earlier quoted context omitted.

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

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 about this to no avail. He just wants to talk things through, and then expects me to be following along and to provide insights when I have no idea what he is talking about. But if we can get it on paper or a whiteboard then I can reason about it quite easily.

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

#57

Post by DiffEq »

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 studied engineering and went to an engineering school (EE, ME, CE, etc). I have had contact with many engineers on a daily basis, although I do not do this work anymore myself, and I have found that engineers can talk very well - actually I have never met one that can't and/or won't (the real problem is getting them to shut up). So in my experience, smart useful people are always able to communicate. There may be the occasional savant who is awkward or such but I have not met them.

As for programmers - same thing. If they are any good they are more than able to talk the talk.

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

#58

Post by bluGill »

mmcnl wrote: post #51
DoofusOfDeath wrote: post #49

Earlier quoted context omitted.

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

Well that would be a perfect answer if you ask me.

No, it would not be a perfect answer, and could work against you: it shows you are not willing to work with me and assume some intelligence on my part (until proven otherwise) and thus you are potentially not going to work well with the rest of the team. I would respond that we have already profiled this code and discovered it is a bottleneck, now answer the question. It won't be hard to overcome the negative impression, but it left a negative that you don't want.

Now if you responded in the form "Of course in the real world we don't look at code until after a profiler shows the need. I see X which is suspicious, let me look deeper". In this case the comment is perfect: it shows you trust, but know to verify that trust. It also has the side effect of giving you time to think.

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

#59

Post by irrational »

Jemmeh wrote: post #35
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…

Just curious, if you've weeded them out at around 5 mins, why does it take 45-60 mins? Also, could you possibly just do an initial phone/Skype interview to save time in that case?

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 interview, but it is done by HR or our boss, neither of whom are technically proficient.

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

#60

Post by dota_fanatic »

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…

It sounded from the example like the code under discussion was quite simple, "ten lines of code". So it's plausible your "look at & investigate independently" is allowed to happen, and should take less than a few minutes, say, and then this interviewer is inviting them to walk through things in a shared manner.

In other words, from my perspective, you're not actually in disagreement with their method. They weren't saying "narrate in real time as you're first having [thoughts]". Practically nobody does that ever, or is expected to do it, except in other practices like mindfulness or therapy and what have you. They were saying they ask them to understand it, explain it, and then talk about improving it. OP's problem was with the candidates whom couldn't understand the code, and weren't even willing to talk about the state of their understanding so that the interviewer might help them walk through things further...

Post reply on HN