I took a number of these courses as an Amazon software engineer and I found them very useful.
Amazon’s goal of the internal program is to train Software Engineers to know enough about data science to be effective as “machine learning engineers.” Once trained, software engineers can either implement models themselves, or more likely, partner with a data science team to productionize a model.
The courses by Brent Werness are particularly good, he has a knack for explaining the intuition behind the math, pulling back the layers of abstraction, so it’s not just “call scikitlearn and cross your fingers.”
Some of the more advanced topic courses like Natural Language Processing are particularly challenging, as the material is more of a survey of the latest research papers, to give you an idea of the state of the art, but understanding the mathematical tools is non trivial.
I really appreciate this kind of courses. And I would like to see more produced from public institutions. As good as Google or now Amazon courses are, I have seen too many colleagues that instead of engineers are Google extperts or Amazon experts and lack a broad view of software engineering.
I love company specific courses to get knowledge that helps my company to evaluate which product to purchase. But, I dread to work with colleagues that invest their curriculum in a company and become radical protectors of that company. Software engineering is more that knowing the API for product A or B.
I would rather say that that is what software engineers do, not what software engineering is. I would describe software engineering as a professional discipline, which involves translating requirements to a programmatic system model, writing code, knowing how to test it, build it, deploy it and support it, etc.
I'm inclined to agree with you, but I'm guessing OP is referring to "craftsmanship in software engineering", which is probably a mix of both computer science and other habits formed over many years of conscious focus on improvement?
One of those habits could be how to generally solve a problem, versus how to just duct-tape together a solution. If we don't understand something from first principles, we don't really understand it in my opinion.
I'm lucky to mostly work with people who're both good at their craft, as well as good at "getting the job done". For me personally it would be frustrating to be subjected to massive tech-debt generation and sub-optimal solutions just because the team is unwilling to step outside a walled garden.
If we don't understand something from first principles, we don't really understand it in my opinion.
How many modern developers have written a single line of assembly yet alone written production assembly code? How many have even written C or used any other language that doesn’t have garbage collection.
Everyone who started working on a technology before abstractions make it more accessible think that you really need to understand deeper to be effective.
I had to get out of that mode of thinking myself as I’ve been in the software field either as a hobbyist or professionally for 35 years and I did start off writing assembly as a hobbyist (and some as a professional) and spent a decade writing C.
But then, I also see the same attitude from old school infrastructure guys now that I live part of my life on that side of the world when they say I really need to understand the “fundamentals” of IT and I can’t possibly be effective as a consultant if my only experience standing up infrastructure is writing a yaml file.
At the end of the day not everyone needs to understand the fundamentals to get their work done and create business value no more than your software as a service CRUD developer needs to know how to reverse a binary tree on the whiteboard.
If what you mean by "on average" is that that is what most people calling themselves software engineers do, that may be true. But framework knowledge is to software engineering what knowledge of tools is to civil engineering.
If you're building a dog house or even a shed, that'll be plenty. But I've seen developers try to take a knowledge of framework alone and attempt to build large-scale, business-critical applications, and they tend to come crashing down around their heads.
Counterpoint: I’ve seen plenty of “smart people” who could reverse a binary tree on a whiteboard in their sleep, wasted hours writing a maintaining their own bespoke frameworks because they thought that their problem was a special snowflake and couldn’t deliver business value that met customer’s needs to save their life.
Part of my role at my last two companies was to know what to outsource and what to build internally and when to outsource the grunt work - ie decide what “the undifferentiated heavy lifting” was.
Absolutely yes. I don't think that raw computer science is what most software engineers need. But it's also a lot more than framework knowledge. What is missing in most developers' educations is the actual engineering. If civil engineering is applied physics, then our discipline is applied computer science. A physicist might be a terrible civil engineer. Plenty of computer scientists are terrible software engineers. But that no more means we need to neglect the computer science then it means that civil engineers should neglect physics.
There are many different ways that people master a profession, and sure, in the best of all possible worlds people would learn under the guidance of expert mentors who supply "guard-rails" for the work of people they mentor.
In reality, however, that's not always possible. Many of us don't have the benefit of a safety net or benevolent deity, we just wing it, fail, learn, and try again. It's not always pretty, but it works, eventually. Someone who is a Dunning-Kruger poster-boy one year may very well become your MVP a couple years later.
If people don't push the limits of their capabilities (which often means failure), they'll not be able to grow.
> Software engineering on average is indeed knowing the APIs of a few frameworks or products well.
I actually would have said that is the main thing that distinguishes a "programmer" from both a "computer scientist" and a "software engineer". Programmers are the tradespeople who know the APIs. Computer scientists know the science of the algorithms. Engineers know the design principles and systematic methodologies to apply them in practice successfully (independent of specific APIs). Of course, all this is blurred in practice.
> I have seen too many colleagues that instead of engineers are Google extperts or Amazon experts and lack a broad view of software engineering.
Maybe that's the key to quick success?
Because I know tons of well paid frontend devs that do not understand even the most basic web technologies. They are however good in using 2-3 specific frameworks.
> I would like to see more produced from public institutions.
I understand this sentiment, but I also don’t think it’s very realistic to expect this based on how much more money people make working in industry vs education.
I was once interested in teaching at a software engineering school and the money offered wasn’t even close to being competitive with what I was earning as a full-time developer.
There’s just no way education for the sake of education can compete with programs put on by these companies that have established business models and practices. Why would experts at FB/GOOG/AZN leave those opportunities to go build curriculum at public institutions for a fraction of what they make as ML experts at these companies?
What would be the criteria to say ML is becoming another commoditized skillset sort of like how cloud computing or mobile app development eventually became? I feel like there is a big increase in these types of resources that make it possible for anyone (with necessary background) to learn.
There are resources out there to learn any tech skill with the necessary background—and resources to pick up the necessary background if you don't have it. At the same time, tech as a whole is not (fully) commoditized, at least in the sense that there is a wide range to the market and a lot of differentiation towards to top end of the skill distribution.
My impression is that ML is getting to the point where you can do useful ML for some businesses without needing particularly deep expertise or creativity so I could see a commoditized lower end to the market developing (just like you can get a generic mobile app from a random consultancy), but there will still be a lot of important business problems that are too hard to tackle that way, leaving a lot of room for experts in the market as well.
1) It's considerably harder and 'up the intellectual stack' - which will be a limiting factor.
2) It requires data, and a lot of it, and the cleaning and maintenance of it. Very few people have access to the necessary data, and companies are protective of it.
3) AI has very few obvious applications. There are a lot of 'apps' because they do something useful for us. But how many 'AIs' have you downloaded or used, i.e. things that are mostly AI? AI is an 'approach' not a 'solution'.
So because of those things, we're not seeing a 'sea of developers' like wit iOS, rather, AI is caught up in the 'big companies'.
Because 1) AI researchers are still expensive and 3) they are generally not profitable.
Because of 2) there are few places regular people can practice AI.
So you end up with massive companies that can support major R&D operations (Google, Amazon), and a ton of secondary companies with tons of data, but can barely manage their own IT, let alone, do 'fancy AI'. Think airlines, most banks, insurance companies.
So the first real applications of AI come out of Google. We will start to see some financial products etc.. We'll some nice experimental apps, but generally not a lot of 'small companies winning hard on an AI play'.
That said - you may see startups who are 90% regular company, but who have some AI tweaks that make them differentiated.
FYI - a lot of AI is still mundane: Spotify playlists, Shopify support - we would not miss it if the AI were removed, it's mostly superficial gains.
AI is a weird subject because 'it will change the world' but mostly by providing incremental jumps in some areas, that allow bigger jumps in others, like 'self driving cars' - the improved image recognition means cars cross a treshhold whereby they can start to understand enough around them so as to actually, possibly drive on their own.
Remember when everyone needed a little computer knowledge, maybe even some minimal programming skills, even if you were a mathematician or a social scientist?
Well, now we have a similar situation with data sciences.
This is a fantastic initiative, like the Career Certificates Google announced lately [1]. I do wonder why Amazon didn’t partner with Coursera, EdX or similar to offer certification along with the knowledge. Anything that makes learning more legible is to Amazon’s benefit as a giant hiring machine limited by the attention of technical talent. If they offered certs they could (perhaps) allow the holders to skip one stage of interviews, like a phone screen, or even just automatically allow them access to Amazon’s coding screen like Hacker Rank.
If they offered certs they could (perhaps) allow the holders to skip one stage of interviews
For all that is holy I hope not - speaking as a consultant who works at AWS. I held a number of AWS certifications before being hired. I used them mostly as a guided learning path to help me know what I didn’t know. I also had “enough” real world experience as both a developer and working with AWS’s fiddly bits to be useful relatively quickly when I started working here.
I saw far too many “paper tigers” when I was in the real world who have all of the certifications you could imagine but couldn’t pass my relatively simple tech screen when I was hiring operations people to take some of the load off of me so I could concentrate on some development projects.
While about 1/3rd of the phone screen covers technical topics, quite a lot of it is “behavioural questioning” to see how well your experience aligns with Amazon’s leadership principles (ignore the “leadership” name, they apply to everybody). Same with the rest of the process, so I’m not sure how much a cert would take off to be honest.
I think there is value in certification anyway, as per the AWS certs, but not as a “let’s skip part of the hiring process”, maybe just edges you on the CV screen perhaps.
My guess: using all amazon tools to get you tied into their stack. This is an Amazon MO I don't likeand have seen frequently (along withmany stockholm syndromed users). I hope I'm wrong though.
When I took some of these courses at Amazon, they were taught using open source tools like numpy and mxnet. Assignments and enrollments used an internal platform, and most hands-on work used a Jupyter-like platform that I don't believe is offered as an external service.
There was a special session offered at one point that covered how to apply what you had learned using AWS services like SageMaker, but it wasn't integrated into the curriculum. (Not sure if this is still the case; I took MLU courses in early 2019.)
Amazon doesn't need to tell people to use their technology to benefit from educational videos.
Completely ignoring the educational content itself, well made educational videos bring community good will. This helps in both purchasing decisions and recruitment. Honestly, this basically can come from a PR / recruiting budget. Lecturer's aren't that expensive.
Now, for ML specifically, expanding the set of ML engineers has a dual benefit:
1) Creates more awareness and therefore demand for ML cloud services. Opensource? No problem, amazon will cheerfully sell you gpu enabled ec2 instances.
2) Expanded pool of candidates for hiring, and increased likelihood that internally, someone will propose a viable ML solution/product.
The ML sector is still growing rapidly, anything that fuels its growth is going to benefit Amazon simply by virtue that they're always going to be in the running for any business purchasing decision, and probabilistically, they'll get a percentage cut of that growth. Education helps grow it, and educational videos are pretty dang cheap.
I have seen the same for Microsoft and IBM. Too many virtual workshops during presentations, even with smaller companies, seek to teach the use of their simplified tool rather than instill under-the-hood knowledge or develop a skill in a broader scope.
On a different note, recently I was looking to learn AWS concepts through online courses. After so much of research I finally found this e-book on Gumroad which is written by Daniel Vassallo who has worked in AWS team for 10+ years. I found this e-book very helpful as a beginner.
This book covers most of the topics that you need to learn to get started:
I'm very interested in giving these classes a shot when they become available. I have been working on a tool (for 4 years now) for a hockey simulation that tracks growth of players and I try to do some predictive analysis, but I have limited knowledge on that subject. I would love to use proper ML techniques to predict player success based on the data points I capture.
I'm fine to use Amazon's cloud services for the course, but I hope they are not required. That will severely limit the usefulness of the course for me.
I think it’s just a much harder problem than Netflix or Youtube recommendations - Amazon has at least 500 million products, and people aren’t buying individual products at the same scale as they watch videos. Has anyone with >1000 products really nailed product recommendations without large precision losses?
That's so true. And it's not just the relevance part of it, we have to even incorporate few operational cues as well while recommending products. Not for Amazon but for a different marketplace, I manage the recommendation engine as a product and we have incorporated product serviceability to customer's address as one of the parameters. Then the usual e-comm stuff kicks in like, out of stock issues, price elasticity during sale periods, new product/category launches etc.
Obviously, I do not want to discount other non-commerce recommendation engines like Spotfiy's or Netflix. They are great in their own ways, but e-comm is quite a different ball game. The cross sell model is really hard to crack if you have 1000s of competing sub categories and millions of products in them to fill in your top 10-20 slots.
Recommendation systems are based on aggregated preferences. The farther you are from an aggregate/group or the rarer your group is, the worse your recommendations. It's an inherent limitation. It's in essence trying to guess at missing data by comparing your past purchase patterns to known data. There's also a bootstrapping problem -- if you haven't bought enough stuff to establish a pattern, the algorithm can't really figure out what you'd want next.
If you order a Rode microphone and a Sony RX cam, it might figure out that you're a Youtuber and might recommend a Zhiyun gimbal. The cluster of data points point to that.
But if you have order pattern where the data is sparse, it's not likely to come up with a good recommendation.
I think what makes them interesting is that now I have a lot of choice in which classes to take... maybe someone will set up a "Rotten Tomatoes" site to rate online classes.
I don't want to take every single NLP class, but if I take one here, and don't quite get it, perhaps the Google (or Stanford, or whoever) course will make it click for me, or offer some alternative insight or useful method.
So I'm glad they're putting them up. Thanks Amazon!
Amazon’s goal of the internal program is to train Software Engineers to know enough about data science to be effective as “machine learning engineers.” Once trained, software engineers can either implement models themselves, or more likely, partner with a data science team to productionize a model.
The courses by Brent Werness are particularly good, he has a knack for explaining the intuition behind the math, pulling back the layers of abstraction, so it’s not just “call scikitlearn and cross your fingers.”
Some of the more advanced topic courses like Natural Language Processing are particularly challenging, as the material is more of a survey of the latest research papers, to give you an idea of the state of the art, but understanding the mathematical tools is non trivial.