Isn't this just observing the fact that college isn't the same as work experience, and only provides the base skill-set needed to enter enter the industry?
"When you join a startup, there’s a lot of emphasis on the design of the application, reusability and clean code, and the ability to conduct and undergo code reviews, as well as the ability to think of and build systems that can scale based on users and geography"
I can't help feel that if you're expecting a recent grad to hit the ground running with this level of insight and experience, your doing something terribly wrong. You should expect to train and mentor a recent graduate, not put them in charge of a project.
* Good design requires having an insight into the requirements of a system, often with an incomplete spec and unclear long-term goals. You can't really do this without actually designing and building real-world systems, and over-time understating where the possible failure points and missing requirements may be.
* Reusability is a double edged sword, if you generalize every bit of code into a a reusable configurable component you miss deadlines and end can end up with an 'Enterprise' mess of OOP code. It takes experience to know when to generalize, and when to KISS.
* Code reviews, best practices, and requirements are different at every company and in every industry. Even someone with experience has to be brought up to speed on this when taking on a new position.
* The "ability to think of and build systems that can scale based on users and geography" ... this is incredibility specific. I work on embedded industrial systems; they're massively complicated but are single user and often only on an isolated network. Knowing how to "scale based on users and geography" is a specific requirement for this person's industry, not software engineering in general. If you want specialization, you don't hire a recent grad (unless maybe your doing research and hire a PhD).
Candidly, I would say that college does not even provide the base skill-set.
In the Real World(tm) of building software, you will work on systems built over years by other people, many of which have long since left the project or company. The level of integration tests, unit tests, documentation, and automation will depend entirely on the culture of the organization.
Databases, low-level I/O, sorting operations, and such are nominally provided either by the standard library or sourced from the community.
Infrastructure will rule your world. Good infrastructure, with smooth provisioning and deployment, will make your day a joy. Poor infrastructure, with lots of manual work and sign-offs from ten degrees of sysadmins, will do the opposite.
You will also work as a member of a team, with a wide variety in terms of background and experience levels, making clear communication, in all forms, an absolutely essential skill.
In college, very little of the above is actually covered
Sure, you'll learn lots of stuff about operating systems, algorithms, compilers, data structures, and the like. But without any real context on what that stuff really does.
But the big place that computer science education is a big let-down is on the collaboration front. There aren't many programs, perhaps none, where you are required to, as a member of a small team, maintain and modify code built three years ago by other people, and graded on your ability to produce work that can continue to be developed by future students.
Instead, the focus is on solving relatively straightforward problems as quickly as possible, with little or no attention paid to user experience, readability, testing, and any of the other things that make up the "engineering" side of the practice of building software.
I'm not sure why some think that a university degree should mean you're ready to be an effective professional engineer from day 1, let alone year 3.
I swear this is another facet of agism: some think that the 22 year old with a 4 year degree is nearly as valuable as the 40 year old professional, just needs some language experience and wham! Ready to go!
> "When you join a startup, there’s a lot of emphasis on the design of the application, reusability and clean code, and the ability to conduct and undergo code reviews, as well as the ability to think of and build systems that can scale based on users and geography"
How can anyone take the article seriously? These are all problems that startups punt on until after they've suceeded.
Colleges are not here to serve startups. Colleges are to help students build a skill set that will serve them throughout their lives. If a startup does not want to invest in a recent college grad, there are many other more experienced hires they can make.
Thinking that free training which is being provided by someone else should fit your custom needs is, well, maybe not the best business case.
"When you join a startup, there’s a lot of emphasis on the design of the application, reusability and clean code, and the ability to conduct and undergo code reviews, as well as the ability to think of and build systems that can scale based on users and geography"?
I don't know which startup he worked for that was doing all this and still managing to stay afloat! Startups want you to crank out features and get clients in, everything else is a failed strategy!
At least in my program (University of Waterloo Computer Science), there is barely any emphasis on practical things like modern tooling, different roles of a software engineer, etc., with the exception of some of the upper year courses. Instead it is largely theoretical - data structures, calculating runtimes, how the networking stack works, theory of distributed systems, etc. You learn practical things, but only enough to help you learn the theory. So yes, this absolutely doesn't prepare you for a job, but I don't think it is supposed to, it is a university program, not a bootcamp. Instead it gives you the foundation to do more research and learn practical applications of the theory you have learned.
Through internships, I feel I've learned the practical I need in order to work full time, and what I learn during internships is complimented by the theory I have learned through my degree.
So I guess what I am saying is that if you are doing a university program, you shouldn't expect it to give you the practical skills for working, that's not what it is for. Instead do lots of internships if you can, they are fantastic.
I don't know about the University of Waterloo, but at the University of Canterbury, we had separate Computer Science and Software Engineering degrees; you could get either a B.Eng (hons) in Software Engineering or a B.Sc in Computer Science.
Software engineering students had to do process and design papers, they (theoretically, at least) learned about agile development, UML diagrams, and all that other SDLC bullshit. As a computer scientist, I instead took fun papers like computer graphics and cryptography.
All the things I missed learning because I did computer science, I picked up as I needed at work. Learning how agile development works doesn't take a semester of reading books, and what you learn in theory about the SDLC at university doesn't reflect reality in any company.
Anecdotally, I've heard many startups (and large tech companies) enjoy (and prioritize) hiring Waterloo grads because of their expansive work experience, due to Waterloo's unique co-op program that mostly doesn't exist in U.S. universities.
So startups want to hire kids right out of school for entry level wages and expect them to command the skillset of a Sr. Developer... Makes sense. I too would like to hire a low cost, plentiful resource thats identical in skill level to a more experienced person while paying them less.
Really? Cause it seems, based on my interviews, startups couldn't care less about my background in leading customers through beta demos, collaborating with scientists, participating in sales presentations and outreach, writing documentation, or any of the issues described here.
They do seem awful interested in whether I can find all matching subtrees in a binary tree, though. Which, now that I think about, is the one thing I learned in college but haven't done even once on the job once in 20 years (I have had to find minimum cost paths in a tree, though. I couldn't have done it on the spot at the whiteboard, but my data structures and algorithms class was helpful in researching and figuring it out years later).
I think that at an even more basic level than hard skills, some graduates lack knowledge in things like basic problem solving, abstract thinking or the ability to switch between languages quickly. It's interesting to see how straight-A students who study well and test well don't make the transition from the academic environment to a job.
What's funny to me about all of these comments is that practically focused CS programs can hit the best of both worlds. There's a reason there's a direct Waterloo to Google pipeline beyond just the 4/4/4 timing. Co-op programs and practically focused programs work great for building that industry know how in a meaningful way while still getting the core CS taught better than you'd get at most if not all bootcamps.
“When you join a startup, there’s a lot of emphasis on the design of the application, reusability and clean code, and the ability to conduct and undergo code reviews, as well as the ability to think of and build systems that can scale based on users and geography,” he says.
I got a good, long laugh out of this. This describes the exact opposite of my experience in a startup. None of those things were ever a concern until I worked for a company that already had a revenue stream.
I think this might be true of the startup is focused on building a web app since that's what most bootcamps teach. From what I've seen bootcamp grads are weaker candidates than CS grads because at least CS grads know enough theory and engineering to learn how to build something.
> Students are taught formal testing methods such as static analysis, which checks code without actually running it. This helps them understand how to test software programs, but it doesn’t address the testing of distributed systems, web services, and infrastructure resiliency. Examination of these types of user interfaces and back-end systems is essential, Devadiga says.
This is a good observation. In my experience, the biggest hurdle new grads have to overcome is to learn to develop in a context where users and co-workers are going to depend on the projects they build, and need to be maintained. I didn't learn how to set up instrumentation, deployment pipelines, outage alerts, and other important pieces of infrastructure in keeping a web service online in my university classes.
> Because startups are heavy users of cloud computing platforms, it’s assumed that most software engineering students understand how these systems work—but that’s often not the case, Devadiga says. Students need a practical understanding of infrastructure architecture design patterns, DevOps, and cloud platform services like compute instances, object storage, and queueing services. The ability to create applications that can execute in services like Amazon Elastic Compute Cloud is important.
Another one that I think is on point. I did use AWS in a networking class, but that was just because the class instructors didn't want to deal with building dev environments for windows, mac, and linux. I didn't really get exposed to deploying and running a web application on a cloud computing platform. For how universal cloud computing is nowadays, it's surprising how little I was exposed to it in university.
I think it'd be great for universities to offer a "practical software development" class that didn't really focus too heavily on any one particular academic topic, but was more emphasized on imitating the kind of work that developers do in industry. It'd be cool students went through the whole class building, maintaining, and extending a single web service over the course of a semester or quarter. It'd be neat if grading was based not just on application functionality, but also uptime, average latency, and similar metrics - though that would probably be too variable to be fair, a student's site might go down while they're away on a sports competition or something like that.
One idea could be to take a page out of phys/chem/bio departments by introducing “lab” courses that have no lectured instructional component (usually you take both lecture and related lab in the same semester).
These labs tend to organize students into pairs or small groups who proceed through a sequence of onsite exercises that attempt to closely emulate more complex scenarios; thus synthesizing the application of multiple book/lecture-learned skills in an environment that naturally elucidates and facilitates the practical systems engineering and communication skills that are only otherwise learned in the workplace.
Student performance in a lab is typically evaluated from structured record keeping of methodology and analysis (testing & documentation). There is also often a presentation component that helps students learn how to effectively communicate results to an audience.
One can imagine lab teams collaborating on all aspects of software engineering including requirements gathering, systems design, infrastructure provisioning, deployment automation, CI/CB/CT, integration testing, release management, diagnostics/troubleshooting, etc. Experienced graduate students can be recruited to play the various roles of chaos monkeys, users and business stakeholders.
Students would get a healthy dose of teamwork experience, and have some tangible software deliverables to seed their technical portfolios.
Note, though, that static analysis can be and is used for distributed systems, web services, and infrastructure resiliency. I’m not certain that overrides the criticism in the article, but they are ignoring how these fields intersect.
What are you going to take out of the curriculum to make room for that? There are limits on how much you can teach in four years, and we're already at that point.
TWO practical software development classes. One for hard skills, and one for soft skills.
The latter is another complaint I've heard from company owners. Too many graduates who just don't know how to work with a company's non-engineers, as they've told me.
I currently work at Amazon, but spent most of my career before Amazon at startups. Here are just a few things that, in my experience, this article gets wrong or over-states:
1. "They [start-ups and next-gen tech companies] want grads who can build scalable systems and program for large-scale, distributed, data-intensive systems that leverage cloud computing." - For start-ups, this is only true if your startup is in that space. Most "start-ups" are trying to find product market fit, and the systems are generally not large scale as a result.
2. "Engineers at established companies mostly work within their specialty areas." - While there's some truth to this, I think it's overstated. In the start-ups I worked with, "engineers" did not do market research. I worked with plenty of specialists at start-ups that worked with language X, but if you asked them to debug an issue in language Y, they'd refuse. In some cases, it can be the opposite of what this article states - engineers at a start-up can often focus on hands-on engineering tasks, whereas in a large company I find a larger portion of my time is around writing documents to align more people around an idea.
3. "The timing of the product release is crucial because it has a direct impact on acquiring customers and affects the bottom line. Significant delays can put a company out of business." - In a large company, you won't go out of business if your release is late, but it could mean that your product gets de-funded. While the change to the company might not be so much, a project getting de-funded certainly affects the daily lives of those involved. So I think this difference is overstated.
4. "Engineers for startups are more likely to play a significant role in defining the system architecture" - My experience is that this depends a lot on the start-up and the seniority of the engineer in question.
This is a valid reason to consider a trade school model ("coding bootcamps") to fill this niche. Let Computer Science programs focus on the Computer "Science", while trade schools focus on fulfilling direct company needs.
Of course, we need a _ton_ more oversight involved to ensure that bootcamps are actually graduating people with a job-ready skillset.
This won’t happen until the signalling that comes with hiring from [elite school] diminishes and/or the signalling that comes with hiring from [code bootcamp] surpasses it.
Trade schools don't turn out people ready to be productive on day 1 either. People that complete trade schools will be partnered up with more experienced people, either informally or as part of some apprenticeship model, they'll be doing grunt work for quite a while.
Experience matters and it's not something you get in any school.
As long as you can avoid the bootcamps that try to teach you 3-4 frameworks/languages in a 4 month program. You could spend 4 months just getting good at bash.
Even startups should be willing to train. The skills really aren't that hard to pick up with the right mindset and knowledge a CS grad ought to have.
We had an intern come in that was still stuck in that student-mode of needing to be told everything and not asking pointed enough questions. After a few weeks they were up to speed and productive.
Frankly even experienced workers will still require a period to absorb specific knowledge.
I think the time required for fresh grads to be productive is way, way overstated and overestimated provided they have the right direction.
I didn't even know schools had 'Software Engineering programs. I've met plenty of Computer Science grads, though. It's truly different. Engineering is more like trade school, Computer Science is foundational.
I'll probably hire you with a CS degree, but I know I'm going to need to teach you how to be a software engineer.
Engineering is nothing like a trade school if you mean Electrical Engineering, Chemical Engineering, Mechanical Engineering... etc (probably not what you meant here by context, but I felt I should clarify).
You basically do 4 years of math and physics with several years of calculus, differential equations, numerical methods, programming, and solving difficult problems. It is nothing like a trade school (no offense to that line of work...they probably make more money than me :)).
Depends on the school you go to as others have pointed out. I spoke to the head of the CS department at a local university this year; he wanted to pick my brain as a bootcamp instructor on the industry. I learned that they had already copied parts of what bootcamps were doing and had many plans to try and stay ahead of other universities doing the same thing (lots of ads for these follow me around). It was a very interesting conversation and it left me believing that the future wave of CS grads will have a much better mix of theory and application.
That's because for decades any type of "engineering" degree required the curriculum to include extensive physical science - thermodynamics, statics, advanced physics, etc. Pretty much a waste of time for an entirely virtual field.
Real engineering is not the same as software engineering. There is no engineering in software as no designer signs their name to their code and is legally responsible for when it crashes and goes wrong. Real engineers are.
My undergraduate degree is in both EE with a CS minor from Illinois/Urbana and EE is significantly more difficult than the CS.
This afternoon I met someone in lunch line that had just graduated in CS who said they tried to do EE but couldn't do it. I've seen others when I was in school drop out of EE to do CS.
It could be that schools cater to large companies' needs because they pay their employees the most and offer the highest number of jobs, and thus offer the best graduation statistics for those schools?
IME, it is because colleges, and specifically tenured college professors in CS and software engineering departments, remain woefully behind the times when it comes to relevant engineering skills.
And the latter have little motivation to stay current.
[+] [-] mreome|6 years ago|reply
"When you join a startup, there’s a lot of emphasis on the design of the application, reusability and clean code, and the ability to conduct and undergo code reviews, as well as the ability to think of and build systems that can scale based on users and geography"
I can't help feel that if you're expecting a recent grad to hit the ground running with this level of insight and experience, your doing something terribly wrong. You should expect to train and mentor a recent graduate, not put them in charge of a project.
* Good design requires having an insight into the requirements of a system, often with an incomplete spec and unclear long-term goals. You can't really do this without actually designing and building real-world systems, and over-time understating where the possible failure points and missing requirements may be.
* Reusability is a double edged sword, if you generalize every bit of code into a a reusable configurable component you miss deadlines and end can end up with an 'Enterprise' mess of OOP code. It takes experience to know when to generalize, and when to KISS.
* Code reviews, best practices, and requirements are different at every company and in every industry. Even someone with experience has to be brought up to speed on this when taking on a new position.
* The "ability to think of and build systems that can scale based on users and geography" ... this is incredibility specific. I work on embedded industrial systems; they're massively complicated but are single user and often only on an isolated network. Knowing how to "scale based on users and geography" is a specific requirement for this person's industry, not software engineering in general. If you want specialization, you don't hire a recent grad (unless maybe your doing research and hire a PhD).
Edited to expanded on a few parts.
[+] [-] donw|6 years ago|reply
In the Real World(tm) of building software, you will work on systems built over years by other people, many of which have long since left the project or company. The level of integration tests, unit tests, documentation, and automation will depend entirely on the culture of the organization.
Databases, low-level I/O, sorting operations, and such are nominally provided either by the standard library or sourced from the community.
Infrastructure will rule your world. Good infrastructure, with smooth provisioning and deployment, will make your day a joy. Poor infrastructure, with lots of manual work and sign-offs from ten degrees of sysadmins, will do the opposite.
You will also work as a member of a team, with a wide variety in terms of background and experience levels, making clear communication, in all forms, an absolutely essential skill.
In college, very little of the above is actually covered
Sure, you'll learn lots of stuff about operating systems, algorithms, compilers, data structures, and the like. But without any real context on what that stuff really does.
But the big place that computer science education is a big let-down is on the collaboration front. There aren't many programs, perhaps none, where you are required to, as a member of a small team, maintain and modify code built three years ago by other people, and graded on your ability to produce work that can continue to be developed by future students.
Instead, the focus is on solving relatively straightforward problems as quickly as possible, with little or no attention paid to user experience, readability, testing, and any of the other things that make up the "engineering" side of the practice of building software.
[+] [-] mr_tristan|6 years ago|reply
I swear this is another facet of agism: some think that the 22 year old with a 4 year degree is nearly as valuable as the 40 year old professional, just needs some language experience and wham! Ready to go!
[+] [-] gowld|6 years ago|reply
How can anyone take the article seriously? These are all problems that startups punt on until after they've suceeded.
[+] [-] HillaryBriss|6 years ago|reply
I've always thought so too. But it doesn't seem like any companies really buy into this any more.
[+] [-] dannykwells|6 years ago|reply
Thinking that free training which is being provided by someone else should fit your custom needs is, well, maybe not the best business case.
[+] [-] sharadov|6 years ago|reply
"When you join a startup, there’s a lot of emphasis on the design of the application, reusability and clean code, and the ability to conduct and undergo code reviews, as well as the ability to think of and build systems that can scale based on users and geography"?
I don't know which startup he worked for that was doing all this and still managing to stay afloat! Startups want you to crank out features and get clients in, everything else is a failed strategy!
[+] [-] toomanybeersies|6 years ago|reply
On the plus side, I work 38 hours a week and not a minute more, and I get paid above median for the privilege.
[+] [-] GhostVII|6 years ago|reply
Through internships, I feel I've learned the practical I need in order to work full time, and what I learn during internships is complimented by the theory I have learned through my degree.
So I guess what I am saying is that if you are doing a university program, you shouldn't expect it to give you the practical skills for working, that's not what it is for. Instead do lots of internships if you can, they are fantastic.
[+] [-] toomanybeersies|6 years ago|reply
Software engineering students had to do process and design papers, they (theoretically, at least) learned about agile development, UML diagrams, and all that other SDLC bullshit. As a computer scientist, I instead took fun papers like computer graphics and cryptography.
All the things I missed learning because I did computer science, I picked up as I needed at work. Learning how agile development works doesn't take a semester of reading books, and what you learn in theory about the SDLC at university doesn't reflect reality in any company.
[+] [-] ipsum2|6 years ago|reply
[+] [-] ummy|6 years ago|reply
[+] [-] SavageBeast|6 years ago|reply
[+] [-] geebee|6 years ago|reply
They do seem awful interested in whether I can find all matching subtrees in a binary tree, though. Which, now that I think about, is the one thing I learned in college but haven't done even once on the job once in 20 years (I have had to find minimum cost paths in a tree, though. I couldn't have done it on the spot at the whiteboard, but my data structures and algorithms class was helpful in researching and figuring it out years later).
[+] [-] ascales|6 years ago|reply
[+] [-] adjkant|6 years ago|reply
[+] [-] logfromblammo|6 years ago|reply
I got a good, long laugh out of this. This describes the exact opposite of my experience in a startup. None of those things were ever a concern until I worked for a company that already had a revenue stream.
[+] [-] jahewson|6 years ago|reply
[+] [-] paxys|6 years ago|reply
[+] [-] bdcravens|6 years ago|reply
[+] [-] all_blue_chucks|6 years ago|reply
So ultimately it is called computer science for the wrong reason.
[+] [-] dikdikvandik|6 years ago|reply
[+] [-] blueatlas|6 years ago|reply
https://www.neumont.edu/
I have no affiliation with them, but like the model.
[+] [-] hildaman|6 years ago|reply
[+] [-] manfredo|6 years ago|reply
> Students are taught formal testing methods such as static analysis, which checks code without actually running it. This helps them understand how to test software programs, but it doesn’t address the testing of distributed systems, web services, and infrastructure resiliency. Examination of these types of user interfaces and back-end systems is essential, Devadiga says.
This is a good observation. In my experience, the biggest hurdle new grads have to overcome is to learn to develop in a context where users and co-workers are going to depend on the projects they build, and need to be maintained. I didn't learn how to set up instrumentation, deployment pipelines, outage alerts, and other important pieces of infrastructure in keeping a web service online in my university classes.
> Because startups are heavy users of cloud computing platforms, it’s assumed that most software engineering students understand how these systems work—but that’s often not the case, Devadiga says. Students need a practical understanding of infrastructure architecture design patterns, DevOps, and cloud platform services like compute instances, object storage, and queueing services. The ability to create applications that can execute in services like Amazon Elastic Compute Cloud is important.
Another one that I think is on point. I did use AWS in a networking class, but that was just because the class instructors didn't want to deal with building dev environments for windows, mac, and linux. I didn't really get exposed to deploying and running a web application on a cloud computing platform. For how universal cloud computing is nowadays, it's surprising how little I was exposed to it in university.
I think it'd be great for universities to offer a "practical software development" class that didn't really focus too heavily on any one particular academic topic, but was more emphasized on imitating the kind of work that developers do in industry. It'd be cool students went through the whole class building, maintaining, and extending a single web service over the course of a semester or quarter. It'd be neat if grading was based not just on application functionality, but also uptime, average latency, and similar metrics - though that would probably be too variable to be fair, a student's site might go down while they're away on a sports competition or something like that.
[+] [-] ende|6 years ago|reply
These labs tend to organize students into pairs or small groups who proceed through a sequence of onsite exercises that attempt to closely emulate more complex scenarios; thus synthesizing the application of multiple book/lecture-learned skills in an environment that naturally elucidates and facilitates the practical systems engineering and communication skills that are only otherwise learned in the workplace.
Student performance in a lab is typically evaluated from structured record keeping of methodology and analysis (testing & documentation). There is also often a presentation component that helps students learn how to effectively communicate results to an audience.
One can imagine lab teams collaborating on all aspects of software engineering including requirements gathering, systems design, infrastructure provisioning, deployment automation, CI/CB/CT, integration testing, release management, diagnostics/troubleshooting, etc. Experienced graduate students can be recruited to play the various roles of chaos monkeys, users and business stakeholders.
Students would get a healthy dose of teamwork experience, and have some tangible software deliverables to seed their technical portfolios.
It even sounds pretty fun!
[+] [-] zeckalpha|6 years ago|reply
[+] [-] joker3|6 years ago|reply
[+] [-] dentemple|6 years ago|reply
The latter is another complaint I've heard from company owners. Too many graduates who just don't know how to work with a company's non-engineers, as they've told me.
[+] [-] jkingsbery|6 years ago|reply
1. "They [start-ups and next-gen tech companies] want grads who can build scalable systems and program for large-scale, distributed, data-intensive systems that leverage cloud computing." - For start-ups, this is only true if your startup is in that space. Most "start-ups" are trying to find product market fit, and the systems are generally not large scale as a result.
2. "Engineers at established companies mostly work within their specialty areas." - While there's some truth to this, I think it's overstated. In the start-ups I worked with, "engineers" did not do market research. I worked with plenty of specialists at start-ups that worked with language X, but if you asked them to debug an issue in language Y, they'd refuse. In some cases, it can be the opposite of what this article states - engineers at a start-up can often focus on hands-on engineering tasks, whereas in a large company I find a larger portion of my time is around writing documents to align more people around an idea.
3. "The timing of the product release is crucial because it has a direct impact on acquiring customers and affects the bottom line. Significant delays can put a company out of business." - In a large company, you won't go out of business if your release is late, but it could mean that your product gets de-funded. While the change to the company might not be so much, a project getting de-funded certainly affects the daily lives of those involved. So I think this difference is overstated.
4. "Engineers for startups are more likely to play a significant role in defining the system architecture" - My experience is that this depends a lot on the start-up and the seniority of the engineer in question.
[+] [-] halis|6 years ago|reply
But they can Google. They can study for interviews that quiz you on computer science trivia.
The interview process on the coasts is broken. In the midwest I don't have to deal with that shit.
[+] [-] dentemple|6 years ago|reply
Of course, we need a _ton_ more oversight involved to ensure that bootcamps are actually graduating people with a job-ready skillset.
[+] [-] dyarosla|6 years ago|reply
[+] [-] flukus|6 years ago|reply
Experience matters and it's not something you get in any school.
[+] [-] bdcravens|6 years ago|reply
[+] [-] mattmcknight|6 years ago|reply
[+] [-] slothtrop|6 years ago|reply
We had an intern come in that was still stuck in that student-mode of needing to be told everything and not asking pointed enough questions. After a few weeks they were up to speed and productive.
Frankly even experienced workers will still require a period to absorb specific knowledge.
I think the time required for fresh grads to be productive is way, way overstated and overestimated provided they have the right direction.
[+] [-] zaphod12|6 years ago|reply
I'll probably hire you with a CS degree, but I know I'm going to need to teach you how to be a software engineer.
[+] [-] 6thaccount2|6 years ago|reply
You basically do 4 years of math and physics with several years of calculus, differential equations, numerical methods, programming, and solving difficult problems. It is nothing like a trade school (no offense to that line of work...they probably make more money than me :)).
[+] [-] dhosek|6 years ago|reply
[+] [-] hysan|6 years ago|reply
[+] [-] pjmlp|6 years ago|reply
If you want a pure CS, usually it is a maths degree with major in computing.
[+] [-] SkyPuncher|6 years ago|reply
[+] [-] aphextron|6 years ago|reply
[+] [-] sys_64738|6 years ago|reply
[+] [-] davidf18|6 years ago|reply
This afternoon I met someone in lunch line that had just graduated in CS who said they tried to do EE but couldn't do it. I've seen others when I was in school drop out of EE to do CS.
[+] [-] Ancalagon|6 years ago|reply
[+] [-] WalterSear|6 years ago|reply
And the latter have little motivation to stay current.
[+] [-] habosa|6 years ago|reply
[+] [-] lalaland1125|6 years ago|reply