4 ms·

Thats the problem, they _don't_ know them and are expected to study beforehand because they're not used often in many roles

908B64B197 6y ago
Any serious intro to CS course will have them as part of the curriculum (at least for linked list). Even when not teaching about memory, it's used to teach recursion.
- 567fghvbb 6y ago
  That's fine for assessing graduates, but good developers with a lot of experience won't be as familiar with writing algorithms from scratch. They'll have to do a lot of revision for technical tests just to memorise reels of information they'd google in 10 seconds in real life.
- nerdponx 6y ago
  Not everyone who is a programmer starts with undergrad CS. Why not ask them to build a basic web app in their preferred framework, or read and process a basic text file, or any number of things that are more practical than implementing a low-level data structure?
- skyde 6y ago
  Right I expect anyone that just graduated 1 or 2 years ago to be able to write it in 15 minutes. But someone who is an expert in machine learning or SQL ... and have not used data-structure for the past 20 year would need to study for it. Do you want to hire the programmer that have 0 deep knowledge of the specific thing you are working on but can quickly tell you the content of CS 101 books or do you want someone that have skill set, experience and knowledge that complement your current team?
- etripe 6y ago
  > Any serious intro to CS course will have them as part of the curriculum (at least for linked list). Your implied assertion is that a CS degree is required for programming. That's a good way to select for people like you, which is one of the strongest biases in hiring. One should also take survivor's bias into account, increasing the likelihood that if you're a programmer and did a CS degree, you think a CS degree is required. Whether a "serious intro" to CS should include recursion and linked lists depends on whether you think: a. a CS degree should prepare for a programming job b. it should only prepare for a programming job c. a CS degree actually prepares for a programming job d. data structure knowledge is fundamental to programming in general My personal answers are it should prepare for a programming job, but not exclusively, and that it doesn't usually (adequately) prepare for a programming job. In that context, it should include data structures, general computer architecture and similar historic/foundational topics. I wouldn't go so far as to call them fundamental, because that implies they're must haves. I also wouldn't go so far as to say any CS course that doesn't offer them isn't serious. Maybe that school has a greater focus on preparing for the job, or maybe someone's major is more akin to IT project management than technical. In the end, a degree is: * a proxy for general intelligence * a basis for your social network * a status symbol (school pedigree) * an introduction to the topics covered * an authority argument * an indication of how well that person does at tests in an academic setting That's it. If you're lucky, someone with a degree remembers most of what they covered in classes. At best, a CS degree is correlated to someone being able do fill a programming role. What programming may require is: * General intelligence * Systems thinking (e.g. abstraction, information flows, decision trees) * Programming language skills * Patterns (architecture, design, OO/FP) * Knowledge of data structures * General IT knowledge (DevOps) * Domain knowledge * Framework familiarity * Math skills * Solving novel problems * Absorbing new knowledge * Communication skills (requirements gathering, expectation management, reporting, etc) One could arrive at these skills through passion and dedication to the hobby, learning on the job, vocational training, a bootcamp, a CS degree, a PhD and more. Of these skills, the ones least likely to be required for the vast majority of positions are math skills and data structures - beyond the absolute basics. I think it's important not to get our Ps and Qs reversed, don't you?
  - 908B64B197 6y ago
    You forgot a crucial variable: Signal to Noise. Sure, a bootcamp grad might have the required skills, if I'm lucky. But most won't and interviewing over and over has a non-negligible cost (I'm wasting everyone's time) A serious CS degree provides a better signal to noise ratio. And should cover most of the points you listed as potentially required to program anyways.
    - etripe 6y ago
      > interviewing over and over has a non-negligible cost I would say, specifically in the US where this type of question is asked, it is negligible compared to a dev's yearly salary. What one should consider is the time spent interviewing all candidates versus the cost of making a bad hire and doing it all over again. The only thing you're limiting when interviewing fewer people is the short-term cost of "hours spent doing interviews". That's a myopic metric. Another thing I didn't mention in my list is churn or employee retention. Another aspect is if your domain/application might be more appealing to someone who doesn't have a degree and might stay interested and on board longer. > A serious CS degree provides a better signal to noise ratio. For one, noise is subjective. And in filtering out the noise, you're filtering out outliers - both good and bad. Even assuming you're right, that would only mainly apply to juniors. > And should cover most of the points you listed as potentially required to program anyways. The question is if you're selecting for the right criteria, since some of my points can only be arrived at through experience and general maturity. The simple fact is: an education is only one aspect of someone's CV, a start and a depreciating asset over time. There is no sense in ignoring the candidate's job experience, general life path, public repos, etc.
      - 908B64B197 6y ago
        > I would say, specifically in the US where this type of question is asked, it is negligible compared to a dev's yearly salary. What one should consider is the time spent interviewing all candidates versus the cost of making a bad hire and doing it all over again. The only thing you're limiting when interviewing fewer people is the short-term cost of "hours spent doing interviews". That's a myopic metric. You are right, most of the cost is in the bad hire. > For one, noise is subjective. And in filtering out the noise, you're filtering out outliers - both good and bad. Even assuming you're right, that would only mainly apply to juniors. True and true. A bad hire is extremely costly.

908B64B197 6y ago

Any serious intro to CS course will have them as part of the curriculum (at least for linked list). Even when not teaching about memory, it's used to teach recursion.

567fghvbb 6y ago
That's fine for assessing graduates, but good developers with a lot of experience won't be as familiar with writing algorithms from scratch. They'll have to do a lot of revision for technical tests just to memorise reels of information they'd google in 10 seconds in real life.
nerdponx 6y ago
Not everyone who is a programmer starts with undergrad CS. Why not ask them to build a basic web app in their preferred framework, or read and process a basic text file, or any number of things that are more practical than implementing a low-level data structure?
skyde 6y ago
Right I expect anyone that just graduated 1 or 2 years ago to be able to write it in 15 minutes. But someone who is an expert in machine learning or SQL ... and have not used data-structure for the past 20 year would need to study for it. Do you want to hire the programmer that have 0 deep knowledge of the specific thing you are working on but can quickly tell you the content of CS 101 books or do you want someone that have skill set, experience and knowledge that complement your current team?
etripe 6y ago
> Any serious intro to CS course will have them as part of the curriculum (at least for linked list). Your implied assertion is that a CS degree is required for programming. That's a good way to select for people like you, which is one of the strongest biases in hiring. One should also take survivor's bias into account, increasing the likelihood that if you're a programmer and did a CS degree, you think a CS degree is required. Whether a "serious intro" to CS should include recursion and linked lists depends on whether you think: a. a CS degree should prepare for a programming job b. it should only prepare for a programming job c. a CS degree actually prepares for a programming job d. data structure knowledge is fundamental to programming in general My personal answers are it should prepare for a programming job, but not exclusively, and that it doesn't usually (adequately) prepare for a programming job. In that context, it should include data structures, general computer architecture and similar historic/foundational topics. I wouldn't go so far as to call them fundamental, because that implies they're must haves. I also wouldn't go so far as to say any CS course that doesn't offer them isn't serious. Maybe that school has a greater focus on preparing for the job, or maybe someone's major is more akin to IT project management than technical. In the end, a degree is: * a proxy for general intelligence * a basis for your social network * a status symbol (school pedigree) * an introduction to the topics covered * an authority argument * an indication of how well that person does at tests in an academic setting That's it. If you're lucky, someone with a degree remembers most of what they covered in classes. At best, a CS degree is correlated to someone being able do fill a programming role. What programming may require is: * General intelligence * Systems thinking (e.g. abstraction, information flows, decision trees) * Programming language skills * Patterns (architecture, design, OO/FP) * Knowledge of data structures * General IT knowledge (DevOps) * Domain knowledge * Framework familiarity * Math skills * Solving novel problems * Absorbing new knowledge * Communication skills (requirements gathering, expectation management, reporting, etc) One could arrive at these skills through passion and dedication to the hobby, learning on the job, vocational training, a bootcamp, a CS degree, a PhD and more. Of these skills, the ones least likely to be required for the vast majority of positions are math skills and data structures - beyond the absolute basics. I think it's important not to get our Ps and Qs reversed, don't you?
- 908B64B197 6y ago
  You forgot a crucial variable: Signal to Noise. Sure, a bootcamp grad might have the required skills, if I'm lucky. But most won't and interviewing over and over has a non-negligible cost (I'm wasting everyone's time) A serious CS degree provides a better signal to noise ratio. And should cover most of the points you listed as potentially required to program anyways.
  - etripe 6y ago
    > interviewing over and over has a non-negligible cost I would say, specifically in the US where this type of question is asked, it is negligible compared to a dev's yearly salary. What one should consider is the time spent interviewing all candidates versus the cost of making a bad hire and doing it all over again. The only thing you're limiting when interviewing fewer people is the short-term cost of "hours spent doing interviews". That's a myopic metric. Another thing I didn't mention in my list is churn or employee retention. Another aspect is if your domain/application might be more appealing to someone who doesn't have a degree and might stay interested and on board longer. > A serious CS degree provides a better signal to noise ratio. For one, noise is subjective. And in filtering out the noise, you're filtering out outliers - both good and bad. Even assuming you're right, that would only mainly apply to juniors. > And should cover most of the points you listed as potentially required to program anyways. The question is if you're selecting for the right criteria, since some of my points can only be arrived at through experience and general maturity. The simple fact is: an education is only one aspect of someone's CV, a start and a depreciating asset over time. There is no sense in ignoring the candidate's job experience, general life path, public repos, etc.
    - 908B64B197 6y ago
      > I would say, specifically in the US where this type of question is asked, it is negligible compared to a dev's yearly salary. What one should consider is the time spent interviewing all candidates versus the cost of making a bad hire and doing it all over again. The only thing you're limiting when interviewing fewer people is the short-term cost of "hours spent doing interviews". That's a myopic metric. You are right, most of the cost is in the bad hire. > For one, noise is subjective. And in filtering out the noise, you're filtering out outliers - both good and bad. Even assuming you're right, that would only mainly apply to juniors. True and true. A bad hire is extremely costly.