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.

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.

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

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.

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.

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.

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?

> > However, it seems that the average C# or Java engineer who goes through our process does less well than the average Ruby or Go engineer. I have no idea why.

> Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?

> Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?

Something I've noticed over time is that a good chunk of the people not too enthusiastic about their work tend to gravitate towards the enterprisey stuff like java, C# or VB while the more enthusiastic may end up in embedded, research or low level code like the guts of an OS or database.

I wonder ....

I suspect it's because most Java and C# engineers are "enterprise" engineers who work on mostly CRUD applications. Go and Ruby would be more aligned for a startup. Given that TripleByte's interview process is more technical and computer science oriented, I'm not surprised they score less. It's mainly about the types of problems you solve at work and how well you keep technical knowledge fresh.

I think the author is saying they have no idea why C# and Java devs are worse on average than Ruby and Go devs. I'm sure they know the specific reason those devs fail, but are trying to understand the more general trends that lead to higher rates of failure. I would guess that this is another instance of the python paradox (http://www.paulgraham.com/pypar.html).

We’ve been a C# house since .net 2.0 and having recently moved a lot of our things to first JS and then python I think it’s the tooling.

Visual studio does a lot of things for you without a CLI. Want to deploy? Right click on your project and do the UI wizard for it. I mean, even nuget has a gui.

On top of that C# comes with a ton of easy to use features from its library. Like AD integration is just a library that gives you everything you need, at least until it doesn’t and you have to write your own bits and things get hard, but until then everything is easy and it’s much easier than using an open source library for it. I think any C# programmer could use its basic functionality from VS without ever looking at its documentation, and while Django and flask integrates with AD as well, you can’t really say the same thing about them.

You don’t get that with most tools. Ironically I think the fact that .net core has moved to a more CLI sort of environment has made visual studio a worse option for it than visual studio code, but we aren’t really going down that road, so what do I care.

I do care about python support for visual studio code, and it’s damned awesome.

I think you are correct here, but also consider what a typical Java and C# programmer's are developing, they are writing line-of-business application's they are not data-mining, or doing a lot with algorithm's.

As you implied they are also less typically less exposed to doing the low level thing, however no one will test you if you can use the EntityFramework in the IDE while everyone will test if you can use SqlConnection, Open , Execute a query and parse the result "by hand"

I think that would explain why they aren’t performing on par with python developers. I also think a lot of python developers started with C, and that typically makes you a better programmer, because if you’ve suffered through memory allocation and finding the paths of least resistance, you’ll never forget.

I don’t see why JAVA or C# should perform worse than JavaScript developers in terms of data structures or algorithms though. Documentation, CLI and environment, sure, but building things?

You could say something similar about go, but I think people who are choosing go, are choosing go. And by that I mean they are thinking about their options, most C# developers that I have known, simply throw C# at everything, even when they shouldn’t.

I use C# and Visual Studio a lot and I think it really makes me dumber. In my C/C++ days I used to be really good at reading docs and quickly setting up configurations but now I am used to the IDE doing a lot of handholding. I am some work with node now and I notice that in this environment you have to know the command line and read a lot because things are less polished.

It's because the process is CS heavy. Slinging business logic together while mapping it through some ORM to satisfy the latest priority shift this sprint is what the average C# and Java engineer excels at. It's more craftsmanship and less computer science.

C# is very well thought out language. It development team is super experienced in language design. Its head designer Anders Hejlsberg has made other languages. And they borrow stuff from other languages like lambda etc.

I think he means he has no idea why candidates of those languages are less likely to meet his pass criteria

If I recall correctly the test is 100% automated. Write code, run tests. Answer multiple choice. Humans and their bias need not apply.

There is always bias in something manmade. The tests might be slightly unfavorable for certain kind of developers.

In some comment here it was mentioned that the C#-tests are not good enough and some others mentioned that this company seem to favor dynamic languages. Maybe there is some truth to that.