4 ms·

> similar tests aren’t necessarily relevant to the work actually done in finance technology roles IMO, what's relevant for a role is the skill set most people

by shados 9y ago

> similar tests aren’t necessarily relevant to the work actually done in finance technology roles IMO, what's relevant for a role is the skill set most people currently doing that role have and that's not always a good thing. I've been the first shouting on top of a roof that we shouldn't ask people to know stupid little algorithm trivias to get a job. But the narative for that quickly devolved to "data structures and algorithms are not important for day to day work". To which I honestly say bullshit. The industry is managing without it: between people who forgot everything from school, bootcamps, self taughts, and people with alternate degree, people who can do actual computer science on the job are a tiny, tiny minority. So the solutions those people come up with to day to day problems are considered a speciality (eg: "machine learning!", "data science!"). But if doing that shit was just second nature to everyone, how would it change the way we do things? What if category theory wasn't so scary? What if people weren't scared of threads? What if hashmaps were not magical black boxes people use because the person who wrote the code before them did? The foundation is becoming pretty darn weak if you ask me. I totally agree shit like HackerRank is poorly done. But I'm not sold that the skillset it tries to assess (poorly!) is that useless. We, as a community and an industry, essentially did everything we could to MAKE IT useless. That's different I think.

Joe-Z 9y ago
I consider it from a problem-solving perspective: I don't need to know the intricate details of dozens of sorting algorithms or data structures. What I need to be able to do is solve the problems that get thrown at me in daily work. So if I get assigned, say, a performance problem I might, after some research, come up with the idea to use a different data structure to solve it. Or something entirely else! Depends on the problem and where my research leads me. As a software developer I see myself mainly as someone who solves problems to help others do their work better. So, while I agree that having a strong CS background is definitely a benefit, I don't think it matters that much if you can't get binary trees just right after not needing to implement them for years.
- shados 9y ago
  > So if I get assigned, say, a performance problem I might, after some research, come up with the idea to use a different data structure to solve it. Yup. And my feel on that is that (assuming the perf issue is related to a core data structure), that -particular- perf issue shouldn't even have happened in the first place. It should have been obvious given the right background and you could have spent that time doing something less fundamental.
  - openmosix 9y ago
    Things evolve. The scale of problems evolve. A data structure that was handling hundred of transactions, crumbles on hundred of thousands. Premature optimizations (and premature abstractions) are the root of all evil.
    - shados 9y ago
      No argument there, but that's not what I'm arguing. Do you have to reach out for google or a book to do a simple if/else statement? What about a for loop? Now what about the difference between a map and a set? Likely not, it's the basics used in any app. Talking about premature optimization here implies there's some work to be done, things to think through, stuff that's not obvious. And that's totally true at a certain complexity level. But what is "complex" and what is "obvious" isn't objective. It's purely a factor of what the "average software developer" knows. What I'm arguing is that while at one point the pendulum was swinging too far one way, it's now too far in the other, and it's affecting software quality industry wide.
    - AstralStorm 9y ago
      Corollary: A data structure that is instantiated million times in small sizes is different from one huge instance with million entries.
jarsin 9y ago
Testing foundation is great but that is not at all what the current interviewing system does. It hides foundation in trick questions that require you to have a moment of insight that fires off a light bulb that you can then use your foundation to solve. For example why cant they just ask. Ok givin an array find all the pairs of the array. Great now whats the big O of that. Great... Instead they ask some trick question that disguises the fact that you should solve this problem by finding all pairs etc.
- shados 9y ago
  I totally agree. My point wasn't that the interviewing system was great. Just that the problem with it isn't what it's trying to test, but how. I have issues with people who dismiss the problem space entirely. "I don't need to know CS fundamentals to do my job". To which I say: you do. You're just doing a subpar job because -everyone else- is and that's the standard even though it's suboptimal. (Note I don't have a CS background myself, and thought this for a long time, until I ended up working in environments that were CS heavy and seeing how "hard problems" were trivialized, so we could spend time solving "real" problems instead)
neverminder 9y ago
I thought about this, I thought about this a lot and I still do. Thing is, this attitude can quickly get you tumbling down the rabbit hole. So say I'm a Java developer. But surely in order to be a good Java developer I should know the innards of the JVM, right? To do that I now have to also have to know C++ because that's what JVM is implemented in or whatever. But surely I can't know C++ well if I don't know C, right? But then I can't really grasp C well enough if I don't understand how assembly works, right? What about CPU instructions, different architectures, etc? My opinion is that nobody should even try to drink what seems to be an ever expanding ocean of knowledge in IT. Let the people (in academia or wherever) who work on algorithms work on algorithms, let the people who write frameworks continue writing frameworks and let the rest of us code monkeys to use all those digested tools and technologies to do what we have to do on daily basis. You don't ask a common plumber to describe Bernoulli's principle during an interview, do you?
- pc86 9y ago
  Scott Hanselman has said a few times that two layers of abstractions is generally sufficient. I'm not sure if he stole it from someone but using your example, that means to be a great Java developer, you should have a good understanding of the JVM, and an adequate understanding of C++. Do you need C++ to be a good Java developer? No. If you've got a decade of experience in both, are you a better Java developer than the guy who learned it in school and that's all he knows? Probably, but not necessarily. In addition I think the argument falls apart the closer down you get. Granted I am no C expert but I don't think you need to know any assembly to be a very good C developer.
  - slededit 9y ago
    When your writing C you are usually thinking about how the compiler will translate it to assembly. A lot of C's features don't really make sense without understanding the underlying machine. You can get away without knowing assembly, but you might as well just use a higher level language at that point.

by shados 9y ago

Joe-Z 9y ago

I consider it from a problem-solving perspective: I don't need to know the intricate details of dozens of sorting algorithms or data structures. What I need to be able to do is solve the problems that get thrown at me in daily work. So if I get assigned, say, a performance problem I might, after some research, come up with the idea to use a different data structure to solve it. Or something entirely else! Depends on the problem and where my research leads me. As a software developer I see myself mainly as someone who solves problems to help others do their work better. So, while I agree that having a strong CS background is definitely a benefit, I don't think it matters that much if you can't get binary trees just right after not needing to implement them for years.

shados 9y ago
> So if I get assigned, say, a performance problem I might, after some research, come up with the idea to use a different data structure to solve it. Yup. And my feel on that is that (assuming the perf issue is related to a core data structure), that -particular- perf issue shouldn't even have happened in the first place. It should have been obvious given the right background and you could have spent that time doing something less fundamental.
- openmosix 9y ago
  Things evolve. The scale of problems evolve. A data structure that was handling hundred of transactions, crumbles on hundred of thousands. Premature optimizations (and premature abstractions) are the root of all evil.
  - shados 9y ago
    No argument there, but that's not what I'm arguing. Do you have to reach out for google or a book to do a simple if/else statement? What about a for loop? Now what about the difference between a map and a set? Likely not, it's the basics used in any app. Talking about premature optimization here implies there's some work to be done, things to think through, stuff that's not obvious. And that's totally true at a certain complexity level. But what is "complex" and what is "obvious" isn't objective. It's purely a factor of what the "average software developer" knows. What I'm arguing is that while at one point the pendulum was swinging too far one way, it's now too far in the other, and it's affecting software quality industry wide.
  - AstralStorm 9y ago
    Corollary: A data structure that is instantiated million times in small sizes is different from one huge instance with million entries.

jarsin 9y ago

Testing foundation is great but that is not at all what the current interviewing system does. It hides foundation in trick questions that require you to have a moment of insight that fires off a light bulb that you can then use your foundation to solve. For example why cant they just ask. Ok givin an array find all the pairs of the array. Great now whats the big O of that. Great... Instead they ask some trick question that disguises the fact that you should solve this problem by finding all pairs etc.

shados 9y ago
I totally agree. My point wasn't that the interviewing system was great. Just that the problem with it isn't what it's trying to test, but how. I have issues with people who dismiss the problem space entirely. "I don't need to know CS fundamentals to do my job". To which I say: you do. You're just doing a subpar job because -everyone else- is and that's the standard even though it's suboptimal. (Note I don't have a CS background myself, and thought this for a long time, until I ended up working in environments that were CS heavy and seeing how "hard problems" were trivialized, so we could spend time solving "real" problems instead)

neverminder 9y ago

I thought about this, I thought about this a lot and I still do. Thing is, this attitude can quickly get you tumbling down the rabbit hole. So say I'm a Java developer. But surely in order to be a good Java developer I should know the innards of the JVM, right? To do that I now have to also have to know C++ because that's what JVM is implemented in or whatever. But surely I can't know C++ well if I don't know C, right? But then I can't really grasp C well enough if I don't understand how assembly works, right? What about CPU instructions, different architectures, etc? My opinion is that nobody should even try to drink what seems to be an ever expanding ocean of knowledge in IT. Let the people (in academia or wherever) who work on algorithms work on algorithms, let the people who write frameworks continue writing frameworks and let the rest of us code monkeys to use all those digested tools and technologies to do what we have to do on daily basis. You don't ask a common plumber to describe Bernoulli's principle during an interview, do you?

pc86 9y ago
Scott Hanselman has said a few times that two layers of abstractions is generally sufficient. I'm not sure if he stole it from someone but using your example, that means to be a great Java developer, you should have a good understanding of the JVM, and an adequate understanding of C++. Do you need C++ to be a good Java developer? No. If you've got a decade of experience in both, are you a better Java developer than the guy who learned it in school and that's all he knows? Probably, but not necessarily. In addition I think the argument falls apart the closer down you get. Granted I am no C expert but I don't think you need to know any assembly to be a very good C developer.
- slededit 9y ago
  When your writing C you are usually thinking about how the compiler will translate it to assembly. A lot of C's features don't really make sense without understanding the underlying machine. You can get away without knowing assembly, but you might as well just use a higher level language at that point.