Starting from the code
I studied Computer Science and Engineering at Óbuda University in Budapest — a practical programme with a strong focus on embedded systems, networks, and software architecture. During those years I wasn't just studying; I was already writing production code and beginning to understand what separates well-structured software from systems that become expensive to maintain.
My early career was firmly in the code. At dmssupport.de I worked across Java/J2EE and .NET environments, building backend systems for enterprise clients. The work was varied and demanding — integrations, business logic layers, systems that needed to run reliably and be handed off cleanly to teams who hadn't built them. That period gave me a solid appreciation for documentation, for consistent design decisions, and for the cost of cutting corners.
At Blue Byte Systems I continued as a .NET developer, deepening that foundation in a more focused context. Each project reinforced something I still believe: that software quality is mostly a function of how well a team communicates, not just how technically capable the individuals are.
Moving into leadership
The transition from individual contributor to team lead happened at Metergram, where I took on responsibility for an engineering team as a Development Team Lead alongside continued .NET development. This is where my perspective changed in a meaningful way.
Leading a team made visible everything that I had previously taken for granted as a developer — the invisible coordination cost, the difference between a good technical hire and a good team fit, the way an unclear requirement can silently derail two weeks of work. I had to develop new fluency: how to run a meaningful technical interview, how to communicate technical constraints upward without losing the room, how to build a working environment that doesn't require constant management overhead.
I also spent time at Liligo.com earlier in my career as an intern — a useful early exposure to how a product-focused engineering organisation operates and makes technical trade-offs under real commercial pressure.
Teaching as a sharpening tool
In parallel with industry work, I lectured at Óbuda University — teaching embedded systems and engineering subjects to undergraduate students. Teaching is one of the most effective ways I know to test whether you actually understand something. If you can't explain a concept clearly to someone encountering it for the first time, there are probably gaps in your own model.
That experience refined how I communicate technical material to non-technical audiences — a skill that turns out to be at least as important in a business context as it is in a lecture hall.
What I do now
At Proxify, I work as a Client Engineering Manager. My focus is on enterprise clients in the Nordics, DACH, Benelux, and the UK — companies that are either scaling their engineering capacity or restructuring how they hire technical talent.
The conversations I have are rarely just about finding a developer. They're about understanding what a team is actually trying to build, where the current gaps are, and what kind of technical capability would genuinely move things forward. That requires being able to engage at the level of architecture and engineering process — not just reviewing CVs.
I lead a team of four, which means I'm also still in the business of building teams and developing people — just now on my own side of the table. The eMobility sector in particular has been a recurring focus; it's a space with genuinely complex technical requirements, and matching the right engineering profiles to those needs is a meaningful challenge.
If you're evaluating whether to grow your engineering team, restructure how you hire, or simply want a technical perspective on a hiring decision — I'm happy to talk.