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

121–130 of 181 posts

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

#121

Post by enobrev »

benjaminjackman wrote: post #38
Jemmeh wrote: post #32

Earlier quoted context omitted.

Something I've learned from making Youtube tutorials is that you need to have a deeper knowledge to actually teach something. The point at which I study a topic and have it "click in my head" comes way before I can actually manage to "explain it back clearly". As I'm writing the script for the tutorial I often realize there's a gap in my understanding that I have to go back and work on. The old saying "If you can't e…

That has been my experience as well, one level abstracted. Back when I was a position when I last had to organize teaching employees technical domain-specific skills, the best way we found for them to learn was for them to teach others, this was accomplished by having one generation of employees train the next and then reviewing the newly trained employees. Then for the next round of hiring, advance the employees up…

I occasionally wonder if something like this would significantly improve our education systems, where part of our schooling includes tutoring / teaching someone from the next year.

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

#123

Post by michaelcampbell »

kccqzy wrote: post #101
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…

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.

I believe it does exactly this. The rise of "rubber duck" debugging is a tool to extract this sort of thing, in fact.

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

#124

Post by Sacho »

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…

You can always find something to talk about in the code, though. You can start by just describing what each line does, in your opinion. Then you can go back and start to group the lines - e.g. "lines 1-3 are the initialization, lines 4-6 are probably intended to flurb the glorb", etc. Yes, it's possible that you can find an interviewee who is great technically but shuts down during an interview. The question is how much time and effort you want to invest digging for that person, especially in light of such studies.

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

#125

Post by jroseattle »

wyager wrote: post #120
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…

Being an introvert isn't an excuse for poor communication. Regardless of its cause, poor communication is bad in a work environment, and it makes sense for interviews to select against it.

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

An interview is a different scenario, but still -- you need to be able to communicate with me. If you can't, we will pass on you as a candidate.

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

#126

Post by hinkley »

sulam wrote: post #28
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…

I'd suggest making it more than 10 lines of code. Similar to kids finding easter eggs -- you want a reasonable number of things out there to talk about. It sounds like you try to get there by keeping it simple, but I would posit that some people's brains may lock up on a single block of code and having it in context or more there gives them something else to look at. Our brains are very bad at having insights when fo…

I bet you could go farther and make a really bad piece of code and introduce it as such, and then have them talk about just how many things are bad about it.

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

#127

Post by cakedoggie »

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…

That is not the opposite problem. Talking through them and working them out on paper are the same thing. They are the opposite of someone doing it in their head.

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

#128

Post by Radim »

"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 the appropriate abstraction boundaries, chisel structure out of chaos.

Articulate speech is the greatest human invention for a reason.

Testing for that (plus conscientiousness -- can you pay attention to details and get shit done?) during interviews makes perfect sense.

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

#129

Post by cakedoggie »

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…

Who doesn't love homework, especially as an adult.

No thanks.

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

#130

Post by sroussey »

zebraflask wrote: post #92

A lot of this article rings true with my experience. And I agree with the comments dinging live coding tests - those are the worst. I can't code effectively unless I'm calm and can concentrate, and these things are almost designed to get you off-balance. Even more galling when you have a healthy GitHub portfolio that they refuse to even look at in favor of a quiz (this has happened recently).

A lot of tech interviewers fall back on college experience of the pop quiz. Or what made them feel smart (which is why standardizing such things across managers is important). Really smart engineers that want to relive the A grades from school will try and be clever and undo such standards.

That all said, the correlation between great whiteboard / coding tricks and them being a successful part of a team isn't so great. It's not their job to code short programs under pressure of being watched. It's a proxy. There are better ways.

Post reply on HN