How should the data be distributed? Where can it be retrieved? What constraints need to be built around it? And if the obvious technical solution isn’t available, what can be done instead?
As a senior backend developer at Bankdata, these are often the kinds of questions Jesper works with. Preferably in front of a computer, with time to focus — and according to Jesper, loud techno music doesn’t hurt when there’s a difficult problem to crack.
“I go into solution mode right away,” he says.
That can be an advantage when something is difficult. It can also be a little inconvenient when everyone else in the meeting is still discussing what actually needs to be built.
“I start thinking about how instead of why.”
When the standard solutions doesn't work
As a senior backend developer, Jesper writes code while also helping maintain consistency across the team's codebase. He helps set standards and serves as a sounding board for less experienced developers.
But when he explains what makes the job interesting, problem-solving is what matters most.
“It’s about getting the pieces of the puzzle to fit,” he says. “I like taking over problems that other people have given up on.”
At Bankdata, that sometimes means the most obvious technical route isn’t available. A technology, for example, has to be approved before it can be used. In one project, Jesper’s team therefore couldn’t use the queueing technology that would otherwise have been the simple solution.
Instead, they had to build their own way of receiving, sorting and distributing messages.
Another project required data from a system that normally wasn’t used that way. That made the task about more than code. The team also had to figure out who could provide the necessary access and how the connection could be established.
“That kind of detective work can be pretty fun too,” Jesper says.
It also has to work tomorrow
Jesper primarily works with Java and the part of Bankdata's system landscape that runs on its cloud platform. Here, he sees more technical options, including when solutions need to be monitored or made faster.
He is also involved in modernizing older code and moving functionality away from the mainframe. But the job isn’t only about building something new.
Even the less glamorous tasks have very tangible consequences. The systems have to keep working. People need to be able to receive their salaries and spend their money. If necessary updates aren’t made, operations can ultimately be affected.
That responsibility was also in the back of Jesper’s mind when he chose Bankdata. The fact that Bankdata operates critical infrastructure was one of the things that appealed to him when he was looking for a job in Jutland.
Or, more bluntly: If something goes down, it can end up on the front page of Ekstra Bladet.
First, he took things apart
Jesper's interest in understanding how things work began long before he became a senior backend developer. As a child, he liked taking things apart. Putting them back together wasn't always quite as important.
When he was eight, he and his younger brother got a computer that had to be assembled. Jesper built it together with his father. It showed him that technology wasn’t just something you could take apart. You could also put the pieces together and make something happen.
“You can actually put something together and see it work,” he says.
That curiosity later developed into coding. Around sixth grade, he managed to send out a command that shut down the computers at his school. The purpose was simply to see whether he could do it — while also getting out of some class time.
He also wrote small programs to prank his father. One of them made the computer’s CD drive open when his father used the computer. Jesper still remembers sitting and waiting for his reaction.
“I was cracking up.”
His original career plan was quite different. For a long time, he expected to follow in his father’s footsteps and become an electrician. At boarding school, he was instead encouraged to pursue an upper-secondary education. He later moved to Copenhagen to study, and after about a year, a fellow student helped him land a full-time job as a developer. He continued his education alongside the job.
Curious about technology
Even though computers ended up becoming his profession, Jesper isn't sure that path was inevitable.
“I could just as easily have become a biochemist or something else,” he says.
He describes himself as generally very curious about how things fit together and work. Computers simply became the area where that curiosity really took hold. And it doesn’t necessarily stop when the workday ends.
When there’s time between his kids, family life and practical tasks around the house, Jesper still sits down at the computer to try other programming languages or explore things he doesn’t work with in his day job. It might be building a simple website or digging into what actually happens inside a computer from the moment you press the power button.
Technology is constantly changing, and that is part of what keeps him interested. At the same time, he likes looking back to understand how the same problems were solved before today’s tools were available.
If technology stopped evolving, he thinks the job would quickly become boring. 
“Then we’ll find a solution”
Jesper points out several times that he isn’t alone in approaching problems this way. On his team, he finds that colleagues are quick to tackle problems. Everyone contributes, and he rarely encounters a response that ends with: It can’t be done.
“Then we’ll find a solution,” he says.
That doesn’t mean every solution can turn out exactly as first envisioned. Sometimes 90 percent is enough. Sometimes a technical option gets rejected, and the team has to find another route. But the starting point remains the same.
This is also where Jesper’s own role has changed somewhat over the years. As a senior developer, his job isn’t only to solve problems himself. He also helps create the conditions for others to solve them. In fact, he describes one of the best feelings at work as seeing a colleague succeed at something they have been struggling with.
Still, it’s hard not to see a connection to the eight-year-old who took things apart and the 12-year-old who wanted to see whether he could make every computer at his school shut down.
Today, the consequences are different, and the job is usually the opposite: The systems need to keep running.
But the question is largely the same.
Not whether it can be done. But how.
Are you looking for new challenges? See our open positions here