4 ms·

Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was respons

Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. Some folks aren't really curious about deep internals, they care more about the bigger picture. Scalability, system maintainability, ease of deployment, monitoring, ease of iteration, etc. If pressed, they can dig in and understand the internals, but that might not be what they are interested in/ care about.

fernandotakai 8y ago
> Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. i'm sorry but i don't agree there. in this specific case, tuples and lists are really different and there's specific reasoning for using one or the other. it's a core feature for the language. it would be like saying someone that is a Java dev and doesn't know the difference between an ArrayList or a LinkedList. i understand not knowing nuances of the language (in python, understanding how __slots__ work and how to make usage of it), but not knowing a core feature?
- iamcasen 8y ago
  Perhaps I come from a different land, but in my field, knowing a specific language intimately is not as important as knowing the wider scope of software engineering and distributed system design. I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.
  - tonyarkles 8y ago
    > I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person. I say this after having done an M.Sc. in Distributed Systems focused on performance analysis. In a lot of cases that I've encountered, mastery of data structures and choosing languages and runtimes appropriately can completely eliminate the need for a distributed system, or significantly reduce the complexity (an efficient 3-node system is much less complex to manage than a 100-node inefficient system). A recent example that comes to mind is a pair of similar systems, one written in Java and one written in Go. There was an approximately 80x larger memory footprint for the Java system while having similar functionality. Plus the Java system took about 2 minutes to start up (yay Spring), vs. sub-second startup for the Go binary. I fully appreciate the high level design of systems, and these days that's what I spend a lot of my time doing, but when shit hits the fan and the implementation of the system doesn't perform the way I'd expect it to, it's time to roll up my sleeves and get down in the weeds to help solve whatever is keeping the system from reaching its full potential. Maybe that means there was a flaw in the design, but often it's just a shoddy implementation (with Pareto 80/20 fixes to make it better)
    - iamcasen 8y ago
      Absolutely! But you if you're interviewing, and you haven't been in the weeds lately, I think it's unreasonable to get passed up for a job because you don't know the nuances of some language specific feature.
taurath 8y ago
Some folks are curious and have learned about deep internals, but after 10 years of actually producing production code and never using them, expecting them to pull it out in a 35 minute "technical" interview is the problem. If your company hires based on a technical interview that everyone says is not representative of the work that is done, you are not hiring right.

fernandotakai 8y ago

> Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. i'm sorry but i don't agree there. in this specific case, tuples and lists are really different and there's specific reasoning for using one or the other. it's a core feature for the language. it would be like saying someone that is a Java dev and doesn't know the difference between an ArrayList or a LinkedList. i understand not knowing nuances of the language (in python, understanding how __slots__ work and how to make usage of it), but not knowing a core feature?

iamcasen 8y ago
Perhaps I come from a different land, but in my field, knowing a specific language intimately is not as important as knowing the wider scope of software engineering and distributed system design. I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.
- tonyarkles 8y ago
  > I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person. I say this after having done an M.Sc. in Distributed Systems focused on performance analysis. In a lot of cases that I've encountered, mastery of data structures and choosing languages and runtimes appropriately can completely eliminate the need for a distributed system, or significantly reduce the complexity (an efficient 3-node system is much less complex to manage than a 100-node inefficient system). A recent example that comes to mind is a pair of similar systems, one written in Java and one written in Go. There was an approximately 80x larger memory footprint for the Java system while having similar functionality. Plus the Java system took about 2 minutes to start up (yay Spring), vs. sub-second startup for the Go binary. I fully appreciate the high level design of systems, and these days that's what I spend a lot of my time doing, but when shit hits the fan and the implementation of the system doesn't perform the way I'd expect it to, it's time to roll up my sleeves and get down in the weeds to help solve whatever is keeping the system from reaching its full potential. Maybe that means there was a flaw in the design, but often it's just a shoddy implementation (with Pareto 80/20 fixes to make it better)
  - iamcasen 8y ago
    Absolutely! But you if you're interviewing, and you haven't been in the weeds lately, I think it's unreasonable to get passed up for a job because you don't know the nuances of some language specific feature.

taurath 8y ago

Some folks are curious and have learned about deep internals, but after 10 years of actually producing production code and never using them, expecting them to pull it out in a 35 minute "technical" interview is the problem. If your company hires based on a technical interview that everyone says is not representative of the work that is done, you are not hiring right.