"How I Went from" is an ongoing blog series that highlights our employees' different journeys to InterWorks. The results are pretty diverse, but each story is special in its own right.
This blog post is AI-Assisted Content: Written by humans with a helping hand.
Honestly, if you asked me when my story started, I’d say it started when I was born.
But if we’re being reasonable about it, the real answer is pre-K, playing Command & Conquer with my dad on our home PC. That’s one of my earliest memories, period, not just my earliest tech memory. I’ve been around technology my entire life, and I’ve had an affinity for it the whole way through — which, unsurprisingly, turned into a lifelong love of video games that I still haven’t grown out of. I don’t think many people in this industry have.
The first real crack in the door came in high school, when I took my first programming class. We started with Scratch, which — if you don’t know it — is the drag-and-drop, brightly colored program schools use to teach elementary schoolers the basics of code. Even as a high schooler, messing around with variables and watching how changing one value rippled across the screen scratched an itch I didn’t know I had. The next year, I took my first real language, Java, and something about it just felt natural. That was my first “big boy” programming course, and I loved it.
So naturally, when I got to Oklahoma State, I enrolled in cybersecurity. A lot of that was thanks to my brother-in-law, who’d gone through the same MIS program a few years ahead of me. He used to tell me about Red Team/Blue Team exercises — two teams just trying to hack each other in a sanctioned, capture-the-flag kind of way — and I thought it sounded incredible. The reality was a little more overwhelming. I remember going to a club meeting early on and getting handed something like a 600-page Windows manual with the instruction to “start reading.” That was a lot. I ended up finding my footing in the business analytics side of the program instead, in a class that was essentially logistics-based problem solving with Excel spreadsheets — using data to actually solve real problems. Even though the case studies were fictional, you could clearly see the shape of real-world scenarios in them, and something about that clicked: “Wait, you’re telling me a spreadsheet can actually tell you something useful?”
Not long after, I fell down a rabbit hole I still haven’t climbed out of: Data science. I don’t remember exactly where I first heard the term, but I chased it on my own time and it took me straight to statistics and machine learning — the idea of building predictive models. I still remember finding a YouTube video of someone building a model to predict if you would survive the sinking of the Titanic — basically the “hello world” of machine learning — and thinking, wait, you can do that? From that point on, I took every single data class OSU offered. By the end of grad school, I’d genuinely run out. Knowing how much they’ve expanded the catalog since, I’m not sure I could pull that off again.
That path eventually led me to InterWorks as an Analytics Consultant — a job title that, to this day, I have never once said smoothly out loud — doing Tableau data visualization. A college friend used to call the Tableau class she took “Data Arts and Crafts,” and honestly, that’s about as accurate a description as you’ll get. Making numbers look good and make sense at the same time is a genuinely fun skill, and I loved the work.
About three years ago, I got back into programming as a hobby, mostly writing janky Python scripts and deciding I actually wanted to learn how to write real programs. Even as an AC, I had visibility into everything happening on the data engineering side of the business, and every new concept that popped up caught my attention. I kept my systems administration chops up on a home server I still maintain, so I’m not caught off guard if someone asks me to drive a command line, and I kept quietly poking around more advanced data concepts out of pure curiosity, long before it was part of my job description.
One of the biggest turning points came from a conversation with my boss at the time, Kent Sloan, who knew I wanted more technical, data-leaning work if the opportunity ever came up. It did, in the form of a cool project a couple of years back — building an entire data platform from the ground up for a small consultancy that worked with churches and nonprofits. They didn’t have the budget for enterprise tooling like Snowflake or Fivetran, so we built the whole thing on open source tooling instead. I still count that platform as my baby. The team was small — myself, Jack Hulbert, and Anna Hadzic as DL, with Justin Lyons handling the web front end — and we were given free rein to build it however we saw fit. That freedom is really what made it the most rewarding project I’ve worked on. Ownership is rare. Getting to build a full product from the ground up, in your own image, doesn’t come around often, and I still have the backend Python saved on GitLab to prove it happened.
These days, I’m a data engineer on the KeepWatch team, wearing more hats than I probably should admit to. If I had to boil down why I ended up here, it’s that keeping a cursory, curious knowledge of niche topics — even ones outside my job description at the time — kept paying off in ways I couldn’t have predicted.
If you’re looking to break into this field, or sit at the desk next to me, here’s what I’d actually tell you: Don’t try to learn every data tool out there. There’s a chart floating around with the logo of every data tool currently in existence, and it’s got hundreds, if not thousands, of entries. That’s not a to-do list, that’s a losing battle. Learn concepts instead — what makes a good ELT pipeline, how to make it resilient to failure, how to build on what you already know — because concepts transfer between tools and tools alone don’t. The one exception I’ll make: Learn SQL. You don’t need to become a wizard, but querying, filtering and transforming data will take you further than almost anything else on this list, even outside of data roles specifically.
It’s also never been easier to just go build something. Open source tooling has all but erased the barrier to entry that used to exist for enterprise data work. My advice: Stop overthinking about what to build. Look around for a real problem you can solve for someone — I built a full data platform for my local community theater in my spare time, with the only real cost being a secondhand computer to run it on. That project is a direct line to how I ended up on the data platform gig in the first place. And build something you actually care about. If that means scraping Pokémon data into an ELT pipeline instead of something finance-related you have zero interest in, do that. Know it inside and out, be able to talk about it, and apply what you learned to other problems. That’ll set you apart more than another line on a resume ever will.
And if you’re job hunting right now, especially in a tighter market for data folks: Perseverance is genuinely key. I know firsthand how brutal that search can be. The tighter the market gets, the more it pays to do your homework and go build something that proves what you can do.
Like I said — it all started when I was born.
