4 ms·

I'd like to understand what data engineering inside Nike is actually like. I'm curious because I have relevant experience on my LinkedIn profile, and I get reac

I'd like to understand what data engineering inside Nike is actually like. I'm curious because I have relevant experience on my LinkedIn profile, and I get reached out to almost weekly from third party recruiters trying to fill really low paying contract data engineering and ML jobs with Nike. These roles seem to be targeting people with professional experience in the US but pay roughly a 3rd of what I would consider the going rate. There's another top level comment here that this tool might make sense "in a shop with a lot of inexperienced devs", which would confirm my anecdata. Maybe the roles are actually scams, who knows :shrug:

steveBK123 2y ago
My experience with these kinds of tools (and I've built some myself) tells me that you're better off hiring people who know what they are doing or having enough experienced people PLUS culture to train up juniors. The idea that you'll just build a tool that makes hiring 10x as many inexperienced devs work is dubious. Just one more new DSL bro. Certainly we have cracked the code that no one else has. The problem with these types of orgs/tools is that by its nature your DSL constrains the juniors/inexperienced devs to what is currently possible. There is not a lot of learning unless you rotate them through the tools team periodically, which no one does. It's also awful for the devs who are building in experience in something they can't use anywhere else. I was in one shop where the "tools team" guys epiphany was he would meta-recruit by poaching the best data engineers out of the ETL team, lol. Very explicit "good team / bad team" vibes.
hipadev23 2y ago
Nike's data engineering is very bad. It's hundreds of temporary contractors, mostly offshore, all with 6-18 month tenures, and everyone reinvents their own square wheel. Thousand upon thousands of abandoned confluence pages of documentation. The most convoluted SQL and data architecture you'll ever find. Getting answers to simple questions like "How many shoes did we sell in-store vs ecommerce last week?" is a nearly impossible task.
- notyourwork 2y ago
  > Getting answers to simple questions like "How many shoes did we sell in-store vs ecommerce last week?" is a nearly impossible task. I find this type of thing scary as an outsider looking in. How a company so large has such immature engineering continues to astonish me.
  - shepardrtc 2y ago
    > I find this type of thing scary as an outsider looking in. How a company so large has such immature engineering continues to astonish me. It's management that doesn't want to risk their positions by doing the very difficult business of either starting over or properly simplifying their stack. It's not easy, it's not quick, but if they can't even answer that basic question then they need to do the work.
    - crowcroft 2y ago
      To defend management a little bit, these massive companies have existed through many eras of technology with many different managers. They work with many external companies in many different ways. They have an exceptionally complex, but functioning tech stack, that allows all of these many dependencies to function together. Lastly, they are successful as they are! It's not usually an issue of immaturity, it's just really hard. To make things worse, often people don't really want to do the work because literally any other data engineering job would probably be more enjoyable. Simplifying the tech stack would probably require simplifying their business operations, which probably means less revenue. Starting over is often literally not possible because there are so many interconnected systems that aren't all necessarily owned by the company trying to make the decision...
      - rexpop 2y ago
        > Simplifying the tech stack would probably require simplifying their business operations, which probably means less revenue. I don't understand this perspective. Simplifying the tech stack might mean taking multiple services in multiple languages, and deprecating some in favor of migrating that functionality to the most maintainable codebase. This shouldn't mean "simplifying their business operations", or affecting their business operations in any way.
alex_lav 2y ago
Speaking only my own experiences, my contract was ~2x what competitors were paying in the US. This was similar amongst the contractors I worked with, depending on seniority.

steveBK123 2y ago

My experience with these kinds of tools (and I've built some myself) tells me that you're better off hiring people who know what they are doing or having enough experienced people PLUS culture to train up juniors. The idea that you'll just build a tool that makes hiring 10x as many inexperienced devs work is dubious. Just one more new DSL bro. Certainly we have cracked the code that no one else has. The problem with these types of orgs/tools is that by its nature your DSL constrains the juniors/inexperienced devs to what is currently possible. There is not a lot of learning unless you rotate them through the tools team periodically, which no one does. It's also awful for the devs who are building in experience in something they can't use anywhere else. I was in one shop where the "tools team" guys epiphany was he would meta-recruit by poaching the best data engineers out of the ETL team, lol. Very explicit "good team / bad team" vibes.

hipadev23 2y ago

Nike's data engineering is very bad. It's hundreds of temporary contractors, mostly offshore, all with 6-18 month tenures, and everyone reinvents their own square wheel. Thousand upon thousands of abandoned confluence pages of documentation. The most convoluted SQL and data architecture you'll ever find. Getting answers to simple questions like "How many shoes did we sell in-store vs ecommerce last week?" is a nearly impossible task.

notyourwork 2y ago
> Getting answers to simple questions like "How many shoes did we sell in-store vs ecommerce last week?" is a nearly impossible task. I find this type of thing scary as an outsider looking in. How a company so large has such immature engineering continues to astonish me.
- shepardrtc 2y ago
  > I find this type of thing scary as an outsider looking in. How a company so large has such immature engineering continues to astonish me. It's management that doesn't want to risk their positions by doing the very difficult business of either starting over or properly simplifying their stack. It's not easy, it's not quick, but if they can't even answer that basic question then they need to do the work.
  - crowcroft 2y ago
    To defend management a little bit, these massive companies have existed through many eras of technology with many different managers. They work with many external companies in many different ways. They have an exceptionally complex, but functioning tech stack, that allows all of these many dependencies to function together. Lastly, they are successful as they are! It's not usually an issue of immaturity, it's just really hard. To make things worse, often people don't really want to do the work because literally any other data engineering job would probably be more enjoyable. Simplifying the tech stack would probably require simplifying their business operations, which probably means less revenue. Starting over is often literally not possible because there are so many interconnected systems that aren't all necessarily owned by the company trying to make the decision...
    - rexpop 2y ago
      > Simplifying the tech stack would probably require simplifying their business operations, which probably means less revenue. I don't understand this perspective. Simplifying the tech stack might mean taking multiple services in multiple languages, and deprecating some in favor of migrating that functionality to the most maintainable codebase. This shouldn't mean "simplifying their business operations", or affecting their business operations in any way.

alex_lav 2y ago

Speaking only my own experiences, my contract was ~2x what competitors were paying in the US. This was similar amongst the contractors I worked with, depending on seniority.