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.
> Candidly, I would say that college does not even provide the base skill-set.
This is true. The things of value (from an industry POV) that you actually learn at university are:
1) You learn to learn. You learn to pick up an entirely new area of knowledge (albeit sometimes based on prior learning) in six months to the point where you're proficient enough to pass an exam in it.
2) You learn to work to sometimes-unreasonable deadlines with minimal supervision (at least, if you graduate you've probably learned this).
3) You learn to stick with something for 3+ years even when it stops being fun.
4) You meet a bunch of people who form the start of your professional network.
Anything else you pick up is a bonus, and your first 3-6 months on the job are where you actually learn what you need for that job.
Conversely, too much practical experience can lead to a lack of fundamental understanding, innovation, and helplessness.
I can’t stand it when an engineer wastes hours looking for a library, instead of even considering actually writing code themselves. Many just can’t because they’re so accustomed to glueing together other people’s code.
Of course, I’ve worked with academic types that can never stop theorizing and actually be productive. That have zero discipline.
There has to be a balance. But yes, fresh out of school == fairly worthless for anything I’ve worked on ever.
> too much practical experience can lead to a lack of fundamental understanding
That's too little theoretical background, not too much practical experience. If you take someone with a good grasp of the basics, you will never remove that grasp by giving them more practical experience.
I often see the opposite: people wasting hours writing code when they could have found the appropriate library with a few minutes of searching. Often the library is actually already installed with the project or even part of the standard library.
The most difficult case is when writing the code from scratch actually is a lot faster than choosing and learning the API for a library, but in the long term takes more effort to maintain (higher TCO).
The choice depends not only on how complex your own code would be, but also how mature and well maintained the library is (e.g. maybe a library that's just right is some solo developer's pet project, whereas a slightly more awkward fit is actively developed by a big company). That is the sort of thing where making the right choice really requires a lot of experience.
There is little point trying to teach work-related skills in a non-work-related environment. If I wanted to teach a bunch of kids how to work, the university system would not be a good starting point. It is the blind leading the blind, there are potentially literally thousands of people with at best limited work experience all crammed in together. That is not a sane environment for teaching people how to add value to others lives through working.
University is supposed to provide networking opportunities, cross-pollinate interesting theoretical ideas that have limited practical application and provide a feeder ramp into the research community. If universities try to teach employable skills it will be hugely inefficient compared to teaching people skills in entry level jobs.
Anyone trying to learn teamwork in a team of university students is not going to understand teamwork. In real teams it is not unusual to have 1 or 2 centuries of pooled experience in the problem domain being worked on and that creates a completely different dynamic for how the work is divided up and work gets done.
> University is supposed to provide networking opportunities, cross-pollinate interesting theoretical ideas that have limited practical application and provide a feeder ramp into the research community. If universities try to teach employable skills it will be hugely inefficient compared to teaching people skills in entry level jobs.
Not to sound flippant, but if this is the case, why do we bother requiring a university degree for really any job?
Annually from the second year on during a computer science or software engineering program, students should be required to have one class where they spend at least one full day per week contributing to their choice of one of the following:
(1) An open-source project approved by the instructor.
(2) Production software used within the university, excluding systems dealing with student or faculty PII or sensitive information (grades, schedules, etc). Lots of opportunities here to contribute across the sciences!
(3) Non-commercial software benefitting the community or government at any level (from local to national).
That's exactly what many UROP schemes are (/were, anecdotally after all). (Undergraduate Research Opportunity Placement, I think. Speaking from UK but I believe it's a pan-European scheme.)
The problem is then their grade ends up being heavily affected by the quality of work done by other people. It'd be impossible to objectively grade such a task.
The key difference between university and work is that in the former you are supposed to receive a pretty fine-grained assessment of your own skill, which is isolated and repeatable. In work, it's understood that promotion and slotting is a much more arbitrary affair and the marking criteria may not even be documented, let alone applied consistently. Also if your project fails because of bad work done by others, well, tough luck, that's what your salary is for. In university you're paying to be there, not the other way around, so the amount of random failure tolerable is much lower.
Maybe it's less about the quality of your code for this and more about how you do on: estimating your time, hitting your schedule, collaborating metrics (response time, ticket closing, etc.)?
- customer oriented thinking (your not working for artistic beauty, balance technical arts and feature set ROI)
- pragmatism (even though they'll send a few "solve it then make it fast") you don't really get to feel the real pressure of aiming right at a good enough solution.
- optimization, not enough variations on a piece of logic to make it faster or whatever metric you need to optimize.
> Candidly, I would say that college does not even provide the base skill.
Things may have changed in college, but when I have very young in their career people start with me, one of their first tasks is to book a 15-minute meeting with me.
Learning Outlook/GCal/? and how to find a book a meeting room is base-level skill.
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!
Ding ding ding. This is just silicon valley living in their v rockstar bubble again. They don't act to have to pay for top talent, they don't want to grow it, but then complain that qualified candidates don't just spring from the womb as willing to be underpaid experienced coders.
> "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.
... Or if they start looking for a new job within a few weeks of starting (the idea of getting 3-4 jobs in the first 2-3 years with increased compensation each step).
After getting a few hires that only stay for 6-12 months, its a question of "is it worth it to put in the time to mentor them if they're going to be gone shortly afterwards?"
> ... Or if they start looking for a new job within a few weeks of starting (the idea of getting 3-4 jobs in the first 2-3 years with increased compensation each step).
This is half tragedy of the commons of so few companies offering training and half companies being so god awful at offering raises as employees gain experience.
Sounds to me like "the tragedy of you being a dick" to paraphrase a xkcd. They caused all of their problems through their policies (not keeping existing competive with new hires, refusal to consider lesser experience, expecting loyalty without any give) and it came to bite them yet they don't want to take any effort to fix them in any way.
At this point, its hard to point to one being the cause and the other being the effect.
It has also lead to companies doing the "we only hire mid to senior level because the entry level is too flaky" which also alleviates much of the need for mentoring new grads.
It also produces the interviews where people are asking about the passion for the particular domain that the company is in, in hopes that passion will keep them around longer.
That said, if someone is planning only staying for 6-12 months regardless of the company's current pay and mentoring practices, I would agree with the "job hopping came first" as an artifact of the dot com boom days when everyone was trying to one up everyone else.
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).
Yes the software interview process is broken; the skills evaluated are rarely the ones that measure the success of an individual at an startup. I prefer to ask system design questions.
I require systems design questions for anyone with >3 years of experience. We also do a coding and PR exercise. My team manages some machine learning systems, but I couldn't care less if they know how to implement SGD in some form. Can they recommend how to reduce the memory footprint of a system/model? Our customers don't care how our system works; only that it works reliably and consistently.
The questions FAANG ask should not be the questions a startup asks... FAANG have to deal with measuring candidates at huge scale, and have literally too much talent coming through the door. A hiring decision in a startup can be a series of life or death decisions.
I think algorithms questions are an OK litmus test for being able to program, but it shouldn't be everything or even 1/4 of an interview at a small company.
The competence is their half and the only bit of filtering - them sticking around is "yours" (the start ups) as you set the environment, pay, and benefits.
I don't know how big the percentages are but a worker's decision to stick around is a function not only of environment, pay and benefits. It's also a function of the worker's level of interest in the company's subject domain, individual desire for continuity, risk aversion, etc.
> FAANG...have literally too much talent coming through the door
From first hand experience, I would strongly disagree...
I won't beat the dead horse of the sad state of tech interviews, but just wanted to point out that this statement does not align with my experience at all.
I'm more referring to quantity than quality. At that scale it's better to optimise for a lower false positive rate because your business isn't going to collapse if you miss a decent candidate.
It will negatively impact the business if the business can’t identify the best candidates. It can have a low false positive rate and still hire relatively mediocre engineers. Which is what I’ve seen happen over and over again.
At what point is a company no longer a startup and just a small business looking for talent? I ask because my view of a startup that isn’t a unicorn worth millions within its first few years (where rapid growth will encourage a hiring spree) is its usually a handful people and some office space.
Are typical start ups really doing whiteboard interviews during their early stages? I expect white boarding from a company like Uber or Discord but don’t most still hire based on networks and recommendations?
> At what point is a company no longer a startup and just a small business looking for talent?
I'd say when it stops accepting funding and determines it wants to stay as a small business. But that's probably a bit rare for companies that have taken on significant funding. After all, if I'm an investor I'd like my money multiplied (>1, thanks).
> Are typical start ups really doing whiteboard interviews during their early stages?
It varies a lot on the startup and the founders. Some founders don't have a large network of engineers (or - rather - engineers who would like to work at a startup for startup compensation; this is especially true with very early startups). You'll eventually have to hire from outside because your network will run out.
I've been hired as an early engineer at a seed stage startup. (Would not recommend) I've interviewed at dozens and dozens of startups in SV all across the funding range. Many of the ones I interviewed with did ask typical whiteboarding questions that you'd find at FAANG. After all, many come from FAANG and don't know any other way to interview. Or they try to imitate "the best".
I can't speak for more recently, but a < 10 person startup I interned at the summer 2014 had me do a number of whiteboard-style interview problems (although remotely, due to how far away I was).
Non CS people may not understand this at first, but you are exactly right. A 'tree' is connected and has n-1 edges. So there can only be precisely one path between any pair of vertices.
He may have meant a general connected graph (not specifically a tree). In which case, there could be multiple paths and some may be cheaper than others.
That’s a good guess/intuition - you’re correct that it wasn’t a binary tree strictly speaking. It was a situation where each node could activated by conditions on sub nodes, with a cost associated with activating each node. Also, in different scenarios, the tree would come with a different set nodes already activated. So the question was to figure out the minimum cost set of activations and in which order.
It wasn’t a graph though as there was a unique path from the root to each leaf
That’s about as well as I’m going to do here it was a while ago...
The thing about all of those skills is they are all soft skills, that can be taught quickly on the job to the right candidates. Whereas a deep ability to solve a technical problem cannot be taught in a reasonable amount of time to most people.
Asking someone to find the matching subtrees in a binary tree might not be the best interview question, and to some extent it is kind of trivia for "did you grok your CS education well" - but the point of algorithms questions overall is to see if the candidate, when confronted with a tricky problem, will solve it.
And no, these tricky problems don't come up all that often, and you're often just doing basic coding plumbing work. But the candidates who can solve these problems can do all the plumbing work too, and when confronted with a tricky problem, they can get past it. And they also may innovate in an algorithmic way where a less deeply technical developer will either get blocked or come up with a worse solution.
“The thing about all of those skills is they are all soft skills, that can be taught quickly on the job to the right candidates”
Citation very much needed. If anything my experience suggests I can teach people with “soft skills” how to do algorithms and data structure tricks much easier than the opposite.
> The thing about all of those skills is they are all soft skills, that can be taught quickly on the job to the right candidates. Whereas a deep ability to solve a technical problem cannot be taught in a reasonable amount of time to most people.
This is the exact opposite I have seen in 20 some odd years of working. Maybe if you mean deep technical skills as an expert in cutting edge ML? Thing is, most companies do not need that that depth of expertise. They need someone who can get build standard web/mobile apps, and not be an asshole (and even a bigger plus if they know anything about business/finance/project management). How many assholes have you ever turned into not assholes vs. how many people have you been able to teach something technical? Soft skills are hard for many people.
EDIT
Wanted to add that a pretty standard soft skill of being able to check their ego often allows people to learn more easily than those who can't put their ego aside.
I can handle most personalities within 2 sigma, coach where I need, what is very hard to change is mindset.
People who won't try new things, because they'll suck at it.
People who don't Google (they know how, they just don't) because they think all answers all received wisdom, not something between a SWAG, an opinion, and a mental model.
People who don't read things outside their domain because that's someone else's job.
People who confuse having 1 experience for 7 years with 7 years experience.
People who think you have to be an expert scientist, engineer, architect, philosopher, and mechanic to change a light bulb, so they never even tried.
People so worried about imposter syndrome they'll never deliberately exert any curiosity for fear it will be seen as ignorance.
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.
Your whole life has goal posts laid out for you. You go to elementary school, get good grades so you can get into honors classes in middle/high school. And you do this again for college. Everything is quantitatively measured. How many questions did you get right? How many days did you attend school? How many extracurricular activities did you participate in? How many hours did you volunteer? All check boxes that other people hate laid out for you so that you can be measured in the funnel. And, artually, for some people this process can continue in their career. You get good grades in college, then you get an internship at BigCo. Then you get a job at BigCo. On and on until you die.
The problem is, you never had to figure anything out. So if you ever decide to do something non-standard or if randomness hits you too hard, or if someone along the way deems you "not good enough", now you're off the track. And you have never had to set your own goal posts. If you have to be constantly told what to do, employers are not going to want to hire you.
I think the lack of critical thinking goes hand in hand with an inability to function without rulebooks and structure.
I think this is somewhat right, but I also think that there aren't enough project based learning opportunities in school, and there certainly is not enough opportuntities to fail in school. A number of universities are implementing a limit of 3, sometimes only 2, on how many times you can fail or drop a course. So there is definetly a comply-or-die academic environment that just doen't exist in most tech jobs nowadays.
I'd love to see a curriculum where there is a class each semester that is 100% project based, where the end result isn't as important as the process.
On the right track, but even moreso of a factor is the personal relations in one's life. A kid straight out of school being told constantly to "go get a job" has trouble trying new things and getting a startup going. They end up trying to please these other naysayers and at the same time trying to pursue their dreams, thereby splitting their efforts and cutting their productivity of both in half, resulting in fewer successes over a longer period of time, further demoralizing them.
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 would best describe software development at startups as speed jenga. The cool thing is the objective of the game isn’t to build a functioning tower but to instead convince more people to join the game.
I mean, early stage startups fit your description, sure ... but I can't imagine many startups surviving much traction if those things don't start being looked at soon enough. Of course, some do (see twitter's Fail Whale), but I'm guessing the vast majority of startups that fail to scale ... well, they fail
There may be some confusion in my mind between companies that are only recently embarked upon a new business venture, and those who are already bringing in sufficient revenue to bootstrap further growth, but are adopting a generic "startup" branding strategy in order to shape their work culture and attract further investments.
That is, after being an indisputably young startup, the business declines to transition its identity into being a growing small business, and remains a self-described "startup" because it is secretly a huge business that is still in its second or third instar, ready to moult, and to also seem like a cooler place to work than it actually is, now that the HR department has multiple permanent employees.
The emergency all-hands pivot brainstorming meeting just doesn't seem like it can even take place in the same building as all those design discussions and code reviews.
Does anyone else think that "startup" has become a branding strategy rather than a descriptive term?
Well, there's lots 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... as long as all of those things cost no money and take no time, because we pay you to crank out features, code-monkey.
Then their needs are mutually exclusive and they have to compromise somewhere. If they want someone that can hit the ground running then they need developers with experience and not fresh graduates. If they really need someone to hit the ground running they might need highly specialized (expensive) experience too.
What schools? I don't know of any such degree at MIT, CMU, Berkeley, UIUC or any other top school. At best it will be a single course or some added certification to your degree, and even then they will teach you software engineering processes, not Node.js and React.
I went to CMU (econ major/CS minor) , and we absolutely had such a degree. It was called Information Systems, and generally taught people the skills needed to become a web developer. Skills such as front end developement, Ruby on rails, ect, as well as even some mobile dev electives I think.
Unfortunately, even though it was one of the best such programs in the world, and turned out graduates who made 80k+, it was still generally looked down upon, as the degree that people took who "couldn't get into Computer Science".
It is unfortunate that people in academia severely look down upon anything that has a more practical focus on useful skills, and only respect theoretical studies.
Information Systems programs are commonly business degrees. At CMU, it is offered by the Dietrich College of Humanities and Social Sciences[0]. In aerospace and defense, some employers and even the government do not value IS, MIS, or CIS degrees as highly because they are not considered engineering degrees like engineering proper, math, computer science, or physics. In those industries, the way to make up the difference is to complete an advanced degree from an accredited institution.
Whether academia is responding to signals from industry, vice versa, or neither is an interesting theoretical question. In practical terms, one might argue that better route for those industries at least is to choose a degree with higher perceived value.
> In aerospace and defense, some employers and even the government
Fortunately, I wasn't talking about areospace, or defense, or whatever. The vast majority of people who come out of CMU, are not working in these very specific job areas, so they aren't relevant.
Instead, they are working at SF tech companies like Facebook, and Apple, and the like.
And if you look at the places that the Info Systems people go to, it turns out that the vast majority of them have the job title "Software Engineer", making a median salary of 90k$:
It turns out that a whole bunch of people with these degrees are able to get top software engineering jobs at top tech companies.
> In practical terms, one might argue that better route for those industries at least is to choose a degree with higher perceived value.
No, the facts show that a very effective way of getting a prestigious job, working at a top tech company, with the official job title of Software Engineer, is to get an Information Systems degree. The stats I showed, prove it.
The problem for most schools is an engineering degree is a specific, formally defined degree. It seems that ABET has recently updated their Software Engineering criteria, but for decades a software engineering degree required extensive curriculum in physical science.
> Information Systems is NOT an engineering degree.
It teaches you how to work as a web developer. Web development being something that people often call software engineering.
Use whatever word or definition that you want to group Info Systems under, but at the end of the day, these people with these degrees are still getting jobs at Google, FB, and the other top companies, and/or startups, and are giving the job title "software engineer".
That is the definition of software engineer that I use. It is defined as "Those people who are working at google, or top startups or whatever".
Agree though that the Soft Eng degree is differs from CS largely by dealing with process, not technology. The first versions of the SWEBOK were pretty terribly biased towards a waterfall process.
I am not aware of any that offer SE. I went to a highly practical school and the SE discussion frequently came up - because many students preferred the pratical to theoretical.
Ultimately, my school could not offer a formal Software Engineering. "Engineering" degrees have not caught up with the times to include software. A software engineering degree would require completely irrelevant course in physical science - like thermodynamics, statics, and advance physics.
The modern day web dev degree is called "Information Systems". Top schools offer it, but it is generally looked down upon as the degree that people take who couldn't get into Computer Science.
There are plenty, but they're mostly graduate degree programs. A full undergraduate degree in software engineering is probably impractical, as it were.
CMU offers a minor in Soft. Eng. It requires 6 courses (one is fluff) and a minimum 8 week internship in industry. What's also good about this CMU minor is that it's open to students of any major.
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.
MIT's was (is?) heavy on theory, light on coding practice. I still think it was a pretty good program, they just expected that you'd learn to program outside of class.
I found them very challenging and interesting. It took me a few weeks to complete them, and I didn't even do the "project" part which was more open-ended.
Right, the labs were the major exception (and by far my favorite part, even though they tended to involve a lot of sleeping on things other than beds).
I'm not an MIT grad, but this has been my approach over the past few years when I decided I needed to educate myself on more paradigms rather than more languages. I found it less helpful to expand my skillset of similarly-styled languages and far more helpful to learn languages that are fundamentally different than the ones I already knew. Basically, I decided I should learn Lisp instead of yet another C-style language.
The end result is nice little feedback loop of far better understanding of the theory and concepts behind the code that I write feeding into writing better code, which then feeds back into better understanding. So now when I help peers (especially friends still in college), I focus less on the language and more on helping the concept click for them.
I can't say how well this works in practice in a university -- it sure seems to work for MIT -- but I know that in my professional life it has made just about everything I do far easier to reason about and my work is all the better for it.
I took the 6.001 edX courses a while back. Introduction to Computer Science and Programming in Python--actually broken in 2 parts for edX.
Yeah, it came across to me that the expectation was that you'd learn to program mostly outside of the course. Or, really, that you already had a reasonable grasp on the basic concepts. Otherwise I think that course would feel to most people like being tossed into the deep end of the pool from a great height.
To be sure, with the campus version of the class there would be recitation sessions and other resources to get help on the programming side. There's also a companion textbook that goes into more Python details. But that's certainly not a class to "learn to program," much less how to work on a command line, use an editor, etc.
That may be reasonable for an MIT CS curriculum but most other majors probably don't have the same degree of implied prerequisites.
Yeah, that was a pretty common feeling in 6.001, especially among those who hadn't done much programming in high school. At the time, it was taught in Scheme (a Lisp), which no one I knew taking it had any experience in, so everyone was on sort of equal footing there, at least. And more generally, it seemed to be a pretty common approach there to throw students into the deep end and let them figure it out - people liked to compare the experience to trying to drink from a firehose :-D. I'm not sure if it's optimal for learning the material itself, but it does make jumping into new subjects seem less daunting after you've gone through that a few times.
There's probably an expectation these days that students have some degree of exposure to computers. When I took an intro to computing course (FORTRAN) it was pretty much no expectations. But times have changed.
And I found 6.001x useful. But then I had a lot of experience with computers even if not programming full-time professionally.
I didn't touch a personal computer until a few years later in a job where we had an Apple II to do some engineering calculations. High school was BASIC using a teletype connected to a local community college--and that was pretty forward looking at the time.
But I didn't really use a computer to speak of (other than as a text editor in grad school) until I was working--and later got into programming as a hobby.
> 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.
If bootcamps churn out employees who are productive from day 1 that will fix the problem. However, when you see a resume from a bootcamper who over the course of 4 months learned Linux, AWS, Javascript, jQuery, Node, SQL, Ruby on Rails, and React, it invites skepticism.
The signaling from [elite school] doesn't matter as much (to that applicant's competitors) if there aren't enough elite school graduates to fill positions.
A startup can hold out for MIT grads for as long as they want, but they ain't getting one if every other startup is doing the same.
_Someone_ is getting hired at the end of the day. A company that's looking to grow rapidly can't hold out forever.
I mean yes, some bootcamps have started cementing their own signal too (see Lambda) but I don’t know whether that many code bootcamps will surpass [second tier schools]’ signals. You are right tho that there will be a supply problem either way.
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.
They should. Often, they aren't. There are a number of reasons there - some don't have the time.
> Because startups need to bring their products to market quickly, applications are built iteratively, with rapid prototyping. 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. While time to market is also vital for large companies, their software releases are typically for established products, and if they run late, such companies usually have the money to survive.
---
Some don't have enough people to properly mentor and train a new hire.
I would contend that any company in the 2-10 range hiring a new grad is a mistake for both particles.
---
Some acknowledge the "they get a job, they get trained, and they go on to greener pa$ture$." In this case, the mentoring is a lost ROI in many cases.
---
My reading of the desires of the person featured in the article... they want to hire a person at new grad wages who knows how to debug a legacy code base, architect a cloud solution, come up with new product ideas, do market research, and be a participant in the "devops means we give developers root" culture... and be able to do this within single digit number of days.
Those are things that come with experience and failure. No class or boot camp will teach those things to a point where the person is competent in them without some good time to work on those skills (side note: this is where college often produces better candidates than boot camps - they've got more time to learn the tools).
Rambling on the above... I now have a one question that will distinguish a good candidate from a poor one: "How do you set a breakpoint in your preferred debugger?"
Concede that time may be a factor, in which case, companies have little choice but to shell out real money.
> mentoring is a lost ROI in many cases.
What investment? Grads are cheap, and time to productivity as I argued isn't that long, before which they aren't merely learning. Most of the investment here is on the worker's part, and greener pastures aren't available as quickly as productivity sets in. If you're fresh out of school and working, leaving a company is unthinkable in the first year, unlikely in the 2nd.
Investment of time by other developers who could be working on the features.
This isn't saying that mentoring can't be a positive ROI - just that the person needs to stay long enough.
> If you're fresh out of school and working, leaving a company is unthinkable in the first year, unlikely in the 2nd.
You should check out reddit /r/cscareerquestions and consider how many people advocate leaving under a year.
I will also note that for my own experience, while there are some developers who stay for a long time, there are more than a few that start and leave within a year.
In trying to get two developers that would stay on, we went through six developers. Four of which left within a year. This is for public sector and the lack monetary compensation shouldn't be a surprise to anyone... still, had four developers that we trained up and left.
The investment of time in getting them to that point where they could be useful contributors if they had stayed was more than what it would have taken the developers who mentored them to just do those tasks and not have hired anyone.
That doesn't touch on the actual pay and paperwork to hire someone.
So management decided it's cheaper to keep compensation low and have a revolving door of developers than try to retain them, or is it merely short-sightedness?
In the public sector, management has very little they can do about raises. Raises are an act of legislature or the governor. The number of people at each level within a bureau is likewise an act of legislature or governor.
People applying and taking the job know exactly what they are getting and going to get for compensation and benefits. Pay is a bit on the lower side, vacation is on the higher side, the pension is fully funded (actually at 102.9%).
Thus the ability to juggle things to retain a person is very limited - especially when that person hasn't been there for a full year.
Consider then, that the person is accepting the job, knowing that this is the public sector, knowing the wage history, and looking for another job elsewhere (many have left to move out west). It is not exactly practical for state government to try to match west coast compensation.
> It is not exactly practical for state government to try to match west coast compensation.
It isn't, though there may be a sharp difference in cost of living and that's a strong consideration with wages. That, and a pension and benefits is taken for granted by younger people. Besides govt positions tending to be less exciting, you can really put some money away. Moving up, though, is a sluggish process.
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.
I went to a state school, and as an EE undergrad I got the sense that anyone who couldn't hack EE switched to CS and anyone who couldn't hack CS dropped to IT or something else.
Clearly both fields are equally complex and challenging, but I got the sense there's something particularly asymmetric and grueling about the EE curriculum.
I went to a state school and went CS, though I had several friends in ECE (electrical and computer engineering). The difference between the classes we took is largely summed up in:
* They took more math and physics than I did.
* They had fewer CS electives than I had.
* I had more 'breadth requirements' outside of of the core major than they did
* They had to maintain a much higher GPA to remain in the engineering college
* They had classes that involved a soldering iron and hours spent in front of mentor graphics (to the point it was nicknamed 'tormentor graphics')
The EE/ECE curriculum may have changed since then. It probably has. However, (at least at my alma mater) the engineering college is still as selective as always while the CS department unanimously voted that they won't cap enrollment (and instead figure out how to get larger lecture halls and more sections as needed).
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.
Revive apprenticeships - where learner goes to master and learns directly from the one who practices the skill on a daily basis. In modern wold, this responsibility should rest on tech giants, who should have dedicated apprenticeship programs; and they should pay apprentices an honorarium for investing their time in studying their area of their, instead of their competitors.
For some reason, I don't know/understand, this responsibility got shifted to taxpayer.
There is a relatively simple solution, one that's been the norm in many other industries where there are shortages of field-specific knowledge and skills - in-house training.
This may not be an option for startups but, then, maybe startups should focus on hiring more experienced professionals who can, with time, bring freshly graduated engineers up to speed, as well as helping design systems and processes tailored for the company and product.
This is because most grads are one step higher than interns. They really dont know much (and shouldnt be expected to) because they lack real experience. Startups higher them because they are cheap and will work hard long hours without question. It's the trade off they are willing to accept.
VC often puts pressure to increase headcount, and unfortunately, those doing the hiring are willing to look the other way when that's the standard for accountability as opposed to productivity.
Yeah I agree, it makes sense and Im not saying its wrong either. In the atmosphere of move fast and break things its often okay to turn out bad code and fix it later once you get your hockey stick of momentum (which in some cases is perfectly acceptable). Hiring truly senior people might slow that down because they know better and want more polish or thoughtfulness put onto a product. I can see it both ways. Im not sure if Ive ever encountered a hiring manager that expect much out of a recent college grad, especially if its an undergrad. But they can learn fast and are usually eager, which is good for a startup where positivity and attitude are needed to keep moving forward.
Edit: I wrote a whole post but now realize that software engineering is a much more conceptual master than computer science. I'll leave the following below still here since it might be interesting. I mistook the perspective though, since I talked about computer science and not software engineering.
/edit
What I'm wondering is: doesn't university prove that one is capable of learning programming/computer-related topics?
The hardest things I've learned about were:
- rowhammer/cache sidechannel attacks via the GPU with C and then porting that to Javascript and do it over the web
- creating a computer graphics engine from scratch (I did this in Java which made it easier)
- reproducing a simplified version of Kevin Mitnick's attack on the Boston super computer (? not sure, memory is vague) with C, libpcap, tcpdump and other tools/libs
- being passable at reading x86/x64 assembly and understanding how a computer is built from the architectural level to a modern programming language, playing around with creating an MUL instruction for a toy ISA
- compilers and reading a toy ISA to then be able to read the toy machine code made for it
Is this practical? No.
Is this a lot harder than creating a new web app for a startup just starting out? Yes, if you know a programming language or two, then it's easy to hack things with JS together and also fairly easy to get up to snuff with ReactJS and ES<whatever_year_it_is> since it's mostly syntax features.
I don't have experience working with legacy systems or 1 million users large scale systems, so I can't comment on whether that's more difficult. However, since this article is about startups. I've worked for startups that existed 2+ years, and becoming productive on the job didn't take me long and I'm not an amazing programmer by any means.
My bachelor though, yea, that was a lot worse. My master in CS saved me by following security courses where the professors expected you to learn almost anything on your own.
During my undergrad, I took an elective course from a visiting Professor on TDD. I found that directly relevant to work experience afterwards. That said, I wouldn't say my core CS classes were useless at all.
My observation is that the CS degree starts making a difference about five years after young programmers start working in industry. Those without the formal background hit a wall in their technical development.
This seems obvious to me since most of the jobs seem to be in web dev, maybe I'm wearing blinders but there doesn't seem to be much out there that isn't CRUD work. Computer science is almost a different field, to me its like masonry vs geology
Web dev seems to be the majority, but there is plenty of work out there in other sectors, eg. banking, finance, day trading, emergency services (my field). The jobs are out there but you have to look for them. And oftentimes they can be much more secure than a role in a startup as well.
It really depends on your skillset. I've got over 20 years experience, and honestly, I don't feel like I have the skills that most startups need either, nor the desire to forgo a decent salary in the hope that they "make it big" someday.
"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.