4 ms·

I find a lot of CS education is not applicable to most SE roles, as they operate at a higher level of abstraction. I've never had to implement a binary tree, i

I find a lot of CS education is not applicable to most SE roles, as they operate at a higher level of abstraction. I've never had to implement a binary tree, if I did, I would be reinventing the wheel. A lot of the necessary skills are hard, if not impossible, to teach in higher education. Mainly because there, you tend to be given an exact, unambiguous specification. Whereas in the commercial world, I've never seen that to be the case, the developers role is to collaborate with the business to nail down the specifics of a high-level business goal. Implementing the code is the easy bit :)

bad_user 10y ago
> Implementing the code is the easy bit :) For web forms that replace an Excel spreadsheet, the kind that usually gets passed around over email or in a Dropbox, yes, the business requirements are usually the ones that are problematic, as you are expected to grok a lot of domain specific details in only a couple of days. But then again IMO, your experience is biased by the problems you've been working on. > I've never had to implement a binary tree, if I did, I would be reinventing the wheel. If you actually had problems involving trees, you'd know that besides the usual data-structures we all know and love, problems involving trees and graphs rarely have prepackaged solutions and the available solutions are leaky abstractions for which you have to know how they work in order to fine tune them or to make a choice between the available solutions. Consider that problems involving graphs many times involve NP solutions that are unacceptable, but that admit solutions producing approximate results, which may or may not be acceptable for your problem. And sure, maybe the problems that you're solving don't involve trees or graphs. That's fine, I think it's been 2 years since I saw a graph problem myself, but then again, medics learn a lot more than they need to treat the common cold, in order for them to be prepared. I wouldn't want to be treated by a doctor that doesn't have the proper education, since my life is on the line. And yet we are the industry that accepts people without a college degree, but given that we also have a lot of responsibility on our shoulders, how accepting can we get? Consider that we build software that controls buildings, that drive cars, that process the confidential data of people. And we as software developers, when we meet, what are we going to talk about anyway? Sure, you might have some personal projects we can talk about, but lets circle back to beginners. What are you going to talk about with somebody fresh out of college or high-school? And even with seniors, not everybody has an interesting project to talk about, so how are you going to assess their worth? Sure, you can always do a trial, but the reality is that firing people is hard and expensive, that's just the way things are and most companies prefer false negatives.
- matt_wulfeck 10y ago
  > If you actually had problems involving trees, you'd know that besides the usual data-structures we all know and love, problems involving trees and graphs rarely have prepackaged solutions... You seem to argue that having deep understandings of these types of issues makes you a better employee in the long term because eventually you will come across a hard problem that requires these skills. I would argue that an engineer who doesn't have a great grasp on the internals of fundamental CS data structures, but knows how to priotize time, will work on somebody else's mess or deal with corporate BS without complaining is more valuable both in the short and long term. These types of engineers are just simply better and more productive to work with.
- walrus1066 10y ago
  I think the best (though not prefect) method to test new devs is with a take-home exercise, no time limit, that is representative of your domain. The key things I look for are: - did they understand the requirements? If not, did they ask for clarification? - did they choose appropriate abstractions? - is the code easy to read? Is it overengineered? Are they trying to show off by overcomplicating things, or optimising prematurely? - the simpler the solution, the better - are the tests good, readable, not too brittle I then ask them how would they extend the code to fit new/changed requirements, they don't necessarily need to write any extra code in my presence, whatever they're most comfortable with.

bad_user 10y ago

> Implementing the code is the easy bit :) For web forms that replace an Excel spreadsheet, the kind that usually gets passed around over email or in a Dropbox, yes, the business requirements are usually the ones that are problematic, as you are expected to grok a lot of domain specific details in only a couple of days. But then again IMO, your experience is biased by the problems you've been working on. > I've never had to implement a binary tree, if I did, I would be reinventing the wheel. If you actually had problems involving trees, you'd know that besides the usual data-structures we all know and love, problems involving trees and graphs rarely have prepackaged solutions and the available solutions are leaky abstractions for which you have to know how they work in order to fine tune them or to make a choice between the available solutions. Consider that problems involving graphs many times involve NP solutions that are unacceptable, but that admit solutions producing approximate results, which may or may not be acceptable for your problem. And sure, maybe the problems that you're solving don't involve trees or graphs. That's fine, I think it's been 2 years since I saw a graph problem myself, but then again, medics learn a lot more than they need to treat the common cold, in order for them to be prepared. I wouldn't want to be treated by a doctor that doesn't have the proper education, since my life is on the line. And yet we are the industry that accepts people without a college degree, but given that we also have a lot of responsibility on our shoulders, how accepting can we get? Consider that we build software that controls buildings, that drive cars, that process the confidential data of people. And we as software developers, when we meet, what are we going to talk about anyway? Sure, you might have some personal projects we can talk about, but lets circle back to beginners. What are you going to talk about with somebody fresh out of college or high-school? And even with seniors, not everybody has an interesting project to talk about, so how are you going to assess their worth? Sure, you can always do a trial, but the reality is that firing people is hard and expensive, that's just the way things are and most companies prefer false negatives.

matt_wulfeck 10y ago
> If you actually had problems involving trees, you'd know that besides the usual data-structures we all know and love, problems involving trees and graphs rarely have prepackaged solutions... You seem to argue that having deep understandings of these types of issues makes you a better employee in the long term because eventually you will come across a hard problem that requires these skills. I would argue that an engineer who doesn't have a great grasp on the internals of fundamental CS data structures, but knows how to priotize time, will work on somebody else's mess or deal with corporate BS without complaining is more valuable both in the short and long term. These types of engineers are just simply better and more productive to work with.
walrus1066 10y ago
I think the best (though not prefect) method to test new devs is with a take-home exercise, no time limit, that is representative of your domain. The key things I look for are: - did they understand the requirements? If not, did they ask for clarification? - did they choose appropriate abstractions? - is the code easy to read? Is it overengineered? Are they trying to show off by overcomplicating things, or optimising prematurely? - the simpler the solution, the better - are the tests good, readable, not too brittle I then ask them how would they extend the code to fit new/changed requirements, they don't necessarily need to write any extra code in my presence, whatever they're most comfortable with.