I can't relate to this line of thinking at all. Your one big method interview example - so you think had they not been able to reply on static typing for refac

I can't relate to this line of thinking at all. Your one big method interview example - so you think had they not been able to reply on static typing for refactoring in their previous work they would have gravitated toward cleaner code? That just seems wildly speculative as a counter to me. A fair amount of projects don't get the refactoring they need in the first place, so developers working on those don't get the experience to begin with. Developers who write large functions often have reasons like "if you use multiple functions you have to jump around to see whats going on." If i'm attacking a straw man, its unintentional. Anyway having unit tests in a projects would encourage smaller units more, you can have tests easily in static languages - so you get the best of both worlds - smaller units and the ease static typing brings to refactoring. The go-to sources on writing good code in c#/java land are proponents of keeping methods and classes small as well - that's where i learnt from. (Not to start any wars on over use of design patterns) Your comment assuming we'd all agree choosing a static language is a bad choice for a small example is also very strange to me. When i'm under pressure id go with what i'm most familiar with, likely C#. Though, with JS and PHP being my dynamic alternatives, i may just be sounding like a very bad programmer to you ;) I've seen plenty of very long functions in javascript (and c#), and dont think it has anything to do with static typing.