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

141–150 of 181 posts

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

#141

Post by spoiler »

wolco wrote: post #133
jroseattle wrote: post #125

Earlier quoted context omitted.

This is significant, and can be more so depending on the company and environment. I've had my own team members tell me they aren't engaged, don't speak up in meetings, etc. because they are an introvert. Like it's a condition we must accommodate. Bullshit. Communication is a skill. We value clear communication in our company. If you join our company, you may not be an expert in communication, but you will grow that s…

If you want diversity you try to accommodate different personaility types. Otherwise you end up with a mono culture. There is value in silence and limited communication.

While I don't fully agree with the parent of your reply, I think they're right about communication being a skill. I am an introvert myself, but I've learned not to let that get in the way of me communicating with my colleagues or friends.

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

#142

Post by javabean22 »

desdiv wrote: post #90
poikniok wrote: post #80

Earlier quoted context omitted.

I must ask, did you get a university degree and if so how? Personally I have found interviews to be trivial compared to exams in school, so while I do get quite nervous for some of my math examinations I have never had this experience in interviews.

I have a CS degree from a first-tier school. My experience with exams and interviews is almost the exact opposite of yours. In exams I don't get as nervous because I know that if I know the material then I will pass, if I don't then I won't. You can't bullshit your way past the professor/TA grading your exam. But in interviews I know that people who are far better than me have failed[0], and that people less competen…

I feel exactly the same way. The good thing is you keep doing the interviews for some time at some point you run into normal people and then it's easy.

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

#143

Post by watwut »

dpark wrote: post #102
flukus wrote: post #99

Earlier quoted context omitted.

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

In one interview, I was left in a room alone with coding exercises. The involved frameworks I did not knew and I had internet available. Then they came in and we talked about solutions.

I still think it was pretty cool way of interviewing.

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

#144

Post by vellum »

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…

Each moment of silence makes the interviewee feel more tense. Instead of staring at them, why not leave the room while they read through the code and collect their thoughts?

You could even have HR do it. When they arrive, HR hands them the code and instructions. Then, they read it for 15 minutes, until you walk in.

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

#145

Post by javabean22 »

Radim wrote: post #128

"Poor technical ability seems highly correlated with poor communication ability" Yep. Articulate attention is the name of the game (where "communication ability" sounds a little nebulous). If you can't organize your thoughts, bring them to the forefront of your attention, name them, you're likely bad at handling abstractions. And abstractions are at the core of "technical ability" -- the ability to name things, find…

Bla bla bla

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

#146

Post by meheleventyone »

lj3 wrote: post #108
gxs wrote: post #83

Earlier quoted context omitted.

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…

Right but that would also be true and exactly what you'd expect if interviewer mainly judged technical competency on ability to communicate. Since the form is self reported it's impossible to separate out whether the correlation is causal (poor communicators are poor technically) or due to interviewer bias (poor communicators have a harder time convincing interviewers of their technical chops) or even other factors (being flustered hurts both a candidates communication and technical skills).

This is after all an advertorial piece of data spelunking not a study.

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

#147

Post by avip »

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…

I'm absolutely not an "introvert" of any sort, but if you give me something I've never seen and ask me to reason about it, you'd better take a very wide step back, stfu, and wait for 10m - if you're to get any results from my slow brain.

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

#148

Post by alexchantavy »

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…

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

I agree. In general I'm mediocre at coding interviews, but I do best when I have a chance to whiteboard and draw the problem. On the other hand I do absolutely terribly on phone screens with a shared document and no where for the interviewer to see my drawing.

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

#149

Post by fian »

lj3 wrote: post #105
irrational wrote: post #56

Earlier quoted context omitted.

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

I am often both requesting and receiving verbal problems related to the software I maintain (an Engineering simulation and analysis tool). When receiving a problem verbally is to slow the other person down by challenging any assumptions they may be making. By asking them to clarify it allows me to build a mental model of the problem before at a sustainable pace and also helps them identify a bad assumption they may be making.

When I am asking someone else to be the rubber duck I strive to highlight any assumptions I am making at each step of defining the problem. If I don't do this the other person will usually struggle to keep up.

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

#150

Post by b0rsuk »

Sacho wrote: post #132
b0rsuk wrote: post #112

Earlier quoted context omitted.

Last but not least, after you fail an exam you can usually see it with errors underlined and often have the teacher explain them for you. If you answer interview questions in a suboptimal way, you get no feedback. You don't know what was the error you made, if any. Maybe another candidate simply read about the logic puzzle that was used. The canned response I got was "We're sorry, but we can't currently recruit you.…

Hmm sure, but companies that don't give canned responses are liable for lawsuits. A teacher's explanation can be wrong or misleading. I've also had some of teachers refuse to explain the alleged errors in my work, and I've even had to argue with teachers that they are wrong and I'm right. I suppose if you went to a great school and then to some shitty interviews, you'd like the school more than the interviews, and vi…

You're justifying company behavior, but my post was in response to the one who wondered how could a person pass exams but fail job interviews. I pointed out there are valid reasons that are not the candidate's fault.

I'm in the profession to write and debug computer programs, not debug people who like to keep me in the dark. This is frustrating.

Post reply on HN