[LZ_Khan]

From my experience, there are plenty of teams in FANG that will hire you as a backend developer in a ML team assuming you can pass their interviews. 90% of the work in these teams is not core ML and is more mundane work supporting these models, such as data piping, cleaning, feature generation, experimentation, and real-time serving. You'll get plenty of experience in working directly with ML systems.

The jump to core ML is a bit trickier. Competing with people with PhD's is a drag. Wish people could also give me some tips there.

[safog]

FWIW I worked at Amazon in one of these teams and it's not something I found very interesting. You get thrown a random binary that some ML researcher compiled with instructions to host-it. No sense of ownership over the product, you're just an Ops frontend for a researcher so they can do the fun stuff building models and you're dealing with the pagers.

[gardenhedge]

That sounds like the worst kind of tech position to be in

[closeparen]

It's about the same tier as BI dashboards. Huge breadths of data you don't produce but are nevertheless accountable for. All your stakeholders can easily stream-of-consciousness rattle off dozens of new metric/feature ideas or questions about the feature/metric values they're seeing over the course of 45 seconds, each one taking you tens of hours eyeballs deep in SQL to even begin to answer.

[quickthrower2]

A job we would be glad to have replace by an AI for sure

[theGnuMe]

That is certainly coming soon.

[LZ_Khan]

As a sort-of counterpoint I work at a non-amazon FANG where I am much more involved in model training and evaluation. I still have never needed to define a model myself, but it's much more complicated and far more ownership than someone throwing me a binary. I think that speaks much more to what's going on in Amazon *grins*.

[checkcircuits]

This has been my experience as a data engineer.

ML guys build the fun stuff, go to conferences, etc. We maintain their stuff and work the 60 hour weeks answering pages.

It's mind numbing. Arguably some of the most boring work I've ever done especially knowing that you're just a CI/CD robot. Nothing has motivated me towards looking into starting a business more than watching other people have fun and you cleaning up their messes.

[ramesh31]

>90% of the work in these teams is not core ML and is more mundane work supporting these models, such as data piping, cleaning, feature generation, experimentation, and real-time serving. You'll get plenty of experience in working directly with ML systems.

MLOps is what you're describing, and it's probably the number one field I'd recommend someone to go down right now as a backend dev.

[sroussey]

This is the #1 thing VC backed startups are trying to automate away

[SQueeeeeL]

They've been trying to automate away the "grunge" work of building and managing complex software systems since the 80s. Trust me, we'll be fine

[disgruntledphd2]

To be fair, it's not as funny as automating data cleaning, on the principle that data scientists don't want to do it.

And yeah, lots of people dislike it, but you can't build models without an understanding of the data, so even if automated data cleaning became possible (unlikely) you'd still need to spend a load of time doing work on the dataset before building anything useful.

[hermitcrab]

Some people seem to think they will be able to type "clean my data" into ChatGPT or similar and get a beautiful clean dataset. They are probably descendents of the people who said "COBOL means we don't need programmers any more".

Data cleaning requires a lot of judgement and domain knowledge. Imagine if an AI did clean your dataset. Are you just going to trust it (Hell no!)? Or are you going to spend ages trying to work out what it did, which doesn't seem much of an improvement.

I write data cleaning/ETL software and I'm confident that the need for my product is going to going up between now and when I retire.

[greymalik]

Why is that your number one recommendation?

[wolterlw]

because 90% of the industry work is MLOps the pipeline usually goes 1. make a POC inside a Jupyter Notebook with some scrappy, data and off-the-shelf model, define metrics and train a baseline to see if the whole ML endeavour might even be worth it 2. Do error analysis, find better data, tune parameters, re-train to see if you can improve upon the baseline 3. Make the first deployment, setup data collection 4. Automate 2 as much as possible because data is ever changing and you want to try many more off-the-shelf models 5. Deploy new models and collect ever more feedback

4 and 5 are basically a while loop that never ends and that's mostly MLOps It still requires proper ML expertise, especially when things break tho

[grogenaut]

we've got 4 and 5 pretty automated... the real issue is (as you likely are alluding to) as #1/2/3 draw in new completely infeasible data to get at scale, and then wants you to re-train daily, 2x day, every 4 hours, continuously. Oh and your costs go through the roof and likely aren't worth the returns anymore chasing that .001%

[bilsbie]

Do you literally search for “MLops”?

[richardw]

Great starting point, with lots of info and podcast and whatnot.

https://mlops.community

[bilsbie]

What terms would you search for for those first type of jobs?

[nerdponx]

Can't speak for FAANG, but you can do well at some companies with "ML Developer" or even "Data Engineer" if you have database admin experience and/or are willing to spend time studying up.

[brutus1213]

Just wanted to add: DL Engineer != MLOps engineer. DL Engineers who deal with scientists have a much harder job IMHO as the scientists ask for 10 different things, each taking a lot of effort to implement. The current DL stacks (e.g. Tensorflow/keras) make it very easy to implement the standard stuff. But if you want to go off the path, it is really very hard (I wonder if Pytorch makes that significantly easier if anyone cares to chime in).

[nerdponx]

Good point in general about working with "scientist code". You definitely will want to at least understand some of the math in order to be effective at implementing it.

I don't think Torch is any easier than Keras if you don't know what you're doing.

I think data engineering is probably the easiest transition for software devs with backend web (read: database and Python) experience. Free learning resources abound nowadays, as well as decent-quality books and online courses. It's largely the same set of engineering "macro" skills (proejct planning, cost-time-correctness tradeoffs, levels of abstraction, deploying stuff to the cloud), and the specific engineering "micro" skills (database performance tuning, indexing, storage and compute cost management, setting up ETL pipelines, integrating with dashboard systems like Tableau) should be well within the capabilities of a mid-senior backend web developer.

The hardest part IMO would be getting up to speed to the stats and data analysis basics enough to be conversant with the analysts and data scientists who would be your primary stakeholders and users. But that too can be done with help from the multitude of free learning resources and chatrooms/forums.

IMO it's worth the effort if you're looking to transition. There is a shortage of good, conscientious data engineers right now. Hiring pipelines are clogged with aspiring junior data scientists who are willing to put up with data engineering for a couple of years to try and get some experience on their resume. Data engineers' skillsets are highly portable across companies and industries, and will remain in demand for many years to come, even as companies find that they can't justify hiring a data scientist, so pay and hiring potential will be accordingly high. And as a data engineer you will quickly establish yourself as an essential team member in all but the most dysfunctional organizations, and your value will be immediately apparent whenever someone wants to build a dashboard or pull a report and it all "just works".

The only thing to beware of is the usual caveat of companies trying to short-sightedly hire inexperienced juniors in mid-senior roles to save a buck, setting both you and them up for failure. But that's a caveat in any field where you're starting from the bottom. If you're already an experienced software engineer, you should hopefully be able to either see through that bullshit, or to be able to handle it somewhat more gracefully than a true junior could.