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

171–180 of 181 posts

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

#171

Post by dando »

cakedoggie wrote: post #129
11thEarlOfMar wrote: post #89

Earlier quoted context omitted.

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.

Is it really that bad? An onsite interview takes the full day anyway.

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

#172

Post by dando »

bluGill wrote: post #58
mmcnl wrote: post #51

Earlier quoted context omitted.

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

>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 don't know how what was said implies this in anyway.

This is one of the biggest problems with interviews. Every interviewer has some dorky idea that x means y is a terrible developer while another interviewer thinks x means y is a great developer.

"I want an opportunity to learn" - Oh great. We want someone whose interested in learning more and isn't cocky.

"I want an opportunity to learn" - Oh no, that just tells me you don't know much and aren't interested in contributing

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

#173

Post by graphememes »

zebraflask wrote: post #163
graphememes wrote: post #95

Earlier quoted context omitted.

To note a few things regarding the interview and hiring process (I do a lot of it, have done about 20 in the past two days), the reason for the quiz and not using your portfolio (unless its extremely outstanding and you are fine doing a live coding questionnaire) is so that we can judge all the candidates equally and fairly. It gives a common baseline to judge. Each candidate does the same thing and we have a good id…

I agree with you about irrelevant questions, and out of the dozen or so coding quizzes I've done over the past several years, mostly with start up companies, those are unfortunately usually what I got. One company was advertising for a front end role and, sensibly enough, asked front end-related questions - that was the exception. And the thought that quizzes provide a fair point of comparison comes across to me as p…

Well a good interview process has steps that come first to evaluate the individuals substance, certainly if someone is simply approaching an interview going... Here do this quiz, that's not beneficial.

What's important to us is the person, their ability to communicate, learn, interests, then their skill set and what we have is a good fit for them and us.

Focusing on a singular part of the interview without taking a step back and reviewing the whole isn't too beneficial.

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

#174

Post by lj3 »

11thEarlOfMar wrote: post #167
lj3 wrote: post #110

Earlier quoted context omitted.

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?

Do you have data that shows how fast and easy the take home test approach is so I can compare? I only have anecdotal data. I do give candidates the option of the take home vs. white boarding. So far (it's admittedly still a pretty small sample) they've all opted for the take home. However, we'll take a look at this approach as well.

> Do you have data that shows how fast and easy the take home test approach is so I can compare? I only have anecdotal data.

I'm not aware of any solid data around take home tests. All I can give is yet more anecdotal data, which is that they take a lot of time on both ends. So much time, in fact, that I've had several interviews where the interviewer never looked at the test code I was required to send in. Whether they work or not is irrelevant if nobody ever looks at the code.

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

#175

Post by mmcnl »

bluGill wrote: post #164
mmcnl wrote: post #86

Earlier quoted context omitted.

I fail to see why analyzing a problem before solving it somehow translates into "not going to work well with the team". Problem analysis skills are far more valuable than problem solving skills. Anyone can search on Google for a solution to a given problem, but no one on Google can tell you what the actual problem is. If you really thing the answer I was responding to is not acceptable, then the question is a lousy q…

Remember, this is an interview situation, I can't give you a realistic 500000 line program with a slow hot spot and ask you to fix: we only have a few minutes (maybe an hour). I have simplified the problem to a single function that is a bottleneck, I want you to analyze this function so I can see how well you can analyze things. Refusing to do something because it hasn't been profiled is not analysis, it is refusing…

I understand what you're saying, but I still fail to see how all of this translates into not being a team player. That really has nothing to do with this at all. If the interviewer still wants a solution based on the facts as they lay on the table, he can always ask again. The first is answer is still the best answer in my opinion, because it is much closer to a real-world situation and it shows a deeper contextual understanding of situation. It also implies experience.

Anyone can repeat someone on StackOverflow who says that function X really is faster than function Y. That's hardly an accomplishment. It's like asking someone to perform a basic non-trivial calculation out of his head -- why bother?

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

#176

Post by sctb »

javabean22 wrote: post #145
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

Please comment civilly and substantively on HN or not at all.

https://news.ycombinator.com/newswelcome.html

https://news.ycombinator.com/newsguidelines.html

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

#177

Post by 11thEarlOfMar »

lj3 wrote: post #174
11thEarlOfMar wrote: post #167

Earlier quoted context omitted.

Do you have data that shows how fast and easy the take home test approach is so I can compare? I only have anecdotal data. I do give candidates the option of the take home vs. white boarding. So far (it's admittedly still a pretty small sample) they've all opted for the take home. However, we'll take a look at this approach as well.

> Do you have data that shows how fast and easy the take home test approach is so I can compare? I only have anecdotal data. I'm not aware of any solid data around take home tests. All I can give is yet more anecdotal data, which is that they take a lot of time on both ends. So much time, in fact, that I've had several interviews where the interviewer never looked at the test code I was required to send in. Whether t…

I see. The take home assignment is not a test or exam, per se. It's code sample that responds to one of 6 coding tasks. We expect something around ~100 lines, typically in C. The candidate leads a code review of their code by the team when they return for the second 2 hour interview. The code review usually takes about 45 minutes. The remaining 1:15 is 1-1 interviews. So we can assure candidates that someone reviews the take home assignment as they lead that review.

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

#178

Post by jaclaz »

Joboman555 wrote: post #122

These people are not particularly good at interpreting statistics.

>These people are not particularly good at interpreting statistics.

Maybe that is a tad bit too harsh, but surely the use of "big difference" and of "significant" seems like not being justified by the actual data:

>On average, successful interviews had final interview code that was on average 2045 characters long, whereas unsuccessful ones were, on average, 1760 characters long. That’s a big difference! This finding is statistically significant and probably not very surprising.

An average of 1760 vs an average of 2045 indicates a general average-average of around 1900 lines, so that would be 1900+/- 7%, and anyway the difference in ranges is so little that anything could cause it.

To have more or less 200 characters, merely calling variables a, b, c, etc. vs. FirstUserChoice, DefaultArrayIndexingField, you know what I mean, would be enough.

Same goes for:

>On average, successful candidates’ code ran successfully (didn’t result in errors) 64% of the time, whereas unsuccessful candidates’ attempts to compile code ran successfully 60% of the time, and this difference was indeed significant.

As I see it 60% or 64% as an average are almost exactly the same number, and bear very little significance. Maybe it is just me missing some sensibility ...

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

#179

Post by davidbanham »

valdiorn wrote: post #154
sundvor wrote: post #96

Earlier quoted context omitted.

Yeah, that's great if you're NT and all that, but if you're interviewing someone who is anxious about the situation this might only add to the pressure, creating a melt down situation making it impossible for them to think. In a normal work environment where he or she is left to think freely the the same candidate might excel .

I'm sorry, but this is an interview. It's entire point of existence is to allow communication. If the candidate would like some quiet time to think about the solution, I expect them to respond with "I think I'm forming a solution, just give me a couple of minutes to think about it before I present my case". If they can't even do that, then I'm sorry, but they are no good to anyone. You can be the smartest and best de…

And on a normal workday in normal surroundings that person might do just fine. An interview is a totally abnormal, high pressure situation.

The point is that with this kind of make or break style of candidate vetting you're probably leaving a lot of great talent by the wayside.

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

#180

Post by sundvor »

davidbanham wrote: post #179
valdiorn wrote: post #154

Earlier quoted context omitted.

I'm sorry, but this is an interview. It's entire point of existence is to allow communication. If the candidate would like some quiet time to think about the solution, I expect them to respond with "I think I'm forming a solution, just give me a couple of minutes to think about it before I present my case". If they can't even do that, then I'm sorry, but they are no good to anyone. You can be the smartest and best de…

And on a normal workday in normal surroundings that person might do just fine. An interview is a totally abnormal, high pressure situation. The point is that with this kind of make or break style of candidate vetting you're probably leaving a lot of great talent by the wayside.

Thanks, yes, that's exactly my point.
Post reply on HN