Coffee Chat #16: Practical Lessons for the Next Generation of Data Scientists

‍Q: What drew you to data science, and how did your early experiences or education shape the way you approach problems in this field today? 

A: What pulled me into data science was the idea of building systems that get better with experience instead of just doing the same thing forever. Traditional software is mostly fixed logic. In data work, you can feed it more data and actually watch it improve, and that feels much more philosophically satisfying! 

 At university, I was exposed to mathematical statistics and machine learning. That didn’t make me an expert in every topic, but it gave me a decent mental map of the space: what kinds of models exist, what assumptions they make, and what failure modes to expect. 

 So now when I see a new problem, I think in terms of structure: what does the data look like, what signal might realistically be in there, what’s the cost of collecting more, and which broad class of methods fits that shape. The early training wasn’t about mastering one perfect technique; it was about having enough of an overview – of developing taste – that I can reason tradeoffs and pick a starting point that makes sense instead of just guessing. 

Q: What developments or emerging trends in data science are you most excited about and why? What should students pay attention to if they want to be prepared for the next wave of innovation? 

A: One thing I find interesting is how much the field has converged architecturally. A few years ago, vision, speech, language, recommendation – each had their own highly specialized model of families. If you jumped from object detection to speech recognition, you were basically starting over in terms of model intuition. 

Now transformers are the default backbone almost everywhere. What changes across tasks is mostly how you represent the input and output (tokens, patches, embeddings) rather than the core algorithm. That’s a big shift. It means your intuition about training dynamics, scaling, and failure modes transfers much more easily between domains. 

 It also hints that we might be getting closer to a small set of core ideas for general-purpose learning, which is extremely exciting. 

 If you’re a student, I’d pay attention to that convergence. Understand transformers properly, not just how to call a library: attention, positional encoding, how scaling laws behave, and how data quality interacts with all of this. Those concepts will likely survive multiple generations of tooling and model names. 

Q: The tools and methods in data science are constantly evolving. How do you stay current with new trends, technologies, and best practices and what advice would you give students to remain adaptable as they enter the field? ‍

A: The space moves fast, but I don’t think the right response is to try to read everything. I mostly rely on a few high-signal channels and a consistent habit. 

I skim relevant arXiv categories and a couple of good newsletters, watch selected conference talks when they bubble up, and follow a small set of people on 𝕏 who are good at finding solid but not yet overhyped work. When something looks promising, I try to engage with it beyond “read the abstract”: look at the main figures, understand the core trick, maybe implement a minimal version or plug a pretrained model into a toy problem. 

Underneath that, I keep coming back to fundamentals: probability, optimization, representation learning, basic numerics. If you understand those reasonably well, new methods feel like variations on themes you’ve already seen instead of an endless stream of unrelated discoveries.

For students, I’d focus on building that combination: a light but regular “what’s new” routine plus a deeper understanding of a few core ideas. That’s usually enough to keep you adaptable without turning staying current into a second full-time job. 

‍Q: How and to what extent are you using language models in your work?

A: At this point, language models are a core part of my workflow. They don’t replace thinking, but they remove a lot of friction. 

Concrete examples: I use them to scaffold experiment code, translate a rough description of an idea into a first sketch of a script, and quickly explore alternative implementations. They’re also good for glue work: small data-cleaning scripts, format conversions, one-off visualizations, or migrating code between libraries. 

On the research side, I use them to summarize papers, compare approaches, and sanity-check whether I’m missing obvious baselines or metrics. They’re not a substitute for reading carefully, but they do help with triage. 

The catch is that they’re confidently wrong often enough that you can’t just trust the output. You still need basic taste and technical judgment: write tests, reason about complexity, check results against your own understanding. 

I suggest students and early professionals to actively adapt your tooling around language models. Let them handle boilerplate and exploration so you can spend more of your limited energy on framing problems well and designing good experiments.

‍Q: It seems you are all about learning and building from there. Can you share an example of a challenge you faced in your work and how did you navigate it? What can students learn about resilience and problem-solving from experiences like this? 

A: The hardest shift for me wasn’t a specific bug or model, it was going from a school environment to a work environment. In school you follow a pre-defined path: there’s a syllabus, a correct answer, and you’re mostly judged on whether you can reproduce it. In real work, nobody hands you a clean problem statement, and very often there is no “known right answer” at all. 

 During one internship I was asked to design camera path motion planning for a new sport. There was no template. I had to define the objective, come up with metrics that made sense, generate data, and try a lot of things that simply didn’t work. For a while it felt like constant failure, but that’s just what genuine exploration looks like. 

There were also completely new criteria which you typically wouldn’t encounter in a university setting: improving the accuracy of an object detector immediately makes sense to a new grad, but getting the right “feel” into a camera motion plan derived from object detections is a completely new concept and required a lot of experimentation to develop intuition for. 

What helped was treating each failed attempt as information instead of a personal evaluation. If you’re still in school, you can practice this by intentionally picking up projects and internships where the path isn’t fully laid out. The earlier you get used to setting your own direction and living with ambiguity, the less of a shock that transition will be. 

‍Q: Given your experience and knowledge about the industry, what can students do now to collect evidence of their abilities? 

A: Looking back, I probably over-weighted formal academic credentials and underweighted actual output. Most of the interesting companies I’ve talked to care less about perfect grades and more about whether they can see a track record of you doing hard things well. 

Evidence of exceptional ability can look like a lot of different things: internships where you own something non-trivial, open-source work that people use, competition results, or personal projects that are clearly thought through and documented. It doesn’t all have to be research-level, but it does have to be real. Take Build Projects, for example. These are great opportunities for students to develop something valuable that showcases their skills and knowledge. 

A common failure mode is doing good work and then never making it visible. You ship a project to a class repo, or keep your experiments on a laptop, and nobody ever knows. Try to do the opposite: write short posts, open source what you can, keep a simple portfolio or README, and let people see your process as well as your results. 

A good strategy especially when you’re applying for a new role is to implement a microscopic version of the product the company you’re applying to is building: you get intuition for the problem they’re solving, and they get to see how you would perform on the type of problems you’d be facing in your new role. 

The goal is to maximize your “luck surface area”: increase the number of people who can bump into concrete evidence that you’re good at what you do.