Learning Where to Begin

After graduating from Columbia with a degree in computer engineering in May of 2026, Marilena Batatoudi spent the summer at Distyl.

A few months into my internship at Distyl, I led my first customer demo. To explain what I had built, I had to begin with the customer problem that had shaped it.

For the clinicians I was presenting to, evaluating a case could mean sifting through years of patient records to piece together the evidence they needed to make a confident decision about a patient’s care. Translating that process into a coherent technical direction required synthesizing operational, domain, and technical knowledge distributed among the many clinical and technical experts involved in the work.

In my previous engineering internships, customer context reached me through product managers, who set the direction for what I built. At Distyl, determining whose expertise the build required—and how that knowledge should shape the system design—was part of engineering itself. By the time of the demo, I was close enough to the code to answer for the technical choices, close enough to the clinicians to understand how the system should fit into their existing decision-making process, and trusted to lead a conversation that required command of both.

Designing for the Decision

First, I had to understand a difficult moment in the clinicians’ work. When our system’s output diverged from an initial clinical judgment, clinicians had to work back through the patient record and the system’s reasoning to understand why. My challenge was to shorten that path.

I walked the clinicians through a pain they recognized immediately: finding the basis for the system’s conclusion across years of patient history, one piece of evidence at a time, to inform a potentially time-sensitive decision about a patient’s care. They recognized their own experience in the way I captured that reality before they later saw it in what I built.

Translating that problem into a technical direction began with one question: What information would a clinician need to see when the system’s output differed from their initial judgment?

To answer that question, I had to design around the larger process of evaluating a case, including what the system should enable the clinician to do at the point of decision. In the demo, I showed how a clinician could evaluate the system’s analysis directly against evidence from the patient’s record to understand why the system had reached a different conclusion. The clinician could then interpret the clinical implications of that evidence for the patient and decide whether it gave them reason to revise their judgment.

In the span of one summer, my responsibility extended across the full chain: determining the technical implications of each expert’s distinct clinical and operational knowledge, using the evolving build to sharpen the problem, turning that understanding into a coherent technical direction, and carrying that direction through implementation and back to the customer.

A Larger View of the Work

Standing in front of the clinicians, I understood why leading the demo felt different from simply presenting a component I had implemented. Leading the conversation meant reasoning in both directions: from the clinicians’ decision process into the system we built, and from that system back into the decision it was designed to support. The customer problem was not context surrounding the engineering work. It had shaped the engineering work all the way through.

At Distyl, I was trusted to build meaningful relationships with the clinicians, translate our shared understanding into concrete technical decisions, and lead the resulting conversation. That trust taught me where to begin as an engineer: not with the system itself, but with an understanding much larger than my own.

If you’re curious about taking on hard, real-world problems with us, explore our open roles.