You wrote many beginner and explanatory articles on TDS. Has teaching the basics modified the way you design or debug real systems at work?
I notice the correlation between the more I teach something, the higher I understand it. In real life, after I write a brand new article, I strive to dive into small details while keeping the reason easy for my readers. Emphasizing information in this manner helps me higher understand the workflow of algorithms.
In that sense, every time I encounter an error in one in every of the algorithms used at work on which I wrote an article previously, there’s the next likelihood that I’ll rapidly work out the answer to the issue by myself. From one other perspective, after I write an article on an unfamiliar topic and explore it myself, it increases my confidence after I apply that exact algorithm at work, as I already know its application scope, benefits, disadvantages, and specific details or constraints.
This fashion, I can provide you with original solutions that usually are not obvious to others and back up my alternative to other teammates, managers, or stakeholders. That knowledge is precious to me.
With so many recent models popping up day by day, it’s easy to feel completely swamped. How do you select what’s price a ‘deep dive’ and what you simply ‘get the gist of’? Has your strategy for managing this modified in any respect recently?
Today, we indeed have an abundance of models and tools that appear day by day. It is straightforward to feel lost whenever you’re unsure about what to pursue next.
With limited time, I often delve deeper into topics that could be applicable at work or in my personal projects. This provides me more confidence when I even have to present or explain my results.
Businesses often want to realize working results as soon as possible. This can be one in every of the the explanation why, in my articles, I focus more on theoretical concepts, as I cannot devote my time at work to going into theoretical depth.
This fashion, I even have an efficient mix of practical experience at work and theoretical insights in my blog. Each of those components are essential for expert data scientists.
You’ve competed in AI hackathons. What did you learn from having such tight deadlines? Did it force you to improve at scoping projects or deciding on a model? And do you end up using any of those ‘hackathon lessons’ whenever you’re sketching out a brand new idea from scratch?
Hackathons typically last between several hours and two days. That may be a very small time period to develop a totally functional product. Nonetheless, at the identical time, it pushed me so much previously to raised prioritize the features on which I should focus. Typically, time management is a invaluable skill to have. When you may have several possible solutions to deal with your problem, you could select the one that most closely fits the business needs while also respecting time constraints.
What can be great is that after every hackathon, you possibly can evaluate yourself by way of the time it took you to implement certain features. For instance, let’s say that it was the primary time you needed to develop a RAG pipeline, which took you around 4 hours to implement. The subsequent time you face a similar problem at work or a hackathon, you’ll have a greater estimate prematurely of how much time it will take in the event you determine to make use of the identical method. In that sense, the hackathon experience means that you can higher define closing dates for the methods you desire to implement in projects.
For me, the largest lesson from the hackathon was not specializing in perfection when creating the MVP. While an MVP is essential, it is usually obligatory to present your product attractively to clients or investors, explain its business value, the issue it solves, and why it is best than existing solutions in the marketplace. On this regard, hackathons teach you to provide you with higher ideas that solve real problems while also shipping the MVP quickly, containing essentially the most essential features.
For readers interested by their profession path: your “Roadmap to Becoming a Data Scientist” series spans fundamentals through advanced ML. Should you were rewriting it today, what topics would get promoted, demoted, or cut entirely, and why?
I wrote this text series a yr ago. For me, all of the concepts and topics I listed are up to this point for aspiring data scientists. All math, computer science, and machine learning topics I present there are a vital foundation for any machine learning engineer.
As we’re now in late 2025, I’d also add a requirement to have at the least minimal experience with prompt engineering and to be aware of some AI-generative tools, reminiscent of GitHub Copilot, Gemini CLI, and Cursor, which might allow for increased work efficiency.
As a note, in comparison with previous years, IT corporations have higher requirements and expectations for junior engineers entering the information science field. It is sensible, as modern AI tools can perform junior-level tasks thoroughly, and plenty of corporations prefer to depend on them now moderately than on entry-level engineers, as they don’t need to pay salaries while in each cases they receive the identical result.
That’s the reason, if a machine learning engineer possesses the strong fundamental skills I described in that series of articles, it would be much easier for them to dive autonomously into more complex topics.
Your background blends software engineering and ML. How does that foundation shape the way in which you write?
Having strong software engineering skills is among the finest benefits you possibly can have as a Data Scientist:
- It makes you realize the importance of well-structured software documentation and creating reproducible ML pipelines.
- You understand higher the way to make your code clean and readable for others.
- You understand algorithmic constraints and which data structure to decide on for a specific task, based on system needs.
- You’ll be able to more easily collaborate with backend and DevOps engineers on integrating your code modules.
- You do not want to depend on others to make SQL queries to retrieve obligatory data from the database.
The list can go on and on…
Speaking of my articles, I don’t have many who present numerous code. Nonetheless, every time I do, I strive to make it readable and comprehensible to others. I at all times put myself within the shoes of others and ask myself how my article text or code examples can be easy to perceive or reproduce if I were in others’ shoes. That is where the software engineering experience makes this realization more essential for me, and I follow the very best established practices to deliver my final product.
Taking a look at your portfolio and GitHub, you’ve blended software engineering fundamentals with ML from the beginning. What’s one engineering habit you would like more aspiring data scientists adopted early?
Many engineers, especially juniors, are likely to underestimate the importance of making good documentation and reproducible pipelines. This also happened to me previously, after I was more focused on developing robust models or conducting research.
Because it turned out, after I had to alter contexts after which several weeks later to return to work on the previous project, I used to be then spending numerous time determining the way to run my old code in a messy Jupyter Notebook or install obligatory libraries again, where I could have just spent a bit of more time previously by developing a well-documented README.md explaining all of the required steps to execute pipelines from zero.
Since it was nearly unimaginable to rerun my pipelines from scratch, I used to be also unable to conduct experiments using other entry parameters, which made the situation much more frustrating.
It was a painful experience for me, yet probably the most invaluable lessons I’ve learned. So if I had to provide a chunk of recommendation to an aspiring data scientist on one particular habit, it will be this:
“All the time make your machine learning pipelines reusable and well-documented”.
Over the past yr, has AI meaningfully modified how you’re employed daily as an ML Engineer? What got easier, what got harder, and what stayed the identical?
In recent times, we have now observed a big rise in powerful AI engineering tools:
- LLMs, which might reply to almost any query, give advice, or find bugs in software
- Cursor, Lovable, and Bolt are acting as AI-powered IDEs for developers
- AI agents can complete multi-step tasks
As a machine learning engineer, it is important for me to often adapt to those tools to make use of them efficiently.
What became easier
Ranging from 2025, I can observe the next positive impact on my work:
- For me, it became easier to rapidly test ideas or prototypes. For instance, there have been times at work after I was given computer vision problems that fell outside my area of information. In this manner, I could ask ChatGPT to propose several ideas to unravel them. There have been even times when ChatGPT generated code for me, and I attempted to execute it without understanding the way it worked inside.
Then I had two possible cases:- If the code ran successfully and solved the initial problem, then I attempted to go deeper contained in the OpenCV documentation to know the way it ultimately works.
- If the code didn’t solve my problem, I’d either ignore it, report the error to ChatGPT, or attempt to seek out the answer myself.
As you possibly can see, I used to be capable of rapidly test an answer that would work and save me hours of research with none risk.
- One other excellent use case for me was inserting error messages directly into ChatGPT as an alternative of looking for an answer on the Web. It worked well more often than not, but sometimes it was affected by errors related to library installations, system errors, and the deployment of pipelines on the Cloud, amongst other issues.
- Finally, I’m a giant fan of AI hackathons! Having tools that may generate each the frontend and backend of your system makes an enormous difference for me, as I can now rapidly create prototypes and test my MVP in several hours. What I develop now during one-day hackathons could require a complete week of labor.
What became harder / dangerous
- When writing code with AI, there’s the next possibility of sensitive data leaks. Imagine you may have a file or code fragment containing essential credentials that you simply by chance feed into an AI model. Then a third-party tool will know your sensitive credentials. It will possibly occur, especially in the event you use a tool like Cursor and store your credentials in one other file moderately than .env. As a consequence, it’s at all times obligatory to be very cautious.
- One other risk is just not properly testing the AI-generated code and never knowing the way to make a rollback. An AI tool can introduce invisible errors within the code, particularly when it’s used to change or refactor existing code. To make sure that AI-generated code doesn’t degrade, it’s obligatory to thoroughly review the generated code parts, test them, and save modifications in a way that means that you can at all times rollback to a previous, correct version if obligatory.
- When relying too heavily on generative AI tools, there’s a risk that the code will change into unreadable, contain excessively long functions, exhibit repetition, or stop to operate appropriately. That’s the reason it is important to know that AI tools work more effectively on prototyping than on maintaining high-quality production code.
What remained the identical
What stays constant for me is the importance of understanding the inner workflow of the algorithms I take advantage of, maintaining strong computer science foundations, and writing high-quality code, amongst other key skills. In other words, the fundamental principles of software development will at all times be obligatory to efficiently use AI tools.
In that sense, I like comparing a set of accessible AI tools to an alternative to a junior developer in my team, to whom I can delegate less essential tasks. I can ask it whatever I need, but I can’t be 100% sure it would do my tasks appropriately, and that is where the importance of getting strong fundamental expertise comes into play.
To learn more about Vyacheslav‘s work and stay up-to-date together with his latest articles, you possibly can follow him on TDS or LinkedIn.
