3 ms·

I have a theory on this. For most interview style coding problems (which tend to be algorithmic in nature), scripting languages such as python or ruby: 1) are

I have a theory on this. For most interview style coding problems (which tend to be algorithmic in nature), scripting languages such as python or ruby: 1) are less verbose 2) don't require worrying about typing 3) have really easy ways to manipulate strings, iterate, etc., which are often found in interview style problems Java and C# have many advantages over python and ruby, but I think that they put you at an inherent disadvantage for many interview style questions which often require you to solve an algorithmic or data structure type problem in a limited amount of time [1]. [1] This doesn't explain why people using Go would tend to pass at higher rates, but since the Go community is comparatively much smaller, there could be other factors at play there.

purple_ducks 8y ago
Maybe because with Go, there's less ways to skin a cat compared to each of the other languages? Less expressive language - just hammer out code worry free about being judged on method or code style?
bargl 8y ago
I am a C# dev who plays with python in my spare time. In coding interviews, some interviewers want compiler approved code. That's a lot less writing with python than with C#. The problem is I'm just not as confident with python as I am with C#. If you want compiler approved board code then I've got to write it with C# and not python.
jamestimmins 8y ago
My job involves interviewing many engineering candidates, and I see the issue with typing all the time. A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose, meaning there are more lines of code which means more small problems that can arise. That matters greatly in a short, time-boxed context.
- bryal 8y ago
  > A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose I don't think that the fact that it's statically typed is the problem. For example, I don't believe a competent Rust, Go, or Haskell dev would be at a disadvantage due to static typing, but rather the opposite.
  - jamestimmins 8y ago
    In my experience, static typing, in general, puts you at a disadvantage. It obviously varies between companies, but in scenarios like HackerRank where you have a fixed amount of time and either pass/no pass, dealing with types can be a real obstacle.
  - ubernostrum 8y ago
    As someone else who's run a lot of interviews including tech exercises (as much as I hate the typical way they're done, I haven't been able to eliminate them everywhere I've worked), I have the same experience as the parent commenter. Yes, even with "good" statically-typed languages like $YOUR_FAVORITE_LANG_HERE. Candidates using those languages can often sketch out the right algorithm and the structure of what the program would look like, but under time pressure have trouble producing something that actually will compile and run properly (and as much as I want "showed they got the right algorithm and how to do it" to be a pass, it isn't always). The "executable pseudocode" nature of the popular dynamic languages is a big advantage there. It's definitely even worse for C#/Java style languages (though C# is better than it used to be), because of all the heavyweight design pattern stuff you need to implement to do things that are just natural idioms in the dynamic languages. But it's something I've seen happen in a broad range of static languages.

purple_ducks 8y ago

Maybe because with Go, there's less ways to skin a cat compared to each of the other languages? Less expressive language - just hammer out code worry free about being judged on method or code style?

bargl 8y ago

I am a C# dev who plays with python in my spare time. In coding interviews, some interviewers want compiler approved code. That's a lot less writing with python than with C#. The problem is I'm just not as confident with python as I am with C#. If you want compiler approved board code then I've got to write it with C# and not python.

jamestimmins 8y ago

My job involves interviewing many engineering candidates, and I see the issue with typing all the time. A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose, meaning there are more lines of code which means more small problems that can arise. That matters greatly in a short, time-boxed context.

bryal 8y ago
> A competent Java dev is at a disadvantage compared to a competent Python dev, simply because it's statically typed and more verbose I don't think that the fact that it's statically typed is the problem. For example, I don't believe a competent Rust, Go, or Haskell dev would be at a disadvantage due to static typing, but rather the opposite.
- jamestimmins 8y ago
  In my experience, static typing, in general, puts you at a disadvantage. It obviously varies between companies, but in scenarios like HackerRank where you have a fixed amount of time and either pass/no pass, dealing with types can be a real obstacle.
- ubernostrum 8y ago
  As someone else who's run a lot of interviews including tech exercises (as much as I hate the typical way they're done, I haven't been able to eliminate them everywhere I've worked), I have the same experience as the parent commenter. Yes, even with "good" statically-typed languages like $YOUR_FAVORITE_LANG_HERE. Candidates using those languages can often sketch out the right algorithm and the structure of what the program would look like, but under time pressure have trouble producing something that actually will compile and run properly (and as much as I want "showed they got the right algorithm and how to do it" to be a pass, it isn't always). The "executable pseudocode" nature of the popular dynamic languages is a big advantage there. It's definitely even worse for C#/Java style languages (though C# is better than it used to be), because of all the heavyweight design pattern stuff you need to implement to do things that are just natural idioms in the dynamic languages. But it's something I've seen happen in a broad range of static languages.