Coffee Chat #27: Zoom Out: Why the Best Engineers Think Beyond the Code

‍Q: You’ve worked in very different environments—from banking at Citizens Bank to an AI-powered dental analytics company like Overjet. What did each experience teach you early in your career? 

A: Each environment shaped a completely different part of how I think about building software. At Citizens Bank, I was working on document intelligence—building pipelines that used AWS Textract to automatically extract data from financial documents. That role taught me the importance of precision and reliability when you’re dealing with sensitive data. In banking, there’s zero tolerance for errors, and everything has to be auditable. I learned real discipline around testing, CI/CD practices, and infrastructure-as-code with Terraform. I also got a crash course in how large, regulated organizations operate, which gave me a deep appreciation for process and compliance. 

When I moved to Overjet, it was a completely different world. Suddenly I was building ML infrastructure for computer vision models that analyze dental X-rays and 3D CBCT scans. The pace was faster, the problems were more ambiguous, and I was working shoulder-to-shoulder with data scientists and ML engineers. That’s where I really leveled up on scalability—I was processing millions of dental images across 15+ medical imaging formats, designing data ingestion systems that synced records from over 900 clinics, and architecting inference infrastructure on Kubernetes. I had to get comfortable with the idea that requirements change constantly when you’re supporting ML teams whose models are always evolving. 

The biggest lesson across both roles is that the technical skills transfer, but the context changes everything. Building an ETL pipeline at a bank and building an ML data pipeline at a healthcare AI company are conceptually similar, but the constraints, stakeholders, and pace are totally different. I’d tell any student: don’t stress about finding the “perfect” first job. Each role teaches you something you can’t learn anywhere else, and that variety actually makes you a more versatile engineer. 

Q: For students who hear “data engineering” or “ML infrastructure” but aren’t quite sure what it means—how would you explain your role in simple terms?

A: Think of it this way: data scientists and ML engineers are the people who build the models that make predictions or decisions—in my case at Overjet, models that detect dental pathologies from X-rays. My job is to make sure the right data actually reaches those models—clean, on time, and in the right format. I build the highways that data travels on. 

On a typical day at Overjet, that might have meant designing a pipeline that pulls raw dental images from hundreds of clinics, preprocesses them (think: converting DICOM files, applying grayscale conversion, noise reduction), validates the data quality, and delivers it to a model for training or real-time inference. I also built the tooling that let data scientists trigger model reprocessing or backfill training data on their own, without needing to file an engineering ticket every time. 

A good analogy is plumbing. Nobody thinks about the plumbing in a building until the water stops running. ML infrastructure is similar: when it’s working well, nobody notices. But if a pipeline breaks or delivers bad data, every team downstream feels it—models make wrong predictions, clinicians get bad results, and trust erodes fast. It’s behind-the-scenes work, but it’s foundational to everything a data-driven company does. 

Q: What’s one concept or tool you wish you had taken more seriously during your time at WPI that now shows up constantly in your work? ‍

A: SQL. Without a doubt. I know it’s not glamorous, and in school it often gets just a single lecture inside a database course, but SQL is the language I use more than any other in my professional life. Whether I’m debugging a pipeline, validating data quality across millions of patient records, exploring a new dataset, or writing transformation logic in BigQuery—it all comes back to SQL. 

Beyond just writing queries, I wish I’d spent more time understanding how databases actually work under the hood: query execution plans, indexing strategies, partitioning, and how different engines (PostgreSQL vs. BigQuery vs. Spark SQL) optimize queries differently. At Overjet, the difference between a well-optimized query and a naive one could mean the difference between a pipeline that processes in minutes versus one that times out on millions of records. 

If you’re still in school, my advice is to go beyond the basics. Try working with a real, messy dataset; something with millions of rows. Platforms like Kaggle or public government data portals are great for this. Practice window functions, CTEs, subqueries, and performance tuning. That kind of hands-on work will put you ahead of most entry-level candidates, because almost every company—whether they’re in finance, healthcare, or tech—runs on data, and SQL is the universal language for working with it. 

‍Q: Working close to machine learning teams can feel intimidating for new engineers. How can entry-level developers add value even if they don’t have deep ML expertise? 

A: This is something I feel strongly about, because I was that person. When I first joined Overjet, I was surrounded by researchers and data scientists with deep computer vision expertise, and I wondered how I’d contribute meaningfully without that same background. It didn’t take long to realize the answer. 

The reality is that ML teams are often bottlenecked not by model development, but by everything around it: data availability, pipeline reliability, deployment infrastructure, monitoring, and documentation. These are all areas where a solid software engineer can make an enormous impact without ever touching a gradient descent equation. 

Here’s a concrete example from my experience: one of the most valuable things I built at Overjet was a configurable patient-to-image matching system that correlated clinical metadata with imaging data for supervised learning. It was fundamentally a data engineering and software design problem—not an ML one—but it solved a major pain point for the ML team by ensuring their training data was correctly labeled and linked. I also built FastAPI-based tooling that let data scientists manage their own feature engineering pipelines and trigger reprocessing without depending on engineering for every request. That kind of developer tooling dramatically sped up experiment iteration. 

My advice to new engineers is to learn enough about ML to understand the workflow: what training data looks like, what a feature store is, what model serving means – and then apply your engineering strengths to make that workflow smoother, faster, and more reliable. Every ML team is hungry for engineers who can do this well, and it’s a fantastic entry point into the AI space. 

‍Q: As the software and AI landscape evolves so rapidly, what mindset or habits do you think will separate engineers who thrive from those who struggle to keep up? 

A: I think the engineers who will thrive are the ones who treat learning as a daily practice, not a once-in-a-while event. Just in the few years I’ve been working, the way we think about ML infrastructure, model deployment, and even code generation has shifted dramatically. You don’t have to master every new framework that comes out, but you do need to stay curious and be willing to experiment. 

Beyond staying current on tools, I think the bigger differentiator is systems thinking. AI tools can write code, but they can’t yet understand the full picture of why a system is designed the way it is, how different services depend on each other, what the compliance requirements are (like HIPAA in my healthcare work), or what the business trade-offs are behind a technical decision. Engineers who develop that broader perspective—who can zoom out and think about architecture, reliability, cost, and team dynamics—will always be in demand. 

One practical habit I’d recommend: set aside even an hour each week to read about something outside your immediate work. It could be a blog post about infrastructure at a company you admire, a paper on a new data format, or a podcast about engineering leadership. Over time, that breadth of knowledge compounds and gives you a much richer mental toolkit to draw from when you hit unfamiliar problems. 

‍Q: As an Open Avenues Build Fellow mentoring students on real projects, what patterns do you see in students who progress the fastest in software roles?