We analyzed thousands of interviews on everything from language to code style • Hacker News Board

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

#151

Post by IanCal » Thu, Jun 15, 2017, 9:41 AM UTC

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.

You might be over-estimating the complexity of the kinds of problems generally used for this.

You're not bothering people while they're taking an expected amount of time to look at it. You're stopping a several minute silence after handing someone a basic loop and if statement.

For most positions we're talking about, this should not be a major problem. I found when doing something similar people either looked at me like I was crazy for giving them such a basic problem and after being reassured there was no catch answered simply and clearly, or just couldn't do anything. Followup questions about the code then went terribly (e.g. a JS contractor asking for £500+/day who didn't know what the difference between global and local variables was, why you should put var in front of things, etc).

These things are often good to weed out the incredible number of people who seem to have little to no coding ability at all for jobs where that's an obvious pre-requisite. I've also had people fail to solve a basic problem (roman numeral generator or reader) at home in whatever language they wanted, not even getting vaguely close. One person even sent in their broken version pasted into a word document.

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

#152

Post by tptacek » Thu, Jun 15, 2017, 9:43 AM UTC

One of the language results doesn't make sense. It claims that it matters, significantly, if you solve interview problems in Java when the hiring company is a Java shop, but not when the hiring company is a C++ shop.

But that's reversed. It is in fact fairly difficult for a high-level language programmer to pick up C++, and facility with C++ (or at least C) is a common, accepted goal for C++ hiring shops. A C++ shop that hired candidates without regard for their aptitude at C++ would have real problems.

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

#153

Post by blacksmythe » Thu, Jun 15, 2017, 10:09 AM UTC

tptacek wrote: post #152

One of the language results doesn't make sense. It claims that it matters, significantly, if you solve interview problems in Java when the hiring company is a Java shop, but not when the hiring company is a C++ shop. But that's reversed. It is in fact fairly difficult for a high-level language programmer to pick up C++, and facility with C++ (or at least C) is a common, accepted goal for C++ hiring shops. A C++ shop…

The data suggests that it is easier for a C++ programmer to get make a good impression in a non-C++ shop, than at a C++ shop where they likely to test you on C++ edge cases.

Interesting that this effect does not show up for Java programmers.

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

#154

Post by valdiorn » Thu, Jun 15, 2017, 10:58 AM UTC

sundvor wrote: post #96

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

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 developer in the world, but if you're completely incapable of representing yourself and your ideas; to have a dialog about your work, you are effectively worthless as an employee.

Some companies might have a place for that special someone, who you can lock in a room for a month and he will later emerge with an amazing new piece of code that will solve your problems, shielded from all the problems of the outside world, but companies where that is possible are very rare.

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

#155

Post by dkersten » Thu, Jun 15, 2017, 11:49 AM UTC

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…

Some companies might have a place for that special someone, who you can lock in a room for a month and he will later emerge with an amazing new piece of code that will solve your problems, shielded from all the problems of the outside world, but companies where that is possible are very rare.

Also, being able to develop like that is very rare because in the real world, requirements change or are vague and need to be clarified, or your software has to interoperate or integrate with other software. There is simply no way to avoid regular communication and still produce something that works how it needs to. Problems where you can shut yourself away for a long period of time certainly exist, but in the grand scheme of software jobs, they're few and far between.

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

#156

Post by dkersten » Thu, Jun 15, 2017, 11:55 AM UTC

spoiler wrote: post #141

wolco wrote: post #133

Earlier quoted context omitted.

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.

Not speaking up in meetings doesn't mean they don't have this skill though. Some people (like me) don't like to add on-the-spot opinions on something, but prefer to go and mull it over, look into it etc before providing feedback. Doing it on the spot often leads to a lot of wasted time and overly long meetings. Meetings and other synchronous communications are, in my opinion, very wasteful and expensive.

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

#157

Post by dkersten » Thu, Jun 15, 2017, 12:02 PM UTC

hexane360 wrote: post #42

NumberCruncher wrote: post #15

>> An average, successful candidates interviewing in Python define 3.29 functions, whereas unsuccessful candidates define 2.71 functions. This finding is statistically significant. The "average" is too sensitive to outliers and should not be used for such a comparison... [Edit] Being bored I calculated the Kolmogorov-Smirnov statistic based on the chart. It is between 10%-10.5%. The number of defined funtions seems t…

Soon to be a clickbait article: "7 simple ways to hack your interviews. #1: Define 10,000 functions. That makes you a good programmer"

4 functions will do. You just need to be above average. 5, just to be safe.

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

#158

Post by dkersten » Thu, Jun 15, 2017, 12:08 PM UTC

blacksmythe wrote: post #153

tptacek wrote: post #152

One of the language results doesn't make sense. It claims that it matters, significantly, if you solve interview problems in Java when the hiring company is a Java shop, but not when the hiring company is a C++ shop. But that's reversed. It is in fact fairly difficult for a high-level language programmer to pick up C++, and facility with C++ (or at least C) is a common, accepted goal for C++ hiring shops. A C++ shop…

The data suggests that it is easier for a C++ programmer to get make a good impression in a non-C++ shop, than at a C++ shop where they likely to test you on C++ edge cases. Interesting that this effect does not show up for Java programmers.

I think this makes sense, because C++ is seen as this difficult beast. Non-C++ shops will be impressed that you know any C++, while a C++ shop will want to dig much deeper and make sure you are sufficiently advanced at the language to do the job. Non-C++ shops won't dig as deeply (either because it doesn't seem relevant -- you're not going to be using C++ anyway, so you just need to show programming ability and not C++ mastery -- or the interviewers don't know C++ well enough themselves, since they don't use it in their jobs) and won't ask you about in-depth edge case language features (because why would they if they don't use the language), but in a C++ shop, they will care about all of these things and have people who use C++ and can ask in-depth questions.

Why isn't it the same in Java? I'm not sure, perhaps its because Java has less gotchas as a language (certainly a lot less undefined behaviour and weird memory-related gotchas, no templates, no multiple inheritance etc) and C++ has this "its a difficult language" prestige which Java doesn't have.

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

#159

Post by ozim » Thu, Jun 15, 2017, 12:13 PM UTC

omot wrote: post #109

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…

Yes guys that do have a lot of commits (and those who don't think through the problem long enough) end up with commits like:

"Fix" "Real fix" "Fix the fix because of fix"

Then you know you don't want those on your team. It really bites on tight deadlines when you have to put something to production but poor dude needs to push that really, really last fix.

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

#160

Post by _0ffh » Thu, Jun 15, 2017, 1:21 PM UTC

flukus wrote: post #137

_0ffh wrote: post #63

Earlier quoted context omitted.

I'm not sure about introverted. I am, but when I get excited about a topic, I can be as loud as the next person. As long as I feel I have something to contribute, that is. I can rant for two minutes straight and then suddenly and unexpectedly shut up when I've made my point. People are sometimes surprised and ask why I suddenly stopped talking. I'll answer: "I've made my point."... :3 So my bet is on error avoidance.

I'm pretty similar, but solving a bug in an interview question is hardly something I'd get excited about.

I agree. Still, the point I was trying to get across is this: While introverts do not strive to take center stage for its own sake, they are perfectly capable to do so for any good reason. Introversion is not shyness.