5 ms·
> 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 fo
by 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 agoYou 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.