
Adapt or fall behind: a review of the Databricks executive survey on AI and its use
Understand how 600 tech leaders think about AI and find out how to future-proof your business before adopting the emerging tech.
Over the past few years, the tech industry has experienced waves of uncertainty. From hiring booms to high-profile layoffs, software engineers have had to rethink not just where they work, but where their skills can take them next.
Amid all this change, one trend has remained consistent: the demand for data engineers keeps rising.
As companies double down on data infrastructure, AI initiatives, and real-time analytics, data engineering has become a core capability, not a niche function. For many developers with a background in Java or backend engineering, this presents a valuable and timely opportunity: a natural, forward-looking transition into data engineering.
If you’ve built scalable systems in Java, worked with APIs or multithreading, or navigated the complexities of backend infrastructure, you already have the foundation for data engineering.
You understand:
The main differences? Tools and platforms. Data engineers often use Python, Spark, Databricks, SQL, and cloud-native data tools. But these can be picked up with structured guidance and the right mindset.
What matters most is the engineering logic you already bring to the table, and your willingness to adapt and learn.
While the AI hype cycle accelerates, few talk about what’s missing beneath the surface. With the market still adjusting after large-scale tech layoffs, many backend engineers are actively reassessing their paths. Data engineering offers a way forward that’s not just relevant, but resilient.
To illustrate what this kind of shift can look like, we spoke with Pál Könyves, Senior Data Engineer at Datapao, who moved from a senior Java engineering consultant role into data engineering. His journey reflects the mindset, learning curve, and strategic thinking that many developers are now considering.
ale.
Can you tell us a bit about your background as a Java developer? What types of projects or domains did you mostly work in before transitioning to data engineering?
“So what projects? I had numerous jobs. I started at a Swiss custom software consulting company. I spent 5 years there, starting as a junior and gradually stepping up the ladder. That is where I acquired good engineering practices. I had great colleagues who set the quality standards for me. My biggest achievement there was taking part in the technical design and implementation of integrating a new ERP system with our project and time tracking applications. At that time, I worked with Java EE, Spring, EJB, JSF, REST, and spent a great deal of time understanding all their details. From there, I did a year freelancing, working for a blockchain startup and smaller projects like code quality review and architecture design. Later, I did several years of remote contracting, one of which was with Tesco to work on the self-service checkout (till) software, which also had parts in the cloud. After that, I worked for an online streaming service and one of the US’s biggest online furniture retail stores.”
What motivated you to move from backend/software engineering into data engineering? Was it a clear goal from the start, or more of an organic transition?
“More organic if I could choose. I started as a senior data engineer in mid-2024. While contracting in Java was lucrative for a while, finding interesting and meaningful work was also difficult. Most of the work dealt with overcomplicated microservice architectures, calling REST APIs, and object mapping between services. If you can work on performance tuning, low latency, and message-oriented systems, you are among the lucky ones. I still love the Java ecosystem, though. Apache Spark is also built on top of it. But in the meantime, I saw that data and AI are getting increasingly popular. Then the FOMO kicked in. I always had something for data: producing meaningful information from raw data is a cool thing, and dealing with big data in particular has always amazed me from an engineering perspective. In fact, in my bachelor’s thesis, I used HBase and Spark. At that time, I stayed in the office and installed HBase and Spark manually on about 10 developer workstations to create a cluster and run my tests. It was fun then, but now it is much simpler in the cloud.”

What were the first things you had to learn or change in your mindset when you started working with data tools and platforms?
“I couldn’t say I needed a big shift in mindset. I always say Data Engineering is a specialized field of software engineering. Java backend engineers always deal with data-driven software. The practice of data modeling, understanding data consistency and integrity, dealing with latency, and data arriving in an async manner are key concepts for us. The best thing is that I did not have to give up the practice of creating CI/CD pipelines and Terraform modules, which I love dearly (lol). Probably the most surprising to me was the realization that using today’s big data in the cloud is so much simpler than big data 10 years ago.”
Which of your existing skills as a backend engineer helped you most when moving into data engineering? Were there any unexpected overlaps or surprises?
“I already mentioned some of them, but understanding distributed systems, networking, data modeling, database design, working with relational and NoSQL databases, and having some programming skills helped me a lot in this field. As for the surprising part. I thought I would have to use a lot more statistics, and was looking forward to practicing it, but so far my projects have not involved much of it. At Datapao, we work 90% with Databricks. I was surprised to see how huge and sophisticated this platform is. We basically need not to worry about the operations, and can focus on implementing the data pipelines or ML models.”
What were the most challenging parts of the transition? How did you overcome them?
“Understanding Databricks is definitely a challenge, but only because of all its features and aspects, there are many. It is also crucial to understand the internals of the platform and how Apache Spark or Delta.io works. We must understand the tools in a certain depth, so we can answer our clients, but also to make educated guesses in our day-to-day jobs to choose the most optimal implementation. These all can be learned, though; all that is needed is some time and practice. It is also a delight to work with Python, and it’s great that I have a chance to practice it, getting better at it day by day.”
What kind of support did you receive during your onboarding or learning phase? What resources, tools, or practices helped the most?
“When I started, I was given a book about Spark and a list of Databricks self-paced courses to start with. I also got a mentor who helped me during the onboarding and whom I could ask technical questions. The majority of the learning was individual, but someone was always there to answer my questions. I had to take a couple of Databricks exams. Before being assigned to my first client, I had an internal interview with one of the most seasoned engineers to assess my knowledge. Fortunately, another senior engineer helped me rehearse the topics before, so I passed and also learned from it.”
What does your current role look like as a data engineer? In what ways is it similar or different from your previous roles?
“I usually work for one client at a time. Projects tend to span from 1 week to several months. I am currently working in a team augmentation setup with the client’s engineers on a day-to-day basis, but I also try to live up to the consulting mindset of proposing new ideas to optimize their way of working. In this particular case, I am implementing a DR solution for the client. This involves creating CI/CD pipelines, Python notebooks using the Databricks SDK. I also had a project where I had to deliver a POC of a migration case from Dremio to Databricks, which took about 1.5 months for two people, where we successfully demonstrated feasibility. But I think the most rewarding projects are the 1 week jumpstart projects with new Databricks clients. In those, we can give tons of new information and best practices in the form of virtual calls and demos to the client.”

What would you say to other senior Java developers who are curious about data engineering but unsure if they can make the shift?
“Motivation and growth mindset are the key. If you are interested enough in data engineering and have the will to learn, transitioning will not be very difficult but rather rewarding. Having the chance of learning new skills and tools for which you have genuine interest is invaluable. Some people are afraid of change therefore never try new things. Others trust themselves and take the leap. Their reward is doing something new with a fresh mindset and the feeling of accomplishment.”
Pál’s story reminds us that career growth doesn’t always mean switching industries. Sometimes, it means expanding your toolkit and shifting your focus to where your skills can make the biggest impact.
In the current climate, where software engineers are looking for stability, growth, and relevance, data engineering stands out as a path that offers all three. It’s a role built on solid engineering principles, applied to some of the most exciting challenges in modern tech, from powering real-time analytics to laying the groundwork for AI systems.
If you’ve been considering what’s next for you, this might be the time to look beyond the code you already know into the data that’s shaping the future.